ਕੁਬਰਨੇਟਸ ਕੰਟੇਨਰਾਂ ਲਈ ਵਧੀਆ ਅਭਿਆਸ: ਸਿਹਤ ਜਾਂਚ

TL; ਡਾ

• ਕੰਟੇਨਰਾਂ ਅਤੇ ਮਾਈਕ੍ਰੋ ਸਰਵਿਸਿਜ਼ ਦੀ ਉੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ, ਲਾਗ ਅਤੇ ਪ੍ਰਾਇਮਰੀ ਮੈਟ੍ਰਿਕਸ ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ।
• ਤੇਜ਼ੀ ਨਾਲ ਰਿਕਵਰੀ ਅਤੇ ਵਧੀ ਹੋਈ ਲਚਕਤਾ ਲਈ, ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਉੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਸਿਧਾਂਤ (HOP) ਨੂੰ ਲਾਗੂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।
• ਐਪਲੀਕੇਸ਼ਨ ਪੱਧਰ 'ਤੇ, NOP ਦੀ ਲੋੜ ਹੈ: ਸਹੀ ਲਾਗਿੰਗ, ਨਜ਼ਦੀਕੀ ਨਿਗਰਾਨੀ, ਸਵੱਛਤਾ ਜਾਂਚ, ਅਤੇ ਪ੍ਰਦਰਸ਼ਨ/ਪਰਿਵਰਤਨ ਟਰੇਸਿੰਗ।
• NOR ਦੇ ਤੱਤ ਦੇ ਤੌਰ 'ਤੇ ਚੈਕਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਿਆਰੀ ਪੜਤਾਲ и livenessProbe ਕੁਬਰਨੇਟਸ।

ਹੈਲਥ ਚੈੱਕ ਟੈਮਪਲੇਟ ਕੀ ਹੈ?

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

ਉੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਸਿਧਾਂਤ (HOP)

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

ਇੱਕ ਚੰਗੀ ਤਰ੍ਹਾਂ ਡਿਜ਼ਾਈਨ ਕੀਤੀ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨ ਸਟੈਂਡਰਡ I/O ਸਟ੍ਰੀਮਜ਼ STDERR ਅਤੇ STDOUT ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸਦੇ ਮੁੱਖ ਇਵੈਂਟਾਂ ਨੂੰ ਲੌਗ ਕਰਦੀ ਹੈ। ਅੱਗੇ ਇੱਕ ਸਹਾਇਕ ਸੇਵਾ ਆਉਂਦੀ ਹੈ, ਉਦਾਹਰਨ ਲਈ ਫਾਈਲਬੀਟ, ਲੌਗਸਟੈਸ਼ ਜਾਂ fluentd, ਇੱਕ ਕੇਂਦਰੀ ਨਿਗਰਾਨੀ ਸਿਸਟਮ (ਉਦਾਹਰਨ ਲਈ ਪ੍ਰੋਮੀਥੀਅਸ) ਅਤੇ ਇੱਕ ਲੌਗ ਕਲੈਕਸ਼ਨ ਸਿਸਟਮ (ELK ਸੌਫਟਵੇਅਰ ਸੂਟ) ਨੂੰ ਲਾਗ ਪ੍ਰਦਾਨ ਕਰਨਾ। ਹੇਠਾਂ ਦਿੱਤਾ ਚਿੱਤਰ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਕਿਵੇਂ ਇੱਕ ਕਲਾਉਡ ਐਪਲੀਕੇਸ਼ਨ ਹੈਲਥ ਟੈਸਟ ਪੈਟਰਨ ਅਤੇ ਉੱਚ ਨਿਰੀਖਣਯੋਗਤਾ ਸਿਧਾਂਤ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦੀ ਹੈ।

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਿਹਤ ਜਾਂਚ ਪੈਟਰਨ ਨੂੰ ਕਿਵੇਂ ਲਾਗੂ ਕਰਨਾ ਹੈ?

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

ਸਾਡੇ ਉਦਾਹਰਨ ਵਿੱਚ, k8s ਕਰਦਾ ਹੈ ਕਾਰਜਕੁਸ਼ਲਤਾ ਜਾਂਚ. ਇਸ ਕਿਸਮ ਦੀ ਤਸਦੀਕ ਵਿੱਚ, ਕੁਬੇਲੇਟ ਲਗਾਤਾਰ ਕੰਟੇਨਰ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆ ਦੀ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਇੱਕ ਵਾਰ ਜਦੋਂ ਉਹ ਸਮਝਦਾ ਹੈ ਕਿ ਪ੍ਰਕਿਰਿਆ ਬੰਦ ਹੋ ਗਈ ਹੈ, ਤਾਂ ਉਹ ਇਸਨੂੰ ਦੁਬਾਰਾ ਸ਼ੁਰੂ ਕਰੇਗਾ। ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਮੁੜ-ਚਾਲੂ ਕਰਨ ਨਾਲ ਗਲਤੀ ਨੂੰ ਹੱਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ, ਅਤੇ ਪ੍ਰੋਗਰਾਮ ਨੂੰ ਕਿਸੇ ਵੀ ਤਰੁੱਟੀ 'ਤੇ ਬੰਦ ਕਰਨ ਲਈ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ NOP ਅਤੇ ਸਿਹਤ ਜਾਂਚ ਪੈਟਰਨ ਦੀ ਪਾਲਣਾ ਕਰਨ ਲਈ ਇੱਕ ਪ੍ਰਕਿਰਿਆ ਸਿਹਤ ਜਾਂਚ ਦੀ ਲੋੜ ਹੈ। ਸਿਰਫ ਅਫਸੋਸ ਦੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਸਾਰੀਆਂ ਗਲਤੀਆਂ ਮੁੜ ਚਾਲੂ ਕਰਨ ਨਾਲ ਖਤਮ ਨਹੀਂ ਹੁੰਦੀਆਂ ਹਨ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, k8s ਪੌਡ ਨਾਲ ਸਮੱਸਿਆਵਾਂ ਦੀ ਪਛਾਣ ਕਰਨ ਦੇ 2 ਡੂੰਘੇ ਤਰੀਕੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ: livenessProbe и ਤਿਆਰੀ ਪੜਤਾਲ.

LivenessProbe

ਦੇ ਦੌਰਾਨ livenessProbe ਕੁਬੇਲੇਟ 3 ਤਰ੍ਹਾਂ ਦੀਆਂ ਜਾਂਚਾਂ ਕਰਦਾ ਹੈ: ਨਾ ਸਿਰਫ਼ ਇਹ ਨਿਰਧਾਰਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੀ ਪੌਡ ਚੱਲ ਰਿਹਾ ਹੈ, ਸਗੋਂ ਇਹ ਵੀ ਕਿ ਕੀ ਇਹ ਬੇਨਤੀਆਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰਨ ਅਤੇ ਢੁਕਵੇਂ ਰੂਪ ਵਿੱਚ ਜਵਾਬ ਦੇਣ ਲਈ ਤਿਆਰ ਹੈ:

• ਪੌਡ ਲਈ ਇੱਕ HTTP ਬੇਨਤੀ ਸੈਟ ਅਪ ਕਰੋ। ਜਵਾਬ ਵਿੱਚ 200 ਤੋਂ 399 ਤੱਕ ਦੀ ਰੇਂਜ ਵਿੱਚ ਇੱਕ HTTP ਜਵਾਬ ਕੋਡ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਸ ਤਰ੍ਹਾਂ, ਕੋਡ 5xx ਅਤੇ 4xx ਸੰਕੇਤ ਦਿੰਦੇ ਹਨ ਕਿ ਪੋਡ ਨੂੰ ਸਮੱਸਿਆ ਆ ਰਹੀ ਹੈ, ਭਾਵੇਂ ਪ੍ਰਕਿਰਿਆ ਚੱਲ ਰਹੀ ਹੋਵੇ।
• ਗੈਰ-HTTP ਸੇਵਾਵਾਂ (ਉਦਾਹਰਨ ਲਈ, ਪੋਸਟਫਿਕਸ ਮੇਲ ਸਰਵਰ) ਨਾਲ ਪੌਡਾਂ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇੱਕ TCP ਕੁਨੈਕਸ਼ਨ ਸਥਾਪਤ ਕਰਨ ਦੀ ਲੋੜ ਹੈ।
• ਇੱਕ ਪੌਡ (ਅੰਦਰੂਨੀ ਤੌਰ 'ਤੇ) ਲਈ ਇੱਕ ਆਰਬਿਟਰਰੀ ਕਮਾਂਡ ਚਲਾਓ। ਜੇਕਰ ਕਮਾਂਡ ਕੰਪਲੀਸ਼ਨ ਕੋਡ 0 ਹੈ ਤਾਂ ਜਾਂਚ ਨੂੰ ਸਫਲ ਮੰਨਿਆ ਜਾਂਦਾ ਹੈ।

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

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

ਇਹ ਕਿਸੇ ਹੋਰ ਪੌਡ ਪਰਿਭਾਸ਼ਾ ਤੋਂ ਵੱਖ ਨਹੀਂ ਹੈ, ਪਰ ਅਸੀਂ ਇੱਕ ਵਸਤੂ ਜੋੜਦੇ ਹਾਂ .spec.containers.livenessProbe. ਪੈਰਾਮੀਟਰ httpGet ਉਸ ਮਾਰਗ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜਿਸ 'ਤੇ HTTP GET ਬੇਨਤੀ ਭੇਜੀ ਜਾਂਦੀ ਹੈ (ਸਾਡੀ ਉਦਾਹਰਣ ਵਿੱਚ ਇਹ ਹੈ /, ਪਰ ਲੜਾਈ ਦੇ ਦ੍ਰਿਸ਼ਾਂ ਵਿੱਚ ਅਜਿਹਾ ਕੁਝ ਹੋ ਸਕਦਾ ਹੈ /api/v1/status). ਇੱਕ ਹੋਰ livenessProbe ਇੱਕ ਪੈਰਾਮੀਟਰ ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ initialDelaySeconds, ਜੋ ਤਸਦੀਕ ਕਾਰਵਾਈ ਨੂੰ ਸਕਿੰਟਾਂ ਦੀ ਇੱਕ ਨਿਸ਼ਚਿਤ ਗਿਣਤੀ ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਨਿਰਦੇਸ਼ ਦਿੰਦਾ ਹੈ। ਦੇਰੀ ਦੀ ਲੋੜ ਹੈ ਕਿਉਂਕਿ ਕੰਟੇਨਰ ਨੂੰ ਚਾਲੂ ਹੋਣ ਲਈ ਸਮਾਂ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਜਦੋਂ ਇਹ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਇਹ ਕੁਝ ਸਮੇਂ ਲਈ ਅਣਉਪਲਬਧ ਹੋਵੇਗਾ।

ਇਸ ਸੈਟਿੰਗ ਨੂੰ ਕਲੱਸਟਰ 'ਤੇ ਲਾਗੂ ਕਰਨ ਲਈ, ਵਰਤੋਂ:

kubectl apply -f pod.yaml

ਕੁਝ ਸਕਿੰਟਾਂ ਬਾਅਦ, ਤੁਸੀਂ ਹੇਠ ਦਿੱਤੀ ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪੌਡ ਦੀ ਸਮੱਗਰੀ ਦੀ ਜਾਂਚ ਕਰ ਸਕਦੇ ਹੋ:

kubectl describe pods node500

ਆਉਟਪੁੱਟ ਦੇ ਅੰਤ ਵਿੱਚ, ਲੱਭੋ ਜੋ ਕਿ ਹੈ.

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, livenessProbe ਨੇ ਇੱਕ HTTP GET ਬੇਨਤੀ ਸ਼ੁਰੂ ਕੀਤੀ, ਕੰਟੇਨਰ ਨੇ ਇੱਕ ਗਲਤੀ 500 ਪੈਦਾ ਕੀਤੀ (ਜੋ ਕਿ ਇਹ ਕਰਨ ਲਈ ਪ੍ਰੋਗਰਾਮ ਕੀਤਾ ਗਿਆ ਸੀ), ਅਤੇ ਕੁਬੇਲੇਟ ਨੇ ਇਸਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ।

ਜੇ ਤੁਸੀਂ ਹੈਰਾਨ ਹੋ ਰਹੇ ਹੋ ਕਿ NideJS ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕਿਵੇਂ ਪ੍ਰੋਗ੍ਰਾਮ ਕੀਤਾ ਗਿਆ ਸੀ, ਤਾਂ ਇੱਥੇ app.js ਅਤੇ Dockerfile ਦੀ ਵਰਤੋਂ ਕੀਤੀ ਗਈ ਸੀ:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

ਡੌਕਰਫਾਈਲ

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

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

ਤਿਆਰੀ ਪੜਤਾਲ

ReadinessProbe ਸਮੱਸਿਆ ਨਿਪਟਾਰਾ ਕਰਨ ਵਾਲੀਆਂ ਕਾਰਵਾਈਆਂ ਨੂੰ ਛੱਡ ਕੇ, livenessProbes (GET ਬੇਨਤੀਆਂ, TCP ਸੰਚਾਰ ਅਤੇ ਕਮਾਂਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ) ਦੇ ਸਮਾਨ ਕੰਮ ਕਰਦਾ ਹੈ। ਉਹ ਕੰਟੇਨਰ ਜਿਸ ਵਿੱਚ ਅਸਫਲਤਾ ਦਾ ਪਤਾ ਲਗਾਇਆ ਗਿਆ ਹੈ, ਨੂੰ ਮੁੜ ਚਾਲੂ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਪਰ ਆਉਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਤੋਂ ਵੱਖ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਲਪਨਾ ਕਰੋ ਕਿ ਕੰਟੇਨਰਾਂ ਵਿੱਚੋਂ ਇੱਕ ਬਹੁਤ ਸਾਰੀਆਂ ਗਣਨਾਵਾਂ ਕਰ ਰਿਹਾ ਹੈ ਜਾਂ ਭਾਰੀ ਬੋਝ ਹੇਠ ਹੈ, ਜਿਸ ਕਾਰਨ ਪ੍ਰਤੀਕਿਰਿਆ ਦੇ ਸਮੇਂ ਵਿੱਚ ਵਾਧਾ ਹੋ ਰਿਹਾ ਹੈ। livenessProbe ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਜਵਾਬ ਉਪਲਬਧਤਾ ਜਾਂਚ ਸ਼ੁਰੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਟਾਈਮਆਉਟ ਸੈਕਿੰਡ ਚੈੱਕ ਪੈਰਾਮੀਟਰ ਦੁਆਰਾ), ਜਿਸ ਤੋਂ ਬਾਅਦ ਕੁਬੇਲੇਟ ਕੰਟੇਨਰ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ। ਜਦੋਂ ਸ਼ੁਰੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਕੰਟੇਨਰ ਸਰੋਤ-ਸੰਬੰਧੀ ਕਾਰਜਾਂ ਨੂੰ ਕਰਨਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ ਅਤੇ ਦੁਬਾਰਾ ਚਾਲੂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਹ ਉਹਨਾਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਮਹੱਤਵਪੂਰਨ ਹੋ ਸਕਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਜਵਾਬ ਦੀ ਗਤੀ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਉਦਾਹਰਨ ਲਈ, ਇੱਕ ਕਾਰ ਜਦੋਂ ਸੜਕ 'ਤੇ ਸਰਵਰ ਤੋਂ ਜਵਾਬ ਦੀ ਉਡੀਕ ਕਰ ਰਹੀ ਹੈ, ਜਵਾਬ ਵਿੱਚ ਦੇਰੀ ਹੁੰਦੀ ਹੈ - ਅਤੇ ਕਾਰ ਦੁਰਘਟਨਾ ਵਿੱਚ ਪੈ ਜਾਂਦੀ ਹੈ।

ਚਲੋ ਇੱਕ ਰੇਡੀਨੇਸਪ੍ਰੋਬ ਪਰਿਭਾਸ਼ਾ ਲਿਖੀਏ ਜੋ GET ਬੇਨਤੀ ਦੇ ਜਵਾਬ ਦੇ ਸਮੇਂ ਨੂੰ ਦੋ ਸਕਿੰਟਾਂ ਤੋਂ ਵੱਧ ਨਹੀਂ ਸੈੱਟ ਕਰੇਗੀ, ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ 5 ਸਕਿੰਟਾਂ ਬਾਅਦ GET ਬੇਨਤੀ ਦਾ ਜਵਾਬ ਦੇਵੇਗੀ। pod.yaml ਫਾਈਲ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਣੀ ਚਾਹੀਦੀ ਹੈ:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

ਆਉ kubectl ਦੇ ਨਾਲ ਇੱਕ ਪੌਡ ਤੈਨਾਤ ਕਰੀਏ:

kubectl apply -f pod.yaml

ਆਉ ਕੁਝ ਸਕਿੰਟਾਂ ਦੀ ਉਡੀਕ ਕਰੀਏ ਅਤੇ ਫਿਰ ਵੇਖੀਏ ਕਿ ਰੈਡੀਨੇਸਪ੍ਰੋਬ ਨੇ ਕਿਵੇਂ ਕੰਮ ਕੀਤਾ:

kubectl describe pods nodedelayed

ਆਉਟਪੁੱਟ ਦੇ ਅੰਤ 'ਤੇ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੁਝ ਘਟਨਾਵਾਂ ਸਮਾਨ ਹਨ ਇਹ ਵਾਲਾ.

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

ਨੋਟ ਕਰੋ ਕਿ ਹੁਣ ਜਦੋਂ ਪੌਡ ਆਫਲੋਡ ਹੋ ਗਿਆ ਹੈ, kubectl ਇਸ ਨੂੰ ਦੁਬਾਰਾ ਬੇਨਤੀ ਕਰਦਾ ਹੈ: GET ਬੇਨਤੀਆਂ ਦੇ ਜਵਾਬਾਂ ਵਿੱਚ ਹੁਣ ਦੇਰੀ ਨਹੀਂ ਹੋਵੇਗੀ।

ਤੁਲਨਾ ਲਈ, ਹੇਠਾਂ ਸੋਧੀ ਹੋਈ app.js ਫਾਈਲ ਹੈ:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

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

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

Kubernetes ਮੂਲ ਰੂਪ ਵਿੱਚ 2 ਕਿਸਮਾਂ ਦੀਆਂ ਸਿਹਤ ਜਾਂਚਾਂ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ: ReadinessProbe ਅਤੇ livenessProbe। ਦੋਵੇਂ ਇੱਕੋ ਕਿਸਮ ਦੀਆਂ ਜਾਂਚਾਂ (HTTP GET ਬੇਨਤੀਆਂ, TCP ਸੰਚਾਰ ਅਤੇ ਕਮਾਂਡ ਐਗਜ਼ੀਕਿਊਸ਼ਨ) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ। ਉਹ ਇਸ ਗੱਲ ਵਿੱਚ ਭਿੰਨ ਹੁੰਦੇ ਹਨ ਕਿ ਉਹ ਫਲੀਆਂ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਦੇ ਜਵਾਬ ਵਿੱਚ ਕਿਹੜੇ ਫੈਸਲੇ ਲੈਂਦੇ ਹਨ। livenessProbe ਕੰਟੇਨਰ ਨੂੰ ਇਸ ਉਮੀਦ ਵਿੱਚ ਮੁੜ ਚਾਲੂ ਕਰਦਾ ਹੈ ਕਿ ਗਲਤੀ ਦੁਬਾਰਾ ਨਹੀਂ ਹੋਵੇਗੀ, ਅਤੇ ReadinessProbe ਪੋਡ ਨੂੰ ਆਉਣ ਵਾਲੇ ਟ੍ਰੈਫਿਕ ਤੋਂ ਉਦੋਂ ਤੱਕ ਅਲੱਗ ਕਰ ਦਿੰਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਸਮੱਸਿਆ ਦਾ ਕਾਰਨ ਹੱਲ ਨਹੀਂ ਹੋ ਜਾਂਦਾ।

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

ਸਰੋਤ: www.habr.com