Istio ਸਰਕਟ ਬ੍ਰੇਕਰ: ਨੁਕਸਦਾਰ ਕੰਟੇਨਰਾਂ ਨੂੰ ਅਯੋਗ ਕਰਨਾ

ਛੁੱਟੀਆਂ ਖਤਮ ਹੋ ਗਈਆਂ ਹਨ ਅਤੇ ਅਸੀਂ ਇਸਟੀਓ ਸਰਵਿਸ ਮੇਸ਼ ਸੀਰੀਜ਼ ਵਿੱਚ ਆਪਣੀ ਦੂਜੀ ਪੋਸਟ ਦੇ ਨਾਲ ਵਾਪਸ ਆ ਗਏ ਹਾਂ।

ਅੱਜ ਦਾ ਵਿਸ਼ਾ ਸਰਕਟ ਬ੍ਰੇਕਰ ਹੈ, ਜਿਸਦਾ ਰੂਸੀ ਇਲੈਕਟ੍ਰੀਕਲ ਇੰਜੀਨੀਅਰਿੰਗ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਗਿਆ ਹੈ "ਸਰਕਟ ਬ੍ਰੇਕਰ", ਆਮ ਭਾਸ਼ਾ ਵਿੱਚ - "ਸਰਕਟ ਬ੍ਰੇਕਰ"। ਸਿਰਫ਼ Istio ਵਿੱਚ ਇਹ ਮਸ਼ੀਨ ਇੱਕ ਸ਼ਾਰਟ ਜਾਂ ਓਵਰਲੋਡ ਸਰਕਟ ਨੂੰ ਡਿਸਕਨੈਕਟ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਪਰ ਨੁਕਸਦਾਰ ਕੰਟੇਨਰਾਂ ਨੂੰ.

ਇਹ ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕੰਮ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ

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

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

ਇਹ ਅਸਲ ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਹੁਣ ਕਲਪਨਾ ਕਰੋ ਕਿ ਇੱਕ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੀ ਇੱਕ ਖਾਸ ਉਦਾਹਰਣ, ਯਾਨੀ ਇੱਕ ਕੰਟੇਨਰ, ਬੇਕਾਰ ਹੋ ਗਿਆ ਹੈ: ਜਾਂ ਤਾਂ ਇਹ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ (ਗਲਤੀ 503), ਜਾਂ, ਜੋ ਜ਼ਿਆਦਾ ਦੁਖਦਾਈ ਹੈ, ਇਹ ਜਵਾਬ ਦਿੰਦਾ ਹੈ, ਪਰ ਬਹੁਤ ਹੌਲੀ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ ਗਲੀਚ ਹੋ ਜਾਂਦਾ ਹੈ ਜਾਂ ਬੇਨਤੀਆਂ ਦਾ ਜਵਾਬ ਨਹੀਂ ਦਿੰਦਾ ਹੈ, ਪਰ ਇਹ ਆਪਣੇ ਆਪ ਪੂਲ ਤੋਂ ਨਹੀਂ ਹਟਾਇਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੀ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ? ਮੁੜ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਲਈ? ਕੀ ਮੈਨੂੰ ਇਸਨੂੰ ਰੂਟਿੰਗ ਸਕੀਮ ਤੋਂ ਹਟਾਉਣਾ ਚਾਹੀਦਾ ਹੈ? ਅਤੇ "ਬਹੁਤ ਹੌਲੀ" ਦਾ ਕੀ ਮਤਲਬ ਹੈ - ਇਹ ਗਿਣਤੀ ਵਿੱਚ ਕਿੰਨੀ ਹੈ, ਅਤੇ ਕੌਣ ਉਹਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ? ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਸਨੂੰ ਇੱਕ ਬ੍ਰੇਕ ਦਿਓ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਦੁਬਾਰਾ ਕੋਸ਼ਿਸ਼ ਕਰੋ? ਜੇਕਰ ਹਾਂ, ਤਾਂ ਕਿੰਨੀ ਦੇਰ ਬਾਅਦ?

ਇਸਟੀਓ ਵਿੱਚ ਪੂਲ ਇਜੈਕਸ਼ਨ ਕੀ ਹੈ?

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

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

ਇਹ ਦਰਸਾਉਣ ਲਈ ਕਿ ਇਹ OpenShift ਪਲੇਟਫਾਰਮ 'ਤੇ Kubernetes ਵਿੱਚ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਆਓ ਰਿਪੋਜ਼ਟਰੀ ਵਿੱਚ ਉਦਾਹਰਨ ਤੋਂ ਆਮ ਤੌਰ 'ਤੇ ਕੰਮ ਕਰਨ ਵਾਲੇ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਸਕ੍ਰੀਨਸ਼ੌਟ ਨਾਲ ਸ਼ੁਰੂਆਤ ਕਰੀਏ। Red Hat ਡਿਵੈਲਪਰ ਡੈਮੋ. ਇੱਥੇ ਸਾਡੇ ਕੋਲ ਦੋ ਪੌਡ ਹਨ, v1 ਅਤੇ v2, ਹਰ ਇੱਕ ਕੰਟੇਨਰ ਚੱਲ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਇਸਟੀਓ ਰੂਟਿੰਗ ਨਿਯਮਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕੀਤੀ ਜਾਂਦੀ, ਤਾਂ ਕੁਬਰਨੇਟਸ ਡਿਫੌਲਟ ਤੌਰ 'ਤੇ ਬਰਾਬਰ ਸੰਤੁਲਿਤ ਰਾਉਂਡ-ਰੋਬਿਨ ਰਾਊਟਿੰਗ ਲਈ ਤਿਆਰ ਹੁੰਦਾ ਹੈ:

ਅਸਫਲਤਾ ਲਈ ਤਿਆਰੀ

ਪੂਲ ਇਜੈਕਸ਼ਨ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ, ਤੁਹਾਨੂੰ ਇੱਕ Istio ਰੂਟਿੰਗ ਨਿਯਮ ਬਣਾਉਣ ਦੀ ਲੋੜ ਹੈ। ਮੰਨ ਲਓ ਕਿ ਅਸੀਂ 50/50 ਅਨੁਪਾਤ ਵਿੱਚ ਪੌਡਾਂ ਵਿਚਕਾਰ ਬੇਨਤੀਆਂ ਨੂੰ ਵੰਡਣਾ ਚਾਹੁੰਦੇ ਹਾਂ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ v2 ਕੰਟੇਨਰਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਇੱਕ ਤੋਂ ਦੋ ਤੱਕ ਵਧਾਵਾਂਗੇ, ਇਸ ਤਰ੍ਹਾਂ:

oc scale deployment recommendation-v2 --replicas=2 -n tutorial

ਹੁਣ ਅਸੀਂ ਇੱਕ ਰੂਟਿੰਗ ਨਿਯਮ ਸੈਟ ਕਰਦੇ ਹਾਂ ਤਾਂ ਜੋ ਟ੍ਰੈਫਿਕ ਨੂੰ 50/50 ਅਨੁਪਾਤ ਵਿੱਚ ਪੌਡਾਂ ਵਿੱਚ ਵੰਡਿਆ ਜਾ ਸਕੇ।

ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਇਸ ਨਿਯਮ ਦਾ ਨਤੀਜਾ ਕੀ ਦਿਸਦਾ ਹੈ:

ਤੁਸੀਂ ਇਸ ਤੱਥ ਦੇ ਨਾਲ ਨੁਕਸ ਲੱਭ ਸਕਦੇ ਹੋ ਕਿ ਇਹ ਸਕ੍ਰੀਨ 50/50 ਨਹੀਂ, ਸਗੋਂ 14:9 ਹੈ, ਪਰ ਸਮੇਂ ਦੇ ਨਾਲ ਸਥਿਤੀ ਵਿੱਚ ਸੁਧਾਰ ਹੋਵੇਗਾ।

ਗੜਬੜ ਕਰ ਰਿਹਾ ਹੈ

ਆਉ ਹੁਣ ਦੋ v2 ਕੰਟੇਨਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਅਸਮਰੱਥ ਕਰੀਏ ਤਾਂ ਜੋ ਸਾਡੇ ਕੋਲ ਇੱਕ ਸਿਹਤਮੰਦ v1 ਕੰਟੇਨਰ, ਇੱਕ ਸਿਹਤਮੰਦ v2 ਕੰਟੇਨਰ ਅਤੇ ਇੱਕ ਨੁਕਸਦਾਰ v2 ਕੰਟੇਨਰ ਹੋਵੇ:

ਗੜਬੜ ਨੂੰ ਠੀਕ ਕਰਨਾ

ਇਸ ਲਈ, ਸਾਡੇ ਕੋਲ ਇੱਕ ਨੁਕਸਦਾਰ ਕੰਟੇਨਰ ਹੈ, ਅਤੇ ਇਹ ਪੂਲ ਇਜੈਕਸ਼ਨ ਦਾ ਸਮਾਂ ਹੈ। ਇੱਕ ਬਹੁਤ ਹੀ ਸਧਾਰਨ ਸੰਰਚਨਾ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਇਸ ਅਸਫ਼ਲ ਕੰਟੇਨਰ ਨੂੰ ਕਿਸੇ ਵੀ ਰੂਟਿੰਗ ਸਕੀਮਾਂ ਤੋਂ 15 ਸਕਿੰਟਾਂ ਲਈ ਇਸ ਉਮੀਦ ਵਿੱਚ ਬਾਹਰ ਕਰ ਦੇਵਾਂਗੇ ਕਿ ਇਹ ਇੱਕ ਸਿਹਤਮੰਦ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਵੇਗਾ (ਜਾਂ ਤਾਂ ਮੁੜ ਚਾਲੂ ਕਰੋ ਜਾਂ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਰੀਸਟੋਰ ਕਰੋ)। ਇਹ ਸੰਰਚਨਾ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦਿੰਦੀ ਹੈ ਅਤੇ ਇਸਦੇ ਕੰਮ ਦੇ ਨਤੀਜੇ:

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਸਫਲ v2 ਕੰਟੇਨਰ ਹੁਣ ਰੂਟਿੰਗ ਬੇਨਤੀਆਂ ਲਈ ਨਹੀਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਪੂਲ ਤੋਂ ਹਟਾ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਪਰ 15 ਸਕਿੰਟਾਂ ਬਾਅਦ ਇਹ ਆਪਣੇ ਆਪ ਪੂਲ ਵਿੱਚ ਵਾਪਸ ਆ ਜਾਵੇਗਾ। ਅਸਲ ਵਿੱਚ, ਅਸੀਂ ਹੁਣੇ ਦਿਖਾਇਆ ਹੈ ਕਿ ਪੂਲ ਇਜੈਕਸ਼ਨ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ।

ਆਉ ਆਰਕੀਟੈਕਚਰ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰੀਏ

ਪੂਲ ਇਜੈਕਸ਼ਨ, Istio ਦੀ ਨਿਗਰਾਨੀ ਸਮਰੱਥਾਵਾਂ ਦੇ ਨਾਲ ਮਿਲ ਕੇ, ਤੁਹਾਨੂੰ ਨੁਕਸਦਾਰ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸਵੈਚਲਿਤ ਤੌਰ 'ਤੇ ਬਦਲਣ ਲਈ ਇੱਕ ਫਰੇਮਵਰਕ ਬਣਾਉਣਾ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਜੇਕਰ ਨਹੀਂ, ਤਾਂ ਡਾਊਨਟਾਈਮ ਅਤੇ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਘਟਾਉਣ ਲਈ.
 
ਨਾਸਾ ਦਾ ਇੱਕ ਉੱਚਾ ਮਨੋਰਥ ਹੈ - ਅਸਫਲਤਾ ਇੱਕ ਵਿਕਲਪ ਨਹੀਂ ਹੈ, ਜਿਸਦਾ ਲੇਖਕ ਫਲਾਈਟ ਡਾਇਰੈਕਟਰ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ ਜੀਨ ਕ੍ਰਾਂਜ਼. ਇਸਦਾ ਰੂਸੀ ਵਿੱਚ ਅਨੁਵਾਦ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ "ਅਸਫ਼ਲਤਾ ਇੱਕ ਵਿਕਲਪ ਨਹੀਂ ਹੈ," ਅਤੇ ਇੱਥੇ ਅਰਥ ਇਹ ਹੈ ਕਿ ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਲੋੜੀਂਦੀ ਇੱਛਾ ਹੈ ਤਾਂ ਹਰ ਚੀਜ਼ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ ਬਣਾਇਆ ਜਾ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਅਸਲ ਜੀਵਨ ਵਿੱਚ, ਅਸਫਲਤਾਵਾਂ ਸਿਰਫ ਵਾਪਰਦੀਆਂ ਹੀ ਨਹੀਂ ਹਨ, ਉਹ ਅਟੱਲ ਹਨ, ਹਰ ਜਗ੍ਹਾ ਅਤੇ ਹਰ ਚੀਜ਼ ਵਿੱਚ. ਅਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਉਹਨਾਂ ਨਾਲ ਕਿਵੇਂ ਨਜਿੱਠਣਾ ਹੈ? ਸਾਡੀ ਰਾਏ ਵਿੱਚ, ਇੱਛਾ ਸ਼ਕਤੀ 'ਤੇ ਭਰੋਸਾ ਨਹੀਂ ਕਰਨਾ ਬਿਹਤਰ ਹੈ, ਪਰ ਕੰਟੇਨਰਾਂ ਦੀਆਂ ਸਮਰੱਥਾਵਾਂ 'ਤੇ, ਕਬਰਨੇਟਿਸ, ਰੈੱਡ ਹੈੱਟ ਓਪਨ ਸ਼ੀਫਟਅਤੇ ਆਈਸਟੀਓ.

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

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

ਸਿਧਾਂਤ ਵਿੱਚ ਸਰਕਟ ਬ੍ਰੇਕਰ

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

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

ਅਭਿਆਸ ਵਿੱਚ ਸਰਕਟ ਬ੍ਰੇਕਰ

ਉਦਾਹਰਨ ਲਈ, ਅਸੀਂ OpenShift 'ਤੇ ਸਾਡੀ ਸਿਫ਼ਾਰਿਸ਼ ਮਾਈਕ੍ਰੋਸਰਵਿਸ ਦੇ ਦੋ ਸੰਸਕਰਣ ਚਲਾਵਾਂਗੇ। ਸੰਸਕਰਣ 1 ਵਧੀਆ ਕੰਮ ਕਰੇਗਾ, ਪਰ v2 ਵਿੱਚ ਅਸੀਂ ਸਰਵਰ 'ਤੇ ਸੁਸਤੀ ਦੀ ਨਕਲ ਕਰਨ ਲਈ ਇੱਕ ਦੇਰੀ ਵਿੱਚ ਬਣਾਵਾਂਗੇ। ਨਤੀਜੇ ਦੇਖਣ ਲਈ, ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰੋ ਘੇਰਾਬੰਦੀ:

siege -r 2 -c 20 -v customer-tutorial.$(minishift ip).nip.io

ਸਭ ਕੁਝ ਕੰਮ ਕਰਨ ਲੱਗਦਾ ਹੈ, ਪਰ ਕਿਸ ਕੀਮਤ 'ਤੇ? ਪਹਿਲੀ ਨਜ਼ਰ 'ਤੇ, ਸਾਡੇ ਕੋਲ 100% ਉਪਲਬਧਤਾ ਹੈ, ਪਰ ਇੱਕ ਨਜ਼ਦੀਕੀ ਨਜ਼ਰ ਮਾਰੋ - ਅਧਿਕਤਮ ਟ੍ਰਾਂਜੈਕਸ਼ਨ ਦੀ ਮਿਆਦ 12 ਸਕਿੰਟ ਜਿੰਨੀ ਹੈ। ਇਹ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਇੱਕ ਰੁਕਾਵਟ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਵਧਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ.

ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਹੌਲੀ ਕੰਟੇਨਰਾਂ ਲਈ ਕਾਲਾਂ ਨੂੰ ਖਤਮ ਕਰਨ ਲਈ Istio ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ। ਇਹ ਉਹੀ ਹੈ ਜੋ ਸਰਕਟ ਬ੍ਰੇਕਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਸੰਬੰਧਿਤ ਸੰਰਚਨਾ ਵਰਗਾ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ:

httpMaxRequestsPerConnection ਪੈਰਾਮੀਟਰ ਵਾਲੀ ਆਖਰੀ ਲਾਈਨ ਸੰਕੇਤ ਦਿੰਦੀ ਹੈ ਕਿ ਮੌਜੂਦਾ ਇੱਕ ਤੋਂ ਇਲਾਵਾ ਇੱਕ ਹੋਰ - ਇੱਕ ਦੂਜਾ - ਕੁਨੈਕਸ਼ਨ ਬਣਾਉਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਸਮੇਂ ਨਾਲ ਕੁਨੈਕਸ਼ਨ ਡਿਸਕਨੈਕਟ ਕੀਤਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਕਿਉਂਕਿ ਸਾਡਾ ਕੰਟੇਨਰ ਇੱਕ ਹੌਲੀ ਸੇਵਾ ਦੀ ਨਕਲ ਕਰਦਾ ਹੈ, ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਸਮੇਂ-ਸਮੇਂ 'ਤੇ ਪੈਦਾ ਹੋਣਗੀਆਂ, ਅਤੇ ਫਿਰ Istio ਇੱਕ 503 ਗਲਤੀ ਵਾਪਸ ਕਰੇਗਾ, ਪਰ ਇਹ ਉਹ ਹੈ ਜੋ ਘੇਰਾਬੰਦੀ ਦਿਖਾਏਗਾ:

ਠੀਕ ਹੈ, ਸਾਡੇ ਕੋਲ ਸਰਕਟ ਬ੍ਰੇਕਰ ਹੈ, ਅੱਗੇ ਕੀ ਹੈ?

ਇਸ ਲਈ, ਅਸੀਂ ਸੇਵਾਵਾਂ ਦੇ ਸਰੋਤ ਕੋਡ ਨੂੰ ਛੂਹਣ ਤੋਂ ਬਿਨਾਂ ਆਟੋਮੈਟਿਕ ਬੰਦ ਨੂੰ ਲਾਗੂ ਕੀਤਾ ਹੈ। ਉੱਪਰ ਦੱਸੇ ਗਏ ਸਰਕਟ ਬ੍ਰੇਕਰ ਅਤੇ ਪੂਲ ਇਜੈਕਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸਰੋਤ ਪੂਲ ਤੋਂ ਬ੍ਰੇਕ ਕੰਟੇਨਰਾਂ ਨੂੰ ਉਦੋਂ ਤੱਕ ਹਟਾ ਸਕਦੇ ਹਾਂ ਜਦੋਂ ਤੱਕ ਉਹ ਆਮ 'ਤੇ ਵਾਪਸ ਨਹੀਂ ਆ ਜਾਂਦੇ, ਅਤੇ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬਾਰੰਬਾਰਤਾ 'ਤੇ ਉਹਨਾਂ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹਾਂ - ਸਾਡੀ ਉਦਾਹਰਨ ਵਿੱਚ, ਇਹ ਦੋ ਮਿੰਟ (ਸਲੀਪ ਵਿੰਡੋ ਪੈਰਾਮੀਟਰ) ਹੈ।

ਨੋਟ ਕਰੋ ਕਿ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਦੀ 503 ਗਲਤੀ ਦਾ ਜਵਾਬ ਦੇਣ ਦੀ ਯੋਗਤਾ ਅਜੇ ਵੀ ਸਰੋਤ ਕੋਡ ਪੱਧਰ 'ਤੇ ਸੈੱਟ ਹੈ। ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਕਰਦਿਆਂ, ਸਰਕਟ ਬ੍ਰੇਕਰ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਬਹੁਤ ਸਾਰੀਆਂ ਰਣਨੀਤੀਆਂ ਹਨ.

ਅਗਲੀ ਪੋਸਟ ਵਿੱਚ: ਅਸੀਂ ਉਸ ਟਰੇਸਿੰਗ ਅਤੇ ਨਿਗਰਾਨੀ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਜੋ ਪਹਿਲਾਂ ਤੋਂ ਹੀ ਬਿਲਟ-ਇਨ ਹੈ ਜਾਂ ਆਸਾਨੀ ਨਾਲ Istio ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ, ਨਾਲ ਹੀ ਸਿਸਟਮ ਵਿੱਚ ਜਾਣਬੁੱਝ ਕੇ ਗਲਤੀਆਂ ਨੂੰ ਕਿਵੇਂ ਪੇਸ਼ ਕਰਨਾ ਹੈ।

ਸਰੋਤ: www.habr.com