Pod, ਨੋਡ ਜਾਂ ਕਲਸਟਰ: VPN sidecar ਅਸਲ ਵਿੱਚ ਕੀ ਰੀਰੂਟ ਕਰਦਾ ਹੈ

Kubernetes Pod ਵਿੱਚ VPN sidecar ਹੋਸਟ-ਪੱਧਰੀ VPN ਵਰਗਾ ਦਿਸਦਾ ਹੈ, ਬਿਹਤਰ ਤਰੀਕਿਆਂ ਨਾਲ, ਅਤੇ ਸਮਾਨਤਾ namespace ਦੀ ਹੱਦ 'ਤੇ ਖ਼ਤਮ ਹੋ ਜਾਂਦੀ ਹੈ। ਇੱਕ Pod ਦੇ ਕੰਟੇਨਰ ਪਤੇ ਅਤੇ ਪੋਰਟ ਦੀ ਥਾਂ ਸਮੇਤ ਨੈੱਟਵਰਕ namespace ਸਾਂਝਾ ਕਰਦੇ ਹਨ, ਇਸ ਲਈ ਰੂਟ ਅਤੇ ਨੀਤੀ ਸਥਾਪਿਤ ਕਰਨ ਵਾਲਾ sidecar ਸੱਚਮੁੱਚ ਬਦਲਦਾ ਹੈ ਕਿ ਐਪ ਦੇ ਪੈਕਟ ਕਿੱਥੇ ਜਾਂਦੇ ਹਨ। ਨੋਡ 'ਤੇ ਹੋਰ Pod ਲਈ ਇਹ ਕੁਝ ਨਹੀਂ ਬਦਲਦਾ, ਅਤੇ ਜੇ ਤੁਸੀਂ ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਕੌਂਫਿਗਰ ਨਾ ਕਰੋ ਤਾਂ ਨੋਡ ਦੇ ਆਪਣੇ ਸਟੈਕ ਨੂੰ ਵੀ ਨਹੀਂ ਛੂਹਦਾ। ਇਸ ਹੱਦ ਨੂੰ ਸਹੀ ਸਮਝਣਾ ਤੈਅ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਕੀ ਤੈਨਾਤ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਕੀ ਪਰਖਣਾ ਪਵੇਗਾ। ਹੇਠਾਂ ਦਿੱਤੇ ਭਾਗ ਇਸ ਨੂੰ namespace ਤੋਂ ਬਾਹਰ ਵੱਲ ਪਿੱਛਾ ਕਰਦੇ ਹਨ।

ਸਾਂਝਾ namespace, ਸਾਂਝੇ ਨਤੀਜੇ

ਇੱਕ Pod ਦੇ ਦੋ ਕੰਟੇਨਰ loopback ਰਾਹੀਂ ਗੱਲ ਕਰਦੇ ਹਨ ਅਤੇ ਉਹੀ ਇੰਟਰਫ਼ੇਸ ਦੇਖਦੇ ਹਨ, ਅਤੇ ਇਸੇ ਕਰਕੇ sidecar ਪੈਟਰਨ ਕੰਮ ਕਰਦਾ ਹੈ: ਐਪ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਕਿ ਟਨਲ ਹੈ, ਕਿਉਂਕਿ ਜਿਸ ਰੂਟ 'ਤੇ ਇਹ ਪਹੁੰਚਦਾ ਹੈ ਉਹ ਉਸ namespace ਵਿੱਚ ਸਥਾਪਿਤ ਹੋਇਆ ਸੀ ਜੋ ਇਹ ਵਰਤਦਾ ਹੈ। ਇਹੀ ਗੁਣ ਦੱਸਦਾ ਹੈ ਕਿ sidecar ਦੀਆਂ ਗਲਤੀਆਂ ਐਪ ਦੀਆਂ ਗਲਤੀਆਂ ਹਨ। ਜੋ ਰੂਟ ਬਹੁਤ ਜ਼ਿਆਦਾ ਫੜ ਲਵੇ, ਜਾਂ ਜੋ DNS ਬਦਲਾਅ ਟਨਲ ਅੰਦਰਲੇ ਰਿਜ਼ੌਲਵਰ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੇ, ਉਹ ਉਸ Pod ਦੇ ਹਰ ਪ੍ਰੋਸੈਸ 'ਤੇ ਤੁਰੰਤ ਲਾਗੂ ਹੁੰਦਾ ਹੈ। ਸਾਂਝੇ namespace ਵਿੱਚ ਕੰਟੇਨਰ-ਵਾਰ ਰਾਊਟਿੰਗ ਨਹੀਂ ਹੁੰਦੀ, ਇਸ ਲਈ sidecar ਨੂੰ ਇੱਕ ਪ੍ਰੋਸੈਸ ਤੱਕ ਸੀਮਿਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ।

ਸਮੀਖਿਆ ਵੇਲੇ ਯਾਦ ਰੱਖਣ ਵਾਲਾ ਢੰਗ ਇਹੀ ਹੈ: ਅਸਰ ਦਾ ਘੇਰਾ Pod ਹੈ, ਨਾ ਨੋਡ ਅਤੇ ਨਾ ਕਲਸਟਰ।

sidecar ਕਿੱਥੇ ਨਹੀਂ ਪਹੁੰਚਦਾ

ਹੋਰ Pod ਆਪਣੇ namespace ਅਤੇ ਆਪਣੀ ਰਾਊਟਿੰਗ ਰੱਖਦੇ ਹਨ, ਇਸ ਲਈ ਉਹੀ ਈਗ੍ਰੈਸ ਚਾਹੁਣ ਵਾਲੇ ਵਰਕਲੋਡ ਨੂੰ ਉਹੀ sidecar ਜਾਂ ਇਸ ਦੀ ਥਾਂ ਨੋਡ-ਪੱਧਰੀ ਡਿਜ਼ਾਈਨ ਚਾਹੀਦਾ ਹੈ। ਨੋਡ ਦਾ ਟ੍ਰੈਫਿਕ ਵੀ Pod namespace ਤੋਂ ਬਾਹਰ ਹੈ, ਅਤੇ ਹੋਸਟ ਨੈੱਟਵਰਕ ਵਾਲੇ Pod ਜਾਣ-ਬੁੱਝ ਕੇ ਇਸ ਵਿਛੋੜੇ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਛੱਡ ਦਿੰਦੇ ਹਨ। ਜੇ ਤੁਸੀਂ ਕੋਈ ਸੁਵਿਧਾਜਨਕ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚਣ ਲਈ sidecar ਨੂੰ ਹੋਸਟ ਨੈੱਟਵਰਕਿੰਗ ਨਾਲ ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਘੇਰਾ ਇੱਕ Pod ਤੋਂ ਪੂਰੇ ਨੋਡ ਤੱਕ ਵਧਾ ਦਿੱਤਾ ਹੈ ਅਤੇ ਇਹ ਉੱਚੀ ਆਵਾਜ਼ ਵਿੱਚ ਕਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।

ਕਲਸਟਰ ਸੇਵਾਵਾਂ ਵੱਲ ਟ੍ਰੈਫਿਕ ਦੂਜਾ ਆਮ ਹੈਰਾਨੀ ਵਾਲਾ ਪੱਖ ਹੈ। Pod ਅੰਦਰ ਚੌੜਾ ਡਿਫ਼ਾਲਟ ਰੂਟ API ਸਰਵਰ ਜਾਂ ClusterIP ਸੇਵਾ ਲਈ ਭੇਜੀਆਂ ਬੇਨਤੀਆਂ ਫੜ ਸਕਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਉਹ ਇੰਝ ਫੇਲ੍ਹ ਹੁੰਦੀਆਂ ਹਨ ਜਿਵੇਂ ਟਨਲ ਟੁੱਟਾ ਹੋਵੇ।

ਰੂਟ ਯੋਜਨਾ: Pod, ਸੇਵਾ, ਨੋਡ ਅਤੇ VPN ਰੇਂਜਾਂ

ਚਾਰੇ ਰੇਂਜ ਲਿਖੋ ਅਤੇ ਕੁਝ ਵੀ ਤੈਨਾਤ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਓਵਰਲੈਪ ਜਾਂਚੋ: Pod CIDR, ਸੇਵਾ CIDR, ਨੋਡ ਦੇ ਪਤੇ ਅਤੇ VPN ਪਿੱਛੇ ਦੀਆਂ ਮੰਤਵ-ਥਾਵਾਂ। VPN ਦੀਆਂ ਨਿੱਜੀ ਰੇਂਜਾਂ ਅਤੇ ਕਲਸਟਰ ਦੀ ਆਪਣੀ ਥਾਂ ਵਿਚਕਾਰ ਓਵਰਲੈਪ ਦੁਰਲੱਭ ਨਹੀਂ, ਅਤੇ ਡਿਫ਼ਾਲਟ ਰੂਟ ਇਸ ਲਈ ਗਲਤ ਹੱਲ ਹੈ। ਰੂਟ ਯੋਜਨਾ ਮੈਨੀਫ਼ੈਸਟ ਵਾਲੀ ਉਸੇ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ, ਕਿਉਂਕਿ ਅਗਲਾ ਕਲਸਟਰ ਬਿਲਕੁਲ ਵੱਖਰੀਆਂ Pod ਅਤੇ ਸੇਵਾ ਰੇਂਜਾਂ ਦੇ ਸਕਦਾ ਹੈ।

DNS ਯੋਜਨਾ ਦਾ ਹਿੱਸਾ ਹੈ, ਵੱਖਰੀ ਚਿੰਤਾ ਨਹੀਂ। ਰਿਜ਼ੌਲਵਰ ਕੌਂਫਿਗਰੇਸ਼ਨ ਮੁੜ ਲਿਖਣ ਵਾਲਾ sidecar ਕਲਸਟਰ ਅੰਦਰ ਸੇਵਾ ਖੋਜ ਤੋੜ ਸਕਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਬਾਹਰੀ ਖੋਜ ਬਿਲਕੁਲ ਠੀਕ ਚੱਲਦੀ ਰਹਿੰਦੀ ਹੈ।

ਸ਼ੁਰੂਆਤ ਅਤੇ ਫੇਲ੍ਹ ਹੋਣਾ ਸਪਸ਼ਟ ਅਵਸਥਾਵਾਂ ਹਨ

ਚੱਲ ਰਿਹਾ sidecar ਪ੍ਰੋਸੈਸ ਈਗ੍ਰੈਸ ਨੀਤੀ ਨਹੀਂ ਹੈ। ਟਨਲ ਤਿਆਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕਿਹੜਾ ਟ੍ਰੈਫਿਕ ਵਹਿ ਸਕਦਾ ਹੈ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਇਹ ਮਰ ਜਾਵੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਇਹ ਤੈਅ ਕਰੋ, ਫਿਰ ਉਹ ਫ਼ੈਸਲਾ ਲਾਗੂ ਕਰੋ: ਐਪ ਕੰਟੇਨਰ ਨੂੰ ਗੇਟ ਕਰਨ ਵਾਲੀ ਪ੍ਰੋਬ, ਡਿਫ਼ਾਲਟ ਤੌਰ 'ਤੇ ਇਨਕਾਰ ਕਰਨ ਵਾਲੀ ਨੈੱਟਵਰਕ ਨੀਤੀ, ਜਾਂ ਦੋਵੇਂ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵੀ ਨਾ ਹੋਵੇ ਤਾਂ ਐਪ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਟਨਲ ਦੇ ਅਜੇ ਜੁੜਦਿਆਂ ਹੀ ਟ੍ਰੈਫਿਕ ਨੋਡ ਦੇ ਆਮ ਰਾਹ ਤੋਂ ਬਾਹਰ ਭੇਜਦਾ ਹੈ।

ਇਹ ਖੱਪਾ ਸਿਹਤਮੰਦ ਕਲਸਟਰ ਵਿੱਚ ਛੋਟਾ ਅਤੇ ਟੁੱਟੇ ਕਲਸਟਰ ਵਿੱਚ ਪੱਕਾ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਹਮਲਾਵਰ ਜਾਂ ਅਚਾਨਕ ਡੇਟਾ ਲੀਕ ਨੂੰ ਇਹੀ ਗੁਣ ਪਸੰਦ ਹੈ।

ਕ੍ਰਮ ਨੂੰ ਫੇਲ੍ਹ ਹੋਣ ਦੀ ਜਾਂਚ ਨਾਲ ਜੋੜੋ। sidecar ਮਾਰੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਐਪ ਚੁੱਪਚਾਪ ਪਿੱਛੇ ਹਟਣ ਦੀ ਬਜਾਏ ਆਪਣਾ ਇੱਛਤ ਈਗ੍ਰੈਸ ਗੁਆ ਦਿੰਦਾ ਹੈ।

ਸਮਰੱਥਾਵਾਂ, ਨੀਤੀਆਂ ਅਤੇ ਐਪ ਕੰਟੇਨਰ ਤੋਂ ਜਾਂਚ

ਇੰਟਰਫ਼ੇਸ ਬਣਾਉਣ ਅਤੇ ਰੂਟ ਬਦਲਣ ਲਈ ਲੋੜੀਂਦੀਆਂ ਸਮਰੱਥਾਵਾਂ ਦੇਣਾ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਦਾ ਫ਼ੈਸਲਾ ਹੈ, ਅਤੇ ਅਲੱਗ ਕੀਤੇ Pod ਲਈ ਢੁਕਵਾਂ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਨੋਡ ਸਟੈਕ 'ਤੇ ਆਪਣੇ ਆਪ ਢੁਕਵਾਂ ਨਹੀਂ ਹੁੰਦਾ। ਕਲਸਟਰ ਵੱਲੋਂ ਸਮਰਥਿਤ ਨੈੱਟਵਰਕ ਅਤੇ ਸੁਰੱਖਿਆ ਨੀਤੀ ਦੇ ਢੰਗ ਵਰਤੋ, ਅਤੇ ਇਹ ਨਾ ਮੰਨੋ ਕਿ ਹਰ CNI ਜਾਂ ਨੀਤੀ ਲਾਗੂਆਂ VPN ਇੰਟਰਫ਼ੇਸ ਨੂੰ ਇੱਕੋ ਜਿਹਾ ਮੰਨਦਾ ਹੈ; ਫ਼ਰਕ ਉਹਨਾਂ ਹੀ ਫੇਲ੍ਹ ਹੋਣ ਦੇ ਕੇਸਾਂ ਵਿੱਚ ਦਿਸਦੇ ਹਨ ਜੋ ਤੁਹਾਡੇ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹਨ।

ਅਸਲ ਐਪ ਕੰਟੇਨਰ ਤੋਂ ਜਾਂਚ ਕਰੋ, ਨਿੱਜੀ ਮੰਤਵ-ਥਾਂ, ਕਲਸਟਰ ਸੇਵਾ ਅਤੇ ਜਨਤਕ ਇੰਟਰਨੈੱਟ 'ਤੇ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ। sidecar ਤੋਂ ਕੀਤੀ ਜਾਂਚ ਸਾਬਤ ਕਰਦੀ ਹੈ ਕਿ ਟਨਲ ਕੰਮ ਕਰਦਾ ਹੈ, ਇਹ ਨਹੀਂ ਕਿ ਐਪ ਨੂੰ ਲੋੜੀਂਦੀ ਚੀਜ਼ ਤੱਕ ਪਹੁੰਚ ਹੈ।

VPN ਕੌਂਫਿਗਰੇਸ਼ਨ ਦੇ ਕੋਲ ਕਲਸਟਰ ਦੀਆਂ ਨੈੱਟਵਰਕ ਧਾਰਨਾਵਾਂ ਦਸਤਾਵੇਜ਼ ਕਰੋ। ਫਿਰ ਵਰਕਲੋਡ ਨੂੰ ਹੋਰ ਕਲਸਟਰ ਵਿੱਚ ਲਿਜਾਣਾ ਚੁੱਪਚਾਪ ਕੰਮ ਕਰਨਾ ਬੰਦ ਕਰਨ ਵਾਲੇ ਇਮੇਜ ਬਦਲਾਅ ਦੀ ਬਜਾਏ ਰੂਟ ਯੋਜਨਾ ਜਾਂਚਣ ਦਾ ਅਭਿਆਸ ਬਣ ਜਾਂਦਾ ਹੈ।