Kubernetes 'ਤੇ ਪਹਿਲੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਤੈਨਾਤ ਕਰਨ ਵੇਲੇ ਪੰਜ ਮਿਸ

Aris Dreamer ਦੁਆਰਾ ਅਸਫਲ

ਬਹੁਤ ਸਾਰੇ ਲੋਕ ਸੋਚਦੇ ਹਨ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕੁਬਰਨੇਟਸ (ਜਾਂ ਤਾਂ ਹੈਲਮ ਜਾਂ ਹੱਥੀਂ ਵਰਤਣਾ) ਨੂੰ ਟ੍ਰਾਂਸਫਰ ਕਰਨਾ ਕਾਫ਼ੀ ਹੈ - ਅਤੇ ਖੁਸ਼ੀ ਹੋਵੇਗੀ. ਪਰ ਹਰ ਚੀਜ਼ ਇੰਨੀ ਸਧਾਰਨ ਨਹੀਂ ਹੈ.

ਦੀ ਟੀਮ Mail.ru ਕਲਾਉਡ ਹੱਲ DevOps ਇੰਜੀਨੀਅਰ ਜੂਲੀਅਨ ਗਿੰਡੀ ਦੁਆਰਾ ਇੱਕ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ। ਉਹ ਦੱਸਦਾ ਹੈ ਕਿ ਮਾਈਗ੍ਰੇਸ਼ਨ ਪ੍ਰਕਿਰਿਆ ਦੌਰਾਨ ਉਸਦੀ ਕੰਪਨੀ ਨੂੰ ਕਿਹੜੀਆਂ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਤਾਂ ਜੋ ਤੁਸੀਂ ਉਸੇ ਰੇਕ 'ਤੇ ਕਦਮ ਨਾ ਰੱਖੋ।

ਪਹਿਲਾ ਕਦਮ: ਪੌਡ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਸੈਟ ਅਪ ਕਰੋ

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

ਪੌਡ ਬੇਨਤੀਆਂ ਸ਼ਡਿਊਲਰ ਦੁਆਰਾ ਪੌਡ ਨੂੰ ਵਧੀਆ ਢੰਗ ਨਾਲ ਰੱਖਣ ਲਈ ਵਰਤਿਆ ਜਾਣ ਵਾਲਾ ਮੁੱਖ ਮੁੱਲ ਹੈ।

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

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸ਼ਡਿਊਲਰ ਅਕਸਰ ਪੌਡਾਂ ਨੂੰ "ਨਿਚੋੜਦਾ" ਹੁੰਦਾ ਹੈ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਮੁੜ ਤਹਿ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੁੰਦਾ ਕਿਉਂਕਿ ਕੰਟਰੋਲ ਪਲੇਨ ਨੂੰ ਇਹ ਨਹੀਂ ਪਤਾ ਸੀ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿੰਨੇ ਸਰੋਤਾਂ ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਜੋ ਕਿ ਸਮਾਂ-ਸਾਰਣੀ ਐਲਗੋਰਿਦਮ ਦਾ ਇੱਕ ਮੁੱਖ ਹਿੱਸਾ ਹੈ।

ਪੌਡ ਸੀਮਾਵਾਂ ਇੱਕ ਪੌਡ ਲਈ ਇੱਕ ਸਪਸ਼ਟ ਸੀਮਾ ਹੈ। ਇਹ ਸਰੋਤਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਮਾਤਰਾ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ ਜੋ ਕਲੱਸਟਰ ਕੰਟੇਨਰ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰੇਗਾ।

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

ਇੱਕ ਕੰਟੇਨਰ ਹਮੇਸ਼ਾਂ ਸਰੋਤ ਬੇਨਤੀ ਤੋਂ ਵੱਧ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ ਕਦੇ ਵੀ ਸੀਮਾ ਤੋਂ ਵੱਧ ਨਹੀਂ ਵਰਤ ਸਕਦਾ। ਇਹ ਮੁੱਲ ਸਹੀ ਢੰਗ ਨਾਲ ਸੈੱਟ ਕਰਨਾ ਮੁਸ਼ਕਲ ਹੈ, ਪਰ ਇਹ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ.

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

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਮੈਂ ਇਸ ਬਾਰੇ ਖਾਸ ਨਿਰਦੇਸ਼ ਨਹੀਂ ਦੇ ਸਕਦਾ ਹਾਂ ਕਿ ਕਿਹੜੇ ਮੁੱਲਾਂ ਨੂੰ ਸੈੱਟ ਕਰਨਾ ਹੈ, ਪਰ ਅਸੀਂ ਖੁਦ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਯਮਾਂ ਦੀ ਪਾਲਣਾ ਕਰਦੇ ਹਾਂ:

1. ਲੋਡ ਟੈਸਟਿੰਗ ਟੂਲ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਟ੍ਰੈਫਿਕ ਦੇ ਅਧਾਰ ਪੱਧਰ ਦੀ ਨਕਲ ਕਰਦੇ ਹਾਂ ਅਤੇ ਪੌਡ ਸਰੋਤਾਂ (ਮੈਮੋਰੀ ਅਤੇ ਪ੍ਰੋਸੈਸਰ) ਦੀ ਵਰਤੋਂ ਦਾ ਨਿਰੀਖਣ ਕਰਦੇ ਹਾਂ।
2. ਪੌਡ ਬੇਨਤੀਆਂ ਨੂੰ ਮਨਮਾਨੇ ਤੌਰ 'ਤੇ ਘੱਟ ਮੁੱਲ 'ਤੇ ਸੈੱਟ ਕਰੋ (ਬੇਨਤੀ ਦੇ ਮੁੱਲ ਤੋਂ ਲਗਭਗ 5 ਗੁਣਾ ਦੀ ਸਰੋਤ ਸੀਮਾ ਦੇ ਨਾਲ) ਅਤੇ ਵੇਖੋ। ਜਦੋਂ ਬੇਨਤੀਆਂ ਬਹੁਤ ਘੱਟ ਪੱਧਰ 'ਤੇ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਪ੍ਰਕਿਰਿਆ ਸ਼ੁਰੂ ਨਹੀਂ ਹੋ ਸਕਦੀ, ਅਕਸਰ ਕ੍ਰਿਪਟਿਕ ਗੋ ਰਨਟਾਈਮ ਗਲਤੀਆਂ ਦਾ ਕਾਰਨ ਬਣਦੀਆਂ ਹਨ।

ਮੈਂ ਨੋਟ ਕਰਦਾ ਹਾਂ ਕਿ ਉੱਚ ਸਰੋਤ ਸੀਮਾਵਾਂ ਸਮਾਂ-ਸਾਰਣੀ ਨੂੰ ਵਧੇਰੇ ਮੁਸ਼ਕਲ ਬਣਾਉਂਦੀਆਂ ਹਨ ਕਿਉਂਕਿ ਪੌਡ ਨੂੰ ਲੋੜੀਂਦੇ ਸਰੋਤਾਂ ਦੇ ਨਾਲ ਇੱਕ ਟੀਚਾ ਨੋਡ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ.

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

ਕਦਮ ਦੋ: ਜੀਵੰਤਤਾ ਅਤੇ ਤਿਆਰੀ ਟੈਸਟ ਸੈੱਟ ਕਰੋ

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

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

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

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

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

ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਵਿੱਚ ਇੱਕ "ਸਿਹਤ" ਅੰਤਮ ਬਿੰਦੂ ਸਥਾਪਤ ਕੀਤਾ ਹੈ ਜੋ ਸਿਰਫ਼ ਇੱਕ 200 ਜਵਾਬ ਕੋਡ ਵਾਪਸ ਕਰਦਾ ਹੈ। ਇਹ ਇੱਕ ਸੂਚਕ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੈ ਅਤੇ ਬੇਨਤੀਆਂ ਨੂੰ ਸੰਭਾਲਣ ਵਿੱਚ ਸਮਰੱਥ ਹੈ (ਪਰ ਅਜੇ ਤੱਕ ਟ੍ਰੈਫਿਕ ਨਹੀਂ)।

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

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

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

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

SELECT small_item FROM table LIMIT 1

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

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

ਤੁਸੀਂ ਕੁਝ ਵਾਧੂ ਸੰਰਚਨਾ ਵਿਕਲਪ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ:

• initialDelaySeconds - ਕੰਟੇਨਰ ਦੇ ਸ਼ੁਰੂ ਹੋਣ ਅਤੇ ਪੜਤਾਲਾਂ ਦੀ ਸ਼ੁਰੂਆਤ ਦੇ ਵਿਚਕਾਰ ਕਿੰਨੇ ਸਕਿੰਟ ਲੰਘਣਗੇ।
• periodSeconds - ਸੈਂਪਲ ਰਨ ਦੇ ਵਿਚਕਾਰ ਉਡੀਕ ਅੰਤਰਾਲ।
• timeoutSeconds - ਸਕਿੰਟਾਂ ਦੀ ਗਿਣਤੀ ਜਿਸ ਤੋਂ ਬਾਅਦ ਪੌਡ ਨੂੰ ਐਮਰਜੈਂਸੀ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ। ਆਮ ਸਮਾਂ ਸਮਾਪਤ।
• failureThreshold ਪੋਡ ਨੂੰ ਰੀਸਟਾਰਟ ਸਿਗਨਲ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ ਟੈਸਟ ਅਸਫਲਤਾਵਾਂ ਦੀ ਸੰਖਿਆ ਹੈ।
• successThreshold ਪੌਡ ਦੇ ਤਿਆਰ ਅਵਸਥਾ ਵਿੱਚ ਪਰਿਵਰਤਨ ਤੋਂ ਪਹਿਲਾਂ ਸਫਲ ਅਜ਼ਮਾਇਸ਼ਾਂ ਦੀ ਗਿਣਤੀ ਹੈ (ਇੱਕ ਅਸਫਲਤਾ ਤੋਂ ਬਾਅਦ ਜਦੋਂ ਪੌਡ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ ਜਾਂ ਠੀਕ ਹੋ ਜਾਂਦਾ ਹੈ)।

ਕਦਮ ਤਿੰਨ: Pod ਦੀਆਂ ਡਿਫਾਲਟ ਨੈੱਟਵਰਕ ਨੀਤੀਆਂ ਨੂੰ ਸੈੱਟ ਕਰਨਾ

ਕੁਬਰਨੇਟਸ ਕੋਲ ਇੱਕ "ਫਲੈਟ" ਨੈਟਵਰਕ ਟੌਪੋਗ੍ਰਾਫੀ ਹੈ, ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਾਰੇ ਪੌਡ ਇੱਕ ਦੂਜੇ ਨਾਲ ਸਿੱਧਾ ਸੰਚਾਰ ਕਰਦੇ ਹਨ। ਕੁਝ ਮਾਮਲਿਆਂ ਵਿੱਚ ਇਹ ਫਾਇਦੇਮੰਦ ਨਹੀਂ ਹੈ।

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

ਉਦਾਹਰਨ ਲਈ, ਹੇਠਾਂ ਦਿੱਤੀ ਇੱਕ ਸਧਾਰਨ ਨੀਤੀ ਹੈ ਜੋ ਕਿਸੇ ਖਾਸ ਨੇਮਸਪੇਸ ਲਈ ਆਉਣ ਵਾਲੇ ਸਾਰੇ ਟ੍ਰੈਫਿਕ ਤੋਂ ਇਨਕਾਰ ਕਰਦੀ ਹੈ:

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

ਇਸ ਸੰਰਚਨਾ ਦਾ ਵਿਜ਼ੂਅਲਾਈਜ਼ੇਸ਼ਨ:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
ਹੋਰ ਵੇਰਵੇ ਇੱਥੇ.

ਕਦਮ ਚਾਰ: ਹੁੱਕਾਂ ਅਤੇ ਇਨਿਟ ਕੰਟੇਨਰਾਂ ਨਾਲ ਕਸਟਮ ਵਿਵਹਾਰ

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

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

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

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

ਪਰ nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

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

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

ਆਮ ਵਾਂਗ, ਦਸਤਾਵੇਜ਼ਾਂ ਤੋਂ ਇੱਕ ਹਵਾਲਾ: init ਕੰਟੇਨਰ ਸੁਰੱਖਿਅਤ ਢੰਗ ਨਾਲ ਕਸਟਮ ਕੋਡ ਜਾਂ ਉਪਯੋਗਤਾਵਾਂ ਨੂੰ ਚਲਾਉਂਦੇ ਹਨ ਜੋ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੰਟੇਨਰ ਚਿੱਤਰ ਦੀ ਸੁਰੱਖਿਆ ਨਾਲ ਸਮਝੌਤਾ ਕਰਨਗੇ। ਬੇਲੋੜੇ ਸਾਧਨਾਂ ਨੂੰ ਵੱਖਰਾ ਰੱਖ ਕੇ, ਤੁਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਕੰਟੇਨਰ ਚਿੱਤਰ ਦੀ ਹਮਲੇ ਵਾਲੀ ਸਤਹ ਨੂੰ ਸੀਮਤ ਕਰਦੇ ਹੋ।

ਕਦਮ ਪੰਜ: ਕਰਨਲ ਸੰਰਚਨਾ

ਅੰਤ ਵਿੱਚ, ਆਓ ਇੱਕ ਹੋਰ ਤਕਨੀਕੀ ਤਕਨੀਕ ਬਾਰੇ ਗੱਲ ਕਰੀਏ.

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

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

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

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

ਅੰਤ ਵਿੱਚ

ਹਾਲਾਂਕਿ ਕੁਬਰਨੇਟਸ ਇੱਕ ਆਊਟ-ਆਫ-ਦ-ਬਾਕਸ ਹੱਲ ਵਾਂਗ ਜਾਪਦਾ ਹੈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੁਚਾਰੂ ਢੰਗ ਨਾਲ ਚਲਾਉਣ ਲਈ ਕੁਝ ਮੁੱਖ ਕਦਮ ਚੁੱਕਣੇ ਚਾਹੀਦੇ ਹਨ।

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

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

ਹਮੇਸ਼ਾ ਆਪਣੇ ਆਪ ਨੂੰ ਇਹ ਸਵਾਲ ਪੁੱਛੋ:

1. ਐਪਲੀਕੇਸ਼ਨ ਕਿੰਨੇ ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ ਅਤੇ ਇਹ ਰਕਮ ਕਿਵੇਂ ਬਦਲੇਗੀ?
2. ਅਸਲ ਸਕੇਲਿੰਗ ਲੋੜਾਂ ਕੀ ਹਨ? ਐਪ ਔਸਤਨ ਕਿੰਨਾ ਟ੍ਰੈਫਿਕ ਸੰਭਾਲੇਗਾ? ਸਿਖਰ ਆਵਾਜਾਈ ਬਾਰੇ ਕੀ?
3. ਕਿੰਨੀ ਵਾਰ ਸੇਵਾ ਨੂੰ ਸਕੇਲ ਕਰਨ ਦੀ ਲੋੜ ਪਵੇਗੀ? ਟ੍ਰੈਫਿਕ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ ਨਵੀਆਂ ਪੌਡਾਂ ਨੂੰ ਕਿੰਨੀ ਜਲਦੀ ਤਿਆਰ ਹੋਣ ਅਤੇ ਚੱਲਣ ਦੀ ਲੋੜ ਹੈ?
4. ਪੌਡਜ਼ ਨੂੰ ਕਿੰਨੀ ਸੁੰਦਰਤਾ ਨਾਲ ਬੰਦ ਕੀਤਾ ਜਾਂਦਾ ਹੈ? ਕੀ ਇਹ ਬਿਲਕੁਲ ਜ਼ਰੂਰੀ ਹੈ? ਕੀ ਡਾਊਨਟਾਈਮ ਤੋਂ ਬਿਨਾਂ ਤੈਨਾਤੀ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨਾ ਸੰਭਵ ਹੈ?
5. ਸੁਰੱਖਿਆ ਜੋਖਮਾਂ ਨੂੰ ਕਿਵੇਂ ਘੱਟ ਕੀਤਾ ਜਾਵੇ ਅਤੇ ਕਿਸੇ ਵੀ ਸਮਝੌਤਾ ਕੀਤੇ ਪੌਡ ਤੋਂ ਨੁਕਸਾਨ ਨੂੰ ਸੀਮਤ ਕਿਵੇਂ ਕਰੀਏ? ਕੀ ਕਿਸੇ ਵੀ ਸੇਵਾਵਾਂ ਕੋਲ ਇਜਾਜ਼ਤਾਂ ਜਾਂ ਪਹੁੰਚ ਹਨ ਜਿਨ੍ਹਾਂ ਦੀ ਉਹਨਾਂ ਨੂੰ ਲੋੜ ਨਹੀਂ ਹੈ?

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

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

ਹੋਰ ਕੀ ਪੜ੍ਹਨਾ ਹੈ:

1. ਉਤਪਾਦਨ ਦੇ ਵਾਤਾਵਰਣ ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਅਤੇ ਕੁਬਰਨੇਟਸ ਨੂੰ ਚਲਾਉਣ ਲਈ ਵਧੀਆ ਅਭਿਆਸ ਅਤੇ ਵਧੀਆ ਅਭਿਆਸ.
2. ਕੁਬਰਨੇਟਸ ਲਈ 90+ ਉਪਯੋਗੀ ਟੂਲ: ਤੈਨਾਤੀ, ਪ੍ਰਬੰਧਨ, ਨਿਗਰਾਨੀ, ਸੁਰੱਖਿਆ ਅਤੇ ਹੋਰ ਬਹੁਤ ਕੁਝ.
3. ਟੈਲੀਗ੍ਰਾਮ ਵਿੱਚ ਕੁਬਰਨੇਟਸ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਸਾਡਾ ਚੈਨਲ.

ਸਰੋਤ: www.habr.com