ਕੁਬਰਨੇਟਸ: CPU ਸੀਮਾਵਾਂ ਨੂੰ ਹਟਾ ਕੇ ਆਪਣੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਤੇਜ਼ ਕਰੋ

2016 ਵਿੱਚ ਵਾਪਸ ਅਸੀਂ ਬਫਰ 'ਤੇ ਹਾਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਬਦਲਿਆ ਗਿਆ, ਅਤੇ ਹੁਣ ਲਗਭਗ 60 ਨੋਡ (AWS 'ਤੇ) ਅਤੇ 1500 ਕੰਟੇਨਰ ਸਾਡੇ k8s ਕਲੱਸਟਰ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ, ਜਿਸ ਦੁਆਰਾ ਪ੍ਰਬੰਧਿਤ ਕਿੱਕ. ਹਾਲਾਂਕਿ, ਅਸੀਂ ਅਜ਼ਮਾਇਸ਼ ਅਤੇ ਗਲਤੀ ਦੁਆਰਾ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਵਿੱਚ ਚਲੇ ਗਏ, ਅਤੇ k8s ਨਾਲ ਕੰਮ ਕਰਨ ਦੇ ਕਈ ਸਾਲਾਂ ਬਾਅਦ ਵੀ ਸਾਨੂੰ ਨਵੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਰਿਹਾ ਹੈ। ਇਸ ਪੋਸਟ ਵਿੱਚ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਾਂਗੇ ਪ੍ਰੋਸੈਸਰ ਸੀਮਾਵਾਂ: ਅਸੀਂ ਕਿਉਂ ਸੋਚਿਆ ਕਿ ਉਹ ਚੰਗੇ ਅਭਿਆਸ ਸਨ ਅਤੇ ਉਹ ਇੰਨੇ ਚੰਗੇ ਕਿਉਂ ਨਹੀਂ ਹੋਏ।

ਪ੍ਰੋਸੈਸਰ ਸੀਮਾਵਾਂ ਅਤੇ ਥ੍ਰੋਟਲਿੰਗ

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

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

ਕੀ ਹੋ ਸਕਦਾ ਹੈ ਜੇਕਰ ਅਸੀਂ ਪ੍ਰੋਸੈਸਰ ਸੀਮਾਵਾਂ ਸੈਟ ਨਹੀਂ ਕਰਦੇ ਹਾਂ?

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

ਥ੍ਰੋਟਲਿੰਗ ਅਤੇ ਜਵਾਬ ਦੀ ਸਮੱਸਿਆ ਦਾ ਪ੍ਰਗਟਾਵਾ

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

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਹੇਠਾਂ ਦੇਖ ਸਕਦੇ ਹੋ, ਅਸੀਂ ਇਸ ਲਈ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਹੈ 800m (0.8 ਜਾਂ 80% ਕੋਰ), ਅਤੇ ਸਭ ਤੋਂ ਵਧੀਆ ਪਹੁੰਚ 'ਤੇ ਸਿਖਰ ਮੁੱਲ 200m (20% ਕੋਰ). ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਸੇਵਾ ਨੂੰ ਥ੍ਰੋਟ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਸਾਡੇ ਕੋਲ ਅਜੇ ਵੀ ਬਹੁਤ ਸਾਰੀ ਪ੍ਰੋਸੈਸਰ ਸ਼ਕਤੀ ਹੈ, ਹਾਲਾਂਕਿ ...

ਤੁਸੀਂ ਦੇਖਿਆ ਹੋਵੇਗਾ ਕਿ ਜਦੋਂ ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਨਿਰਧਾਰਤ ਸੀਮਾਵਾਂ ਤੋਂ ਹੇਠਾਂ ਹੈ - ਕਾਫ਼ੀ ਹੇਠਾਂ - ਥ੍ਰੋਟਲਿੰਗ ਅਜੇ ਵੀ ਵਾਪਰਦੀ ਹੈ।

ਇਸਦਾ ਸਾਹਮਣਾ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਜਲਦੀ ਹੀ ਕਈ ਸਰੋਤਾਂ ਦੀ ਖੋਜ ਕੀਤੀ (github 'ਤੇ ਸਮੱਸਿਆ, zadano 'ਤੇ ਪੇਸ਼ਕਾਰੀ, ਓਮੀਓ 'ਤੇ ਪੋਸਟ ਕਰੋ) ਥ੍ਰੋਟਲਿੰਗ ਦੇ ਕਾਰਨ ਸੇਵਾਵਾਂ ਦੇ ਪ੍ਰਦਰਸ਼ਨ ਅਤੇ ਜਵਾਬ ਸਮੇਂ ਵਿੱਚ ਗਿਰਾਵਟ ਬਾਰੇ।

ਅਸੀਂ ਘੱਟ CPU ਲੋਡ 'ਤੇ ਥ੍ਰੋਟਲਿੰਗ ਕਿਉਂ ਦੇਖਦੇ ਹਾਂ? ਛੋਟਾ ਸੰਸਕਰਣ ਹੈ: "ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਇੱਕ ਬੱਗ ਹੈ ਜੋ ਨਿਰਧਾਰਤ ਪ੍ਰੋਸੈਸਰ ਸੀਮਾਵਾਂ ਵਾਲੇ ਕੰਟੇਨਰਾਂ ਦੀ ਬੇਲੋੜੀ ਥ੍ਰੋਟਲਿੰਗ ਦਾ ਕਾਰਨ ਬਣਦਾ ਹੈ।" ਜੇ ਤੁਸੀਂ ਸਮੱਸਿਆ ਦੀ ਪ੍ਰਕਿਰਤੀ ਵਿੱਚ ਦਿਲਚਸਪੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਪੇਸ਼ਕਾਰੀ ਨੂੰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ (видео и ਟੈਕਸਟ ਵਿਕਲਪ) ਡੇਵ ਚਿਲੁਕ ਦੁਆਰਾ।

CPU ਪਾਬੰਦੀਆਂ ਨੂੰ ਹਟਾਉਣਾ (ਬਹੁਤ ਸਾਵਧਾਨੀ ਨਾਲ)

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

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

ਇੱਕ ਦਬਾਉਣ ਵਾਲੇ ਮੁੱਦੇ 'ਤੇ ਵਪਾਰਕ ਪੱਤਰ ਵਿਹਾਰ।

ਜਦੋਂ ਪਾਬੰਦੀਆਂ ਹਟਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ ਤਾਂ ਆਪਣੇ ਨੋਡਾਂ ਦੀ ਰੱਖਿਆ ਕਿਵੇਂ ਕਰੀਏ?

"ਅਪ੍ਰਬੰਧਿਤ" ਸੇਵਾਵਾਂ ਨੂੰ ਅਲੱਗ ਕਰਨਾ:

ਅਤੀਤ ਵਿੱਚ, ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਕੁਝ ਨੋਡਾਂ ਨੂੰ ਇੱਕ ਰਾਜ ਵਿੱਚ ਆਉਂਦੇ ਦੇਖਿਆ ਹੈ notReady, ਮੁੱਖ ਤੌਰ 'ਤੇ ਬਹੁਤ ਸਾਰੇ ਸਰੋਤਾਂ ਦੀ ਖਪਤ ਕਰਨ ਵਾਲੀਆਂ ਸੇਵਾਵਾਂ ਦੇ ਕਾਰਨ।

ਅਸੀਂ ਅਜਿਹੀਆਂ ਸੇਵਾਵਾਂ ਨੂੰ ਵੱਖਰੇ ("ਲੇਬਲ ਕੀਤੇ") ਨੋਡਾਂ ਵਿੱਚ ਰੱਖਣ ਦਾ ਫੈਸਲਾ ਕੀਤਾ ਹੈ ਤਾਂ ਜੋ ਉਹ "ਸਬੰਧਤ" ਸੇਵਾਵਾਂ ਵਿੱਚ ਦਖਲ ਨਾ ਦੇਣ। ਨਤੀਜੇ ਵਜੋਂ, ਕੁਝ ਨੋਡਾਂ ਨੂੰ ਚਿੰਨ੍ਹਿਤ ਕਰਕੇ ਅਤੇ "ਅਸੰਬੰਧਿਤ" ਸੇਵਾਵਾਂ ਵਿੱਚ ਸਹਿਣਸ਼ੀਲਤਾ ਮਾਪਦੰਡ ਜੋੜ ਕੇ, ਅਸੀਂ ਕਲੱਸਟਰ 'ਤੇ ਵਧੇਰੇ ਨਿਯੰਤਰਣ ਪ੍ਰਾਪਤ ਕੀਤਾ, ਅਤੇ ਸਾਡੇ ਲਈ ਨੋਡਾਂ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨਾ ਆਸਾਨ ਹੋ ਗਿਆ। ਸਮਾਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਆਪਣੇ ਆਪ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਜਾਣੂ ਕਰ ਸਕਦੇ ਹੋ ਦਸਤਾਵੇਜ਼.

ਇੱਕ ਸਹੀ ਪ੍ਰੋਸੈਸਰ ਅਤੇ ਮੈਮੋਰੀ ਬੇਨਤੀ ਨਿਰਧਾਰਤ ਕਰਨਾ:

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

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਗ੍ਰਾਫ ਵਿੱਚ ਦੇਖ ਸਕਦੇ ਹੋ, ਪ੍ਰੋਸੈਸਰ 'ਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਲੋਡ ਪਹੁੰਚ ਗਿਆ ਹੈ 242m CPU ਕੋਰ (0.242 ਪ੍ਰੋਸੈਸਰ ਕੋਰ)। ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਬੇਨਤੀ ਲਈ, ਇਸ ਮੁੱਲ ਤੋਂ ਥੋੜ੍ਹਾ ਵੱਡਾ ਨੰਬਰ ਲੈਣਾ ਕਾਫ਼ੀ ਹੈ। ਕਿਰਪਾ ਕਰਕੇ ਨੋਟ ਕਰੋ ਕਿ ਕਿਉਂਕਿ ਸੇਵਾਵਾਂ ਉਪਭੋਗਤਾ-ਕੇਂਦ੍ਰਿਤ ਹਨ, ਪੀਕ ਲੋਡ ਮੁੱਲ ਟ੍ਰੈਫਿਕ ਨਾਲ ਮੇਲ ਖਾਂਦੇ ਹਨ।

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

ਕਮੀਆਂ ਵਿੱਚੋਂ, ਇਹ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਅਸੀਂ "ਵਿੱਚ ਹਾਰ ਗਏ"ਕੰਟੇਨਰ ਦੀ ਘਣਤਾ", i.e. ਇੱਕ ਨੋਡ 'ਤੇ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰਾਂ ਦੀ ਗਿਣਤੀ। ਸਾਡੇ ਕੋਲ ਘੱਟ ਟ੍ਰੈਫਿਕ ਘਣਤਾ 'ਤੇ ਬਹੁਤ ਸਾਰੀਆਂ "ਆਰਾਮ" ਵੀ ਹੋ ਸਕਦੀਆਂ ਹਨ, ਅਤੇ ਇਹ ਵੀ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਸੀਂ ਇੱਕ ਉੱਚ ਪ੍ਰੋਸੈਸਰ ਲੋਡ ਤੱਕ ਪਹੁੰਚ ਜਾਓਗੇ, ਪਰ ਆਟੋਸਕੇਲਿੰਗ ਨੋਡਸ ਨੂੰ ਬਾਅਦ ਵਿੱਚ ਮਦਦ ਕਰਨੀ ਚਾਹੀਦੀ ਹੈ।

Результаты

ਮੈਨੂੰ ਪਿਛਲੇ ਕੁਝ ਹਫ਼ਤਿਆਂ ਦੇ ਪ੍ਰਯੋਗਾਂ ਤੋਂ ਇਹਨਾਂ ਸ਼ਾਨਦਾਰ ਨਤੀਜਿਆਂ ਨੂੰ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਨ ਵਿੱਚ ਖੁਸ਼ੀ ਹੋ ਰਹੀ ਹੈ; ਅਸੀਂ ਪਹਿਲਾਂ ਹੀ ਸਾਰੀਆਂ ਸੰਸ਼ੋਧਿਤ ਸੇਵਾਵਾਂ ਵਿੱਚ ਜਵਾਬ ਵਿੱਚ ਮਹੱਤਵਪੂਰਨ ਸੁਧਾਰ ਦੇਖੇ ਹਨ:

ਅਸੀਂ ਆਪਣੇ ਹੋਮ ਪੇਜ 'ਤੇ ਵਧੀਆ ਨਤੀਜੇ ਪ੍ਰਾਪਤ ਕੀਤੇ (buffer.com), ਉੱਥੇ ਸੇਵਾ ਵਿੱਚ ਤੇਜ਼ੀ ਆਈ ਵੀਹ ਵਾਰ!

ਕੀ ਲੀਨਕਸ ਕਰਨਲ ਬੱਗ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਹੈ?

, ਜੀ ਬੱਗ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਕੀਤਾ ਜਾ ਚੁੱਕਾ ਹੈ ਅਤੇ ਫਿਕਸ ਨੂੰ ਕਰਨਲ ਵਿੱਚ ਜੋੜਿਆ ਗਿਆ ਹੈ ਡਿਸਟਰੀਬਿਊਸ਼ਨ ਵਰਜਨ 4.19 ਅਤੇ ਉੱਚਾ।

ਹਾਲਾਂਕਿ, ਪੜ੍ਹਨ 'ਤੇ github 'ਤੇ kubernetes ਸਮੱਸਿਆਵਾਂ ਸਤੰਬਰ 2020 ਦੇ ਦੂਜੇ ਲਈ ਅਸੀਂ ਅਜੇ ਵੀ ਸਮਾਨ ਬੱਗ ਵਾਲੇ ਕੁਝ ਲੀਨਕਸ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਜ਼ਿਕਰ ਕਰਦੇ ਹਾਂ। ਮੇਰਾ ਮੰਨਣਾ ਹੈ ਕਿ ਕੁਝ ਲੀਨਕਸ ਡਿਸਟਰੀਬਿਊਸ਼ਨਾਂ ਵਿੱਚ ਅਜੇ ਵੀ ਇਹ ਬੱਗ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ 'ਤੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ।

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

• ਡੇਬੀਅਨ: ਵੰਡ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਫਿਕਸ, ਬੱਸਟਰ, ਅਤੇ ਕਾਫ਼ੀ ਤਾਜ਼ਾ ਦਿਸਦਾ ਹੈ (ਅਗਸਤ 2020). ਕੁਝ ਪਿਛਲੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਵੀ ਠੀਕ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।
• ਉਬੰਟੂ: ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਿੱਚ ਏਕੀਕ੍ਰਿਤ ਫਿਕਸ ਉਬੰਟੂ ਫੋਕਲ ਫੋਸਾ 20.04
• EKS ਨੂੰ ਅਜੇ ਤੱਕ ਇੱਕ ਹੱਲ ਮਿਲਿਆ ਹੈ ਦਸੰਬਰ 2019 ਵਿੱਚ. ਜੇਕਰ ਤੁਹਾਡਾ ਸੰਸਕਰਣ ਇਸ ਤੋਂ ਘੱਟ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ AMI ਨੂੰ ਅਪਡੇਟ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਕੋਪਸ: ਜੂਨ 2020 ਤੋਂ у kops 1.18+ ਮੁੱਖ ਹੋਸਟ ਚਿੱਤਰ ਉਬੰਟੂ 20.04 ਹੋਵੇਗਾ। ਜੇਕਰ ਕੋਪਸ ਦਾ ਤੁਹਾਡਾ ਸੰਸਕਰਣ ਪੁਰਾਣਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਫਿਕਸ ਦੀ ਉਡੀਕ ਕਰਨੀ ਪੈ ਸਕਦੀ ਹੈ। ਅਸੀਂ ਖੁਦ ਹੁਣ ਇੰਤਜ਼ਾਰ ਕਰ ਰਹੇ ਹਾਂ।
• GKE (ਗੂਗਲ ਕਲਾਉਡ): ਫਿਕਸ ਏਕੀਕ੍ਰਿਤ ਜਨਵਰੀ 2020 ਵਿੱਚ, ਹਾਲਾਂਕਿ ਥ੍ਰੋਟਲਿੰਗ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਹਨ ਅਜੇ ਵੀ ਦੇਖਿਆ ਜਾ ਰਿਹਾ ਹੈ.

ਕੀ ਕਰਨਾ ਹੈ ਜੇਕਰ ਫਿਕਸ ਨੇ ਥ੍ਰੋਟਲਿੰਗ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕੀਤਾ ਹੈ?

ਮੈਨੂੰ ਯਕੀਨ ਨਹੀਂ ਹੈ ਕਿ ਸਮੱਸਿਆ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹੱਲ ਹੋ ਗਈ ਹੈ। ਜਦੋਂ ਅਸੀਂ ਫਿਕਸ ਦੇ ਨਾਲ ਕਰਨਲ ਸੰਸਕਰਣ 'ਤੇ ਪਹੁੰਚਦੇ ਹਾਂ, ਮੈਂ ਕਲੱਸਟਰ ਦੀ ਜਾਂਚ ਕਰਾਂਗਾ ਅਤੇ ਪੋਸਟ ਨੂੰ ਅਪਡੇਟ ਕਰਾਂਗਾ। ਜੇਕਰ ਕਿਸੇ ਨੇ ਪਹਿਲਾਂ ਹੀ ਅੱਪਡੇਟ ਕੀਤਾ ਹੈ, ਤਾਂ ਮੈਂ ਤੁਹਾਡੇ ਨਤੀਜਿਆਂ ਨੂੰ ਪੜ੍ਹਨਾ ਚਾਹਾਂਗਾ।

ਸਿੱਟਾ

• ਜੇਕਰ ਤੁਸੀਂ ਲੀਨਕਸ ਦੇ ਅਧੀਨ ਡੌਕਰ ਕੰਟੇਨਰਾਂ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹੋ (ਕੋਈ ਗੱਲ ਨਹੀਂ ਕਿ ਕੁਬਰਨੇਟਸ, ਮੇਸੋਸ, ਸਵੈਰਮ ਜਾਂ ਹੋਰ), ਤੁਹਾਡੇ ਕੰਟੇਨਰ ਥ੍ਰੋਟਲਿੰਗ ਦੇ ਕਾਰਨ ਪ੍ਰਦਰਸ਼ਨ ਗੁਆ ​​ਸਕਦੇ ਹਨ;
• ਆਪਣੀ ਵੰਡ ਦੇ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਨੂੰ ਇਸ ਉਮੀਦ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ ਕਿ ਬੱਗ ਪਹਿਲਾਂ ਹੀ ਠੀਕ ਹੋ ਗਿਆ ਹੈ;
• ਪ੍ਰੋਸੈਸਰ ਪਾਬੰਦੀਆਂ ਨੂੰ ਹਟਾਉਣ ਨਾਲ ਸਮੱਸਿਆ ਹੱਲ ਹੋ ਜਾਵੇਗੀ, ਪਰ ਇਹ ਇੱਕ ਖ਼ਤਰਨਾਕ ਤਕਨੀਕ ਹੈ ਜੋ ਬਹੁਤ ਸਾਵਧਾਨੀ ਨਾਲ ਵਰਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ (ਪਹਿਲਾਂ ਕਰਨਲ ਨੂੰ ਅੱਪਡੇਟ ਕਰਨਾ ਅਤੇ ਨਤੀਜਿਆਂ ਦੀ ਤੁਲਨਾ ਕਰਨਾ ਬਿਹਤਰ ਹੈ);
• ਜੇਕਰ ਤੁਸੀਂ CPU ਸੀਮਾਵਾਂ ਨੂੰ ਹਟਾ ਦਿੱਤਾ ਹੈ, ਤਾਂ ਧਿਆਨ ਨਾਲ ਆਪਣੇ CPU ਅਤੇ ਮੈਮੋਰੀ ਵਰਤੋਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ ਅਤੇ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੇ CPU ਸਰੋਤ ਤੁਹਾਡੀ ਖਪਤ ਤੋਂ ਵੱਧ ਰਹੇ ਹਨ;
• ਇੱਕ ਸੁਰੱਖਿਅਤ ਵਿਕਲਪ ਉੱਚ ਹਾਰਡਵੇਅਰ ਲੋਡ ਹੋਣ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਨਵੇਂ ਪੌਡ ਬਣਾਉਣ ਲਈ ਆਟੋਸਕੇਲ ਪੌਡਾਂ ਦਾ ਹੋਵੇਗਾ, ਤਾਂ ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਉਹਨਾਂ ਨੂੰ ਮੁਫਤ ਨੋਡਾਂ ਲਈ ਨਿਰਧਾਰਤ ਕਰੇ।

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਪੋਸਟ ਤੁਹਾਡੇ ਕੰਟੇਨਰ ਸਿਸਟਮ ਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਬਿਹਤਰ ਬਣਾਉਣ ਵਿੱਚ ਤੁਹਾਡੀ ਮਦਦ ਕਰੇਗੀ।

PS ਇਹ ਇਸ ਲਈ ਹੈ ਲੇਖਕ ਪਾਠਕਾਂ ਅਤੇ ਟਿੱਪਣੀਕਾਰਾਂ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ (ਅੰਗਰੇਜ਼ੀ ਵਿੱਚ)।


ਸਰੋਤ: www.habr.com