ਕੁਬਰਨੇਟਸ ਵਿੱਚ CPU ਸੀਮਾਵਾਂ ਅਤੇ ਹਮਲਾਵਰ ਥ੍ਰੋਟਲਿੰਗ

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

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

TL; ਡਾ:
ਜੇਕਰ ਤੁਸੀਂ CFS ਕੋਟਾ ਬੱਗ ਦੇ ਨਾਲ ਲੀਨਕਸ ਕਰਨਲ ਦੇ ਇੱਕ ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਅਸੀਂ ਕੁਬਰਨੇਟਸ (ਜਾਂ ਕੁਬੇਲੇਟ ਵਿੱਚ CFS ਕੋਟਾ ਅਯੋਗ ਕਰਨ) ਵਿੱਚ CPU ਸੀਮਾਵਾਂ ਨੂੰ ਅਯੋਗ ਕਰਨ ਦੀ ਜ਼ੋਰਦਾਰ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ। ਕੋਰ ਵਿੱਚ ਉੱਥੇ ਹੈ ਗੰਭੀਰ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਜਾਣਿਆ ਜਾਂਦਾ ਹੈ ਇੱਕ ਬੱਗ ਜੋ ਬਹੁਤ ਜ਼ਿਆਦਾ ਥ੍ਰੋਟਲਿੰਗ ਅਤੇ ਦੇਰੀ ਵੱਲ ਲੈ ਜਾਂਦਾ ਹੈ.

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

ਲੇਖ ਦਾ ਸੰਖੇਪ:

• ਕੰਟੇਨਰਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ;
• CPU ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ;
• ਮਲਟੀ-ਕੋਰ ਵਾਤਾਵਰਨ ਵਿੱਚ CPU ਸੀਮਾ ਕਿਵੇਂ ਕੰਮ ਕਰਦੀ ਹੈ;
• CPU ਥ੍ਰੋਟਲਿੰਗ ਨੂੰ ਕਿਵੇਂ ਟ੍ਰੈਕ ਕਰਨਾ ਹੈ;
• ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਅਤੇ ਸੂਖਮਤਾ।

ਕੰਟੇਨਰਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਕੁਝ ਸ਼ਬਦ

ਕੁਬਰਨੇਟਸ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਦੀ ਦੁਨੀਆ ਵਿੱਚ ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਆਧੁਨਿਕ ਮਿਆਰ ਹੈ। ਇਸ ਦਾ ਮੁੱਖ ਕੰਮ ਕੰਟੇਨਰ ਆਰਕੈਸਟਰੇਸ਼ਨ ਹੈ।

ਕੰਟੇਨਰ

ਅਤੀਤ ਵਿੱਚ, ਸਾਨੂੰ ਸਰਵਰਾਂ 'ਤੇ ਚਲਾਉਣ ਲਈ Java JARs/WARs, Python Eggs, ਜਾਂ ਐਗਜ਼ੀਕਿਊਟੇਬਲ ਵਰਗੀਆਂ ਕਲਾਕ੍ਰਿਤੀਆਂ ਬਣਾਉਣੀਆਂ ਪੈਂਦੀਆਂ ਸਨ। ਹਾਲਾਂਕਿ, ਉਹਨਾਂ ਨੂੰ ਕੰਮ ਕਰਨ ਲਈ, ਵਾਧੂ ਕੰਮ ਕਰਨੇ ਪੈਣਗੇ: ਰਨਟਾਈਮ ਵਾਤਾਵਰਣ (ਜਾਵਾ/ਪਾਈਥਨ) ਨੂੰ ਸਥਾਪਿਤ ਕਰਨਾ, ਲੋੜੀਂਦੀਆਂ ਫਾਈਲਾਂ ਨੂੰ ਸਹੀ ਸਥਾਨਾਂ 'ਤੇ ਰੱਖਣਾ, ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੇ ਇੱਕ ਖਾਸ ਸੰਸਕਰਣ ਨਾਲ ਅਨੁਕੂਲਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣਾ, ਆਦਿ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਸੰਰਚਨਾ ਪ੍ਰਬੰਧਨ (ਜੋ ਅਕਸਰ ਡਿਵੈਲਪਰਾਂ ਅਤੇ ਸਿਸਟਮ ਪ੍ਰਸ਼ਾਸਕਾਂ ਵਿਚਕਾਰ ਵਿਵਾਦ ਦਾ ਇੱਕ ਸਰੋਤ ਹੁੰਦਾ ਸੀ) ਵੱਲ ਧਿਆਨ ਨਾਲ ਧਿਆਨ ਦੇਣਾ ਪੈਂਦਾ ਸੀ।

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

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

ਕਬਰਨੇਟਿਸ

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

ਆਮ ਆਦਮੀ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ ਕੁਬਰਨੇਟਸ

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

ਠੀਕ ਹੈ, ਅਸੀਂ ਕੰਟੇਨਰਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਨੂੰ ਕਵਰ ਕੀਤਾ ਹੈ। ਅਸੀਂ ਇਹ ਵੀ ਜਾਣਦੇ ਹਾਂ ਕਿ ਇੱਕੋ ਮਸ਼ੀਨ 'ਤੇ ਕਈ ਕੰਟੇਨਰ ਰਹਿ ਸਕਦੇ ਹਨ।

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

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

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਕੁਬਰਨੇਟਸ CPU ਸੀਮਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ ਕਰਨਲ ਵਿੱਚ ਬਣੇ ਥ੍ਰੋਟਲਿੰਗ ਵਿਧੀ (ਘੜੀ ਦੇ ਚੱਕਰ ਛੱਡਣ) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਕੋਈ ਐਪਲੀਕੇਸ਼ਨ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਥ੍ਰੋਟਲਿੰਗ ਨੂੰ ਸਮਰੱਥ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ (ਅਰਥਾਤ ਇਸ ਨੂੰ ਘੱਟ CPU ਚੱਕਰ ਪ੍ਰਾਪਤ ਹੁੰਦੇ ਹਨ)। ਮੈਮੋਰੀ ਲਈ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਸੰਗਠਿਤ ਕੀਤੀਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਇਸਲਈ ਉਹਨਾਂ ਦਾ ਪਤਾ ਲਗਾਉਣਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਅਜਿਹਾ ਕਰਨ ਲਈ, ਸਿਰਫ਼ ਪੌਡ ਦੀ ਆਖਰੀ ਰੀਸਟਾਰਟ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰੋ: ਕੀ ਇਹ "OOMKilled" ਹੈ। CPU ਥ੍ਰੋਟਲਿੰਗ ਇੰਨੀ ਸਰਲ ਨਹੀਂ ਹੈ, ਕਿਉਂਕਿ K8s ਸਿਰਫ ਵਰਤੋਂ ਦੁਆਰਾ ਮੈਟ੍ਰਿਕਸ ਉਪਲਬਧ ਕਰਵਾਉਂਦਾ ਹੈ, cgroups ਦੁਆਰਾ ਨਹੀਂ।

CPU ਬੇਨਤੀ

CPU ਬੇਨਤੀ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ

ਸਰਲਤਾ ਲਈ, ਆਉ ਇੱਕ ਉਦਾਹਰਨ ਵਜੋਂ 4-ਕੋਰ CPU ਵਾਲੀ ਮਸ਼ੀਨ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਵੇਖੀਏ।

K8s ਸਰੋਤਾਂ (ਮੈਮੋਰੀ ਅਤੇ ਪ੍ਰੋਸੈਸਰ) ਦੀ ਵੰਡ ਨੂੰ ਨਿਯੰਤਰਿਤ ਕਰਨ ਲਈ ਇੱਕ ਕੰਟਰੋਲ ਗਰੁੱਪ ਵਿਧੀ (cgroups) ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਇਸਦੇ ਲਈ ਇੱਕ ਲੜੀਵਾਰ ਮਾਡਲ ਉਪਲਬਧ ਹੈ: ਬੱਚੇ ਨੂੰ ਮਾਤਾ-ਪਿਤਾ ਸਮੂਹ ਦੀਆਂ ਸੀਮਾਵਾਂ ਪ੍ਰਾਪਤ ਹੁੰਦੀਆਂ ਹਨ। ਵੰਡ ਵੇਰਵੇ ਇੱਕ ਵਰਚੁਅਲ ਫਾਈਲ ਸਿਸਟਮ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (/sys/fs/cgroup). ਇੱਕ ਪ੍ਰੋਸੈਸਰ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਇਹ ਹੈ /sys/fs/cgroup/cpu,cpuacct/*.

K8s ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ cpu.share ਪ੍ਰੋਸੈਸਰ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ. ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਰੂਟ cgroup CPU ਸਰੋਤਾਂ ਦੇ 4096 ਸ਼ੇਅਰ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ - ਉਪਲਬਧ ਪ੍ਰੋਸੈਸਰ ਪਾਵਰ ਦਾ 100% (1 ਕੋਰ = 1024; ਇਹ ਇੱਕ ਸਥਿਰ ਮੁੱਲ ਹੈ)। ਰੂਟ ਸਮੂਹ ਵਿੱਚ ਰਜਿਸਟਰਡ ਵੰਸ਼ਜਾਂ ਦੇ ਸ਼ੇਅਰਾਂ ਦੇ ਅਧਾਰ ਤੇ ਅਨੁਪਾਤਕ ਤੌਰ 'ਤੇ ਸਰੋਤਾਂ ਨੂੰ ਵੰਡਦਾ ਹੈ cpu.share, ਅਤੇ ਉਹ, ਬਦਲੇ ਵਿੱਚ, ਆਪਣੇ ਵੰਸ਼ਜਾਂ ਨਾਲ ਵੀ ਅਜਿਹਾ ਕਰਦੇ ਹਨ, ਆਦਿ। ਇੱਕ ਆਮ ਕੁਬਰਨੇਟਸ ਨੋਡ 'ਤੇ, ਰੂਟ cgroup ਦੇ ਤਿੰਨ ਬੱਚੇ ਹਨ: system.slice, user.slice и kubepods. ਪਹਿਲੇ ਦੋ ਉਪ-ਸਮੂਹਾਂ ਦੀ ਵਰਤੋਂ K8s ਤੋਂ ਬਾਹਰ ਨਾਜ਼ੁਕ ਸਿਸਟਮ ਲੋਡ ਅਤੇ ਉਪਭੋਗਤਾ ਪ੍ਰੋਗਰਾਮਾਂ ਵਿਚਕਾਰ ਸਰੋਤਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। ਆਖਰੀ - kubepods - ਪੌਡਾਂ ਵਿਚਕਾਰ ਸਰੋਤਾਂ ਨੂੰ ਵੰਡਣ ਲਈ ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ।

ਉਪਰੋਕਤ ਚਿੱਤਰ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਪਹਿਲੇ ਅਤੇ ਦੂਜੇ ਉਪ ਸਮੂਹਾਂ ਨੇ ਹਰੇਕ ਨੂੰ ਪ੍ਰਾਪਤ ਕੀਤਾ 1024 ਸ਼ੇਅਰ, kuberpod ਸਬਗਰੁੱਪ ਅਲਾਟ ਕੀਤੇ ਗਏ ਹਨ 4096 ਸ਼ੇਅਰ ਇਹ ਕਿਵੇਂ ਸੰਭਵ ਹੈ: ਆਖ਼ਰਕਾਰ, ਰੂਟ ਸਮੂਹ ਕੋਲ ਸਿਰਫ ਪਹੁੰਚ ਹੈ 4096 ਸ਼ੇਅਰ, ਅਤੇ ਉਸਦੇ ਵੰਸ਼ਜਾਂ ਦੇ ਸ਼ੇਅਰਾਂ ਦਾ ਜੋੜ ਇਸ ਸੰਖਿਆ ਤੋਂ ਕਾਫ਼ੀ ਜ਼ਿਆਦਾ ਹੈ (6144)? ਬਿੰਦੂ ਇਹ ਹੈ ਕਿ ਮੁੱਲ ਲਾਜ਼ੀਕਲ ਅਰਥ ਰੱਖਦਾ ਹੈ, ਇਸਲਈ ਲੀਨਕਸ ਸ਼ਡਿਊਲਰ (CFS) ਇਸਦੀ ਵਰਤੋਂ CPU ਸਰੋਤਾਂ ਨੂੰ ਅਨੁਪਾਤਕ ਤੌਰ 'ਤੇ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਕਰਦਾ ਹੈ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ, ਪਹਿਲੇ ਦੋ ਸਮੂਹ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ 680 ਅਸਲ ਸ਼ੇਅਰ (16,6 ਦਾ 4096%), ਅਤੇ ਕੁਬੇਪੋਡ ਬਾਕੀ ਬਚਦਾ ਹੈ 2736 ਸ਼ੇਅਰ ਡਾਊਨਟਾਈਮ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਪਹਿਲੇ ਦੋ ਸਮੂਹ ਨਿਰਧਾਰਤ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਨਗੇ।

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

ਇਹ ਵਿਧੀ ਪ੍ਰੋਸੈਸਰ ਦੀ ਸ਼ਕਤੀ ਦੀ ਨਿਰਪੱਖ ਵੰਡ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਅਤੇ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੀ ਹੈ ਕਿ ਕੋਈ ਵੀ ਪ੍ਰਕਿਰਿਆ ਦੂਜਿਆਂ ਤੋਂ ਸਰੋਤ "ਚੋਰੀ" ਨਹੀਂ ਕਰਦਾ ਹੈ।

CPU ਸੀਮਾ

ਇਸ ਤੱਥ ਦੇ ਬਾਵਜੂਦ ਕਿ K8 ਵਿੱਚ ਸੀਮਾਵਾਂ ਅਤੇ ਬੇਨਤੀਆਂ ਦੀਆਂ ਸੰਰਚਨਾਵਾਂ ਇੱਕੋ ਜਿਹੀਆਂ ਦਿਖਾਈ ਦਿੰਦੀਆਂ ਹਨ, ਉਹਨਾਂ ਦਾ ਲਾਗੂਕਰਨ ਬਿਲਕੁਲ ਵੱਖਰਾ ਹੈ: ਇਹ ਸਭ ਗੁੰਮਰਾਹਕੁੰਨ ਅਤੇ ਸਭ ਤੋਂ ਘੱਟ ਦਸਤਾਵੇਜ਼ੀ ਹਿੱਸਾ।

K8s ਜੁੜਦਾ ਹੈ CFS ਕੋਟਾ ਵਿਧੀ ਸੀਮਾਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ. ਉਹਨਾਂ ਦੀਆਂ ਸੈਟਿੰਗਾਂ ਫਾਈਲਾਂ ਵਿੱਚ ਦਰਸਾਈਆਂ ਗਈਆਂ ਹਨ cfs_period_us и cfs_quota_us cgroup ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ (ਫਾਇਲ ਵੀ ਉੱਥੇ ਸਥਿਤ ਹੈ cpu.share).

ਉਲਟ cpu.share, ਕੋਟਾ 'ਤੇ ਆਧਾਰਿਤ ਹੈ ਸਮਾਂ ਮਿਆਦ, ਅਤੇ ਉਪਲਬਧ ਪ੍ਰੋਸੈਸਰ ਪਾਵਰ 'ਤੇ ਨਹੀਂ। cfs_period_us ਪੀਰੀਅਡ (ਯੁਗ) ਦੀ ਮਿਆਦ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ - ਇਹ ਹਮੇਸ਼ਾ 100000 μs (100 ms) ਹੁੰਦਾ ਹੈ। K8s ਵਿੱਚ ਇਸ ਮੁੱਲ ਨੂੰ ਬਦਲਣ ਦਾ ਵਿਕਲਪ ਹੈ, ਪਰ ਇਹ ਹੁਣੇ ਲਈ ਸਿਰਫ਼ ਅਲਫ਼ਾ ਵਿੱਚ ਉਪਲਬਧ ਹੈ। ਸ਼ਡਿਊਲਰ ਵਰਤੇ ਹੋਏ ਕੋਟਾ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਲਈ epoch ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ। ਦੂਜੀ ਫਾਈਲ cfs_quota_us, ਹਰੇਕ ਯੁੱਗ ਵਿੱਚ ਉਪਲਬਧ ਸਮਾਂ (ਕੋਟਾ) ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ। ਨੋਟ ਕਰੋ ਕਿ ਇਹ ਮਾਈਕ੍ਰੋਸਕਿੰਟਾਂ ਵਿੱਚ ਵੀ ਨਿਰਦਿਸ਼ਟ ਹੈ। ਕੋਟਾ ਯੁੱਗ ਦੀ ਲੰਬਾਈ ਤੋਂ ਵੱਧ ਹੋ ਸਕਦਾ ਹੈ; ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਹ 100 ms ਤੋਂ ਵੱਧ ਹੋ ਸਕਦਾ ਹੈ।

ਆਉ 16-ਕੋਰ ਮਸ਼ੀਨਾਂ (ਓਮੀਓ ਵਿੱਚ ਸਾਡੇ ਕੋਲ ਸਭ ਤੋਂ ਆਮ ਕਿਸਮ ਦਾ ਕੰਪਿਊਟਰ) ਉੱਤੇ ਦੋ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਵੇਖੀਏ:

ਦ੍ਰਿਸ਼ 1: 2 ਥ੍ਰੈੱਡ ਅਤੇ 200 ms ਸੀਮਾ। ਕੋਈ ਥ੍ਰੋਟਲਿੰਗ ਨਹੀਂ

ਦ੍ਰਿਸ਼ 2: 10 ਥ੍ਰੈੱਡ ਅਤੇ 200 ms ਸੀਮਾ। ਥਰੋਟਲਿੰਗ 20 ms ਤੋਂ ਬਾਅਦ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਪ੍ਰੋਸੈਸਰ ਸਰੋਤਾਂ ਤੱਕ ਪਹੁੰਚ ਹੋਰ 80 ms ਤੋਂ ਬਾਅਦ ਮੁੜ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ

ਮੰਨ ਲਓ ਕਿ ਤੁਸੀਂ CPU ਸੀਮਾ ਨੂੰ ਸੈੱਟ ਕੀਤਾ ਹੈ 2 ਕਰਨਲ; Kubernetes ਇਸ ਮੁੱਲ ਨੂੰ 200 ms ਵਿੱਚ ਅਨੁਵਾਦ ਕਰੇਗਾ। ਇਸਦਾ ਮਤਲਬ ਹੈ ਕਿ ਕੰਟੇਨਰ ਥ੍ਰੋਟਲਿੰਗ ਦੇ ਬਿਨਾਂ ਵੱਧ ਤੋਂ ਵੱਧ 200ms CPU ਸਮਾਂ ਵਰਤ ਸਕਦਾ ਹੈ।

ਅਤੇ ਇਹ ਉਹ ਥਾਂ ਹੈ ਜਿੱਥੇ ਮਜ਼ੇ ਦੀ ਸ਼ੁਰੂਆਤ ਹੁੰਦੀ ਹੈ. ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਉਪਲਬਧ ਕੋਟਾ 200 ਐਮ.ਐਸ. ਜੇਕਰ ਤੁਸੀਂ ਸਮਾਨਾਂਤਰ ਕੰਮ ਕਰ ਰਹੇ ਹੋ ਦਸ 12-ਕੋਰ ਮਸ਼ੀਨ 'ਤੇ ਥਰਿੱਡ (ਦ੍ਰਿਸ਼ਟੀ 2 ਲਈ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਦੇਖੋ), ਜਦੋਂ ਕਿ ਹੋਰ ਸਾਰੇ ਪੌਡ ਵਿਹਲੇ ਹਨ, ਕੋਟਾ ਸਿਰਫ਼ 20 ms (10 * 20 ms = 200 ms ਤੋਂ) ਵਿੱਚ ਖਤਮ ਹੋ ਜਾਵੇਗਾ, ਅਤੇ ਇਸ ਪੋਡ ਦੇ ਸਾਰੇ ਥ੍ਰੈੱਡ ਲਟਕ ਜਾਣਗੇ। » (ਗਲਾ) ਅਗਲੇ 80 ms ਲਈ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤਾ ਗਿਆ ਹੈ ਸ਼ਡਿਊਲਰ ਬੱਗ, ਜਿਸ ਕਾਰਨ ਬਹੁਤ ਜ਼ਿਆਦਾ ਥਰੋਟਲਿੰਗ ਹੁੰਦੀ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਮੌਜੂਦਾ ਕੋਟੇ ਨੂੰ ਵੀ ਪੂਰਾ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ।

ਪੌਡਾਂ ਵਿੱਚ ਥ੍ਰੋਟਲਿੰਗ ਦਾ ਮੁਲਾਂਕਣ ਕਿਵੇਂ ਕਰੀਏ?

ਬਸ ਪੌਡ ਵਿੱਚ ਲੌਗਇਨ ਕਰੋ ਅਤੇ ਚਲਾਓ cat /sys/fs/cgroup/cpu/cpu.stat.

• nr_periods - ਸ਼ਡਿਊਲਰ ਪੀਰੀਅਡਾਂ ਦੀ ਕੁੱਲ ਗਿਣਤੀ;
• nr_throttled - ਰਚਨਾ ਵਿੱਚ ਥ੍ਰੋਟਲਡ ਪੀਰੀਅਡਾਂ ਦੀ ਗਿਣਤੀ nr_periods;
• throttled_time - ਨੈਨੋ ਸਕਿੰਟਾਂ ਵਿੱਚ ਸੰਚਤ ਥ੍ਰੋਟਲਡ ਸਮਾਂ।

ਅਸਲ ਵਿੱਚ ਕੀ ਹੋ ਰਿਹਾ ਹੈ?

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

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

ਫੈਸਲਾ ਅਤੇ ਨਤੀਜੇ

ਇੱਥੇ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ. ਅਸੀਂ CPU ਸੀਮਾਵਾਂ ਨੂੰ ਛੱਡ ਦਿੱਤਾ ਹੈ ਅਤੇ ਕਲੱਸਟਰਾਂ ਵਿੱਚ OS ਕਰਨਲ ਨੂੰ ਨਵੀਨਤਮ ਸੰਸਕਰਣ ਵਿੱਚ ਅੱਪਡੇਟ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੱਤਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬੱਗ ਫਿਕਸ ਕੀਤਾ ਗਿਆ ਸੀ। ਸਾਡੀਆਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਤਰੁੱਟੀਆਂ (HTTP 5xx) ਦੀ ਸੰਖਿਆ ਵਿੱਚ ਤੁਰੰਤ ਮਹੱਤਵਪੂਰਨ ਗਿਰਾਵਟ ਆਈ:

HTTP 5xx ਗਲਤੀਆਂ

ਇੱਕ ਨਾਜ਼ੁਕ ਸੇਵਾ ਲਈ HTTP 5xx ਗਲਤੀਆਂ

ਜਵਾਬ ਸਮਾਂ p95

ਗੰਭੀਰ ਸੇਵਾ ਬੇਨਤੀ ਲੇਟੈਂਸੀ, 95ਵਾਂ ਪ੍ਰਤੀਸ਼ਤ

ਓਪਰੇਟਿੰਗ ਖਰਚੇ

ਬਿਤਾਏ ਗਏ ਉਦਾਹਰਨ ਘੰਟਿਆਂ ਦੀ ਸੰਖਿਆ

ਕੈਚ ਕੀ ਹੈ?

ਜਿਵੇਂ ਕਿ ਲੇਖ ਦੇ ਸ਼ੁਰੂ ਵਿੱਚ ਕਿਹਾ ਗਿਆ ਹੈ:

ਇੱਕ ਸੰਪਰਦਾਇਕ ਅਪਾਰਟਮੈਂਟ ਨਾਲ ਇੱਕ ਸਮਾਨਤਾ ਖਿੱਚੀ ਜਾ ਸਕਦੀ ਹੈ... ਕੁਬਰਨੇਟਸ ਇੱਕ ਰੀਅਲਟਰ ਵਜੋਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਪਰ ਕਿਰਾਏਦਾਰਾਂ ਨੂੰ ਇਕ ਦੂਜੇ ਨਾਲ ਟਕਰਾਅ ਤੋਂ ਕਿਵੇਂ ਰੱਖਣਾ ਹੈ? ਉਦੋਂ ਕੀ ਜੇ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਕੋਈ, ਕਹੋ, ਅੱਧੇ ਦਿਨ ਲਈ ਬਾਥਰੂਮ ਉਧਾਰ ਲੈਣ ਦਾ ਫੈਸਲਾ ਕਰਦਾ ਹੈ?

ਇੱਥੇ ਕੈਚ ਹੈ. ਇੱਕ ਲਾਪਰਵਾਹ ਕੰਟੇਨਰ ਇੱਕ ਮਸ਼ੀਨ 'ਤੇ ਉਪਲਬਧ ਸਾਰੇ CPU ਸਰੋਤਾਂ ਨੂੰ ਖਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਮਾਰਟ ਐਪਲੀਕੇਸ਼ਨ ਸਟੈਕ ਹੈ (ਉਦਾਹਰਣ ਲਈ, ਜੇਵੀਐਮ, ਗੋ, ਨੋਡ ਵੀਐਮ ਸਹੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਹਨ), ਤਾਂ ਇਹ ਕੋਈ ਸਮੱਸਿਆ ਨਹੀਂ ਹੈ: ਤੁਸੀਂ ਲੰਬੇ ਸਮੇਂ ਲਈ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ। ਪਰ ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਮਾੜੇ ਅਨੁਕੂਲਿਤ ਹਨ ਜਾਂ ਬਿਲਕੁਲ ਅਨੁਕੂਲ ਨਹੀਂ ਹਨ (FROM java:latest) ਸਥਿਤੀ ਕਾਬੂ ਤੋਂ ਬਾਹਰ ਹੋ ਸਕਦੀ ਹੈ। ਓਮੀਓ ਵਿਖੇ ਸਾਡੇ ਕੋਲ ਮੁੱਖ ਭਾਸ਼ਾ ਸਟੈਕ ਲਈ ਢੁਕਵੀਂ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਆਟੋਮੇਟਿਡ ਬੇਸ ਡੌਕਰਫਾਈਲਾਂ ਹਨ, ਇਸਲਈ ਇਹ ਮੁੱਦਾ ਮੌਜੂਦ ਨਹੀਂ ਸੀ।

ਅਸੀਂ ਮੈਟ੍ਰਿਕਸ ਦੀ ਨਿਗਰਾਨੀ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕਰਦੇ ਹਾਂ ਵਰਤੋਂ (ਵਰਤੋਂ, ਸੰਤ੍ਰਿਪਤਾ ਅਤੇ ਤਰੁੱਟੀਆਂ), API ਦੇਰੀ ਅਤੇ ਗਲਤੀ ਦਰਾਂ। ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਨਤੀਜੇ ਉਮੀਦਾਂ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ।

ਹਵਾਲੇ

ਇਹ ਸਾਡੀ ਕਹਾਣੀ ਹੈ। ਹੇਠ ਲਿਖੀਆਂ ਸਮੱਗਰੀਆਂ ਨੇ ਇਹ ਸਮਝਣ ਵਿੱਚ ਬਹੁਤ ਮਦਦ ਕੀਤੀ ਕਿ ਕੀ ਹੋ ਰਿਹਾ ਸੀ:

• kernel.org → CFS ਸ਼ਡਿਊਲਰ;
• kernel.org → CFS ਬੈਂਡਵਿਡਥ ਕੰਟਰੋਲ;
• ਲੀਨਕਸ ਕੰਟੇਨਰ ਸ਼ਡਿਊਲਿੰਗ ਨੂੰ ਸਮਝਣਾ;
• ਲੀਨਕਸ ਕੰਟੇਨਰਾਂ ਬਾਰੇ ਤੁਹਾਨੂੰ ਸਭ ਕੁਝ ਜਾਣਨ ਦੀ ਲੋੜ ਹੈ, ਭਾਗ I: ਲੀਨਕਸ ਕੰਟਰੋਲ ਸਮੂਹ ਅਤੇ ਪ੍ਰਕਿਰਿਆ ਅਲੱਗ-ਥਲੱਗ;
• ਕੁਬਰਨੇਟਸ ਅਸਫਲਤਾ ਦੀਆਂ ਕਹਾਣੀਆਂ - "cpu ਥ੍ਰੋਟਲਿੰਗ" ਦੀ ਭਾਲ ਕਰੋ।

ਕੁਬਰਨੇਟਸ ਬੱਗ ਰਿਪੋਰਟਾਂ:

• #51135: ਗਰੰਟੀਸ਼ੁਦਾ ਪੌਡਾਂ ਲਈ CPU ਸੀਮਾਵਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨ ਤੋਂ ਬਚੋ;
• #67577: CFS ਕੋਟਾ ਬੇਲੋੜੀ ਥ੍ਰੋਟਲਿੰਗ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦਾ ਹੈ;
• ਬਹੁਤ ਜ਼ਿਆਦਾ ਹਮਲਾਵਰ CFS.

ਕੀ ਤੁਹਾਨੂੰ ਆਪਣੇ ਅਭਿਆਸ ਵਿੱਚ ਸਮਾਨ ਸਮੱਸਿਆਵਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਹੈ ਜਾਂ ਕੰਟੇਨਰਾਈਜ਼ਡ ਉਤਪਾਦਨ ਵਾਤਾਵਰਣਾਂ ਵਿੱਚ ਥ੍ਰੋਟਲਿੰਗ ਨਾਲ ਸਬੰਧਤ ਅਨੁਭਵ ਹੈ? ਟਿੱਪਣੀਆਂ ਵਿੱਚ ਆਪਣੀ ਕਹਾਣੀ ਸਾਂਝੀ ਕਰੋ!

ਅਨੁਵਾਦਕ ਤੋਂ ਪੀ.ਐਸ

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਵੀ ਪੜ੍ਹੋ:

• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ CPU ਮੈਨੇਜਰ ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ";
• «ਜਦੋਂ ਤੁਸੀਂ kubectl ਰਨ ਚਲਾਉਂਦੇ ਹੋ ਤਾਂ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਕੀ ਹੁੰਦਾ ਹੈ? ਭਾਗ 2".

ਸਰੋਤ: www.habr.com