🥇ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਦੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਤੁਲਨ ਅਤੇ ਸਕੇਲਿੰਗ ਕਰੋ

ਇਹ ਲੇਖ ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ ਕਿ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੋਡ ਬੈਲੇਂਸਿੰਗ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਲੰਬੇ ਸਮੇਂ ਦੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਕੇਲ ਕਰਨ ਵੇਲੇ ਕੀ ਹੁੰਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਤੁਸੀਂ HTTP/2, gRPC, RSockets, AMQP, ਜਾਂ ਹੋਰ ਲੰਬੇ ਸਮੇਂ ਦੇ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ ਤਾਂ ਤੁਹਾਨੂੰ ਕਲਾਇੰਟ-ਸਾਈਡ ਬੈਲੇਂਸਿੰਗ 'ਤੇ ਕਿਉਂ ਵਿਚਾਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। .

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਟ੍ਰੈਫਿਕ ਨੂੰ ਕਿਵੇਂ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ ਇਸ ਬਾਰੇ ਥੋੜਾ ਜਿਹਾ

ਕੁਬਰਨੇਟਸ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਲਈ ਦੋ ਸੁਵਿਧਾਜਨਕ ਐਬਸਟਰੈਕਸ਼ਨ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ: ਸੇਵਾਵਾਂ ਅਤੇ ਤੈਨਾਤੀਆਂ।

ਤੈਨਾਤੀਆਂ ਇਹ ਦਰਸਾਉਂਦੀਆਂ ਹਨ ਕਿ ਤੁਹਾਡੀ ਅਰਜ਼ੀ ਦੀਆਂ ਕਿੰਨੀਆਂ ਅਤੇ ਕਿੰਨੀਆਂ ਕਾਪੀਆਂ ਕਿਸੇ ਵੀ ਦਿੱਤੇ ਸਮੇਂ 'ਤੇ ਚੱਲਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ। ਹਰੇਕ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਇੱਕ Pod ਵਜੋਂ ਤਾਇਨਾਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਅਤੇ ਇੱਕ IP ਪਤਾ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਸੇਵਾਵਾਂ ਇੱਕ ਲੋਡ ਬੈਲੈਂਸਰ ਦੇ ਕੰਮ ਵਿੱਚ ਸਮਾਨ ਹਨ। ਉਹ ਕਈ ਪੌਡਾਂ ਵਿੱਚ ਆਵਾਜਾਈ ਨੂੰ ਵੰਡਣ ਲਈ ਤਿਆਰ ਕੀਤੇ ਗਏ ਹਨ।

ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਹੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ.

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

ਸੇਵਾਵਾਂ ਨੂੰ IP ਪਤਿਆਂ ਦੇ ਸੰਗ੍ਰਹਿ ਵਜੋਂ ਸੋਚਣਾ ਲਾਭਦਾਇਕ ਹੈ। ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰਦੇ ਹੋ, ਤਾਂ ਸੂਚੀ ਵਿੱਚੋਂ ਇੱਕ IP ਪਤੇ ਚੁਣੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਮੰਜ਼ਿਲ ਪਤੇ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ.

ਸੇਵਾ ਨੂੰ ਇੱਕ ਕਰਲ 10.96.45.152 ਬੇਨਤੀ ਪ੍ਰਾਪਤ ਹੋਈ ਹੈ:
ਸੇਵਾ ਆਪਣੀ ਮੰਜ਼ਿਲ ਵਜੋਂ ਤਿੰਨ ਪੌਡ ਪਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ:
ਟ੍ਰੈਫਿਕ ਨੂੰ ਇੱਕ ਖਾਸ ਪੌਡ ਤੇ ਰੀਡਾਇਰੈਕਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ:

ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਵਿੱਚ ਇੱਕ ਫਰੰਟਐਂਡ ਅਤੇ ਇੱਕ ਬੈਕਐਂਡ ਹੈ, ਤਾਂ ਤੁਹਾਡੇ ਕੋਲ ਹਰੇਕ ਲਈ ਇੱਕ ਸੇਵਾ ਅਤੇ ਇੱਕ ਤੈਨਾਤੀ ਦੋਵੇਂ ਹੋਣਗੇ।

ਜਦੋਂ ਫਰੰਟਐਂਡ ਬੈਕਐਂਡ ਨੂੰ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸ ਨੂੰ ਇਹ ਜਾਣਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ ਹੈ ਕਿ ਬੈਕਐਂਡ ਕਿੰਨੇ ਪੌਡਾਂ ਦੀ ਸੇਵਾ ਕਰਦਾ ਹੈ: ਇੱਕ, ਦਸ ਜਾਂ ਸੌ ਹੋ ਸਕਦੇ ਹਨ।

ਨਾਲ ਹੀ, ਫਰੰਟਐਂਡ ਨੂੰ ਬੈਕਐਂਡ ਦੀ ਸੇਵਾ ਕਰਨ ਵਾਲੇ ਪੌਡਾਂ ਦੇ ਪਤਿਆਂ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਪਤਾ।

ਜਦੋਂ ਫਰੰਟਐਂਡ ਬੈਕਐਂਡ ਨੂੰ ਬੇਨਤੀ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਹ ਬੈਕਐਂਡ ਸੇਵਾ ਦੇ IP ਐਡਰੈੱਸ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਜੋ ਬਦਲਦਾ ਨਹੀਂ ਹੈ।

ਇੱਥੇ ਉਹ ਕਿਹੋ ਜਿਹਾ ਦਿੱਸਦਾ ਹੈ.

1 ਦੇ ਤਹਿਤ ਅੰਦਰੂਨੀ ਬੈਕਐਂਡ ਕੰਪੋਨੈਂਟ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਬੈਕਐਂਡ ਲਈ ਇੱਕ ਖਾਸ ਚੁਣਨ ਦੀ ਬਜਾਏ, ਇਹ ਸੇਵਾ ਨੂੰ ਬੇਨਤੀ ਕਰਦਾ ਹੈ:
ਸੇਵਾ ਮੰਜ਼ਿਲ ਪਤੇ ਵਜੋਂ ਬੈਕਐਂਡ ਪੌਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਚੋਣ ਕਰਦੀ ਹੈ:
ਟ੍ਰੈਫਿਕ Pod 1 ਤੋਂ Pod 5 ਤੱਕ ਜਾਂਦਾ ਹੈ, ਸੇਵਾ ਦੁਆਰਾ ਚੁਣਿਆ ਗਿਆ:
ਅੰਡਰ 1 ਨੂੰ ਬਿਲਕੁਲ ਨਹੀਂ ਪਤਾ ਕਿ ਸੇਵਾ ਦੇ ਪਿੱਛੇ 5 ਦੇ ਅਧੀਨ ਕਿੰਨੇ ਪੌਡ ਲੁਕੇ ਹੋਏ ਹਨ:

ਪਰ ਸੇਵਾ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਵੰਡਦੀ ਹੈ? ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਰਾਊਂਡ-ਰੋਬਿਨ ਸੰਤੁਲਨ ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ? ਆਓ ਇਸ ਨੂੰ ਬਾਹਰ ਕੱਢੀਏ।

ਕੁਬਰਨੇਟਸ ਸੇਵਾਵਾਂ ਵਿੱਚ ਸੰਤੁਲਨ ਬਣਾਉਣਾ

ਕੁਬਰਨੇਟਸ ਸੇਵਾਵਾਂ ਮੌਜੂਦ ਨਹੀਂ ਹਨ। ਆਈਪੀ ਐਡਰੈੱਸ ਅਤੇ ਪੋਰਟ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਸੇਵਾ ਲਈ ਕੋਈ ਪ੍ਰਕਿਰਿਆ ਨਹੀਂ ਹੈ।

ਤੁਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਕਿਸੇ ਵੀ ਨੋਡ ਵਿੱਚ ਲਾਗਇਨ ਕਰਕੇ ਅਤੇ netstat -ntlp ਕਮਾਂਡ ਚਲਾ ਕੇ ਇਸਦੀ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ।

ਤੁਸੀਂ ਸੇਵਾ ਲਈ ਨਿਰਧਾਰਤ IP ਪਤਾ ਵੀ ਨਹੀਂ ਲੱਭ ਸਕੋਗੇ।

ਸੇਵਾ ਦਾ IP ਪਤਾ ਕੰਟਰੋਲ ਪਰਤ ਵਿੱਚ ਸਥਿਤ ਹੈ, ਕੰਟਰੋਲਰ ਵਿੱਚ, ਅਤੇ ਡਾਟਾਬੇਸ ਵਿੱਚ ਦਰਜ ਕੀਤਾ ਗਿਆ ਹੈ - etcd. ਉਹੀ ਪਤਾ ਕਿਸੇ ਹੋਰ ਹਿੱਸੇ ਦੁਆਰਾ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ - kube-proxy.
Kube-proxy ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਲਈ IP ਪਤਿਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਨੋਡ 'ਤੇ iptables ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਤਿਆਰ ਕਰਦਾ ਹੈ।

ਇਹ ਨਿਯਮ ਕਹਿੰਦੇ ਹਨ: "ਜੇ ਅਸੀਂ ਸੇਵਾ ਦਾ IP ਪਤਾ ਦੇਖਦੇ ਹਾਂ, ਤਾਂ ਸਾਨੂੰ ਬੇਨਤੀ ਦੇ ਮੰਜ਼ਿਲ ਦੇ ਪਤੇ ਨੂੰ ਸੰਸ਼ੋਧਿਤ ਕਰਨ ਅਤੇ ਇਸਨੂੰ ਕਿਸੇ ਇੱਕ ਪੌਡ 'ਤੇ ਭੇਜਣ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।"

ਸੇਵਾ IP ਐਡਰੈੱਸ ਨੂੰ ਸਿਰਫ਼ ਇੱਕ ਐਂਟਰੀ ਪੁਆਇੰਟ ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਅਤੇ ਉਸ IP ਪਤੇ ਅਤੇ ਪੋਰਟ ਨੂੰ ਸੁਣਨ ਵਾਲੀ ਕਿਸੇ ਵੀ ਪ੍ਰਕਿਰਿਆ ਦੁਆਰਾ ਨਹੀਂ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ।

ਆਓ ਇਸ ਨੂੰ ਦੇਖੀਏ.

ਤਿੰਨ ਨੋਡਾਂ ਦੇ ਕਲੱਸਟਰ 'ਤੇ ਵਿਚਾਰ ਕਰੋ। ਹਰੇਕ ਨੋਡ ਵਿੱਚ ਪੌਡ ਹੁੰਦੇ ਹਨ:
ਟਾਈਡ ਪੌਡ ਪੇਂਟ ਕੀਤੇ ਬੇਜ ਸੇਵਾ ਦਾ ਹਿੱਸਾ ਹਨ। ਕਿਉਂਕਿ ਸੇਵਾ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਵਜੋਂ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਇਸ ਨੂੰ ਸਲੇਟੀ ਵਿੱਚ ਦਿਖਾਇਆ ਗਿਆ ਹੈ:
ਪਹਿਲੀ ਪੋਡ ਇੱਕ ਸੇਵਾ ਲਈ ਬੇਨਤੀ ਕਰਦੀ ਹੈ ਅਤੇ ਉਸ ਨੂੰ ਸੰਬੰਧਿਤ ਪੌਡਾਂ ਵਿੱਚੋਂ ਇੱਕ 'ਤੇ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ:
ਪਰ ਸੇਵਾ ਮੌਜੂਦ ਨਹੀਂ ਹੈ, ਪ੍ਰਕਿਰਿਆ ਮੌਜੂਦ ਨਹੀਂ ਹੈ. ਇਹ ਕਿਵੇਂ ਚਲਦਾ ਹੈ?
ਬੇਨਤੀ ਨੋਡ ਨੂੰ ਛੱਡਣ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ iptables ਨਿਯਮਾਂ ਦੁਆਰਾ ਜਾਂਦੀ ਹੈ:
iptables ਨਿਯਮ ਜਾਣਦੇ ਹਨ ਕਿ ਸੇਵਾ ਮੌਜੂਦ ਨਹੀਂ ਹੈ ਅਤੇ ਇਸਦੇ IP ਪਤੇ ਨੂੰ ਉਸ ਸੇਵਾ ਨਾਲ ਜੁੜੇ ਪੌਡਾਂ ਦੇ IP ਪਤਿਆਂ ਵਿੱਚੋਂ ਇੱਕ ਨਾਲ ਬਦਲੋ:
ਬੇਨਤੀ ਨੂੰ ਮੰਜ਼ਿਲ ਪਤੇ ਵਜੋਂ ਇੱਕ ਵੈਧ IP ਪਤਾ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ ਅਤੇ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰਕਿਰਿਆ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:
ਨੈੱਟਵਰਕ ਟੋਪੋਲੋਜੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਬੇਨਤੀ ਆਖਰਕਾਰ ਪੌਡ ਤੱਕ ਪਹੁੰਚਦੀ ਹੈ:

ਕੀ iptables ਸੰਤੁਲਨ ਲੋਡ ਕਰ ਸਕਦਾ ਹੈ?

ਨਹੀਂ, iptables ਫਿਲਟਰਿੰਗ ਲਈ ਵਰਤੇ ਜਾਂਦੇ ਹਨ ਅਤੇ ਸੰਤੁਲਨ ਲਈ ਤਿਆਰ ਨਹੀਂ ਕੀਤੇ ਗਏ ਸਨ।

ਹਾਲਾਂਕਿ, ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸੈੱਟ ਲਿਖਣਾ ਸੰਭਵ ਹੈ ਜੋ ਕੰਮ ਕਰਦੇ ਹਨ pseudo-balancer.

ਅਤੇ ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜੋ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ.

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਤਿੰਨ ਪੌਡ ਹਨ, ਤਾਂ kube-proxy ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਯਮ ਲਿਖੇਗਾ:

33% ਦੀ ਸੰਭਾਵਨਾ ਦੇ ਨਾਲ ਪਹਿਲੇ ਉਪ ਨੂੰ ਚੁਣੋ, ਨਹੀਂ ਤਾਂ ਅਗਲੇ ਨਿਯਮ 'ਤੇ ਜਾਓ।
50% ਦੀ ਸੰਭਾਵਨਾ ਵਾਲਾ ਦੂਜਾ ਚੁਣੋ, ਨਹੀਂ ਤਾਂ ਅਗਲੇ ਨਿਯਮ 'ਤੇ ਜਾਓ।
ਹੇਠ ਤੀਜੇ ਨੂੰ ਚੁਣੋ.

ਇਸ ਸਿਸਟਮ ਦੇ ਨਤੀਜੇ ਵਜੋਂ ਹਰੇਕ ਪੌਡ ਨੂੰ 33% ਦੀ ਸੰਭਾਵਨਾ ਨਾਲ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ।

ਅਤੇ ਇਸ ਗੱਲ ਦੀ ਕੋਈ ਗਰੰਟੀ ਨਹੀਂ ਹੈ ਕਿ Pod 2 ਨੂੰ Pod 1 ਤੋਂ ਬਾਅਦ ਚੁਣਿਆ ਜਾਵੇਗਾ।

ਟਿੱਪਣੀ: iptables ਬੇਤਰਤੀਬ ਵੰਡ ਦੇ ਨਾਲ ਇੱਕ ਅੰਕੜਾ ਮੋਡੀਊਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਸੰਤੁਲਨ ਐਲਗੋਰਿਦਮ ਬੇਤਰਤੀਬ ਚੋਣ 'ਤੇ ਅਧਾਰਤ ਹੈ।

ਹੁਣ ਜਦੋਂ ਤੁਸੀਂ ਸਮਝ ਗਏ ਹੋ ਕਿ ਸੇਵਾਵਾਂ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਆਓ ਹੋਰ ਦਿਲਚਸਪ ਸੇਵਾ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਵੇਖੀਏ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨ ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ ਮਾਪਦੇ ਨਹੀਂ ਹਨ

ਫਰੰਟਐਂਡ ਤੋਂ ਬੈਕਐਂਡ ਤੱਕ ਹਰੇਕ HTTP ਬੇਨਤੀ ਨੂੰ ਇੱਕ ਵੱਖਰੇ TCP ਕੁਨੈਕਸ਼ਨ ਦੁਆਰਾ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਖੋਲ੍ਹਿਆ ਅਤੇ ਬੰਦ ਹੁੰਦਾ ਹੈ।

ਜੇਕਰ ਫਰੰਟਐਂਡ ਬੈਕਐਂਡ ਨੂੰ ਪ੍ਰਤੀ ਸਕਿੰਟ 100 ਬੇਨਤੀਆਂ ਭੇਜਦਾ ਹੈ, ਤਾਂ 100 ਵੱਖ-ਵੱਖ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੇ ਅਤੇ ਬੰਦ ਕੀਤੇ ਜਾਂਦੇ ਹਨ।

ਤੁਸੀਂ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਕੇ ਅਤੇ ਅਗਲੀਆਂ ਸਾਰੀਆਂ HTTP ਬੇਨਤੀਆਂ ਲਈ ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੇਨਤੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਸਮੇਂ ਅਤੇ ਲੋਡ ਨੂੰ ਘਟਾ ਸਕਦੇ ਹੋ।

HTTP ਪ੍ਰੋਟੋਕੋਲ ਵਿੱਚ ਇੱਕ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ ਜਿਸਨੂੰ HTTP ਕੀਪ-ਲਾਈਵ, ਜਾਂ ਕੁਨੈਕਸ਼ਨ ਮੁੜ ਵਰਤੋਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ। ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਇੱਕ ਸਿੰਗਲ TCP ਕਨੈਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਮਲਟੀਪਲ HTTP ਬੇਨਤੀਆਂ ਅਤੇ ਜਵਾਬਾਂ ਨੂੰ ਭੇਜਣ ਅਤੇ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ:

ਇਹ ਵਿਸ਼ੇਸ਼ਤਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰੱਥ ਨਹੀਂ ਹੈ: ਸਰਵਰ ਅਤੇ ਕਲਾਇੰਟ ਦੋਵਾਂ ਨੂੰ ਉਸੇ ਅਨੁਸਾਰ ਸੰਰਚਿਤ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਗਰਾਮਿੰਗ ਭਾਸ਼ਾਵਾਂ ਅਤੇ ਵਾਤਾਵਰਣਾਂ ਲਈ ਸੈੱਟਅੱਪ ਆਪਣੇ ਆਪ ਵਿੱਚ ਸਧਾਰਨ ਅਤੇ ਪਹੁੰਚਯੋਗ ਹੈ।

ਇੱਥੇ ਵੱਖ-ਵੱਖ ਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਉਦਾਹਰਨਾਂ ਦੇ ਕੁਝ ਲਿੰਕ ਹਨ:

ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਕੁਬਰਨੇਟਸ ਸੇਵਾ ਵਿੱਚ ਕੀਪ-ਲਾਈਵ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਾਂ?
ਚਲੋ ਇਹ ਮੰਨ ਲਓ ਕਿ ਫਰੰਟਐਂਡ ਅਤੇ ਬੈਕਐਂਡ ਦੋਵੇਂ ਸਪੋਰਟ ਕਰਦੇ ਰਹਿੰਦੇ ਹਨ।

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

ਆਮ ਸਥਿਤੀ ਦੇ ਉਲਟ ਜਿੱਥੇ ਜਵਾਬ ਮਿਲਣ ਤੋਂ ਬਾਅਦ TCP ਕੁਨੈਕਸ਼ਨ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਇਸ ਨੂੰ ਹੁਣ ਹੋਰ HTTP ਬੇਨਤੀਆਂ ਲਈ ਖੁੱਲ੍ਹਾ ਰੱਖਿਆ ਗਿਆ ਹੈ।

ਕੀ ਹੁੰਦਾ ਹੈ ਜੇਕਰ ਫਰੰਟਐਂਡ ਬੈਕਐਂਡ ਨੂੰ ਹੋਰ ਬੇਨਤੀਆਂ ਭੇਜਦਾ ਹੈ?

ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਨੂੰ ਅੱਗੇ ਭੇਜਣ ਲਈ, ਇੱਕ ਖੁੱਲਾ TCP ਕਨੈਕਸ਼ਨ ਵਰਤਿਆ ਜਾਵੇਗਾ, ਸਾਰੀਆਂ ਬੇਨਤੀਆਂ ਉਸੇ ਬੈਕਐਂਡ ਵਿੱਚ ਜਾਣਗੀਆਂ ਜਿੱਥੇ ਪਹਿਲੀ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਸੀ।

ਕੀ iptables ਨੂੰ ਟ੍ਰੈਫਿਕ ਦੀ ਮੁੜ ਵੰਡ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ?

ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਨਹੀਂ.

ਜਦੋਂ ਇੱਕ TCP ਕੁਨੈਕਸ਼ਨ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ, ਇਹ iptables ਨਿਯਮਾਂ ਦੁਆਰਾ ਜਾਂਦਾ ਹੈ, ਜੋ ਇੱਕ ਖਾਸ ਬੈਕਐਂਡ ਚੁਣਦਾ ਹੈ ਜਿੱਥੇ ਟ੍ਰੈਫਿਕ ਜਾਵੇਗਾ।

ਕਿਉਂਕਿ ਸਾਰੀਆਂ ਅਗਲੀਆਂ ਬੇਨਤੀਆਂ ਪਹਿਲਾਂ ਹੀ ਖੁੱਲ੍ਹੇ TCP ਕੁਨੈਕਸ਼ਨ 'ਤੇ ਹਨ, ਇਸ ਲਈ iptables ਨਿਯਮਾਂ ਨੂੰ ਹੁਣ ਨਹੀਂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਆਓ ਦੇਖੀਏ ਕਿ ਇਹ ਕਿਹੋ ਜਿਹਾ ਲੱਗਦਾ ਹੈ.

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

ਨਤੀਜਾ ਤੇਜ਼ ਜਵਾਬ ਸਮਾਂ ਅਤੇ ਉੱਚ ਥ੍ਰੋਪੁੱਟ ਹੈ, ਪਰ ਤੁਸੀਂ ਬੈਕਐਂਡ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਯੋਗਤਾ ਗੁਆ ਦਿੰਦੇ ਹੋ।

ਭਾਵੇਂ ਤੁਹਾਡੇ ਕੋਲ ਬੈਕਐਂਡ ਵਿੱਚ ਦੋ ਪੌਡ ਹਨ, ਇੱਕ ਨਿਰੰਤਰ ਕਨੈਕਸ਼ਨ ਦੇ ਨਾਲ, ਟ੍ਰੈਫਿਕ ਹਮੇਸ਼ਾਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਵਿੱਚ ਜਾਵੇਗਾ.

ਕੀ ਇਸ ਨੂੰ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

ਕਿਉਂਕਿ ਕੁਬਰਨੇਟਸ ਇਹ ਨਹੀਂ ਜਾਣਦਾ ਹੈ ਕਿ ਲਗਾਤਾਰ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਕਿਵੇਂ ਸੰਤੁਲਿਤ ਕਰਨਾ ਹੈ, ਇਹ ਕੰਮ ਤੁਹਾਡੇ ਲਈ ਆਉਂਦਾ ਹੈ।

ਸੇਵਾਵਾਂ IP ਪਤਿਆਂ ਅਤੇ ਪੋਰਟਾਂ ਦਾ ਸੰਗ੍ਰਹਿ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਅੰਤਮ ਬਿੰਦੂ ਕਿਹਾ ਜਾਂਦਾ ਹੈ।

ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਸੇਵਾ ਤੋਂ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਇੱਕ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੀ ਹੈ ਅਤੇ ਉਹਨਾਂ ਵਿਚਕਾਰ ਬੇਨਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਵੰਡਣਾ ਹੈ ਇਹ ਫੈਸਲਾ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਸੀਂ ਰਾਊਂਡ-ਰੋਬਿਨ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਹਰੇਕ ਪੌਡ ਲਈ ਇੱਕ ਨਿਰੰਤਰ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ ਅਤੇ ਇਹਨਾਂ ਕਨੈਕਸ਼ਨਾਂ ਵਿਚਕਾਰ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰ ਸਕਦੇ ਹੋ।

ਜਾਂ ਹੋਰ ਲਾਗੂ ਕਰੋ ਗੁੰਝਲਦਾਰ ਸੰਤੁਲਨ ਐਲਗੋਰਿਦਮ.

ਸੰਤੁਲਨ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਕਲਾਇੰਟ-ਸਾਈਡ ਕੋਡ ਨੂੰ ਇਸ ਤਰਕ ਦੀ ਪਾਲਣਾ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ:

ਸੇਵਾ ਤੋਂ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਸੂਚੀ ਪ੍ਰਾਪਤ ਕਰੋ।
ਹਰੇਕ ਅੰਤਮ ਬਿੰਦੂ ਲਈ ਇੱਕ ਨਿਰੰਤਰ ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹੋ।
ਜਦੋਂ ਬੇਨਤੀ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਤਾਂ ਖੁੱਲ੍ਹੇ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚੋਂ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰੋ।
ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਸੂਚੀ ਨੂੰ ਨਿਯਮਿਤ ਤੌਰ 'ਤੇ ਅੱਪਡੇਟ ਕਰੋ, ਨਵੇਂ ਬਣਾਓ ਜਾਂ ਪੁਰਾਣੇ ਸਥਾਈ ਕਨੈਕਸ਼ਨ ਬੰਦ ਕਰੋ ਜੇਕਰ ਸੂਚੀ ਬਦਲਦੀ ਹੈ।

ਇਹ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ.

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

ਹੁਣ ਸਵਾਲ ਉੱਠਦਾ ਹੈ: ਕੀ ਇਹ ਸਮੱਸਿਆ ਸਿਰਫ HTTP ਰੱਖਣ-ਜੀਵਣ 'ਤੇ ਲਾਗੂ ਹੁੰਦੀ ਹੈ?

ਕਲਾਇੰਟ-ਸਾਈਡ ਲੋਡ ਸੰਤੁਲਨ

HTTP ਇੱਕੋ ਇੱਕ ਪ੍ਰੋਟੋਕੋਲ ਨਹੀਂ ਹੈ ਜੋ ਸਥਾਈ TCP ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਡੇਟਾਬੇਸ ਦੀ ਵਰਤੋਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਹਰ ਵਾਰ ਜਦੋਂ ਤੁਹਾਨੂੰ ਡੇਟਾਬੇਸ ਤੋਂ ਇੱਕ ਬੇਨਤੀ ਕਰਨ ਜਾਂ ਦਸਤਾਵੇਜ਼ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਇੱਕ TCP ਕਨੈਕਸ਼ਨ ਨਹੀਂ ਖੋਲ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਇਸਦੀ ਬਜਾਏ, ਡੇਟਾਬੇਸ ਲਈ ਇੱਕ ਨਿਰੰਤਰ TCP ਕਨੈਕਸ਼ਨ ਖੋਲ੍ਹਿਆ ਅਤੇ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

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

ਇੱਕ ਡਾਟਾਬੇਸ ਪ੍ਰਤੀਕ੍ਰਿਤੀ ਦੂਜਿਆਂ ਨਾਲੋਂ ਵਧੇਰੇ ਲੋਡ ਕੀਤੀ ਜਾਵੇਗੀ। Kube-proxy ਅਤੇ Kubernetes ਸੰਤੁਲਨ ਕਨੈਕਸ਼ਨਾਂ ਵਿੱਚ ਮਦਦ ਨਹੀਂ ਕਰਨਗੇ। ਤੁਹਾਨੂੰ ਆਪਣੇ ਡੇਟਾਬੇਸ ਵਿੱਚ ਪ੍ਰਸ਼ਨਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਡਾਟਾਬੇਸ ਨਾਲ ਜੁੜਨ ਲਈ ਤੁਸੀਂ ਕਿਹੜੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਇਸ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ, ਤੁਹਾਡੇ ਕੋਲ ਇਸ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ ਵੱਖ-ਵੱਖ ਵਿਕਲਪ ਹੋ ਸਕਦੇ ਹਨ।

ਹੇਠਾਂ Node.js ਤੋਂ MySQL ਡੇਟਾਬੇਸ ਕਲੱਸਟਰ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ:

var mysql = require('mysql');
var poolCluster = mysql.createPoolCluster();

var endpoints = /* retrieve endpoints from the Service */

for (var [index, endpoint] of endpoints) {
  poolCluster.add(`mysql-replica-${index}`, endpoint);
}

// Make queries to the clustered MySQL database

ਇੱਥੇ ਬਹੁਤ ਸਾਰੇ ਹੋਰ ਪ੍ਰੋਟੋਕੋਲ ਹਨ ਜੋ ਨਿਰੰਤਰ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ:

WebSockets ਅਤੇ ਸੁਰੱਖਿਅਤ WebSockets
HTTP / 2
ਜੀਆਰਪੀਸੀ
RSockets
AMQP

ਤੁਹਾਨੂੰ ਇਹਨਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਪ੍ਰੋਟੋਕੋਲਾਂ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਜਾਣੂ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।

ਪਰ ਜੇ ਇਹ ਪ੍ਰੋਟੋਕੋਲ ਇੰਨੇ ਮਸ਼ਹੂਰ ਹਨ, ਤਾਂ ਇੱਥੇ ਇੱਕ ਪ੍ਰਮਾਣਿਤ ਸੰਤੁਲਨ ਹੱਲ ਕਿਉਂ ਨਹੀਂ ਹੈ? ਕਲਾਇੰਟ ਤਰਕ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਕਿਉਂ ਹੈ? ਕੀ ਕੋਈ ਮੂਲ ਕੁਬਰਨੇਟਸ ਹੱਲ ਹੈ?

Kube-proxy ਅਤੇ iptables ਨੂੰ Kubernetes ਵਿੱਚ ਤੈਨਾਤ ਕਰਨ ਵੇਲੇ ਸਭ ਤੋਂ ਆਮ ਵਰਤੋਂ ਦੇ ਮਾਮਲਿਆਂ ਨੂੰ ਕਵਰ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ। ਇਹ ਸਹੂਲਤ ਲਈ ਹੈ।

ਜੇ ਤੁਸੀਂ ਇੱਕ ਵੈਬ ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਜੋ ਇੱਕ REST API ਦਾ ਪਰਦਾਫਾਸ਼ ਕਰਦੀ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਕਿਸਮਤ ਵਿੱਚ ਹੋ - ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਨਿਰੰਤਰ TCP ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤੁਸੀਂ ਕਿਸੇ ਵੀ Kubernetes ਸੇਵਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਪਰ ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਸਥਾਈ TCP ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਲਗਾਉਣਾ ਪਵੇਗਾ ਕਿ ਬੈਕਐਂਡ ਵਿੱਚ ਲੋਡ ਨੂੰ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਕਿਵੇਂ ਵੰਡਣਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇਸ ਕੇਸ ਲਈ ਤਿਆਰ ਕੀਤੇ ਹੱਲ ਸ਼ਾਮਲ ਨਹੀਂ ਹਨ।

ਹਾਲਾਂਕਿ, ਨਿਸ਼ਚਤ ਤੌਰ 'ਤੇ ਅਜਿਹੇ ਵਿਕਲਪ ਹਨ ਜੋ ਮਦਦ ਕਰ ਸਕਦੇ ਹਨ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਦੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨਾ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਚਾਰ ਕਿਸਮਾਂ ਦੀਆਂ ਸੇਵਾਵਾਂ ਹਨ:

ClusterIP
ਨੋਡਪੋਰਟ
ਲੋਡਬੈਲੈਂਸਰ
ਸਿਰਹੀਣ

ਪਹਿਲੀਆਂ ਤਿੰਨ ਸੇਵਾਵਾਂ ਇੱਕ ਵਰਚੁਅਲ IP ਐਡਰੈੱਸ 'ਤੇ ਆਧਾਰਿਤ ਕੰਮ ਕਰਦੀਆਂ ਹਨ, ਜਿਸਦੀ ਵਰਤੋਂ iptables ਨਿਯਮ ਬਣਾਉਣ ਲਈ kube-proxy ਦੁਆਰਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਪਰ ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਦਾ ਮੂਲ ਆਧਾਰ ਸਿਰ ਰਹਿਤ ਸੇਵਾ ਹੈ।

ਸਿਰਲੇਖ ਰਹਿਤ ਸੇਵਾ ਦਾ ਕੋਈ ਵੀ IP ਪਤਾ ਇਸ ਨਾਲ ਜੁੜਿਆ ਨਹੀਂ ਹੁੰਦਾ ਹੈ ਅਤੇ ਸਿਰਫ IP ਪਤਿਆਂ ਦੀ ਸੂਚੀ ਅਤੇ ਇਸ ਨਾਲ ਜੁੜੇ ਪੌਡਾਂ (ਐਂਡਪੁਆਇੰਟਸ) ਦੇ ਪੋਰਟਾਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ।

ਸਾਰੀਆਂ ਸੇਵਾਵਾਂ ਸਿਰ ਰਹਿਤ ਸੇਵਾ 'ਤੇ ਅਧਾਰਤ ਹਨ।

ClusterIP ਸੇਵਾ ਕੁਝ ਜੋੜਾਂ ਦੇ ਨਾਲ ਇੱਕ ਸਿਰਲੇਖ ਰਹਿਤ ਸੇਵਾ ਹੈ:

ਪ੍ਰਬੰਧਨ ਪਰਤ ਇਸ ਨੂੰ ਇੱਕ IP ਪਤਾ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ।
Kube-proxy ਲੋੜੀਂਦੇ iptables ਨਿਯਮ ਬਣਾਉਂਦਾ ਹੈ।

ਇਸ ਤਰੀਕੇ ਨਾਲ ਤੁਸੀਂ kube-proxy ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਆਪਣੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸੰਤੁਲਨ ਲੋਡ ਕਰਨ ਲਈ ਹੈੱਡਲੈੱਸ ਸੇਵਾ ਤੋਂ ਪ੍ਰਾਪਤ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੀ ਸੂਚੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਪਰ ਅਸੀਂ ਕਲੱਸਟਰ ਵਿੱਚ ਤੈਨਾਤ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਸਮਾਨ ਤਰਕ ਕਿਵੇਂ ਜੋੜ ਸਕਦੇ ਹਾਂ?

ਜੇਕਰ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਤੈਨਾਤ ਹੈ, ਤਾਂ ਇਹ ਕੰਮ ਅਸੰਭਵ ਜਾਪਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਇੱਕ ਵਿਕਲਪਿਕ ਵਿਕਲਪ ਹੈ.

ਸਰਵਿਸ ਮੇਸ਼ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗਾ

ਤੁਸੀਂ ਸ਼ਾਇਦ ਪਹਿਲਾਂ ਹੀ ਦੇਖਿਆ ਹੋਵੇਗਾ ਕਿ ਕਲਾਇੰਟ-ਸਾਈਡ ਲੋਡ ਬੈਲੇਂਸਿੰਗ ਰਣਨੀਤੀ ਕਾਫ਼ੀ ਮਿਆਰੀ ਹੈ।

ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਇਹ:

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

ਇੱਕ ਵਾਰ ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਇੱਕ ਬੇਨਤੀ ਕਰਨਾ ਚਾਹੁੰਦੀ ਹੈ, ਤਾਂ ਇਹ:

ਕੁਝ ਤਰਕ (ਜਿਵੇਂ ਰਾਊਂਡ-ਰੋਬਿਨ) ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇੱਕ ਉਪਲਬਧ ਕੁਨੈਕਸ਼ਨ ਚੁਣਦਾ ਹੈ।
ਬੇਨਤੀ ਨੂੰ ਲਾਗੂ ਕਰਦਾ ਹੈ।

ਇਹ ਕਦਮ WebSockets, gRPC, ਅਤੇ AMQP ਕਨੈਕਸ਼ਨਾਂ ਲਈ ਕੰਮ ਕਰਦੇ ਹਨ।

ਤੁਸੀਂ ਇਸ ਤਰਕ ਨੂੰ ਇੱਕ ਵੱਖਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਵੱਖ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਇਸਨੂੰ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਵਰਤ ਸਕਦੇ ਹੋ।

ਹਾਲਾਂਕਿ, ਤੁਸੀਂ ਇਸਦੀ ਬਜਾਏ ਸੇਵਾ ਜਾਲ ਜਿਵੇਂ ਕਿ Istio ਜਾਂ Linkerd ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ।

ਸਰਵਿਸ ਮੈਸ਼ ਤੁਹਾਡੀ ਅਰਜ਼ੀ ਨੂੰ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਨਾਲ ਵਧਾਉਂਦਾ ਹੈ ਜੋ:

ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਸੇਵਾ IP ਪਤਿਆਂ ਦੀ ਖੋਜ ਕਰਦਾ ਹੈ।
ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ ਜਿਵੇਂ ਕਿ WebSockets ਅਤੇ gRPC।
ਸਹੀ ਪ੍ਰੋਟੋਕੋਲ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਦਾ ਹੈ।

ਸਰਵਿਸ ਮੈਸ਼ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਟ੍ਰੈਫਿਕ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ, ਪਰ ਇਹ ਕਾਫ਼ੀ ਸਰੋਤ-ਸੰਬੰਧਿਤ ਹੈ। ਹੋਰ ਵਿਕਲਪ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਿਵੇਂ ਕਿ Netflix ਰਿਬਨ ਜਾਂ ਪ੍ਰੋਗਰਾਮੇਬਲ ਪ੍ਰੌਕਸੀਜ਼ ਜਿਵੇਂ ਐਂਵੋਏ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ ਸੰਤੁਲਨ ਦੇ ਮੁੱਦਿਆਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਤੁਸੀਂ ਲੋਡ ਸੰਤੁਲਨ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰਨ ਦੀ ਚੋਣ ਕਰ ਸਕਦੇ ਹੋ ਅਤੇ ਫਿਰ ਵੀ ਕੋਈ ਬਦਲਾਅ ਨਹੀਂ ਦੇਖਦੇ। ਆਓ ਕੁਝ ਕੰਮ ਦੇ ਦ੍ਰਿਸ਼ਾਂ 'ਤੇ ਨਜ਼ਰ ਮਾਰੀਏ।

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸਰਵਰਾਂ ਨਾਲੋਂ ਵਧੇਰੇ ਗਾਹਕ ਹਨ, ਤਾਂ ਇਹ ਇੰਨੀ ਵੱਡੀ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ.

ਮੰਨ ਲਓ ਕਿ ਇੱਥੇ ਪੰਜ ਕਲਾਇੰਟ ਹਨ ਜੋ ਦੋ ਸਰਵਰਾਂ ਨਾਲ ਜੁੜਦੇ ਹਨ। ਭਾਵੇਂ ਕੋਈ ਸੰਤੁਲਨ ਨਾ ਹੋਵੇ, ਦੋਵੇਂ ਸਰਵਰ ਵਰਤੇ ਜਾਣਗੇ:

ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸਮਾਨ ਰੂਪ ਵਿੱਚ ਵੰਡਿਆ ਨਹੀਂ ਜਾ ਸਕਦਾ ਹੈ: ਸ਼ਾਇਦ ਚਾਰ ਕਲਾਇੰਟ ਇੱਕੋ ਸਰਵਰ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ, ਪਰ ਇੱਕ ਵਧੀਆ ਮੌਕਾ ਹੈ ਕਿ ਦੋਵੇਂ ਸਰਵਰ ਵਰਤੇ ਜਾਣਗੇ।

ਕੀ ਹੋਰ ਸਮੱਸਿਆ ਹੈ ਉਲਟ ਦ੍ਰਿਸ਼.

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਘੱਟ ਕਲਾਇੰਟਸ ਅਤੇ ਵਧੇਰੇ ਸਰਵਰ ਹਨ, ਤਾਂ ਤੁਹਾਡੇ ਸਰੋਤ ਘੱਟ ਵਰਤੇ ਜਾ ਸਕਦੇ ਹਨ ਅਤੇ ਇੱਕ ਸੰਭਾਵੀ ਰੁਕਾਵਟ ਦਿਖਾਈ ਦੇਵੇਗੀ।

ਮੰਨ ਲਓ ਕਿ ਇੱਥੇ ਦੋ ਕਲਾਇੰਟਸ ਅਤੇ ਪੰਜ ਸਰਵਰ ਹਨ। ਸਭ ਤੋਂ ਵਧੀਆ ਸਥਿਤੀ ਵਿੱਚ, ਪੰਜ ਵਿੱਚੋਂ ਦੋ ਸਰਵਰਾਂ ਨਾਲ ਦੋ ਸਥਾਈ ਕਨੈਕਸ਼ਨ ਹੋਣਗੇ।

ਬਾਕੀ ਸਰਵਰ ਨਿਸ਼ਕਿਰਿਆ ਹੋ ਜਾਣਗੇ:

ਜੇਕਰ ਇਹ ਦੋ ਸਰਵਰ ਕਲਾਇੰਟ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨੂੰ ਨਹੀਂ ਸੰਭਾਲ ਸਕਦੇ, ਤਾਂ ਹਰੀਜੱਟਲ ਸਕੇਲਿੰਗ ਮਦਦ ਨਹੀਂ ਕਰੇਗੀ।

ਸਿੱਟਾ

Kubernetes ਸੇਵਾਵਾਂ ਜ਼ਿਆਦਾਤਰ ਮਿਆਰੀ ਵੈੱਬ ਐਪਲੀਕੇਸ਼ਨ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਕੰਮ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ।

ਹਾਲਾਂਕਿ, ਇੱਕ ਵਾਰ ਜਦੋਂ ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਪ੍ਰੋਟੋਕੋਲ ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ ਜੋ ਲਗਾਤਾਰ TCP ਕਨੈਕਸ਼ਨਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ, ਜਿਵੇਂ ਕਿ ਡਾਟਾਬੇਸ, gRPC ਜਾਂ WebSockets, ਸੇਵਾਵਾਂ ਹੁਣ ਢੁਕਵੇਂ ਨਹੀਂ ਹਨ। ਕੁਬਰਨੇਟਸ ਨਿਰੰਤਰ TCP ਕੁਨੈਕਸ਼ਨਾਂ ਨੂੰ ਸੰਤੁਲਿਤ ਕਰਨ ਲਈ ਅੰਦਰੂਨੀ ਵਿਧੀ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ ਹੈ।

ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਕਲਾਇੰਟ-ਸਾਈਡ ਸੰਤੁਲਨ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੇ ਹੋਏ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਿਖਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ।

ਟੀਮ ਦੁਆਰਾ ਤਿਆਰ ਕੀਤਾ ਅਨੁਵਾਦ Mail.ru ਤੋਂ Kubernetes aaS.

ਵਿਸ਼ੇ 'ਤੇ ਹੋਰ ਕੀ ਪੜ੍ਹਨਾ ਹੈ:

ਸਰੋਤ: www.habr.com

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਲੰਬੇ ਸਮੇਂ ਤੱਕ ਚੱਲਣ ਵਾਲੇ ਕਨੈਕਸ਼ਨਾਂ ਨੂੰ ਲੋਡ ਕਰਨਾ ਅਤੇ ਸਕੇਲਿੰਗ ਕਰਨਾ