ਕੁਬਰਨੇਟਸ ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ: NGINX ਅਤੇ PHP-FPM ਵਿੱਚ ਸ਼ਾਨਦਾਰ ਬੰਦ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ

ਕੁਬਰਨੇਟਸ ਵਿੱਚ CI/CD ਨੂੰ ਲਾਗੂ ਕਰਨ ਵੇਲੇ ਇੱਕ ਆਮ ਸਥਿਤੀ: ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਰੋਕਣ ਤੋਂ ਪਹਿਲਾਂ ਨਵੀਆਂ ਕਲਾਇੰਟ ਬੇਨਤੀਆਂ ਨੂੰ ਸਵੀਕਾਰ ਨਾ ਕਰਨ ਦੇ ਯੋਗ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ, ਅਤੇ ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ, ਮੌਜੂਦਾ ਨੂੰ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

ਇਸ ਸ਼ਰਤ ਦੀ ਪਾਲਣਾ ਤੁਹਾਨੂੰ ਤੈਨਾਤੀ ਦੌਰਾਨ ਜ਼ੀਰੋ ਡਾਊਨਟਾਈਮ ਪ੍ਰਾਪਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੀ ਹੈ। ਹਾਲਾਂਕਿ, ਬਹੁਤ ਮਸ਼ਹੂਰ ਬੰਡਲ (ਜਿਵੇਂ ਕਿ NGINX ਅਤੇ PHP-FPM) ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਵੀ, ਤੁਹਾਨੂੰ ਮੁਸ਼ਕਲਾਂ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪੈ ਸਕਦਾ ਹੈ ਜੋ ਹਰੇਕ ਤੈਨਾਤੀ ਦੇ ਨਾਲ ਗਲਤੀਆਂ ਦੇ ਵਾਧੇ ਵੱਲ ਲੈ ਜਾਵੇਗਾ...

ਥਿਊਰੀ. ਪੌਡ ਕਿਵੇਂ ਰਹਿੰਦਾ ਹੈ

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

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

ਚੰਗੀ ਤਰ੍ਹਾਂ ਸਮਝਣ ਲਈ ਕਿ ਜਦੋਂ ਇੱਕ ਪੌਡ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ, ਹੇਠਾਂ ਦਿੱਤੇ ਚਿੱਤਰ ਨੂੰ ਦੇਖੋ:

A1, B1 - ਚੁੱਲ੍ਹਾ ਦੀ ਸਥਿਤੀ ਬਾਰੇ ਬਦਲਾਅ ਪ੍ਰਾਪਤ ਕਰਨਾ
A2 - ਰਵਾਨਗੀ SIGTERM
B2 - ਅੰਤਮ ਬਿੰਦੂਆਂ ਤੋਂ ਇੱਕ ਪੌਡ ਨੂੰ ਹਟਾਉਣਾ
B3 - ਤਬਦੀਲੀਆਂ ਪ੍ਰਾਪਤ ਕਰਨਾ (ਅੰਤ ਬਿੰਦੂਆਂ ਦੀ ਸੂਚੀ ਬਦਲ ਗਈ ਹੈ)
B4 - iptables ਨਿਯਮਾਂ ਨੂੰ ਅੱਪਡੇਟ ਕਰੋ

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

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

ਥਿਊਰੀ. ਕਿਵੇਂ NGINX ਅਤੇ PHP-FPM ਆਪਣੀਆਂ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਖਤਮ ਕਰਦੇ ਹਨ

NGINX

ਆਓ NGINX ਨਾਲ ਸ਼ੁਰੂ ਕਰੀਏ, ਕਿਉਂਕਿ ਇਸਦੇ ਨਾਲ ਸਭ ਕੁਝ ਘੱਟ ਜਾਂ ਘੱਟ ਸਪੱਸ਼ਟ ਹੈ। ਸਿਧਾਂਤ ਵਿੱਚ ਗੋਤਾਖੋਰੀ ਕਰਦੇ ਹੋਏ, ਅਸੀਂ ਸਿੱਖਦੇ ਹਾਂ ਕਿ NGINX ਵਿੱਚ ਇੱਕ ਮਾਸਟਰ ਪ੍ਰਕਿਰਿਆ ਅਤੇ ਕਈ "ਕਰਮਚਾਰੀ" ਹਨ - ਇਹ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ ਜੋ ਕਲਾਇੰਟ ਦੀਆਂ ਬੇਨਤੀਆਂ 'ਤੇ ਕਾਰਵਾਈ ਕਰਦੀਆਂ ਹਨ। ਇੱਕ ਸੁਵਿਧਾਜਨਕ ਵਿਕਲਪ ਦਿੱਤਾ ਗਿਆ ਹੈ: ਕਮਾਂਡ ਦੀ ਵਰਤੋਂ ਕਰਕੇ nginx -s <SIGNAL> ਪ੍ਰਕਿਰਿਆਵਾਂ ਨੂੰ ਜਾਂ ਤਾਂ ਤੇਜ਼ ਬੰਦ ਜਾਂ ਸ਼ਾਨਦਾਰ ਬੰਦ ਮੋਡ ਵਿੱਚ ਖਤਮ ਕਰੋ। ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ, ਇਹ ਬਾਅਦ ਵਾਲਾ ਵਿਕਲਪ ਹੈ ਜੋ ਸਾਡੀ ਦਿਲਚਸਪੀ ਰੱਖਦਾ ਹੈ।

ਫਿਰ ਸਭ ਕੁਝ ਸਧਾਰਨ ਹੈ: ਤੁਹਾਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਦੀ ਲੋੜ ਹੈ preStop-ਹੁੱਕ ਇੱਕ ਕਮਾਂਡ ਜੋ ਇੱਕ ਸ਼ਾਨਦਾਰ ਬੰਦ ਸਿਗਨਲ ਭੇਜੇਗੀ। ਇਹ ਤੈਨਾਤੀ ਵਿੱਚ, ਕੰਟੇਨਰ ਬਲਾਕ ਵਿੱਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ:

       lifecycle:
          preStop:
            exec:
              command:
              - /usr/sbin/nginx
              - -s
              - quit

ਹੁਣ, ਜਦੋਂ ਪੌਡ ਬੰਦ ਹੋ ਜਾਂਦਾ ਹੈ, ਅਸੀਂ NGINX ਕੰਟੇਨਰ ਲੌਗਸ ਵਿੱਚ ਹੇਠਾਂ ਦਿੱਤੇ ਨੂੰ ਦੇਖਾਂਗੇ:

2018/01/25 13:58:31 [notice] 1#1: signal 3 (SIGQUIT) received, shutting down
2018/01/25 13:58:31 [notice] 11#11: gracefully shutting down

ਅਤੇ ਇਸਦਾ ਮਤਲਬ ਇਹ ਹੋਵੇਗਾ ਕਿ ਸਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ: NGINX ਬੇਨਤੀਆਂ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ। ਹਾਲਾਂਕਿ, ਹੇਠਾਂ ਅਸੀਂ ਇੱਕ ਆਮ ਸਮੱਸਿਆ 'ਤੇ ਵੀ ਵਿਚਾਰ ਕਰਾਂਗੇ ਜਿਸ ਕਾਰਨ, ਕਮਾਂਡ ਦੇ ਨਾਲ ਵੀ nginx -s quit ਪ੍ਰਕਿਰਿਆ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਹੁੰਦੀ ਹੈ।

ਅਤੇ ਇਸ ਪੜਾਅ 'ਤੇ ਅਸੀਂ NGINX ਨਾਲ ਕੀਤਾ ਹੈ: ਘੱਟੋ ਘੱਟ ਲੌਗਸ ਤੋਂ ਤੁਸੀਂ ਸਮਝ ਸਕਦੇ ਹੋ ਕਿ ਸਭ ਕੁਝ ਉਸੇ ਤਰ੍ਹਾਂ ਕੰਮ ਕਰ ਰਿਹਾ ਹੈ ਜਿਵੇਂ ਕਿ ਇਹ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ.

PHP-FPM ਨਾਲ ਕੀ ਸੌਦਾ ਹੈ? ਇਹ ਸ਼ਾਨਦਾਰ ਬੰਦ ਨੂੰ ਕਿਵੇਂ ਸੰਭਾਲਦਾ ਹੈ? ਆਓ ਇਸ ਨੂੰ ਬਾਹਰ ਕੱਢੀਏ।

PHP-FPM

PHP-FPM ਦੇ ਮਾਮਲੇ ਵਿੱਚ, ਥੋੜੀ ਘੱਟ ਜਾਣਕਾਰੀ ਹੈ. ਜੇ ਤੁਸੀਂ 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਤ ਕਰਦੇ ਹੋ ਅਧਿਕਾਰਤ ਮੈਨੂਅਲ PHP-FPM ਦੇ ਅਨੁਸਾਰ, ਇਹ ਕਹੇਗਾ ਕਿ ਹੇਠਾਂ ਦਿੱਤੇ POSIX ਸਿਗਨਲ ਸਵੀਕਾਰ ਕੀਤੇ ਗਏ ਹਨ:

1. SIGINT, SIGTERM - ਤੇਜ਼ ਬੰਦ;
2. SIGQUIT - ਸ਼ਾਨਦਾਰ ਬੰਦ (ਸਾਨੂੰ ਕੀ ਚਾਹੀਦਾ ਹੈ)।

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

        lifecycle:
          preStop:
            exec:
              command:
              - /bin/kill
              - -SIGQUIT
              - "1"

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

ਅਭਿਆਸ. ਸ਼ਾਨਦਾਰ ਸ਼ਟਡਾਊਨ ਨਾਲ ਸੰਭਵ ਸਮੱਸਿਆਵਾਂ

NGINX

ਸਭ ਤੋਂ ਪਹਿਲਾਂ, ਇਹ ਯਾਦ ਰੱਖਣਾ ਲਾਭਦਾਇਕ ਹੈ: ਕਮਾਂਡ ਚਲਾਉਣ ਤੋਂ ਇਲਾਵਾ nginx -s quit ਇੱਥੇ ਇੱਕ ਹੋਰ ਪੜਾਅ ਹੈ ਜਿਸ ਵੱਲ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ. ਸਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਦਾ ਸਾਹਮਣਾ ਕਰਨਾ ਪਿਆ ਜਿੱਥੇ NGINX ਅਜੇ ਵੀ SIGQUIT ਸਿਗਨਲ ਦੀ ਬਜਾਏ SIGTERM ਭੇਜੇਗਾ, ਜਿਸ ਕਾਰਨ ਬੇਨਤੀਆਂ ਸਹੀ ਢੰਗ ਨਾਲ ਪੂਰੀਆਂ ਨਹੀਂ ਹੋਈਆਂ। ਇਸੇ ਤਰ੍ਹਾਂ ਦੇ ਕੇਸ ਪਾਏ ਜਾ ਸਕਦੇ ਹਨ, ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ. ਬਦਕਿਸਮਤੀ ਨਾਲ, ਅਸੀਂ ਇਸ ਵਿਵਹਾਰ ਦੇ ਖਾਸ ਕਾਰਨ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਵਿੱਚ ਅਸਮਰੱਥ ਸੀ: NGINX ਸੰਸਕਰਣ ਬਾਰੇ ਇੱਕ ਸ਼ੱਕ ਸੀ, ਪਰ ਇਸਦੀ ਪੁਸ਼ਟੀ ਨਹੀਂ ਕੀਤੀ ਗਈ ਸੀ। ਲੱਛਣ ਇਹ ਸੀ ਕਿ NGINX ਕੰਟੇਨਰ ਲੌਗਸ ਵਿੱਚ ਸੰਦੇਸ਼ ਦੇਖੇ ਗਏ ਸਨ: "ਕੁਨੈਕਸ਼ਨ 10 ਵਿੱਚ ਓਪਨ ਸਾਕੇਟ #5 ਬਾਕੀ ਹੈ", ਜਿਸ ਤੋਂ ਬਾਅਦ ਪੌਡ ਬੰਦ ਹੋ ਗਿਆ।

ਅਸੀਂ ਅਜਿਹੀ ਸਮੱਸਿਆ ਨੂੰ ਦੇਖ ਸਕਦੇ ਹਾਂ, ਉਦਾਹਰਨ ਲਈ, ਇੰਗਰੈਸ 'ਤੇ ਸਾਨੂੰ ਲੋੜੀਂਦੇ ਜਵਾਬਾਂ ਤੋਂ:

ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਸਥਿਤੀ ਕੋਡ ਦੇ ਸੂਚਕ

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਾਨੂੰ Ingress ਤੋਂ ਸਿਰਫ਼ ਇੱਕ 503 ਗਲਤੀ ਕੋਡ ਪ੍ਰਾਪਤ ਹੁੰਦਾ ਹੈ: ਇਹ NGINX ਕੰਟੇਨਰ ਤੱਕ ਪਹੁੰਚ ਨਹੀਂ ਕਰ ਸਕਦਾ, ਕਿਉਂਕਿ ਇਹ ਹੁਣ ਪਹੁੰਚਯੋਗ ਨਹੀਂ ਹੈ। ਜੇ ਤੁਸੀਂ NGINX ਵਾਲੇ ਕੰਟੇਨਰ ਲੌਗਸ ਨੂੰ ਦੇਖਦੇ ਹੋ, ਤਾਂ ਉਹਨਾਂ ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਸ਼ਾਮਲ ਹਨ:

[alert] 13939#0: *154 open socket #3 left in connection 16
[alert] 13939#0: *168 open socket #6 left in connection 13

ਸਟਾਪ ਸਿਗਨਲ ਨੂੰ ਬਦਲਣ ਤੋਂ ਬਾਅਦ, ਕੰਟੇਨਰ ਸਹੀ ਢੰਗ ਨਾਲ ਬੰਦ ਹੋਣਾ ਸ਼ੁਰੂ ਹੋ ਜਾਂਦਾ ਹੈ: ਇਹ ਇਸ ਤੱਥ ਦੁਆਰਾ ਪੁਸ਼ਟੀ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ 503 ਗਲਤੀ ਹੁਣ ਨਹੀਂ ਵੇਖੀ ਜਾਂਦੀ.

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

PHP-FPM... ਅਤੇ ਹੋਰ

PHP-FPM ਦੀ ਸਮੱਸਿਆ ਨੂੰ ਮਾਮੂਲੀ ਤਰੀਕੇ ਨਾਲ ਦੱਸਿਆ ਗਿਆ ਹੈ: ਇਹ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਨਹੀਂ ਕਰਦਾ, ਇਹ ਉਹਨਾਂ ਨੂੰ ਖਤਮ ਕਰ ਦਿੰਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਤੈਨਾਤੀ ਅਤੇ ਹੋਰ ਕਾਰਵਾਈਆਂ ਦੌਰਾਨ 502 ਗਲਤੀਆਂ ਹੁੰਦੀਆਂ ਹਨ। 2005 ਤੋਂ bugs.php.net 'ਤੇ ਕਈ ਬੱਗ ਰਿਪੋਰਟਾਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ ਇੱਥੇ и ਇੱਥੇ), ਜੋ ਇਸ ਸਮੱਸਿਆ ਦਾ ਵਰਣਨ ਕਰਦਾ ਹੈ। ਪਰ ਤੁਸੀਂ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਲੌਗਸ ਵਿੱਚ ਕੁਝ ਵੀ ਨਹੀਂ ਦੇਖ ਸਕੋਗੇ: PHP-FPM ਬਿਨਾਂ ਕਿਸੇ ਗਲਤੀ ਜਾਂ ਤੀਜੀ-ਧਿਰ ਦੀਆਂ ਸੂਚਨਾਵਾਂ ਦੇ ਇਸਦੀ ਪ੍ਰਕਿਰਿਆ ਦੇ ਪੂਰਾ ਹੋਣ ਦਾ ਐਲਾਨ ਕਰੇਗਾ।

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

ਇਹ ਪਤਾ ਚਲਦਾ ਹੈ ਕਿ lifecycle ਕੰਟੇਨਰ ਲਈ ਇਸ ਤਰ੍ਹਾਂ ਦਿਖਾਈ ਦੇਵੇਗਾ:

    lifecycle:
      preStop:
        exec:
          command:
          - /bin/sleep
          - "30"

ਹਾਲਾਂਕਿ, 30-ਸਕਿੰਟ ਦੇ ਕਾਰਨ sleep ਅਸੀਂ ਹਾਂ ਬਹੁਤ ਅਸੀਂ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਨੂੰ ਵਧਾਵਾਂਗੇ, ਕਿਉਂਕਿ ਹਰੇਕ ਪੌਡ ਨੂੰ ਖਤਮ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ ਘੱਟੋ ਘੱਟ 30 ਸਕਿੰਟ, ਜੋ ਕਿ ਬੁਰਾ ਹੈ. ਇਸ ਬਾਰੇ ਕੀ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ?

ਆਓ ਅਰਜ਼ੀ ਦੇ ਸਿੱਧੇ ਅਮਲ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਧਿਰ ਵੱਲ ਮੁੜੀਏ। ਸਾਡੇ ਕੇਸ ਵਿੱਚ ਇਹ ਹੈ PHP-FPM, ਜੋ ਕਿ ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਸ ਦੀਆਂ ਚਾਈਲਡ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਐਗਜ਼ੀਕਿਊਸ਼ਨ ਦੀ ਨਿਗਰਾਨੀ ਨਹੀਂ ਕਰਦਾ ਹੈ: ਮਾਸਟਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਤੁਰੰਤ ਖਤਮ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਨਿਰਦੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਇਸ ਵਿਵਹਾਰ ਨੂੰ ਬਦਲ ਸਕਦੇ ਹੋ process_control_timeout, ਜੋ ਮਾਸਟਰ ਤੋਂ ਸਿਗਨਲਾਂ ਦੀ ਉਡੀਕ ਕਰਨ ਲਈ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਲਈ ਸਮਾਂ ਸੀਮਾਵਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਮੁੱਲ ਨੂੰ 20 ਸਕਿੰਟਾਂ 'ਤੇ ਸੈੱਟ ਕਰਦੇ ਹੋ, ਤਾਂ ਇਹ ਕੰਟੇਨਰ ਵਿੱਚ ਚੱਲ ਰਹੀਆਂ ਜ਼ਿਆਦਾਤਰ ਪੁੱਛਗਿੱਛਾਂ ਨੂੰ ਕਵਰ ਕਰੇਗਾ ਅਤੇ ਮਾਸਟਰ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰਾ ਕਰਨ ਤੋਂ ਬਾਅਦ ਰੋਕ ਦੇਵੇਗਾ।

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

ਇਸ ਲਈ, ਕੁੱਲ ਵਿੱਚ ਪਹਿਲਾਂ ਹੀ ਜ਼ਿਕਰ ਕੀਤੇ ਨਿਰਦੇਸ਼ ਦੇ ਨਾਲ process_control_timeout ਤੁਸੀਂ ਹੇਠਾਂ ਦਿੱਤੇ ਨਿਰਮਾਣ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ lifecycle:

lifecycle:
  preStop:
    exec:
      command: ["/bin/bash","-c","/bin/sleep 1; kill -QUIT 1"]

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਕਮਾਂਡ ਨਾਲ ਦੇਰੀ ਲਈ ਮੁਆਵਜ਼ਾ ਦੇਵਾਂਗੇ sleep ਅਤੇ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਨੂੰ ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਾ ਵਧਾਓ: ਕੀ 30 ਸਕਿੰਟ ਅਤੇ ਇੱਕ ਵਿੱਚ ਕੋਈ ਧਿਆਨ ਦੇਣ ਯੋਗ ਅੰਤਰ ਹੈ?... ਅਸਲ ਵਿੱਚ, ਇਹ ਹੈ process_control_timeoutਅਤੇ lifecycle ਪਛੜਨ ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਸਿਰਫ਼ "ਸੁਰੱਖਿਆ ਜਾਲ" ਵਜੋਂ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।

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

ਅਭਿਆਸ. ਪੌਡ ਦੇ ਸੰਚਾਲਨ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਲੋਡ ਟੈਸਟਿੰਗ

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

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

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

ਇਸ ਲਈ, ਪਹਿਲਾ ਟੈਸਟ ਰਨ ਬਿਨਾਂ ਹੋਇਆ ਸੀ lifecycle ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰਵਰ ਲਈ ਵਾਧੂ ਨਿਰਦੇਸ਼ਾਂ ਤੋਂ ਬਿਨਾਂ (process_control_timeout PHP-FPM ਵਿੱਚ). ਇਸ ਟੈਸਟ ਦਾ ਉਦੇਸ਼ ਗਲਤੀਆਂ ਦੀ ਅੰਦਾਜ਼ਨ ਸੰਖਿਆ (ਅਤੇ ਕੀ ਕੋਈ ਹਨ) ਦੀ ਪਛਾਣ ਕਰਨਾ ਸੀ। ਇਸ ਤੋਂ ਇਲਾਵਾ, ਵਾਧੂ ਜਾਣਕਾਰੀ ਤੋਂ, ਤੁਹਾਨੂੰ ਇਹ ਪਤਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਹਰੇਕ ਪੌਡ ਲਈ ਔਸਤ ਤੈਨਾਤੀ ਸਮਾਂ ਲਗਭਗ 5-10 ਸਕਿੰਟ ਸੀ ਜਦੋਂ ਤੱਕ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਤਿਆਰ ਨਹੀਂ ਸੀ। ਨਤੀਜੇ ਹਨ:

Yandex.Tank ਜਾਣਕਾਰੀ ਪੈਨਲ 502 ਤਰੁੱਟੀਆਂ ਦਾ ਵਾਧਾ ਦਰਸਾਉਂਦਾ ਹੈ, ਜੋ ਕਿ ਤੈਨਾਤੀ ਦੇ ਸਮੇਂ ਆਈਆਂ ਅਤੇ ਔਸਤਨ 5 ਸਕਿੰਟਾਂ ਤੱਕ ਚੱਲੀਆਂ। ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ ਇਹ ਇਸ ਲਈ ਸੀ ਕਿਉਂਕਿ ਪੁਰਾਣੇ ਪੋਡ ਲਈ ਮੌਜੂਦਾ ਬੇਨਤੀਆਂ ਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ ਜਦੋਂ ਇਸਨੂੰ ਖਤਮ ਕੀਤਾ ਜਾ ਰਿਹਾ ਸੀ। ਇਸ ਤੋਂ ਬਾਅਦ, 503 ਗਲਤੀਆਂ ਸਾਹਮਣੇ ਆਈਆਂ, ਜੋ ਕਿ ਇੱਕ ਰੁਕੇ ਹੋਏ ਐਨਜੀਆਈਐਨਐਕਸ ਕੰਟੇਨਰ ਦਾ ਨਤੀਜਾ ਸੀ, ਜਿਸ ਨੇ ਬੈਕਐਂਡ ਦੇ ਕਾਰਨ ਕੁਨੈਕਸ਼ਨ ਵੀ ਘਟਾ ਦਿੱਤੇ (ਜਿਸ ਨੇ ਇੰਗਰੈਸ ਨੂੰ ਇਸ ਨਾਲ ਜੁੜਨ ਤੋਂ ਰੋਕਿਆ)।

ਆਓ ਦੇਖੀਏ ਕਿਵੇਂ process_control_timeout PHP-FPM ਵਿੱਚ ਬਾਲ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੇ ਪੂਰਾ ਹੋਣ ਦੀ ਉਡੀਕ ਕਰਨ ਵਿੱਚ ਸਾਡੀ ਮਦਦ ਕਰੇਗਾ, ਜਿਵੇਂ ਕਿ ਅਜਿਹੀਆਂ ਗਲਤੀਆਂ ਨੂੰ ਠੀਕ ਕਰੋ। ਇਸ ਨਿਰਦੇਸ਼ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਮੁੜ-ਤੈਨਾਤ ਕਰੋ:

500 ਵੀਂ ਤੈਨਾਤੀ ਦੌਰਾਨ ਕੋਈ ਹੋਰ ਗਲਤੀਆਂ ਨਹੀਂ ਹਨ! ਤੈਨਾਤੀ ਸਫਲ ਹੈ, ਸ਼ਾਨਦਾਰ ਬੰਦ ਕੰਮ ਕਰਦਾ ਹੈ।

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

ਸਿੱਟਾ

ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਸ਼ਾਨਦਾਰ ਤਰੀਕੇ ਨਾਲ ਖਤਮ ਕਰਨ ਲਈ, ਅਸੀਂ ਐਪਲੀਕੇਸ਼ਨ ਤੋਂ ਹੇਠਾਂ ਦਿੱਤੇ ਵਿਵਹਾਰ ਦੀ ਉਮੀਦ ਕਰਦੇ ਹਾਂ:

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

ਹਾਲਾਂਕਿ, ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਇਸ ਤਰ੍ਹਾਂ ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਕੁਬਰਨੇਟਸ ਹਕੀਕਤਾਂ ਵਿੱਚ ਸਮੱਸਿਆ ਦਾ ਇੱਕ ਹੱਲ ਹੈ:

• ਇੱਕ ਪ੍ਰੀ-ਸਟਾਪ ਹੁੱਕ ਜੋੜਨਾ ਜੋ ਕੁਝ ਸਕਿੰਟਾਂ ਦੀ ਉਡੀਕ ਕਰੇਗਾ;
• ਢੁਕਵੇਂ ਪੈਰਾਮੀਟਰਾਂ ਲਈ ਸਾਡੇ ਬੈਕਐਂਡ ਦੀ ਸੰਰਚਨਾ ਫਾਈਲ ਦਾ ਅਧਿਐਨ ਕਰਨਾ.

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

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

ਲੇਖ 'ਤੇ ਫੀਡਬੈਕ ਦੇ ਜਵਾਬ ਵਿੱਚ: ਇਹ ਵਰਣਨ ਯੋਗ ਹੈ ਕਿ ਇੱਥੇ NGINX Ingress ਦੇ ਸਬੰਧ ਵਿੱਚ ਸਮੱਸਿਆਵਾਂ ਅਤੇ ਹੱਲ ਦੱਸੇ ਗਏ ਹਨ। ਦੂਜੇ ਮਾਮਲਿਆਂ ਲਈ, ਹੋਰ ਹੱਲ ਵੀ ਹਨ, ਜਿਨ੍ਹਾਂ ਬਾਰੇ ਅਸੀਂ ਲੜੀ ਦੀਆਂ ਹੇਠ ਲਿਖੀਆਂ ਸਮੱਗਰੀਆਂ ਵਿੱਚ ਵਿਚਾਰ ਕਰ ਸਕਦੇ ਹਾਂ।

PS

K8s ਟਿਪਸ ਅਤੇ ਟ੍ਰਿਕਸ ਸੀਰੀਜ਼ ਤੋਂ ਹੋਰ:

• «NGINX ਦਾਖਲੇ ਵਿੱਚ ਕਸਟਮ ਗਲਤੀ ਪੰਨੇ";
• «ਵੈਬ ਐਪਲੀਕੇਸ਼ਨ 'ਤੇ ਨੋਡ ਅਲੋਕੇਸ਼ਨ ਅਤੇ ਲੋਡ ਬਾਰੇ";
• «dev ਸਾਈਟਾਂ ਤੱਕ ਪਹੁੰਚ";
• «ਵੱਡੇ ਡੇਟਾਬੇਸ ਲਈ ਬੂਟਸਟਰੈਪ ਨੂੰ ਤੇਜ਼ ਕਰਨਾ".

ਸਰੋਤ: www.habr.com