Kubernetes ਵਿੱਚ Liveness Probes ਖਤਰਨਾਕ ਹੋ ਸਕਦੀ ਹੈ

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

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

ਮੇਰੇ ਸਹਿਕਰਮੀ ਸੈਂਡਰ ਨੇ ਹਾਲ ਹੀ ਵਿੱਚ ਟਵਿੱਟਰ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਆਮ ਤਰੁਟੀਆਂ ਸਾਂਝੀਆਂ ਕੀਤੀਆਂ ਹਨ ਜਿਨ੍ਹਾਂ ਦਾ ਉਹ ਸਾਹਮਣਾ ਕਰਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਤਿਆਰੀ/ਜੀਵਨਤਾ ਜਾਂਚਾਂ ਦੀ ਵਰਤੋਂ ਨਾਲ ਸਬੰਧਤ ਸ਼ਾਮਲ ਹਨ:

ਗਲਤ ਢੰਗ ਨਾਲ ਕੌਂਫਿਗਰ ਕੀਤਾ ਗਿਆ livenessProbe ਉੱਚ-ਲੋਡ ਵਾਲੀਆਂ ਸਥਿਤੀਆਂ (ਸਨੋਬਾਲ ਬੰਦ + ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਲੰਬਾ ਕੰਟੇਨਰ/ਐਪਲੀਕੇਸ਼ਨ ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ) ਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਰ ਨਕਾਰਾਤਮਕ ਨਤੀਜਿਆਂ ਜਿਵੇਂ ਕਿ ਨਿਰਭਰਤਾ ਵਿੱਚ ਕਮੀ (ਇਹ ਵੀ ਵੇਖੋ ਮੇਰਾ ਹਾਲੀਆ ਲੇਖ K3s+ACME ਸੁਮੇਲ ਵਿੱਚ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਸੀਮਤ ਕਰਨ ਬਾਰੇ). ਇਹ ਹੋਰ ਵੀ ਮਾੜਾ ਹੁੰਦਾ ਹੈ ਜਦੋਂ ਜੀਵਣ ਜਾਂਚ ਨੂੰ ਸਿਹਤ ਜਾਂਚ ਨਾਲ ਜੋੜਿਆ ਜਾਂਦਾ ਹੈ, ਜੋ ਕਿ ਇੱਕ ਬਾਹਰੀ ਡੇਟਾਬੇਸ ਹੈ: ਇੱਕ ਸਿੰਗਲ DB ਅਸਫਲਤਾ ਤੁਹਾਡੇ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰ ਦੇਵੇਗੀ!

ਆਮ ਸੁਨੇਹਾ "ਜੀਵਨਤਾ ਜਾਂਚਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ" ਇਸ ਕੇਸ ਵਿੱਚ ਇਹ ਬਹੁਤ ਮਦਦ ਨਹੀਂ ਕਰਦਾ, ਇਸ ਲਈ ਆਓ ਦੇਖੀਏ ਕਿ ਤਿਆਰੀ ਅਤੇ ਜੀਵਣਤਾ ਜਾਂਚਾਂ ਕੀ ਹਨ।

ਨੋਟ: ਹੇਠਾਂ ਦਿੱਤੇ ਜ਼ਿਆਦਾਤਰ ਟੈਸਟ ਅਸਲ ਵਿੱਚ ਜ਼ਲੈਂਡੋ ਦੇ ਅੰਦਰੂਨੀ ਵਿਕਾਸਕਾਰ ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤੇ ਗਏ ਸਨ।

ਤਿਆਰੀ ਅਤੇ ਜੀਵੰਤਤਾ ਦੀ ਜਾਂਚ

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

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

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

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਅੱਪਡੇਟ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ ਜੋ ਲੀਨਤਾ/ਤਿਆਰੀ ਜਾਂਚਾਂ ਨੂੰ ਅਸਫਲ ਕਰਦਾ ਹੈ, ਤਾਂ ਇਸਦਾ ਰੋਲਆਊਟ ਰੁਕ ਜਾਵੇਗਾ ਕਿਉਂਕਿ ਕੁਬਰਨੇਟਸ ਸਥਿਤੀ ਦੀ ਉਡੀਕ ਕਰ ਰਿਹਾ ਹੈ Ready ਸਾਰੀਆਂ ਪੌਡਾਂ ਤੋਂ.

ਉਦਾਹਰਨ:

ਇੱਥੇ ਇੱਕ ਮਾਰਗ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਤਿਆਰੀ ਜਾਂਚ ਦੀ ਇੱਕ ਉਦਾਹਰਨ ਹੈ /health ਮੂਲ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ HTTP ਰਾਹੀਂ (ਅੰਤਰਾਲ: 10 ਸਕਿੰਟ, ਸਮਾਂ ਖ਼ਤਮ: 1 ਸਕਿੰਟ, ਸਫਲਤਾ ਥ੍ਰੈਸ਼ਹੋਲਡ: 1, ਅਸਫਲਤਾ ਥ੍ਰੈਸ਼ਹੋਲਡ:3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

ਿਸਫ਼ਾਰ

1. HTTP ਅੰਤਮ ਬਿੰਦੂ (REST, ਆਦਿ) ਵਾਲੀਆਂ ਮਾਈਕਰੋਸੇਵਾਵਾਂ ਲਈ ਹਮੇਸ਼ਾ ਇੱਕ ਤਿਆਰੀ ਜਾਂਚ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ, ਜੋ ਜਾਂਚ ਕਰਦਾ ਹੈ ਕਿ ਐਪਲੀਕੇਸ਼ਨ (ਪੋਡ) ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ ਜਾਂ ਨਹੀਂ।
2. ਤਿਆਰੀ ਪੜਤਾਲ ਨੂੰ ਯਕੀਨੀ ਬਣਾਓ ਅਸਲ ਵੈੱਬ ਸਰਵਰ ਪੋਰਟ ਦੀ ਉਪਲਬਧਤਾ ਨੂੰ ਕਵਰ ਕਰਦਾ ਹੈ:
   • ਪ੍ਰਬੰਧਕੀ ਉਦੇਸ਼ਾਂ ਲਈ ਪੋਰਟਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ, ਜਿਸਨੂੰ "ਪ੍ਰਬੰਧਕ" ਜਾਂ "ਪ੍ਰਬੰਧਨ" ਕਿਹਾ ਜਾਂਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ, 9090), ਲਈ readinessProbe, ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਅੰਤਮ ਬਿੰਦੂ ਕੇਵਲ ਓਕੇ ਵਾਪਸ ਕਰਦਾ ਹੈ ਜੇਕਰ ਪ੍ਰਾਇਮਰੀ HTTP ਪੋਰਟ (ਜਿਵੇਂ 8080) ਟ੍ਰੈਫਿਕ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਲਈ ਤਿਆਰ ਹੈ*;

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

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

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

4. ਵਰਤੋਂ ਕਰੋ httpGet ਆਮ ਸਿਹਤ ਜਾਂਚ ਅੰਤਮ ਬਿੰਦੂਆਂ ਦੁਆਰਾ ਤਿਆਰੀ ਜਾਂਚਾਂ ਲਈ (ਉਦਾਹਰਨ ਲਈ, /health).
5. ਡਿਫੌਲਟ ਜਾਂਚ ਪੈਰਾਮੀਟਰਾਂ ਨੂੰ ਸਮਝੋ (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ਡਿਫਾਲਟ ਵਿਕਲਪਾਂ ਦਾ ਮਤਲਬ ਹੈ ਪੌਡ ਬਣ ਜਾਵੇਗਾ ਤਿਆਰ ਨਹੀਂ ਲਗਭਗ 30 ਸਕਿੰਟਾਂ ਤੋਂ ਬਾਅਦ (3 ਅਸਫਲ ਸਵੱਛਤਾ ਜਾਂਚਾਂ)।
6. "ਪ੍ਰਬੰਧਕ" ਜਾਂ "ਪ੍ਰਬੰਧਨ" ਲਈ ਇੱਕ ਵੱਖਰਾ ਪੋਰਟ ਵਰਤੋ ਜੇਕਰ ਤਕਨਾਲੋਜੀ ਸਟੈਕ (ਜਿਵੇਂ ਕਿ Java/ਬਸੰਤ) ਇਸਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਸਿਹਤ ਅਤੇ ਮੈਟ੍ਰਿਕਸ ਪ੍ਰਬੰਧਨ ਨੂੰ ਨਿਯਮਤ ਆਵਾਜਾਈ ਤੋਂ ਵੱਖ ਕਰਨ ਲਈ:
   • ਪਰ ਬਿੰਦੂ 2 ਬਾਰੇ ਨਾ ਭੁੱਲੋ।
7. ਜੇ ਜਰੂਰੀ ਹੋਵੇ, ਰੈਡੀਨੇਸ ਪ੍ਰੋਬ ਦੀ ਵਰਤੋਂ ਕੈਸ਼ ਨੂੰ ਗਰਮ ਕਰਨ/ਲੋਡ ਕਰਨ ਲਈ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ ਅਤੇ ਕੰਟੇਨਰ ਦੇ ਗਰਮ ਹੋਣ ਤੱਕ 503 ਸਥਿਤੀ ਕੋਡ ਵਾਪਸ ਕਰ ਸਕਦਾ ਹੈ:
   • ਮੈਂ ਇਹ ਵੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦਾ ਹਾਂ ਕਿ ਤੁਸੀਂ ਨਵਾਂ ਚੈੱਕ ਪੜ੍ਹੋ startupProbe, ਸੰਸਕਰਣ 1.16 ਵਿੱਚ ਪ੍ਰਗਟ ਹੋਇਆ (ਅਸੀਂ ਇਸ ਬਾਰੇ ਰੂਸੀ ਵਿੱਚ ਲਿਖਿਆ ਹੈ ਇੱਥੇ - ਲਗਭਗ ਅਨੁਵਾਦ।).

ਸਿਵਤਾਂ

1. ਬਾਹਰੀ ਨਿਰਭਰਤਾ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਡੇਟਾ ਵੇਅਰਹਾਊਸ) ਜਦੋਂ ਤਿਆਰੀ/ਜੀਵਨਤਾ ਟੈਸਟ ਚਲਾਉਂਦੇ ਹੋ - ਇਸ ਨਾਲ ਕੈਸਕੇਡਿੰਗ ਅਸਫਲਤਾਵਾਂ ਹੋ ਸਕਦੀਆਂ ਹਨ:
   • ਇੱਕ ਉਦਾਹਰਨ ਦੇ ਤੌਰ ਤੇ, ਆਓ ਇੱਕ ਪੋਸਟਗ੍ਰੇਸ ਡੇਟਾਬੇਸ ਦੇ ਅਧਾਰ ਤੇ 10 ਪੌਡਸ ਦੇ ਨਾਲ ਇੱਕ ਸਟੇਟਫੁੱਲ REST ਸੇਵਾ ਲਈਏ: ਜਦੋਂ ਜਾਂਚ DB ਨਾਲ ਇੱਕ ਕਾਰਜਸ਼ੀਲ ਕਨੈਕਸ਼ਨ 'ਤੇ ਨਿਰਭਰ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਾਰੇ 10 ਪੌਡ ਅਸਫਲ ਹੋ ਸਕਦੇ ਹਨ ਜੇਕਰ ਨੈੱਟਵਰਕ/DB ਸਾਈਡ 'ਤੇ ਦੇਰੀ ਹੁੰਦੀ ਹੈ - ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਸਭ ਦਾ ਅੰਤ ਇਸ ਤੋਂ ਵੀ ਮਾੜਾ ਹੋ ਸਕਦਾ ਹੈ;
   • ਕਿਰਪਾ ਕਰਕੇ ਧਿਆਨ ਦਿਓ ਕਿ ਸਪਰਿੰਗ ਡੇਟਾ ਮੂਲ ਰੂਪ ਵਿੱਚ ਡਾਟਾਬੇਸ ਕੁਨੈਕਸ਼ਨ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ*;

     * ਇਹ ਸਪਰਿੰਗ ਡੇਟਾ ਰੈਡਿਸ ਦਾ ਡਿਫੌਲਟ ਵਿਵਹਾਰ ਹੈ (ਘੱਟੋ-ਘੱਟ ਇਹ ਆਖਰੀ ਵਾਰ ਸੀ ਜਦੋਂ ਮੈਂ ਜਾਂਚ ਕੀਤੀ ਸੀ), ਜਿਸ ਨਾਲ "ਘਾਤਕ" ਅਸਫਲਤਾ ਹੋਈ: ਜਦੋਂ ਰੈਡਿਸ ਥੋੜੇ ਸਮੇਂ ਲਈ ਉਪਲਬਧ ਨਹੀਂ ਸੀ, ਤਾਂ ਸਾਰੇ ਪੌਡ "ਕਰੈਸ਼" ਹੋ ਗਏ।

   • ਇਸ ਅਰਥ ਵਿੱਚ "ਬਾਹਰੀ" ਦਾ ਅਰਥ ਉਸੇ ਐਪਲੀਕੇਸ਼ਨ ਦੇ ਹੋਰ ਪੌਡ ਵੀ ਹੋ ਸਕਦਾ ਹੈ, ਭਾਵ, ਆਦਰਸ਼ਕ ਤੌਰ 'ਤੇ ਕੈਸਕੇਡਿੰਗ ਕਰੈਸ਼ਾਂ ਨੂੰ ਰੋਕਣ ਲਈ ਚੈੱਕ ਨੂੰ ਉਸੇ ਕਲੱਸਟਰ ਦੇ ਦੂਜੇ ਪੌਡਾਂ ਦੀ ਸਥਿਤੀ 'ਤੇ ਨਿਰਭਰ ਨਹੀਂ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ:
     • ਡਿਸਟਰੀਬਿਊਟਡ ਸਟੇਟ (ਉਦਾਹਰਨ ਲਈ, ਪੌਡਸ ਵਿੱਚ ਇਨ-ਮੈਮੋਰੀ ਕੈਚਿੰਗ) ਵਾਲੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਲਈ ਨਤੀਜੇ ਵੱਖੋ-ਵੱਖਰੇ ਹੋ ਸਕਦੇ ਹਨ।
2. ਇੱਕ ਜੀਵਿਤਤਾ ਜਾਂਚ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ ਪੌਡਾਂ ਲਈ (ਅਪਵਾਦ ਉਹ ਕੇਸ ਹੁੰਦੇ ਹਨ ਜਦੋਂ ਉਹ ਅਸਲ ਵਿੱਚ ਜ਼ਰੂਰੀ ਹੁੰਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਦੀ ਵਰਤੋਂ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਅਤੇ ਨਤੀਜਿਆਂ ਤੋਂ ਪੂਰੀ ਤਰ੍ਹਾਂ ਜਾਣੂ ਹੁੰਦੇ ਹੋ):
   • ਇੱਕ ਜੀਵਿਤਤਾ ਜਾਂਚ ਲਟਕ ਰਹੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਮੁੜ ਪ੍ਰਾਪਤ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦੀ ਹੈ, ਪਰ ਕਿਉਂਕਿ ਤੁਹਾਡੀ ਅਰਜ਼ੀ 'ਤੇ ਤੁਹਾਡਾ ਪੂਰਾ ਨਿਯੰਤਰਣ ਹੈ, ਇਸ ਲਈ ਹੰਗ ਪ੍ਰਕਿਰਿਆਵਾਂ ਅਤੇ ਰੁਕਾਵਟਾਂ ਵਰਗੀਆਂ ਚੀਜ਼ਾਂ ਆਦਰਸ਼ ਰੂਪ ਵਿੱਚ ਨਹੀਂ ਹੋਣੀਆਂ ਚਾਹੀਦੀਆਂ: ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਹੈ ਜਾਣਬੁੱਝ ਕੇ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਕ੍ਰੈਸ਼ ਕਰਨਾ ਅਤੇ ਇਸਨੂੰ ਪਿਛਲੀ ਸਥਿਰ ਸਥਿਤੀ ਵਿੱਚ ਵਾਪਸ ਲਿਆਉਣਾ;
   • ਇੱਕ ਅਸਫਲ ਲਾਈਵਨੈਸ ਪੜਤਾਲ ਕੰਟੇਨਰ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਦਾ ਕਾਰਨ ਬਣੇਗੀ, ਜਿਸ ਨਾਲ ਸੰਭਾਵੀ ਤੌਰ 'ਤੇ ਲੋਡਿੰਗ-ਸਬੰਧਤ ਗਲਤੀਆਂ ਦੇ ਨਤੀਜਿਆਂ ਨੂੰ ਵਧਾਇਆ ਜਾ ਸਕਦਾ ਹੈ: ਕੰਟੇਨਰ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਨਾਲ ਡਾਊਨਟਾਈਮ ਹੋਵੇਗਾ (ਘੱਟੋ-ਘੱਟ ਐਪਲੀਕੇਸ਼ਨ ਸਟਾਰਟਅਪ ਦੀ ਮਿਆਦ ਲਈ, 30-ਅਜੀਬ ਸਕਿੰਟਾਂ ਲਈ), ਨਵੀਆਂ ਗਲਤੀਆਂ ਪੈਦਾ ਕਰਨਗੀਆਂ। , ਦੂਜੇ ਕੰਟੇਨਰਾਂ 'ਤੇ ਲੋਡ ਵਧਾਉਣਾ ਅਤੇ ਉਹਨਾਂ ਦੀ ਅਸਫਲਤਾ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਵਧਾਉਣਾ, ਆਦਿ;
   • ਇੱਕ ਬਾਹਰੀ ਨਿਰਭਰਤਾ ਦੇ ਨਾਲ ਸੰਯੁਕਤ ਜੀਵਣਤਾ ਜਾਂਚਾਂ ਸਭ ਤੋਂ ਭੈੜਾ ਸੰਭਾਵਿਤ ਸੁਮੇਲ ਹਨ, ਕੈਸਕੇਡਿੰਗ ਅਸਫਲਤਾਵਾਂ ਨੂੰ ਖ਼ਤਰਾ: ਡੇਟਾਬੇਸ ਸਾਈਡ 'ਤੇ ਥੋੜੀ ਜਿਹੀ ਦੇਰੀ ਤੁਹਾਡੇ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਨ ਵੱਲ ਲੈ ਜਾਵੇਗੀ!
3. ਜੀਵੰਤਤਾ ਅਤੇ ਤਿਆਰੀ ਜਾਂਚਾਂ ਦੇ ਮਾਪਦੰਡ ਵੱਖਰਾ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ:
   • ਤੁਸੀਂ ਉਸੇ ਸਿਹਤ ਜਾਂਚ ਦੇ ਨਾਲ ਇੱਕ ਜੀਵਣ ਜਾਂਚ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ, ਪਰ ਇੱਕ ਉੱਚ ਪ੍ਰਤੀਕਿਰਿਆ ਥ੍ਰੈਸ਼ਹੋਲਡ (failureThreshold), ਉਦਾਹਰਨ ਲਈ, ਸਥਿਤੀ ਨਿਰਧਾਰਤ ਕਰੋ ਤਿਆਰ ਨਹੀਂ 3 ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਅਤੇ ਵਿਚਾਰ ਕਰੋ ਕਿ 10 ਕੋਸ਼ਿਸ਼ਾਂ ਤੋਂ ਬਾਅਦ ਜੀਵਣਤਾ ਜਾਂਚ ਅਸਫਲ ਹੋ ਗਈ ਹੈ;
4. exec ਜਾਂਚਾਂ ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਉਹ ਜਾਣੀਆਂ-ਪਛਾਣੀਆਂ ਸਮੱਸਿਆਵਾਂ ਨਾਲ ਜੁੜੇ ਹੋਏ ਹਨ ਜੋ ਜੂਮਬੀਨ ਪ੍ਰਕਿਰਿਆਵਾਂ ਦੀ ਦਿੱਖ ਵੱਲ ਲੈ ਜਾਂਦੇ ਹਨ:
   • ਵੇਰਵੇ: ਵੇਖੋ ਡੈਟਾਡੌਗ ਮਾਹਿਰਾਂ ਦੁਆਰਾ ਪੇਸ਼ਕਾਰੀ.

ਸੰਖੇਪ

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

ਵਿਸ਼ੇ 'ਤੇ ਵਾਧੂ ਸਮੱਗਰੀ

• ਕੁਬਰਨੇਟਸ ਡੌਕਸ: ਸਜੀਵਤਾ ਅਤੇ ਤਿਆਰੀ ਪੜਤਾਲਾਂ ਦੀ ਸੰਰਚਨਾ ਕਰੋ;
• ਕੁਬਰਨੇਟਸ ਲਿਵਨੇਸ ਅਤੇ ਰੈਡੀਨੇਸ ਪ੍ਰੋਬਸ ਮੁੜ ਵਿਚਾਰੇ: ਦੂਜੇ ਪੈਰਾਂ ਵਿੱਚ ਆਪਣੇ ਆਪ ਨੂੰ ਗੋਲੀ ਮਾਰਨ ਤੋਂ ਕਿਵੇਂ ਬਚਣਾ ਹੈ;
• NRE ਲੈਬ ਆਊਟੇਜ ਪੋਸਟ-ਮਾਰਟਮ (ਉਹ livenessProbe ਬਾਰੇ ਵੀ ਗੱਲ ਕਰਦਾ ਹੈ)।

1-2019-09 ਤੋਂ ਅੱਪਡੇਟ ਨੰਬਰ 29

ਡਾਟਾਬੇਸ ਮਾਈਗਰੇਸ਼ਨ ਲਈ init ਕੰਟੇਨਰਾਂ ਬਾਰੇ: ਫੁਟਨੋਟ ਜੋੜਿਆ ਗਿਆ।

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

ਬ੍ਰਾਇਨ ਨੇ ਇਸ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਨਾਲ ਲਗਾਇਆ: “ਜਦੋਂ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ ਕਿ ਅਸਲ ਵਿੱਚ ਕੀ ਹੈ, ਤਾਂ ਜੀਵਣਤਾ ਜਾਂਚ ਦੀ ਵਰਤੋਂ ਕਰੋ ਸਭ ਤੋਂ ਵਧੀਆ ਕੰਮ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਖਤਮ ਕਰਨਾ ਹੈ"(ਦੁਬਾਰਾ, ਦੂਰ ਨਾ ਹੋਵੋ).

2-2019-09 ਤੋਂ ਅੱਪਡੇਟ ਨੰਬਰ 29

ਵਰਤੋਂ ਤੋਂ ਪਹਿਲਾਂ ਦਸਤਾਵੇਜ਼ਾਂ ਨੂੰ ਪੜ੍ਹਨ ਦੇ ਸੰਬੰਧ ਵਿੱਚ: ਮੈਂ ਅਨੁਸਾਰੀ ਬੇਨਤੀ ਬਣਾਈ ਹੈ (ਫੀਚਰ ਲਈ ਬੇਨਤੀ) ਜੀਵਤਤਾ ਪੜਤਾਲਾਂ ਬਾਰੇ ਦਸਤਾਵੇਜ਼ ਜੋੜਨ ਲਈ।

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

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

• «ਕੁਬਰਨੇਟਸ: ਪੌਡ ਲਾਈਫ";
• «ਗੂਗਲ ਦੇ ਅਨੁਸਾਰ ਕੰਟੇਨਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ 7 ਸਭ ਤੋਂ ਵਧੀਆ ਅਭਿਆਸ";
• «ਕੰਟੇਨਰ-ਅਧਾਰਿਤ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲਈ 7 ਸਿਧਾਂਤ".

ਸਰੋਤ: www.habr.com