VPN ਵਰਤੋਂਕਾਰਾਂ ਲਈ Pod IP, ClusterIP ਜਾਂ ਅੰਦਰੂਨੀ ਲੋਡ ਬੈਲੇਂਸਰ
Pod ਬਦਲਣ ਤੱਕ Pod IP VPN ਰਾਹੀਂ ਰੂਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਸਿੱਧੀ Pod ਪਹੁੰਚ, ClusterIP ਅਤੇ ਅੰਦਰੂਨੀ ਬੈਲੇਂਸਰ ਦੀ ਤੁਲਨਾ ਕਰੋ, ਅਤੇ ਹਰ ਇੱਕ ਦੀ ਲਾਗਤ ਕੀ ਹੈ।
VPC CNI ਨਾਲ Pod VPC ਤੋਂ ਪਤਾ ਲੈ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਹੀ ਰੂਟ ਵਾਲਾ VPN ਵਰਤੋਂਕਾਰ ਸਿੱਧਾ ਉਸ ਤੱਕ ਪਹੁੰਚ ਸਕਦਾ ਹੈ। ਇਸ ਲਈ ਸਿੱਧੀ Pod ਪਹੁੰਚ ਸਭ ਤੋਂ ਸੌਖਾ ਵਿਕਲਪ ਲੱਗਦੀ ਹੈ, ਅਤੇ Pod ਬਦਲਣ ਤੱਕ ਇਹ ਸੱਚ ਹੈ। ਵਰਤੋਂਕਾਰ ਜੋ ਪਤਾ ਯਾਦ ਰੱਖਦਾ ਹੈ ਉਹ ਐਪਲੀਕੇਸ਼ਨ ਦਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਕਿਸੇ ਪ੍ਰਤੀਰੂਪ ਦਾ ਨਹੀਂ। ਤਿੰਨਾਂ ਪ੍ਰਵੇਸ਼ਾਂ ਦੀ ਤੁਲਨਾ ਆਖਰਕਾਰ ਇਸ ਗੱਲ ’ਤੇ ਆਉਂਦੀ ਹੈ ਕਿ ਪਤਾ ਕਿਸ ਵਸਤੂ ਦਾ ਹੈ ਅਤੇ ਵਰਕਲੋਡ ਖਿਸਕਣ ’ਤੇ ਕੀ ਚੱਲਦਾ ਰਹਿਣਾ ਚਾਹੀਦਾ ਹੈ।
ਪਹਿਲਾਂ ਜੀਵਨ-ਚੱਕਰ ਅਨੁਸਾਰ ਚੁਣੋ, ਫਿਰ ਪ੍ਰਵੇਸ਼ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਣ ਲਈ ਨੈੱਟਵਰਕ ਨੂੰ ਕੀ ਕਰਨਾ ਹੈ ਦੇ ਅਨੁਸਾਰ।
ਤਿੰਨ ਪ੍ਰਵੇਸ਼, ਤਿੰਨ ਜੀਵਨ-ਚੱਕਰ
Pod IP ਦੀ ਮਾਲਕੀ Pod ਕੋਲ ਹੁੰਦੀ ਹੈ: ਇਹ ਉਸ ਨਾਲ ਹੀ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ ਦੇ ਖਤਮ ਹੋਣ ’ਤੇ ਛੱਡ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ClusterIP ਦੀ ਮਾਲਕੀ Service ਕੋਲ ਹੁੰਦੀ ਹੈ ਅਤੇ ਇਹ ਵਰਚੁਅਲ ਹੈ, ਇਸ ਦਾ ਅਰਥ ਸਿਰਫ਼ ਉੱਥੇ ਹੈ ਜਿੱਥੇ ਕਲਸਟਰ ਦੀ ਸੇਵਾ ਰੂਟਿੰਗ ਮੌਜੂਦ ਹੈ। ਅੰਦਰੂਨੀ ਲੋਡ ਬੈਲੇਂਸਰ ਦੀ ਮਾਲਕੀ ਇੱਕ ਕਲਾਊਡ ਸਰੋਤ ਕੋਲ ਹੁੰਦੀ ਹੈ ਜਿਸ ਨੂੰ ਕਲਸਟਰ ਦਾ ਨਿਯੰਤਰਕ ਬੈਕਐਂਡ ਨਾਲ ਪ੍ਰੋਗਰਾਮ ਕਰਦਾ ਹੈ। ਇਹ ਮਾਲਕੀ ਮਾਡਲ ਪਹਿਲਾਂ ਹੀ ਦੱਸ ਦਿੰਦੇ ਹਨ ਕਿ ਤੁਹਾਨੂੰ ਕੀ ਨਾਕਾਮੀ ਮਿਲੇਗੀ: ਪੁਰਾਣਾ ਪਤਾ, ਪਹੁੰਚ ਤੋਂ ਬਾਹਰ ਨਾਮ, ਜਾਂ ਪੁਰਾਣਾ ਬੈਕਐਂਡ ਸਮੂਹ।
ਚੁਣਨ ਤੋਂ ਪਹਿਲਾਂ ਤੁਲਨਾ ਲਿਖੋ। ਮਾਲਕ ਅਤੇ ਨਾਕਾਮੀ ਦਾ ਨਾਮ ਆ ਜਾਣ ਤੋਂ ਬਾਅਦ ਚੋਣ ਆਮ ਤੌਰ ’ਤੇ ਆਪਣੇ ਆਪ ਹੋ ਜਾਂਦੀ ਹੈ।
| Entry | Owner | Failure when the workload moves |
|---|---|---|
| Pod IP | The Pod | Address changes and saved links break |
| ClusterIP | The Service | Virtual address with no meaning outside cluster routing |
| Internal balancer | Cloud resource plus controller | Backends update, but the DNS view is yours to maintain |
ਸਿੱਧੀ Pod ਪਹੁੰਚ: ਲਾਹੇਵੰਦ, ਅਸਥਾਈ
ਨਿਯੰਤਰਿਤ ਜਾਂਚ ਲਈ ਸਿੱਧੀ ਪਹੁੰਚ ਸੱਚਮੁੱਚ ਲਾਹੇਵੰਦ ਹੈ: ਇੱਕ ਪ੍ਰਬੰਧਕ, ਇੱਕ ਛੋਟਾ ਸੈਸ਼ਨ, ਇੱਕ ਖਾਸ ਪੋਰਟ। ਪਰ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਇਹ ਮਾੜਾ ਸਮਝੌਤਾ ਹੈ, ਕਿਉਂਕਿ ਪਤਾ ਲਾਗੂ ਕਰਨ ਦੀ ਵਿਸਤ੍ਰਿਤ ਹੈ ਜੋ ਹਰ ਤੈਨਾਤੀ ’ਤੇ ਬਦਲਦੀ ਹੈ। ਅਤੇ ਇਸ ਨੂੰ ਵਿਕੀ ਵਿੱਚ ਲਿਖਣਾ ਹੀ ਉਹ ਰਾਹ ਹੈ ਜਿਸ ਨਾਲ ਚੱਲਦੀ ਸੇਵਾ ਅਫ਼ਵਾਹ ਬਣ ਜਾਂਦੀ ਹੈ।
ਇਹ ਖੁੱਲ੍ਹੇ ਨਿਯਮਾਂ ਨੂੰ ਵੀ ਸੱਦਾ ਦਿੰਦਾ ਹੈ। ਇੱਕ ਪ੍ਰਬੰਧਕ ਨੂੰ ਇੱਕ Pod ਤੱਕ ਪਹੁੰਚਣ ਦੀ ਇਜਾਜ਼ਤ ਨੋਡ ਸਬਨੈੱਟ ਦੇ ਹਰ ਪਤੇ ਲਈ ਇਜਾਜ਼ਤ ਨਹੀਂ ਹੈ, ਅਤੇ ਆਮ ਤੌਰ ’ਤੇ ਦੂਜਾ ਹੀ ਲਿਖਿਆ ਜਾਂਦਾ ਹੈ।
ClusterIP: ਡਿਜ਼ਾਈਨ ਅਨੁਸਾਰ ਕਲਸਟਰ ਤੱਕ ਸੀਮਿਤ
ClusterIP ਕੰਮ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਕਲਸਟਰ ਦਾ ਡੇਟਾਪਲੇਨ ਇਸ ਲਈ ਕਲਸਟਰ ਦੇ ਅੰਦਰ ਰੂਟਿੰਗ ਪ੍ਰੋਗਰਾਮ ਕਰਦਾ ਹੈ। VPN ’ਤੇ ਲੈਪਟਾਪ ਤੋਂ ਪਤੇ ਦਾ ਕੋਈ ਅਰਥ ਨਹੀਂ, ਜਦ ਤੱਕ ਕੋਈ ਇਸ ਨੂੰ ਜਾਣ-ਬੁੱਝ ਕੇ ਜ਼ਾਹਰ ਨਾ ਕਰੇ। svc.cluster.local ’ਤੇ ਖਤਮ ਹੋਣ ਵਾਲਾ ਨਾਮ ਕਲਸਟਰ DNS ਦਾ ਹੈ, ਇਸ ਲਈ ਇਸ ਨੂੰ ਹੋਰ ਰਿਜ਼ੋਲਵਰ ਵਾਲੇ ਕਲਾਇੰਟ ’ਤੇ ਕਾਪੀ ਕਰਨ ਨਾਲ ਰੂਟਿੰਗ ਗਲਤੀ ਦੀ ਥਾਂ ਨਾ-ਮੌਜੂਦ ਨਾਮ ਮਿਲਦਾ ਹੈ।
ਕਲਸਟਰ ਦੇ ਅੰਦਰਲੇ ਕਾਲ ਕਰਨ ਵਾਲਿਆਂ ਲਈ, ਹੋਰ ਵਰਕਲੋਡਾਂ ਸਮੇਤ, ClusterIP ਸਹੀ ਪ੍ਰਵੇਸ਼ ਹੀ ਰਹਿੰਦਾ ਹੈ। ਇਹ ਸਿਰਫ਼ ਕਲਸਟਰ ਦੇ ਰੂਟਿੰਗ ਡੋਮੇਨ ਤੋਂ ਬਾਹਰਲੇ ਵਰਤੋਂਕਾਰਾਂ ਲਈ ਪ੍ਰਕਾਸ਼ਨ ਵਿਵਸਥਾ ਨਹੀਂ ਹੈ।
ਅੰਦਰੂਨੀ ਲੋਡ ਬੈਲੇਂਸਰ: ਪ੍ਰਕਾਸ਼ਿਤ ਮਾਰਗ
ਅੰਦਰੂਨੀ ਲੋਡ ਬੈਲੇਂਸਰ ਤੁਹਾਨੂੰ ਸਥਿਰ ਨਿੱਜੀ ਪਤਾ ਅਤੇ ਅਜਿਹਾ ਨਾਮ ਦਿੰਦਾ ਹੈ ਜਿਸ ਵੱਲ ਤੁਹਾਡਾ ਜ਼ੋਨ ਇਸ਼ਾਰਾ ਕਰ ਸਕਦਾ ਹੈ, ਜਦ ਕਿ ਨਿਯੰਤਰਕ ਬੈਕਐਂਡ ਸਮੂਹ ਨੂੰ ਅਦਿਆਤਨ ਰੱਖਦਾ ਹੈ, ਜਿਵੇਂ EKS ਲੋਡ-ਬੈਲੈਂਸਿੰਗ ਗਾਈਡ ਦੱਸਦੀ ਹੈ। ਇਹੀ ਉਹ ਪ੍ਰਵੇਸ਼ ਹੈ ਜੋ ਕਿਸੇ ਵੱਲੋਂ ਦਸਤਾਵੇਜ਼ ਸੋਧੇ ਬਿਨਾਂ ਆਮ Pod ਬਦਲੀ ਵਿੱਚ ਵੀ ਟਿਕਦਾ ਹੈ। ਇਸ ਦੀ ਲਾਗਤ ਇੱਕ ਕਲਾਊਡ ਸਰੋਤ, ਨਿਯੰਤਰਕ ਸੰਰਚਨਾ ਅਤੇ VPN ਤੋਂ ਇੱਕ ਰੂਟ ਹੈ, ਅਤੇ ਲੋਕ ਇਹਨਾਂ ਹਿੱਸਿਆਂ ਨੂੰ ਹੀ ਘੱਟ ਸਮਝਦੇ ਹਨ।
ਕਲਸਟਰ ਅਸਲ ਵਿੱਚ ਜੋ ਨਿਯੰਤਰਕ ਮਾਡਲ ਚਲਾਉਂਦਾ ਹੈ ਉਹੀ ਵਰਤੋ। ਇੱਕ ਏਕੀਕਰਨ ਲਈ ਲਿਖੀਆਂ ਟਿੱਪਣੀਆਂ ਦੂਜੇ ’ਤੇ ਲਾਗੂ ਨਹੀਂ ਹੁੰਦੀਆਂ।
ਸਰੋਤ ਪਤਾ ਕੌਣ ਹੈ
ਸੁਰੱਖਿਆ ਸਮੂਹ ਆਪਣੀ ਸੀਮਾ ’ਤੇ ਆਉਂਦੇ ਸਰੋਤ ਨੂੰ ਦੇਖਦੇ ਹਨ, ਅਤੇ ਇਹ VPN ਅਤੇ ਲੋਡ-ਬੈਲੈਂਸਿੰਗ ਮਾਰਗ ਦੇ ਆਧਾਰ ’ਤੇ ਜੁੜਿਆ ਕਲਾਇੰਟ ਜਾਂ ਅਨੁਵਾਦਿਤ ਪਤਾ ਹੋ ਸਕਦਾ ਹੈ। EC2 ਅਧਾਰਿਤ ਨੋਡਾਂ ’ਤੇ, ਆਮ VPC CNI Pod ਡਿਫਾਲਟ ਰੂਪ ਵਿੱਚ ਨੋਡ ਦੇ ENI ਸਮੂਹ ਵਿਰਾਸਤ ਵਿੱਚ ਲੈਂਦੇ ਹਨ, ਜਦ ਕਿ ਸਮਰਥਿਤ ਸੰਰਚਨਾਵਾਂ Pod-ਖਾਸ ਸਮੂਹ ਜੋੜ ਸਕਦੀਆਂ ਹਨ। ਅਨੁਮਾਨਿਤ ਲੈਪਟਾਪ ਪਤੇ ਲਈ ਨਹੀਂ, ਦਸਤਾਵੇਜ਼ੀ ਮਾਰਗ ਲਈ ਨਿਯਮ ਲਿਖੋ।
ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਆਪਣੇ ਸਰੋਤਾ ਅਤੇ ਪ੍ਰਮਾਣਿਕਤਾ ਨੂੰ ਵੱਖਰੇ ਨਿਯੰਤਰਣ ਵਜੋਂ ਰੱਖੋ। ਪ੍ਰਵਾਹ ਦੀ ਇਜਾਜ਼ਤ ਦੇਣ ਵਾਲਾ ਨੈੱਟਵਰਕ ਨਿਯਮ ਅਧਿਕਾਰ ਦਾ ਫੈਸਲਾ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਇਸ ਤਰ੍ਹਾਂ ਨਹੀਂ ਮੰਨਿਆ ਜਾਣਾ ਚਾਹੀਦਾ।
ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਕੀ ਦੇਣਾ ਹੈ
ਵਰਤੋਂਕਾਰਾਂ ਨੂੰ ਪਤਾ ਨਹੀਂ, ਸੇਵਾ ਦਾ ਨਾਮ ਦਿਓ। ਨਾਮ ਨਿੱਜੀ ਜ਼ੋਨ ਵਿੱਚ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰੋ, ਇਸ ਨੂੰ ਅੰਦਰੂਨੀ ਪ੍ਰਵੇਸ਼ ਵੱਲ ਇਸ਼ਾਰਾ ਕਰੋ, ਅਤੇ ਫਿਰ ਬੈਕਐਂਡ Pod ਬਦਲ ਕੇ ਪਰਖੋ ਜਦ ਕਿ ਕਲਾਇੰਟ ਉਹੀ ਨਾਮ ਖੁੱਲ੍ਹਾ ਰੱਖੇ। ਇਹ ਅਭਿਆਸ ਉਸ ਗੁਣ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਜੋ ਮਹੱਤਵਪੂਰਨ ਹੈ: ਨਿਯਮਿਤ ਤੈਨਾਤੀ ਤੋਂ ਬਾਅਦ ਵੀ ਉਸੇ ਐਪਲੀਕੇਸ਼ਨ ਤੱਕ ਪਹੁੰਚਣਾ।
ਸਿੱਧੀ Pod ਪਹੁੰਚ ਨੂੰ ਆਪਣੇ ਦਾਇਰੇ ਵਾਲਾ ਦਸਤਾਵੇਜ਼ੀ ਕਾਰਜਕਾਰੀ ਅਪਵਾਦ ਰੱਖੋ, ਵਰਤੋਂਕਾਰ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਦੂਰ।