ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ (ਸੰਖੇਪ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ)

ਕਾਨਫਰੰਸ ਵਿਚ 27 ਅਪ੍ਰੈਲ ਨੂੰ ਹੜਤਾਲ 2019, "DevOps" ਭਾਗ ਦੇ ਹਿੱਸੇ ਵਜੋਂ, ਰਿਪੋਰਟ "ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ" ਦਿੱਤੀ ਗਈ ਸੀ। ਇਹ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਆਪਣੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੀ ਉੱਚ ਉਪਲਬਧਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਅਤੇ ਉੱਚ ਪ੍ਰਦਰਸ਼ਨ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ K8s ਦੀ ਵਰਤੋਂ ਕਿਵੇਂ ਕਰ ਸਕਦੇ ਹੋ।

ਪਰੰਪਰਾ ਦੁਆਰਾ, ਅਸੀਂ ਪੇਸ਼ ਕਰਨ ਲਈ ਖੁਸ਼ ਹਾਂ ਰਿਪੋਰਟ ਦੀ ਵੀਡੀਓ (44 ਮਿੰਟ, ਲੇਖ ਨਾਲੋਂ ਬਹੁਤ ਜ਼ਿਆਦਾ ਜਾਣਕਾਰੀ ਭਰਪੂਰ) ਅਤੇ ਪਾਠ ਰੂਪ ਵਿੱਚ ਮੁੱਖ ਸੰਖੇਪ। ਜਾਣਾ!

ਆਉ ਰਿਪੋਰਟ ਸ਼ਬਦ ਦੇ ਵਿਸ਼ੇ ਦਾ ਸ਼ਬਦ ਦੁਆਰਾ ਵਿਸ਼ਲੇਸ਼ਣ ਕਰੀਏ ਅਤੇ ਅੰਤ ਤੋਂ ਸ਼ੁਰੂ ਕਰੀਏ।

ਕਬਰਨੇਟਿਸ

ਮੰਨ ਲਓ ਕਿ ਸਾਡੇ ਮੇਜ਼ਬਾਨ 'ਤੇ ਡੌਕਰ ਕੰਟੇਨਰ ਹਨ। ਕਾਹਦੇ ਲਈ? ਦੁਹਰਾਉਣਯੋਗਤਾ ਅਤੇ ਅਲੱਗ-ਥਲੱਗਤਾ ਨੂੰ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ, ਜੋ ਬਦਲੇ ਵਿੱਚ ਸਧਾਰਨ ਅਤੇ ਚੰਗੀ ਤੈਨਾਤੀ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, CI/CD. ਸਾਡੇ ਕੋਲ ਕੰਟੇਨਰਾਂ ਵਾਲੇ ਅਜਿਹੇ ਕਈ ਵਾਹਨ ਹਨ।

ਕੁਬਰਨੇਟਸ ਇਸ ਕੇਸ ਵਿੱਚ ਕੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ?

1. ਅਸੀਂ ਇਹਨਾਂ ਮਸ਼ੀਨਾਂ ਬਾਰੇ ਸੋਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹਾਂ ਅਤੇ "ਕਲਾਊਡ" ਨਾਲ ਕੰਮ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦੇ ਹਾਂ। ਕੰਟੇਨਰਾਂ ਦਾ ਸਮੂਹ ਜਾਂ ਫਲੀਆਂ (ਡੱਬਿਆਂ ਦੇ ਸਮੂਹ)।
2. ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਵਿਅਕਤੀਗਤ ਪੌਡਾਂ ਬਾਰੇ ਵੀ ਨਹੀਂ ਸੋਚਦੇ, ਪਰ ਹੋਰ ਪ੍ਰਬੰਧ ਕਰਦੇ ਹਾਂоਵੱਡੇ ਸਮੂਹ. ਅਜਿਹੇ ਉੱਚ-ਪੱਧਰ ਦੇ ਮੁੱਢਲੇ ਸਾਨੂੰ ਇਹ ਕਹਿਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿਓ ਕਿ ਇੱਕ ਖਾਸ ਵਰਕਲੋਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਇੱਕ ਟੈਂਪਲੇਟ ਹੈ, ਅਤੇ ਇੱਥੇ ਇਸਨੂੰ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਉਦਾਹਰਨਾਂ ਦੀ ਗਿਣਤੀ ਹੈ। ਜੇਕਰ ਅਸੀਂ ਬਾਅਦ ਵਿੱਚ ਟੈਂਪਲੇਟ ਨੂੰ ਬਦਲਦੇ ਹਾਂ, ਤਾਂ ਸਾਰੀਆਂ ਉਦਾਹਰਣਾਂ ਬਦਲ ਜਾਣਗੀਆਂ।
3. ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਘੋਸ਼ਣਾਤਮਕ API ਖਾਸ ਕਮਾਂਡਾਂ ਦੇ ਕ੍ਰਮ ਨੂੰ ਚਲਾਉਣ ਦੀ ਬਜਾਏ, ਅਸੀਂ "ਸੰਸਾਰ ਦੀ ਬਣਤਰ" (YAML ਵਿੱਚ) ਦਾ ਵਰਣਨ ਕਰਦੇ ਹਾਂ, ਜੋ ਕਿ ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਬਣਾਇਆ ਗਿਆ ਹੈ। ਅਤੇ ਦੁਬਾਰਾ: ਜਦੋਂ ਵਰਣਨ ਬਦਲਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਅਸਲ ਡਿਸਪਲੇ ਵੀ ਬਦਲ ਜਾਵੇਗਾ।

ਸਰੋਤ ਪ੍ਰਬੰਧਨ

CPU

ਆਉ ਸਰਵਰ ਤੇ nginx, php-fpm ਅਤੇ mysql ਨੂੰ ਚਲਾਉਂਦੇ ਹਾਂ। ਇਹਨਾਂ ਸੇਵਾਵਾਂ ਵਿੱਚ ਅਸਲ ਵਿੱਚ ਹੋਰ ਵੀ ਪ੍ਰਕਿਰਿਆਵਾਂ ਚੱਲ ਰਹੀਆਂ ਹੋਣਗੀਆਂ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ:

(ਸਲਾਈਡ 'ਤੇ ਨੰਬਰ "ਤੋਤੇ" ਹਨ, ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਲਈ ਹਰੇਕ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸੰਖੇਪ ਲੋੜ)

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

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

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

ਆਓ ਇਹਨਾਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ CPU ਲੋੜਾਂ 'ਤੇ ਵਾਪਸ ਚਲੀਏ, ਅਤੇ ਹੁਣ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਸਮੂਹਾਂ ਲਈ:

(ਮੈਂ ਦੁਹਰਾਉਂਦਾ ਹਾਂ ਕਿ ਸਾਰੀਆਂ ਸੰਖਿਆਵਾਂ ਸਰੋਤਾਂ ਦੀ ਜ਼ਰੂਰਤ ਦਾ ਇੱਕ ਸੰਖੇਪ ਪ੍ਰਗਟਾਵਾ ਹਨ)

ਇਸ ਦੇ ਨਾਲ ਹੀ, CPU ਵਿੱਚ ਆਪਣੇ ਆਪ ਵਿੱਚ ਇੱਕ ਨਿਸ਼ਚਿਤ ਸੀਮਿਤ ਸਰੋਤ ਹੈ (ਉਦਾਹਰਨ ਵਿੱਚ ਇਹ 1000 ਹੈ), ਜਿਸ ਦੀ ਹਰ ਕਿਸੇ ਕੋਲ ਕਮੀ ਹੋ ਸਕਦੀ ਹੈ (ਸਾਰੇ ਸਮੂਹਾਂ ਦੀਆਂ ਲੋੜਾਂ ਦਾ ਜੋੜ 150+850+460=1460 ਹੈ)। ਇਸ ਮਾਮਲੇ ਵਿੱਚ ਕੀ ਹੋਵੇਗਾ?

ਕਰਨਲ ਸਰੋਤਾਂ ਨੂੰ ਵੰਡਣਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸਨੂੰ "ਨਿਰਪੱਖ ਢੰਗ ਨਾਲ" ਕਰਦਾ ਹੈ, ਹਰੇਕ ਸਮੂਹ ਨੂੰ ਸਮਾਨ ਮਾਤਰਾ ਵਿੱਚ ਸਰੋਤ ਦਿੰਦਾ ਹੈ। ਪਰ ਪਹਿਲੇ ਕੇਸ ਵਿੱਚ, ਉਹਨਾਂ ਵਿੱਚੋਂ ਲੋੜ ਤੋਂ ਵੱਧ ਹਨ (333>150), ਇਸਲਈ ਵਾਧੂ (333-150=183) ਰਿਜ਼ਰਵ ਵਿੱਚ ਰਹਿੰਦਾ ਹੈ, ਜੋ ਕਿ ਦੋ ਹੋਰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਬਰਾਬਰ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ:

ਨਤੀਜੇ ਵਜੋਂ: ਪਹਿਲੇ ਕੰਟੇਨਰ ਕੋਲ ਲੋੜੀਂਦੇ ਸਰੋਤ ਸਨ, ਦੂਜੇ ਵਿੱਚ - ਇਸਦੇ ਕੋਲ ਲੋੜੀਂਦੇ ਸਰੋਤ ਨਹੀਂ ਸਨ, ਤੀਜੇ ਵਿੱਚ - ਇਸਦੇ ਕੋਲ ਲੋੜੀਂਦੇ ਸਰੋਤ ਨਹੀਂ ਸਨ। ਇਹ ਕਾਰਵਾਈਆਂ ਦਾ ਨਤੀਜਾ ਹੈ ਲੀਨਕਸ ਵਿੱਚ "ਇਮਾਨਦਾਰ" ਸ਼ਡਿਊਲਰ - CFS. ਇਸਦੀ ਕਾਰਵਾਈ ਨੂੰ ਅਸਾਈਨਮੈਂਟ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਐਡਜਸਟ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ ਵਜ਼ਨ ਕੰਟੇਨਰ ਦੇ ਹਰ. ਉਦਾਹਰਨ ਲਈ, ਇਸ ਤਰ੍ਹਾਂ:

ਆਉ ਦੂਜੇ ਕੰਟੇਨਰ (php-fpm) ਵਿੱਚ ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਦੇ ਮਾਮਲੇ ਨੂੰ ਵੇਖੀਏ. ਸਾਰੇ ਕੰਟੇਨਰ ਸਰੋਤ ਪ੍ਰਕਿਰਿਆਵਾਂ ਵਿਚਕਾਰ ਬਰਾਬਰ ਵੰਡੇ ਜਾਂਦੇ ਹਨ। ਨਤੀਜੇ ਵਜੋਂ, ਮਾਸਟਰ ਪ੍ਰਕਿਰਿਆ ਚੰਗੀ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦੀ ਹੈ, ਪਰ ਸਾਰੇ ਕਰਮਚਾਰੀ ਹੌਲੀ ਹੋ ਜਾਂਦੇ ਹਨ, ਉਹਨਾਂ ਨੂੰ ਲੋੜੀਂਦੀ ਅੱਧੇ ਤੋਂ ਵੀ ਘੱਟ ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ:

CFS ਸ਼ਡਿਊਲਰ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰਦਾ ਹੈ। ਅਸੀਂ ਅੱਗੇ ਉਹਨਾਂ ਵਜ਼ਨ ਨੂੰ ਕਾਲ ਕਰਾਂਗੇ ਜੋ ਅਸੀਂ ਕੰਟੇਨਰਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ ਬੇਨਤੀਆਂ. ਅਜਿਹਾ ਕਿਉਂ ਹੈ - ਅੱਗੇ ਦੇਖੋ।

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

ਇਸ ਪਹੁੰਚ ਨੂੰ ਹਾਰਡ ਕੋਟਾ ਕਿਹਾ ਜਾਂਦਾ ਹੈ (ਸਖਤ ਸੀਮਤ). ਦੇ ਇਸ ਨੂੰ ਸਧਾਰਨ ਤੌਰ 'ਤੇ ਯਾਦ ਕਰੀਏ ਸੀਮਾਵਾਂ. ਹਾਲਾਂਕਿ, ਜੇਕਰ ਤੁਸੀਂ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਸੀਮਾਵਾਂ ਵੰਡਦੇ ਹੋ, ਤਾਂ ਇੱਕ ਸਮੱਸਿਆ ਪੈਦਾ ਹੁੰਦੀ ਹੈ: mysql ਸੜਕ ਦੇ ਨਾਲ ਗੱਡੀ ਚਲਾ ਰਿਹਾ ਸੀ ਅਤੇ ਕਿਸੇ ਸਮੇਂ CPU ਲਈ ਇਸਦੀ ਲੋੜ ਖਤਮ ਹੋ ਗਈ ਸੀ, ਪਰ ਹੋਰ ਸਾਰੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ CPU ਤੱਕ ਉਡੀਕ ਕਰਨ ਲਈ ਮਜਬੂਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ. ਵਿਹਲਾ.

ਚਲੋ ਲੀਨਕਸ ਕਰਨਲ ਅਤੇ CPU ਨਾਲ ਇਸ ਦੇ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਤੇ ਵਾਪਸ ਆਓ - ਸਮੁੱਚੀ ਤਸਵੀਰ ਇਸ ਪ੍ਰਕਾਰ ਹੈ:

cgroup ਦੀਆਂ ਦੋ ਸੈਟਿੰਗਾਂ ਹਨ - ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ ਇਹ ਦੋ ਸਧਾਰਨ "ਮੋੜ" ਹਨ ਜੋ ਤੁਹਾਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਦਿੰਦੇ ਹਨ:

1. ਕੰਟੇਨਰ (ਬੇਨਤੀ) ਲਈ ਭਾਰ ਹੈ ਸ਼ੇਅਰ;
2. ਕੰਟੇਨਰ ਕੰਮਾਂ (ਸੀਮਾਵਾਂ) 'ਤੇ ਕੰਮ ਕਰਨ ਲਈ ਕੁੱਲ CPU ਸਮੇਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਹੈ ਕੋਟਾ.

CPU ਨੂੰ ਕਿਵੇਂ ਮਾਪਣਾ ਹੈ?

ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਹਨ:

1. ਕੀ ਤੋਤੇ, ਕੋਈ ਨਹੀਂ ਜਾਣਦਾ - ਤੁਹਾਨੂੰ ਹਰ ਵਾਰ ਗੱਲਬਾਤ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ।
2. ਵਿਆਜ ਸਪਸ਼ਟ, ਪਰ ਅਨੁਸਾਰੀ: 50 ਕੋਰ ਅਤੇ 4 ਕੋਰ ਵਾਲੇ ਸਰਵਰ ਦਾ 20% ਪੂਰੀ ਤਰ੍ਹਾਂ ਵੱਖਰੀਆਂ ਚੀਜ਼ਾਂ ਹਨ।
3. ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਦੱਸੇ ਗਏ ਲੋਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ ਵਜ਼ਨ, ਜੋ ਲੀਨਕਸ ਜਾਣਦਾ ਹੈ, ਪਰ ਉਹ ਰਿਸ਼ਤੇਦਾਰ ਵੀ ਹਨ।
4. ਵਿੱਚ ਕੰਪਿਊਟਿੰਗ ਸਰੋਤਾਂ ਨੂੰ ਮਾਪਣ ਲਈ ਸਭ ਤੋਂ ਢੁਕਵਾਂ ਵਿਕਲਪ ਹੈ ਸਕਿੰਟ. ਉਹ. ਰੀਅਲ ਟਾਈਮ ਦੇ ਸਕਿੰਟਾਂ ਦੇ ਮੁਕਾਬਲੇ ਪ੍ਰੋਸੈਸਰ ਸਮੇਂ ਦੇ ਸਕਿੰਟਾਂ ਵਿੱਚ: ਪ੍ਰੋਸੈਸਰ ਸਮੇਂ ਦਾ 1 ਸਕਿੰਟ ਪ੍ਰਤੀ 1 ਰੀਅਲ ਸਕਿੰਟ ਦਿੱਤਾ ਗਿਆ ਸੀ - ਇਹ ਇੱਕ ਪੂਰਾ CPU ਕੋਰ ਹੈ।

ਇਸ ਨੂੰ ਬੋਲਣਾ ਹੋਰ ਵੀ ਆਸਾਨ ਬਣਾਉਣ ਲਈ, ਉਹ ਸਿੱਧੇ ਅੰਦਰ ਮਾਪਣ ਲੱਗੇ ਕਰਨਲ, ਉਹਨਾਂ ਦੁਆਰਾ ਮਤਲਬ ਕਿ ਅਸਲ ਦੇ ਮੁਕਾਬਲੇ ਉਹੀ CPU ਸਮਾਂ। ਕਿਉਂਕਿ ਲੀਨਕਸ ਵਜ਼ਨ ਨੂੰ ਸਮਝਦਾ ਹੈ, ਪਰ ਇੰਨਾ ਜ਼ਿਆਦਾ CPU ਸਮਾਂ/ਕੋਰ ਨਹੀਂ, ਇੱਕ ਤੋਂ ਦੂਜੇ ਵਿੱਚ ਅਨੁਵਾਦ ਕਰਨ ਲਈ ਇੱਕ ਵਿਧੀ ਦੀ ਲੋੜ ਸੀ।

ਆਉ 3 CPU ਕੋਰ ਵਾਲੇ ਸਰਵਰ ਦੇ ਨਾਲ ਇੱਕ ਸਧਾਰਨ ਉਦਾਹਰਨ 'ਤੇ ਵਿਚਾਰ ਕਰੀਏ, ਜਿੱਥੇ ਤਿੰਨ ਪੌਡਾਂ ਨੂੰ ਵਜ਼ਨ (500, 1000 ਅਤੇ 1500) ਦਿੱਤੇ ਜਾਣਗੇ ਜੋ ਉਹਨਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਕੋਰਾਂ (0,5, 1 ਅਤੇ 1,5) ਦੇ ਅਨੁਸਾਰੀ ਹਿੱਸਿਆਂ ਵਿੱਚ ਆਸਾਨੀ ਨਾਲ ਬਦਲ ਜਾਂਦੇ ਹਨ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਦੂਜਾ ਸਰਵਰ ਲੈਂਦੇ ਹੋ, ਜਿੱਥੇ ਦੁੱਗਣੇ ਕੋਰ (6) ਹੋਣਗੇ, ਅਤੇ ਉੱਥੇ ਉਹੀ ਪੌਡ ਰੱਖੋ, ਤਾਂ ਕੋਰਾਂ ਦੀ ਵੰਡ ਨੂੰ ਕ੍ਰਮਵਾਰ 2 (1, 2 ਅਤੇ 3, ਕ੍ਰਮਵਾਰ) ਨਾਲ ਗੁਣਾ ਕਰਕੇ ਆਸਾਨੀ ਨਾਲ ਗਿਣਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਪਰ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਪਲ ਉਦੋਂ ਵਾਪਰਦਾ ਹੈ ਜਦੋਂ ਇਸ ਸਰਵਰ 'ਤੇ ਇੱਕ ਚੌਥਾ ਪੌਡ ਦਿਖਾਈ ਦਿੰਦਾ ਹੈ, ਜਿਸਦਾ ਭਾਰ, ਸਹੂਲਤ ਲਈ, 3000 ਹੋਵੇਗਾ। ਇਹ CPU ਸਰੋਤਾਂ (ਅੱਧੇ ਕੋਰ) ਦਾ ਹਿੱਸਾ ਲੈ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਬਾਕੀ ਪੌਡਾਂ ਲਈ ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਗਣਨਾ (ਅੱਧਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ):

ਕੁਬਰਨੇਟਸ ਅਤੇ CPU ਸਰੋਤ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ, CPU ਸਰੋਤਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ millidrax, i.e. 0,001 ਕੋਰ ਨੂੰ ਬੇਸ ਵੇਟ ਵਜੋਂ ਲਿਆ ਜਾਂਦਾ ਹੈ। (ਲੀਨਕਸ/cgroups ਸ਼ਬਦਾਵਲੀ ਵਿੱਚ ਇੱਕੋ ਚੀਜ਼ ਨੂੰ ਇੱਕ CPU ਸ਼ੇਅਰ ਕਿਹਾ ਜਾਂਦਾ ਹੈ, ਹਾਲਾਂਕਿ, ਹੋਰ ਸਹੀ ਰੂਪ ਵਿੱਚ, 1000 ਮਿਲੀਕੋਰ = 1024 CPU ਸ਼ੇਅਰ।) K8s ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਇਹ ਸਰਵਰ 'ਤੇ ਸਾਰੇ ਪੌਡਾਂ ਦੇ ਵਜ਼ਨ ਦੇ ਜੋੜ ਲਈ CPU ਸਰੋਤਾਂ ਨਾਲੋਂ ਜ਼ਿਆਦਾ ਪੌਡ ਨਹੀਂ ਰੱਖਦਾ ਹੈ।

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

ਕੀ ਹੋਵੇਗਾ ਜੇ ਨਾ ਬੇਨਤੀ ਨਿਸ਼ਚਿਤ ਕੀਤੀ ਗਈ ਹੈ (ਜਿਵੇਂ ਕਿ ਪੌਡ ਕੋਲ ਲੋੜੀਂਦੇ ਕੋਰਾਂ ਦੀ ਇੱਕ ਪਰਿਭਾਸ਼ਿਤ ਸੰਖਿਆ ਨਹੀਂ ਹੈ)? ਆਓ ਇਹ ਪਤਾ ਲਗਾਓ ਕਿ ਕੁਬਰਨੇਟਸ ਆਮ ਤੌਰ 'ਤੇ ਸਰੋਤਾਂ ਦੀ ਗਿਣਤੀ ਕਿਵੇਂ ਕਰਦੇ ਹਨ।

ਇੱਕ ਪੌਡ ਲਈ ਤੁਸੀਂ ਬੇਨਤੀਆਂ (CFS ਸ਼ਡਿਊਲਰ) ਅਤੇ ਸੀਮਾਵਾਂ (ਟ੍ਰੈਫਿਕ ਲਾਈਟ ਨੂੰ ਯਾਦ ਰੱਖੋ?):

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

ਮੈਮੋਰੀ

ਮੈਮੋਰੀ ਦੇ ਨਾਲ, ਸਥਿਤੀ ਸਮਾਨ ਹੈ, ਪਰ ਥੋੜ੍ਹਾ ਵੱਖਰਾ ਹੈ - ਆਖ਼ਰਕਾਰ, ਇਹਨਾਂ ਸਰੋਤਾਂ ਦੀ ਪ੍ਰਕਿਰਤੀ ਵੱਖਰੀ ਹੈ. ਆਮ ਤੌਰ 'ਤੇ, ਸਮਾਨਤਾ ਇਸ ਤਰ੍ਹਾਂ ਹੈ:

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

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

ਚਲੋ CPU ਦੀਆਂ QoS ਕਲਾਸਾਂ 'ਤੇ ਵਾਪਸ ਚੱਲੀਏ ਅਤੇ oom_score_adj ਮੁੱਲਾਂ ਨਾਲ ਸਮਾਨਤਾ ਬਣਾਈਏ ਜੋ ਪੌਡਾਂ ਲਈ ਮੈਮੋਰੀ ਦੀ ਖਪਤ ਦੀਆਂ ਤਰਜੀਹਾਂ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ:

• ਇੱਕ ਪੌਡ ਲਈ ਸਭ ਤੋਂ ਘੱਟ oom_score_adj ਮੁੱਲ - -998 - ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਅਜਿਹੀ ਪੌਡ ਨੂੰ ਆਖਰੀ ਵਾਰ ਮਾਰਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ, ਇਹ ਗਾਰੰਟੀ.
• ਸਭ ਤੋਂ ਵੱਧ - 1000 - ਹੈ ਵਧੀਆ ਕੋਸ਼ਿਸ਼, ਅਜਿਹੀਆਂ ਫਲੀਆਂ ਨੂੰ ਪਹਿਲਾਂ ਮਾਰਿਆ ਜਾਂਦਾ ਹੈ।
• ਬਾਕੀ ਮੁੱਲਾਂ ਦੀ ਗਣਨਾ ਕਰਨ ਲਈ (ਫਟਣਯੋਗ) ਇੱਕ ਫਾਰਮੂਲਾ ਹੈ, ਜਿਸਦਾ ਸਾਰ ਇਸ ਤੱਥ 'ਤੇ ਉਬਾਲਦਾ ਹੈ ਕਿ ਇੱਕ ਪੌਡ ਨੇ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਸਰੋਤਾਂ ਦੀ ਬੇਨਤੀ ਕੀਤੀ ਹੈ, ਓਨੀ ਹੀ ਘੱਟ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਇਸਨੂੰ ਮਾਰਿਆ ਜਾਵੇਗਾ।

ਦੂਜਾ "ਮੋੜ" - limit_in_bytes - ਸੀਮਾਵਾਂ ਲਈ. ਇਸਦੇ ਨਾਲ, ਸਭ ਕੁਝ ਸੌਖਾ ਹੈ: ਅਸੀਂ ਜਾਰੀ ਕੀਤੀ ਮੈਮੋਰੀ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਤਰਾ ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਾਂ, ਅਤੇ ਇੱਥੇ (ਸੀਪੀਯੂ ਦੇ ਉਲਟ) ਇਸ (ਮੈਮੋਰੀ) ਨੂੰ ਕਿਵੇਂ ਮਾਪਣਾ ਹੈ ਇਸਦਾ ਕੋਈ ਸਵਾਲ ਨਹੀਂ ਹੈ.

ਕੁੱਲ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਹਰੇਕ ਪੌਡ ਦਿੱਤਾ ਗਿਆ ਹੈ requests и limits - CPU ਅਤੇ ਮੈਮੋਰੀ ਲਈ ਦੋਵੇਂ ਪੈਰਾਮੀਟਰ:

1. ਬੇਨਤੀਆਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਕੁਬਰਨੇਟਸ ਸ਼ਡਿਊਲਰ ਕੰਮ ਕਰਦਾ ਹੈ, ਜੋ ਸਰਵਰਾਂ ਵਿਚਕਾਰ ਪੌਡ ਵੰਡਦਾ ਹੈ;
2. ਸਾਰੇ ਮਾਪਦੰਡਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਪੌਡ ਦੀ QoS ਕਲਾਸ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
3. CPU ਬੇਨਤੀਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਬੰਧਿਤ ਵਜ਼ਨ ਦੀ ਗਣਨਾ ਕੀਤੀ ਜਾਂਦੀ ਹੈ;
4. CFS ਸ਼ਡਿਊਲਰ ਨੂੰ CPU ਬੇਨਤੀਆਂ ਦੇ ਆਧਾਰ 'ਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ;
5. OOM ਕਿਲਰ ਨੂੰ ਮੈਮੋਰੀ ਬੇਨਤੀਆਂ ਦੇ ਅਧਾਰ ਤੇ ਸੰਰਚਿਤ ਕੀਤਾ ਗਿਆ ਹੈ;
6. ਇੱਕ "ਟ੍ਰੈਫਿਕ ਲਾਈਟ" CPU ਸੀਮਾਵਾਂ ਦੇ ਅਧਾਰ 'ਤੇ ਕੌਂਫਿਗਰ ਕੀਤੀ ਗਈ ਹੈ;
7. ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, cgroup ਲਈ ਇੱਕ ਸੀਮਾ ਸੰਰਚਿਤ ਕੀਤੀ ਗਈ ਹੈ।

ਆਮ ਤੌਰ 'ਤੇ, ਇਹ ਤਸਵੀਰ ਸਾਰੇ ਸਵਾਲਾਂ ਦੇ ਜਵਾਬ ਦਿੰਦੀ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਦਾ ਮੁੱਖ ਹਿੱਸਾ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ।

ਆਟੋਸਕੇਲਿੰਗ

K8s ਕਲੱਸਟਰ-ਆਟੋਸਕੇਲਰ

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

ਇਹ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਦੀ ਆਟੋਸਕੇਲਿੰਗ ਹੈ, ਜੋ ਬਹੁਤ ਵਧੀਆ ਕੰਮ ਕਰਦਾ ਹੈ (ਸਾਡੇ ਅਨੁਭਵ ਵਿੱਚ)। ਹਾਲਾਂਕਿ, ਹੋਰ ਕਿਤੇ ਵਾਂਗ, ਇੱਥੇ ਕੁਝ ਸੂਖਮਤਾਵਾਂ ਹਨ ...

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

3 ਸਰਵਰਾਂ ਦੇ ਇੱਕ ਕਲੱਸਟਰ 'ਤੇ ਵਿਚਾਰ ਕਰੋ ਜਿਸ ਵਿੱਚ ਤੈਨਾਤੀ ਹੈ। ਇਸ ਵਿੱਚ 6 ਪੌਡ ਹਨ: ਹੁਣ ਹਰੇਕ ਸਰਵਰ ਲਈ 2 ਹਨ। ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਅਸੀਂ ਸਰਵਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨੂੰ ਬੰਦ ਕਰਨਾ ਚਾਹੁੰਦੇ ਸੀ। ਅਜਿਹਾ ਕਰਨ ਲਈ ਅਸੀਂ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਾਂਗੇ kubectl drain, ਜੋ:

• ਇਸ ਸਰਵਰ ਨੂੰ ਨਵੇਂ ਪੌਡ ਭੇਜਣ ਦੀ ਮਨਾਹੀ ਕਰੇਗਾ;
• ਸਰਵਰ 'ਤੇ ਮੌਜੂਦਾ ਪੌਡ ਨੂੰ ਮਿਟਾ ਦੇਵੇਗਾ।

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

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

MongoDB ਸਕਦਾ ਹੈ die ਕਿਉਂਕਿ ਇਸ ਨੂੰ ਕੋਰਮ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ: ਤਿੰਨ ਸਥਾਪਨਾਵਾਂ ਦੇ ਕਲੱਸਟਰ ਲਈ, ਘੱਟੋ-ਘੱਟ ਦੋ ਕੰਮ ਕਰਨੇ ਚਾਹੀਦੇ ਹਨ। ਹਾਲਾਂਕਿ, ਇਹ ਨਹੀਂ ਹੋ ਰਿਹਾ - ਦਾ ਧੰਨਵਾਦ PodDisruption Budget. ਇਹ ਪੈਰਾਮੀਟਰ ਕਾਰਜਸ਼ੀਲ ਪੌਡਾਂ ਦੀ ਘੱਟੋ-ਘੱਟ ਲੋੜੀਂਦੀ ਗਿਣਤੀ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਇਹ ਜਾਣਨਾ ਕਿ MongoDB ਪੌਡਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੁਣ ਕੰਮ ਨਹੀਂ ਕਰ ਰਿਹਾ ਹੈ, ਅਤੇ ਇਹ ਦੇਖਣਾ ਕਿ PodDisruptionBudget MongoDB ਲਈ ਸੈੱਟ ਕੀਤਾ ਗਿਆ ਹੈ minAvailable: 2, Kubernetes ਤੁਹਾਨੂੰ ਇੱਕ ਪੋਡ ਨੂੰ ਮਿਟਾਉਣ ਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇਵੇਗਾ।

ਹੇਠਲੀ ਲਾਈਨ: ਜਦੋਂ ਕਲੱਸਟਰ ਜਾਰੀ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਪੌਡਾਂ ਦੀ ਗਤੀ (ਅਤੇ ਅਸਲ ਵਿੱਚ, ਮੁੜ-ਨਿਰਮਾਣ) ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਕੰਮ ਕਰਨ ਲਈ, ਪੌਡਡਿਸਰਪਸ਼ਨਬਜਟ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਜ਼ਰੂਰੀ ਹੈ।

ਹਰੀਜ਼ੱਟਲ ਸਕੇਲਿੰਗ

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

ਅੱਜ ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇਸਨੂੰ ਹੱਥੀਂ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ: ਪੌਡਾਂ ਦੀ ਗਿਣਤੀ ਵਿੱਚ ਇੱਕ ਆਟੋਮੈਟਿਕ ਵਾਧਾ/ਘਟਨਾ ਮਾਪਿਆ ਲੋਡ ਸੂਚਕਾਂ ਦੇ ਮੁੱਲਾਂ ਦੇ ਅਧਾਰ ਤੇ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।

ਇੱਥੇ ਮੁੱਖ ਸਵਾਲ ਹਨ: ਅਸਲ ਵਿੱਚ ਕੀ ਮਾਪਣਾ ਹੈ и ਕਿਵੇਂ ਵਿਆਖਿਆ ਕਰਨੀ ਹੈ ਪ੍ਰਾਪਤ ਮੁੱਲ (ਪੋਡਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਦਲਣ ਬਾਰੇ ਫੈਸਲਾ ਲੈਣ ਲਈ)। ਤੁਸੀਂ ਬਹੁਤ ਮਾਪ ਸਕਦੇ ਹੋ:

ਇਹ ਤਕਨੀਕੀ ਤੌਰ 'ਤੇ ਕਿਵੇਂ ਕਰਨਾ ਹੈ - ਮੈਟ੍ਰਿਕਸ ਇਕੱਠਾ ਕਰੋ, ਆਦਿ. - ਮੈਂ ਇਸ ਬਾਰੇ ਰਿਪੋਰਟ ਵਿੱਚ ਵਿਸਥਾਰ ਨਾਲ ਗੱਲ ਕੀਤੀ ਸੀ ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ. ਅਤੇ ਅਨੁਕੂਲ ਮਾਪਦੰਡਾਂ ਦੀ ਚੋਣ ਕਰਨ ਲਈ ਮੁੱਖ ਸਲਾਹ ਹੈ ਪ੍ਰਯੋਗ!

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

ਸੰਪੂਰਨ ਹੋਣ ਦੇ ਬਜਾਏ

ਰਿਪੋਰਟ ਵਿੱਚ ਇੱਕ ਨਿਰੰਤਰਤਾ ਹੈ: ਲੰਬਕਾਰੀ ਸਕੇਲਿੰਗ ਬਾਰੇ ਅਤੇ ਸਹੀ ਸਰੋਤਾਂ ਦੀ ਚੋਣ ਕਿਵੇਂ ਕਰਨੀ ਹੈ। ਮੈਂ ਇਸ ਬਾਰੇ ਭਵਿੱਖ ਦੀਆਂ ਵੀਡੀਓਜ਼ ਵਿੱਚ ਗੱਲ ਕਰਾਂਗਾ ਸਾਡਾ YouTube - ਗਾਹਕ ਬਣੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਖੁੰਝ ਨਾ ਜਾਓ!

ਵੀਡੀਓਜ਼ ਅਤੇ ਸਲਾਈਡਾਂ

ਪ੍ਰਦਰਸ਼ਨ ਤੋਂ ਵੀਡੀਓ (44 ਮਿੰਟ):

ਰਿਪੋਰਟ ਦੀ ਪੇਸ਼ਕਾਰੀ:

PS

ਸਾਡੇ ਬਲੌਗ 'ਤੇ ਕੁਬਰਨੇਟਸ ਬਾਰੇ ਹੋਰ ਰਿਪੋਰਟਾਂ:

• «ਕੁਬਰਨੇਟਸ ਨੂੰ ਵਧਾਉਣਾ ਅਤੇ ਪੂਰਕ ਕਰਨਾ» (ਐਂਡਰੀ ਪੋਲੋਵੋਵ; ਸੇਂਟ ਹਾਈਲੋਡ++ 'ਤੇ 8 ਅਪ੍ਰੈਲ, 2019);
• «ਡਾਟਾਬੇਸ ਅਤੇ ਕੁਬਰਨੇਟਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 8 ਨਵੰਬਰ, 2018);
• «ਨਿਗਰਾਨੀ ਅਤੇ ਕੁਬਰਨੇਟਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 28 ਮਈ, 2018);
• «ਕੁਬਰਨੇਟਸ ਅਤੇ ਗਿਟਲੈਬ ਦੇ ਨਾਲ CI/CD ਵਧੀਆ ਅਭਿਆਸ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਹਾਈਲੋਡ++ 'ਤੇ 7 ਨਵੰਬਰ, 2017);
• «ਛੋਟੇ ਪ੍ਰੋਜੈਕਟਾਂ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਨਾਲ ਸਾਡਾ ਅਨੁਭਵ» (ਦਮਿਤਰੀ ਸਟੋਲਯਾਰੋਵ; ਰੂਟਕਾਨਫ 'ਤੇ 6 ਜੂਨ, 2017).

ਸਰੋਤ: www.habr.com