ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ 10 ਆਮ ਗਲਤੀਆਂ

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

ਕੁਬਰਨੇਟਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੇ ਸਾਲਾਂ ਦੌਰਾਨ, ਅਸੀਂ ਬਹੁਤ ਸਾਰੇ ਕਲੱਸਟਰਾਂ ਨਾਲ ਕੰਮ ਕੀਤਾ ਹੈ (ਪ੍ਰਬੰਧਿਤ ਅਤੇ ਅਪ੍ਰਬੰਧਿਤ - GCP, AWS ਅਤੇ Azure 'ਤੇ)। ਸਮੇਂ ਦੇ ਨਾਲ, ਅਸੀਂ ਧਿਆਨ ਦੇਣਾ ਸ਼ੁਰੂ ਕੀਤਾ ਕਿ ਕੁਝ ਗਲਤੀਆਂ ਲਗਾਤਾਰ ਦੁਹਰਾਈਆਂ ਗਈਆਂ ਸਨ. ਹਾਲਾਂਕਿ, ਇਸ ਵਿੱਚ ਕੋਈ ਸ਼ਰਮ ਦੀ ਗੱਲ ਨਹੀਂ ਹੈ: ਅਸੀਂ ਉਨ੍ਹਾਂ ਵਿੱਚੋਂ ਜ਼ਿਆਦਾਤਰ ਆਪਣੇ ਆਪ ਕੀਤੇ ਹਨ!

ਲੇਖ ਵਿੱਚ ਸਭ ਤੋਂ ਆਮ ਤਰੁਟੀਆਂ ਹਨ ਅਤੇ ਇਹ ਵੀ ਦੱਸਿਆ ਗਿਆ ਹੈ ਕਿ ਉਹਨਾਂ ਨੂੰ ਕਿਵੇਂ ਠੀਕ ਕਰਨਾ ਹੈ।

1. ਸਰੋਤ: ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ

ਇਹ ਆਈਟਮ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਸਭ ਤੋਂ ਨਜ਼ਦੀਕੀ ਧਿਆਨ ਅਤੇ ਸੂਚੀ ਵਿੱਚ ਪਹਿਲੇ ਸਥਾਨ ਦਾ ਹੱਕਦਾਰ ਹੈ।

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

ਵਧੀਆ ਕੋਸ਼ਿਸ਼ (ਬਹੁਤ ਜ਼ਿਆਦਾ ਨਾ ਸਿਫਾਰਸ਼ ਕੀਤੀ):

resources: {}

ਬਹੁਤ ਘੱਟ CPU ਬੇਨਤੀ (ਬਹੁਤ ਹੀ ਨਾ ਸਿਫਾਰਸ਼ ਕੀਤੀ):

   resources:
      Requests:
        cpu: "1m"

ਦੂਜੇ ਪਾਸੇ, ਇੱਕ CPU ਸੀਮਾ ਦੀ ਮੌਜੂਦਗੀ ਪੌਡ ਦੁਆਰਾ ਘੜੀ ਦੇ ਚੱਕਰਾਂ ਨੂੰ ਅਣਉਚਿਤ ਛੱਡਣ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ, ਭਾਵੇਂ ਨੋਡ ਪ੍ਰੋਸੈਸਰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਲੋਡ ਨਾ ਹੋਵੇ। ਦੁਬਾਰਾ ਫਿਰ, ਇਸ ਨਾਲ ਵਧੀ ਹੋਈ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਪੈਰਾਮੀਟਰ ਨੂੰ ਲੈ ਕੇ ਵਿਵਾਦ ਜਾਰੀ ਹੈ CPU CFS ਕੋਟਾ ਲੀਨਕਸ ਕਰਨਲ ਅਤੇ CPU ਥ੍ਰੋਟਲਿੰਗ ਵਿੱਚ ਸੈੱਟ ਸੀਮਾਵਾਂ ਦੇ ਆਧਾਰ 'ਤੇ, ਨਾਲ ਹੀ CFS ਕੋਟਾ ਨੂੰ ਅਯੋਗ ਕਰਨਾ... ਹਾਏ, CPU ਸੀਮਾਵਾਂ ਉਹਨਾਂ ਨੂੰ ਹੱਲ ਕਰਨ ਨਾਲੋਂ ਵੱਧ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਕਰ ਸਕਦੀਆਂ ਹਨ। ਇਸ ਬਾਰੇ ਹੋਰ ਜਾਣਕਾਰੀ ਹੇਠਾਂ ਦਿੱਤੇ ਲਿੰਕ 'ਤੇ ਮਿਲ ਸਕਦੀ ਹੈ।

ਬਹੁਤ ਜ਼ਿਆਦਾ ਚੋਣ (ਜ਼ਿਆਦਾ ਵਚਨਬੱਧ) ਯਾਦਦਾਸ਼ਤ ਦੀਆਂ ਸਮੱਸਿਆਵਾਂ ਵੱਡੀਆਂ ਸਮੱਸਿਆਵਾਂ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀਆਂ ਹਨ। CPU ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ ਨਾਲ ਘੜੀ ਦੇ ਚੱਕਰ ਨੂੰ ਛੱਡਣਾ ਪੈਂਦਾ ਹੈ, ਜਦੋਂ ਕਿ ਮੈਮੋਰੀ ਸੀਮਾ ਤੱਕ ਪਹੁੰਚਣ ਨਾਲ ਪੌਡ ਨੂੰ ਖਤਮ ਕਰਨਾ ਪੈਂਦਾ ਹੈ। ਕੀ ਤੁਸੀਂ ਕਦੇ ਦੇਖਿਆ ਹੈ OOMkill? ਹਾਂ, ਇਹ ਬਿਲਕੁਲ ਉਹੀ ਹੈ ਜਿਸ ਬਾਰੇ ਅਸੀਂ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ।

ਕੀ ਤੁਸੀਂ ਅਜਿਹਾ ਹੋਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘੱਟ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ? ਮੈਮੋਰੀ ਨੂੰ ਓਵਰ-ਐਲੋਕੇਟ ਨਾ ਕਰੋ ਅਤੇ ਮੈਮੋਰੀ ਬੇਨਤੀ ਨੂੰ ਸੀਮਾ 'ਤੇ ਸੈੱਟ ਕਰਕੇ ਗਾਰੰਟੀਸ਼ੁਦਾ QoS (ਸੇਵਾ ਦੀ ਗੁਣਵੱਤਾ) ਦੀ ਵਰਤੋਂ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਹੇਠਾਂ ਦਿੱਤੀ ਉਦਾਹਰਨ ਵਿੱਚ)। ਵਿੱਚ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹੋ ਹੇਨਿੰਗ ਜੈਕਬਸ ਦੀਆਂ ਪੇਸ਼ਕਾਰੀਆਂ (ਜ਼ਲੈਂਡੋ ਵਿਖੇ ਲੀਡ ਇੰਜੀਨੀਅਰ)।

ਬਰਸਟਬਲ (OOM ਮਾਰੇ ਜਾਣ ਦੀ ਉੱਚ ਸੰਭਾਵਨਾ):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ਗਾਰੰਟੀਸ਼ੁਦਾ:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

ਸੰਸਾਧਨਾਂ ਨੂੰ ਸਥਾਪਤ ਕਰਨ ਵੇਲੇ ਕੀ ਮਦਦ ਕਰੇਗਾ?

ਦੀ ਸਹਾਇਤਾ ਨਾਲ ਮੈਟ੍ਰਿਕਸ-ਸਰਵਰ ਤੁਸੀਂ ਮੌਜੂਦਾ CPU ਸਰੋਤ ਦੀ ਖਪਤ ਅਤੇ ਮੈਮੋਰੀ ਵਰਤੋਂ ਨੂੰ ਪੌਡਜ਼ (ਅਤੇ ਉਹਨਾਂ ਦੇ ਅੰਦਰ ਕੰਟੇਨਰ) ਦੁਆਰਾ ਦੇਖ ਸਕਦੇ ਹੋ। ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸਦੀ ਵਰਤੋਂ ਕਰ ਰਹੇ ਹੋ. ਬੱਸ ਹੇਠ ਲਿਖੀਆਂ ਕਮਾਂਡਾਂ ਚਲਾਓ:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

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

ਵਰਟੀਕਲਪੋਡ ਆਟੋਸਕੇਲਰ ਇਹ ਸਹਾਇਕ ਹੈ ਸਵੈਚਾਲਤ ਇਸ ਪ੍ਰਕਿਰਿਆ ਨੂੰ. ਇਹ CPU ਅਤੇ ਮੈਮੋਰੀ ਵਰਤੋਂ ਇਤਿਹਾਸ ਨੂੰ ਟਰੈਕ ਕਰਦਾ ਹੈ ਅਤੇ ਇਸ ਜਾਣਕਾਰੀ ਦੇ ਆਧਾਰ 'ਤੇ ਨਵੀਆਂ ਬੇਨਤੀਆਂ ਅਤੇ ਸੀਮਾਵਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦਾ ਹੈ।

ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ ਦੀ ਕੁਸ਼ਲਤਾ ਨਾਲ ਵਰਤੋਂ ਕਰਨਾ ਕੋਈ ਆਸਾਨ ਕੰਮ ਨਹੀਂ ਹੈ। ਇਹ ਹਰ ਸਮੇਂ ਟੈਟ੍ਰਿਸ ਖੇਡਣ ਵਰਗਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਘੱਟ ਔਸਤ ਖਪਤ (~10% ਕਹੋ) ਨਾਲ ਕੰਪਿਊਟ ਪਾਵਰ ਲਈ ਬਹੁਤ ਜ਼ਿਆਦਾ ਭੁਗਤਾਨ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਅਸੀਂ AWS Fargate ਜਾਂ Virtual Kubelet 'ਤੇ ਆਧਾਰਿਤ ਉਤਪਾਦਾਂ ਨੂੰ ਦੇਖਣ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ। ਉਹ ਸਰਵਰ ਰਹਿਤ/ਪੇ-ਪ੍ਰਤੀ-ਵਰਤੋਂ ਬਿਲਿੰਗ ਮਾਡਲ 'ਤੇ ਬਣਾਏ ਗਏ ਹਨ, ਜੋ ਕਿ ਅਜਿਹੀਆਂ ਸਥਿਤੀਆਂ ਵਿੱਚ ਸਸਤਾ ਹੋ ਸਕਦਾ ਹੈ।

2. ਜੀਵੰਤਤਾ ਅਤੇ ਤਤਪਰਤਾ ਪੜਤਾਲਾਂ

ਡਿਫੌਲਟ ਰੂਪ ਵਿੱਚ, ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸਜੀਵਤਾ ਅਤੇ ਤਿਆਰੀ ਜਾਂਚਾਂ ਯੋਗ ਨਹੀਂ ਹਨ। ਅਤੇ ਕਈ ਵਾਰ ਉਹ ਉਹਨਾਂ ਨੂੰ ਚਾਲੂ ਕਰਨਾ ਭੁੱਲ ਜਾਂਦੇ ਹਨ ...

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

ਇਹ ਟੈਸਟ ਅਕਸਰ ਇੱਕ ਦੂਜੇ ਨਾਲ ਉਲਝਣ ਵਿੱਚ ਹੁੰਦੇ ਹਨ:

• ਜੀਵਤ - "ਬਚਣਯੋਗਤਾ" ਜਾਂਚ, ਜੋ ਪੌਡ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕਰਦੀ ਹੈ ਜੇਕਰ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ;
• ਤਿਆਰੀ - ਤਿਆਰੀ ਦੀ ਜਾਂਚ, ਜੇ ਇਹ ਅਸਫਲ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਇਹ ਕੁਬਰਨੇਟਸ ਸੇਵਾ ਤੋਂ ਪੌਡ ਨੂੰ ਡਿਸਕਨੈਕਟ ਕਰ ਦਿੰਦਾ ਹੈ (ਇਸਦੀ ਵਰਤੋਂ ਕਰਕੇ ਜਾਂਚ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ kubectl get endpoints) ਅਤੇ ਟ੍ਰੈਫਿਕ ਇਸ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚਦਾ ਜਦੋਂ ਤੱਕ ਅਗਲੀ ਜਾਂਚ ਸਫਲਤਾਪੂਰਵਕ ਪੂਰੀ ਨਹੀਂ ਹੋ ਜਾਂਦੀ।

ਇਹ ਦੋਵੇਂ ਚੈਕ ਪੋਡ ਦੇ ਪੂਰੇ ਜੀਵਨ ਚੱਕਰ ਦੌਰਾਨ ਪ੍ਰਦਰਸ਼ਨ ਕੀਤਾ. ਇਹ ਬਹੁਤ ਜ਼ਰੂਰੀ ਹੈ।

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

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

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

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

3. ਹਰੇਕ HTTP ਸੇਵਾ ਲਈ ਲੋਡਬੈਲੈਂਸਰ

ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਨਾ ਹੈ, ਤੁਹਾਡੇ ਕੋਲ ਤੁਹਾਡੇ ਕਲੱਸਟਰ ਵਿੱਚ HTTP ਸੇਵਾਵਾਂ ਹਨ ਜੋ ਤੁਸੀਂ ਬਾਹਰੀ ਦੁਨੀਆ ਨੂੰ ਅੱਗੇ ਭੇਜਣਾ ਚਾਹੁੰਦੇ ਹੋ।

ਜੇ ਤੁਸੀਂ ਸੇਵਾ ਨੂੰ ਖੋਲ੍ਹਦੇ ਹੋ type: LoadBalancer, ਇਸਦਾ ਕੰਟਰੋਲਰ (ਸੇਵਾ ਪ੍ਰਦਾਤਾ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ) ਇੱਕ ਬਾਹਰੀ ਲੋਡਬੈਲੈਂਸਰ ਪ੍ਰਦਾਨ ਕਰੇਗਾ ਅਤੇ ਗੱਲਬਾਤ ਕਰੇਗਾ (ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ L7 'ਤੇ ਨਹੀਂ, ਸਗੋਂ L4 'ਤੇ ਵੀ ਚੱਲਦਾ ਹੈ), ਅਤੇ ਇਹ ਲਾਗਤ (ਬਾਹਰੀ ਸਥਿਰ IPv4 ਪਤਾ, ਕੰਪਿਊਟਿੰਗ ਪਾਵਰ, ਪ੍ਰਤੀ-ਸੈਕਿੰਡ ਬਿਲਿੰਗ) ਨੂੰ ਪ੍ਰਭਾਵਿਤ ਕਰ ਸਕਦਾ ਹੈ। ) ਅਜਿਹੇ ਸਰੋਤਾਂ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ ਬਣਾਉਣ ਦੀ ਜ਼ਰੂਰਤ ਦੇ ਕਾਰਨ.

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

ਹੋਰ ਇੰਟਰਾ-ਕਲੱਸਟਰ (ਮਾਈਕਰੋ) ਸੇਵਾਵਾਂ ਜੋ ਇੱਕ ਦੂਜੇ ਨਾਲ ਪਰਸਪਰ ਪ੍ਰਭਾਵ ਪਾਉਂਦੀਆਂ ਹਨ, ਜਿਵੇਂ ਕਿ ਸੇਵਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ "ਸੰਚਾਰ" ਕਰ ਸਕਦੀਆਂ ਹਨ ClusterIP ਅਤੇ DNS ਦੁਆਰਾ ਇੱਕ ਬਿਲਟ-ਇਨ ਸੇਵਾ ਖੋਜ ਵਿਧੀ। ਬਸ ਉਹਨਾਂ ਦੇ ਜਨਤਕ DNS/IP ਦੀ ਵਰਤੋਂ ਨਾ ਕਰੋ, ਕਿਉਂਕਿ ਇਹ ਲੇਟੈਂਸੀ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਕਲਾਉਡ ਸੇਵਾਵਾਂ ਦੀ ਲਾਗਤ ਨੂੰ ਵਧਾ ਸਕਦਾ ਹੈ।

4. ਇੱਕ ਕਲੱਸਟਰ ਦੀਆਂ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖੇ ਬਿਨਾਂ ਆਟੋਸਕੇਲਿੰਗ ਕਰਨਾ

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

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

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

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

5. IAM/RBAC ਸਮਰੱਥਾਵਾਂ ਨੂੰ ਨਜ਼ਰਅੰਦਾਜ਼ ਕਰਨਾ

ਲਈ ਲਗਾਤਾਰ ਭੇਦ ਰੱਖਣ ਵਾਲੇ IAM ਉਪਭੋਗਤਾਵਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਤੋਂ ਸਾਵਧਾਨ ਰਹੋ ਮਸ਼ੀਨਾਂ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ. ਭੂਮਿਕਾਵਾਂ ਅਤੇ ਸੇਵਾ ਖਾਤਿਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਅਸਥਾਈ ਪਹੁੰਚ ਦਾ ਪ੍ਰਬੰਧ ਕਰੋ (ਸੇਵਾ ਖਾਤੇ).

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

kube2iam ਬਾਰੇ ਭੁੱਲ ਜਾਓ ਅਤੇ ਸੇਵਾ ਖਾਤਿਆਂ ਲਈ ਸਿੱਧੇ IAM ਭੂਮਿਕਾਵਾਂ 'ਤੇ ਜਾਓ (ਜਿਵੇਂ ਕਿ ਵਿੱਚ ਦੱਸਿਆ ਗਿਆ ਹੈ ਉਸੇ ਨਾਮ ਦਾ ਨੋਟ ਸਟੈਪਨ ਵਰਾਨੀ):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ਇੱਕ ਐਨੋਟੇਸ਼ਨ। ਇੰਨਾ ਔਖਾ ਨਹੀਂ, ਠੀਕ ਹੈ?

ਨਾਲ ਹੀ, ਸੇਵਾ ਖਾਤਿਆਂ ਅਤੇ ਉਦਾਹਰਣ ਪ੍ਰੋਫਾਈਲਾਂ ਦੇ ਵਿਸ਼ੇਸ਼ ਅਧਿਕਾਰ ਨਾ ਦਿਓ admin и cluster-adminਜੇਕਰ ਉਹਨਾਂ ਨੂੰ ਇਸਦੀ ਲੋੜ ਨਹੀਂ ਹੈ। ਇਹ ਲਾਗੂ ਕਰਨਾ ਥੋੜਾ ਹੋਰ ਔਖਾ ਹੈ, ਖਾਸ ਕਰਕੇ RBAC K8s ਵਿੱਚ, ਪਰ ਯਕੀਨੀ ਤੌਰ 'ਤੇ ਕੋਸ਼ਿਸ਼ ਦੇ ਯੋਗ ਹੈ।

6. ਪੌਡਾਂ ਲਈ ਆਟੋਮੈਟਿਕ ਐਂਟੀ-ਐਫੀਨਿਟੀ 'ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਨੋਡ 'ਤੇ ਕੁਝ ਤੈਨਾਤੀ ਦੀਆਂ ਤਿੰਨ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਹਨ। ਨੋਡ ਡਿੱਗਦਾ ਹੈ, ਅਤੇ ਇਸਦੇ ਨਾਲ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ. ਅਣਸੁਖਾਵੀਂ ਸਥਿਤੀ, ਠੀਕ ਹੈ? ਪਰ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਇੱਕੋ ਨੋਡ 'ਤੇ ਕਿਉਂ ਸਨ? ਕੀ ਕੁਬਰਨੇਟਸ ਨੂੰ ਉੱਚ ਉਪਲਬਧਤਾ (HA) ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਨੀ ਚਾਹੀਦੀ?!

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

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

ਇਹ ਸਭ ਹੈ. ਹੁਣ ਪੌਡਾਂ ਨੂੰ ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ ਤਹਿ ਕੀਤਾ ਜਾਵੇਗਾ (ਇਸ ਸਥਿਤੀ ਦੀ ਜਾਂਚ ਸਿਰਫ ਸਮਾਂ-ਸਾਰਣੀ ਦੌਰਾਨ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਪਰ ਉਹਨਾਂ ਦੇ ਸੰਚਾਲਨ ਦੌਰਾਨ ਨਹੀਂ - ਇਸ ਲਈ requiredDuringSchedulingIgnoredDuringExecution).

ਇੱਥੇ ਅਸੀਂ ਇਸ ਬਾਰੇ ਗੱਲ ਕਰ ਰਹੇ ਹਾਂ podAntiAffinity ਵੱਖ-ਵੱਖ ਨੋਡਾਂ 'ਤੇ: topologyKey: "kubernetes.io/hostname", - ਅਤੇ ਵੱਖ-ਵੱਖ ਉਪਲਬਧਤਾ ਜ਼ੋਨਾਂ ਬਾਰੇ ਨਹੀਂ। ਇੱਕ ਪੂਰਨ HA ਨੂੰ ਲਾਗੂ ਕਰਨ ਲਈ, ਤੁਹਾਨੂੰ ਇਸ ਵਿਸ਼ੇ ਵਿੱਚ ਡੂੰਘਾਈ ਨਾਲ ਖੋਦਣ ਦੀ ਲੋੜ ਹੋਵੇਗੀ।

7. PodDisruption Budgets ਨੂੰ ਅਣਡਿੱਠ ਕਰਨਾ

ਕਲਪਨਾ ਕਰੋ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ 'ਤੇ ਉਤਪਾਦਨ ਲੋਡ ਹੈ। ਸਮੇਂ-ਸਮੇਂ 'ਤੇ, ਨੋਡਸ ਅਤੇ ਕਲੱਸਟਰ ਨੂੰ ਖੁਦ ਅੱਪਡੇਟ ਕਰਨਾ ਪੈਂਦਾ ਹੈ (ਜਾਂ ਡੀਕਮਿਸ਼ਨਡ)। PodDisruptionBudget (PDB) ਕਲੱਸਟਰ ਪ੍ਰਸ਼ਾਸਕਾਂ ਅਤੇ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਸੇਵਾ ਗਾਰੰਟੀ ਸਮਝੌਤੇ ਵਰਗਾ ਕੁਝ ਹੈ।

PDB ਤੁਹਾਨੂੰ ਨੋਡਾਂ ਦੀ ਘਾਟ ਕਾਰਨ ਸੇਵਾ ਰੁਕਾਵਟਾਂ ਤੋਂ ਬਚਣ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

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

ਤੁਸੀਂ ਇਸ ਬਾਰੇ ਹੋਰ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ.

8. ਇੱਕ ਸਾਂਝੇ ਕਲੱਸਟਰ ਵਿੱਚ ਕਈ ਉਪਭੋਗਤਾ ਜਾਂ ਵਾਤਾਵਰਣ

ਕੁਬਰਨੇਟਸ ਨੇਮਸਪੇਸ (ਨਾਮਸਥਾਨ) ਮਜ਼ਬੂਤ ​​​​ਇਨਸੂਲੇਸ਼ਨ ਪ੍ਰਦਾਨ ਨਾ ਕਰੋ.

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

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

9. ਬਾਹਰੀ ਆਵਾਜਾਈ ਨੀਤੀ: ਕਲੱਸਟਰ

ਅਕਸਰ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਕਲੱਸਟਰ ਦੇ ਅੰਦਰ ਸਾਰਾ ਟ੍ਰੈਫਿਕ NodePort ਵਰਗੀ ਸੇਵਾ ਰਾਹੀਂ ਆਉਂਦਾ ਹੈ, ਜਿਸ ਲਈ ਡਿਫਾਲਟ ਨੀਤੀ ਸੈੱਟ ਕੀਤੀ ਜਾਂਦੀ ਹੈ। externalTrafficPolicy: Cluster... ਇਸਦਾ ਅਰਥ ਹੈ ਨੋਡਪੋਰਟ ਕਲੱਸਟਰ ਵਿੱਚ ਹਰੇਕ ਨੋਡ 'ਤੇ ਖੁੱਲ੍ਹਾ ਹੈ, ਅਤੇ ਤੁਸੀਂ ਉਹਨਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਨੂੰ ਵੀ ਲੋੜੀਂਦੀ ਸੇਵਾ (ਪੋਡਾਂ ਦੇ ਸੈੱਟ) ਨਾਲ ਇੰਟਰੈਕਟ ਕਰਨ ਲਈ ਵਰਤ ਸਕਦੇ ਹੋ।

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

ਦੂਜੇ ਪਾਸੇ, ਜੇਕਰ ਕਿਸੇ ਖਾਸ ਕੁਬਰਨੇਟਸ ਸੇਵਾ ਕੋਲ ਨੀਤੀ ਸੈੱਟ ਹੈ externalTrafficPolicy: Local, ਫਿਰ ਨੋਡਪੋਰਟ ਸਿਰਫ਼ ਉਹਨਾਂ ਨੋਡਾਂ 'ਤੇ ਖੁੱਲ੍ਹਦਾ ਹੈ ਜਿੱਥੇ ਲੋੜੀਂਦੇ ਪੌਡ ਅਸਲ ਵਿੱਚ ਚੱਲ ਰਹੇ ਹਨ। ਇੱਕ ਬਾਹਰੀ ਲੋਡ ਬੈਲੇਂਸਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਜੋ ਰਾਜ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ (ਸਿਹਤ ਜਾਂਚ) endpoints (ਇਹ ਕਿਵੇਂ ਕਰਦਾ ਹੈ AWS ELB), ਉਹ ਟਰੈਫਿਕ ਨੂੰ ਸਿਰਫ ਲੋੜੀਂਦੇ ਨੋਡਾਂ 'ਤੇ ਭੇਜੇਗਾ, ਜਿਸਦਾ ਦੇਰੀ, ਕੰਪਿਊਟਿੰਗ ਲੋੜਾਂ, ਨਿਕਾਸੀ ਬਿੱਲਾਂ 'ਤੇ ਲਾਹੇਵੰਦ ਪ੍ਰਭਾਵ ਹੋਵੇਗਾ (ਅਤੇ ਆਮ ਸਮਝ ਇਹੀ ਹੁਕਮ ਦਿੰਦੀ ਹੈ)।

ਇੱਥੇ ਇੱਕ ਉੱਚ ਸੰਭਾਵਨਾ ਹੈ ਕਿ ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਇਸ ਤਰ੍ਹਾਂ ਦੀ ਕੋਈ ਚੀਜ਼ ਵਰਤ ਰਹੇ ਹੋ ਟ੍ਰੈਫਿਕ ਜ nginx-ingress-ਕੰਟਰੋਲਰ HTTP ਪ੍ਰਵੇਸ਼ ਟ੍ਰੈਫਿਕ ਨੂੰ ਰੂਟ ਕਰਨ ਲਈ ਨੋਡਪੋਰਟ ਐਂਡਪੁਆਇੰਟ (ਜਾਂ ਲੋਡਬੈਲੈਂਸਰ, ਜੋ ਨੋਡਪੋਰਟ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦਾ ਹੈ) ਦੇ ਰੂਪ ਵਿੱਚ, ਅਤੇ ਇਸ ਵਿਕਲਪ ਨੂੰ ਸੈਟ ਕਰਨਾ ਅਜਿਹੀਆਂ ਬੇਨਤੀਆਂ ਲਈ ਲੇਟੈਂਸੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾ ਸਕਦਾ ਹੈ।

В ਇਸ ਪ੍ਰਕਾਸ਼ਨ ਤੁਸੀਂ externalTrafficPolicy, ਇਸਦੇ ਫਾਇਦਿਆਂ ਅਤੇ ਨੁਕਸਾਨਾਂ ਬਾਰੇ ਹੋਰ ਜਾਣ ਸਕਦੇ ਹੋ।

10. ਕਲੱਸਟਰਾਂ ਨਾਲ ਨਾ ਬੰਨ੍ਹੋ ਅਤੇ ਕੰਟਰੋਲ ਪਲੇਨ ਦੀ ਦੁਰਵਰਤੋਂ ਨਾ ਕਰੋ

ਪਹਿਲਾਂ, ਸਰਵਰਾਂ ਨੂੰ ਸਹੀ ਨਾਵਾਂ ਨਾਲ ਕਾਲ ਕਰਨ ਦਾ ਰਿਵਾਜ ਸੀ: ਐਂਟੋਨੀ, HAL9000 ਅਤੇ Colossus... ਅੱਜ ਉਹਨਾਂ ਨੂੰ ਬੇਤਰਤੀਬੇ ਤੌਰ 'ਤੇ ਤਿਆਰ ਕੀਤੇ ਪਛਾਣਕਰਤਾਵਾਂ ਦੁਆਰਾ ਬਦਲ ਦਿੱਤਾ ਗਿਆ ਹੈ। ਹਾਲਾਂਕਿ, ਆਦਤ ਰਹੀ, ਅਤੇ ਹੁਣ ਸਹੀ ਨਾਮ ਕਲੱਸਟਰ ਵਿੱਚ ਜਾਂਦੇ ਹਨ.

ਇੱਕ ਆਮ ਕਹਾਣੀ (ਅਸਲ ਘਟਨਾਵਾਂ 'ਤੇ ਅਧਾਰਤ): ਇਹ ਸਭ ਸੰਕਲਪ ਦੇ ਸਬੂਤ ਨਾਲ ਸ਼ੁਰੂ ਹੋਇਆ ਸੀ, ਇਸ ਲਈ ਕਲੱਸਟਰ ਦਾ ਇੱਕ ਮਾਣਮੱਤਾ ਨਾਮ ਸੀ ਟੈਸਟਿੰਗ… ਸਾਲ ਬੀਤ ਗਏ ਹਨ ਅਤੇ ਇਹ ਅਜੇ ਵੀ ਉਤਪਾਦਨ ਵਿੱਚ ਵਰਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਹਰ ਕੋਈ ਇਸਨੂੰ ਛੂਹਣ ਤੋਂ ਡਰਦਾ ਹੈ।

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

ਦੂਜੇ ਪਾਸੇ, ਤੁਹਾਨੂੰ ਇਸ ਵਿੱਚ ਹੇਰਾਫੇਰੀ ਕਰਨ ਤੋਂ ਦੂਰ ਨਹੀਂ ਜਾਣਾ ਚਾਹੀਦਾ। ਸਮੇਂ ਦੇ ਨਾਲ ਕੰਟਰੋਲ ਪਰਤ ਹੌਲੀ ਹੋ ਸਕਦੀ ਹੈ. ਜ਼ਿਆਦਾਤਰ ਸੰਭਾਵਤ ਤੌਰ 'ਤੇ, ਇਹ ਉਹਨਾਂ ਦੇ ਰੋਟੇਸ਼ਨ ਦੇ ਬਿਨਾਂ ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਆਬਜੈਕਟ ਬਣਾਏ ਜਾਣ ਦੇ ਕਾਰਨ ਹੈ (ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਹੇਲਮ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਇੱਕ ਆਮ ਸਥਿਤੀ, ਜਿਸ ਕਾਰਨ ਸੰਰਚਨਾਮੈਪ/ਸੀਕਰੇਟਸ ਵਿੱਚ ਇਸਦੀ ਸਥਿਤੀ ਨੂੰ ਅਪਡੇਟ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - ਨਤੀਜੇ ਵਜੋਂ, ਹਜ਼ਾਰਾਂ ਆਬਜੈਕਟ ਇਕੱਠੇ ਹੋ ਜਾਂਦੇ ਹਨ। ਕੰਟਰੋਲ ਲੇਅਰ) ਜਾਂ kube-api ਵਸਤੂਆਂ ਦੇ ਨਿਰੰਤਰ ਸੰਪਾਦਨ ਦੇ ਨਾਲ (ਆਟੋਮੈਟਿਕ ਸਕੇਲਿੰਗ ਲਈ, CI/CD ਲਈ, ਨਿਗਰਾਨੀ ਲਈ, ਇਵੈਂਟ ਲੌਗਸ, ਕੰਟਰੋਲਰ, ਆਦਿ)।

ਇਸ ਤੋਂ ਇਲਾਵਾ, ਅਸੀਂ ਪ੍ਰਬੰਧਿਤ Kubernetes ਪ੍ਰਦਾਤਾ ਨਾਲ SLA/SLO ਸਮਝੌਤਿਆਂ ਦੀ ਜਾਂਚ ਕਰਨ ਅਤੇ ਗਾਰੰਟੀਆਂ ਵੱਲ ਧਿਆਨ ਦੇਣ ਦੀ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ। ਵਿਕਰੇਤਾ ਗਾਰੰਟੀ ਦੇ ਸਕਦਾ ਹੈ ਕੰਟਰੋਲ ਲੇਅਰ ਉਪਲਬਧਤਾ (ਜਾਂ ਇਸਦੇ ਉਪ-ਕੰਪੋਨੈਂਟ), ਪਰ ਤੁਹਾਡੇ ਦੁਆਰਾ ਇਸ ਨੂੰ ਭੇਜੀਆਂ ਗਈਆਂ ਬੇਨਤੀਆਂ ਦੀ p99 ਦੇਰੀ ਨਾਲ ਨਹੀਂ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿਚ, ਤੁਸੀਂ ਦਾਖਲ ਕਰ ਸਕਦੇ ਹੋ kubectl get nodes, ਅਤੇ ਸਿਰਫ 10 ਮਿੰਟਾਂ ਬਾਅਦ ਇੱਕ ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰੋ, ਅਤੇ ਇਹ ਸੇਵਾ ਸਮਝੌਤੇ ਦੀਆਂ ਸ਼ਰਤਾਂ ਦੀ ਉਲੰਘਣਾ ਨਹੀਂ ਹੋਵੇਗੀ।

11. ਬੋਨਸ: ਨਵੀਨਤਮ ਟੈਗ ਦੀ ਵਰਤੋਂ ਕਰਨਾ

ਪਰ ਇਹ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕਲਾਸਿਕ ਹੈ. ਹਾਲ ਹੀ ਵਿੱਚ ਅਸੀਂ ਇਸ ਤਕਨੀਕ ਨੂੰ ਬਹੁਤ ਘੱਟ ਦੇਖਿਆ ਹੈ, ਕਿਉਂਕਿ ਬਹੁਤ ਸਾਰੇ, ਕੌੜੇ ਅਨੁਭਵ ਤੋਂ ਸਿੱਖ ਕੇ, ਟੈਗ ਦੀ ਵਰਤੋਂ ਬੰਦ ਕਰ ਦਿੱਤੀ ਹੈ :latest ਅਤੇ ਸੰਸਕਰਣਾਂ ਨੂੰ ਪਿੰਨ ਕਰਨਾ ਸ਼ੁਰੂ ਕੀਤਾ। ਹੂਰੇ!

ECR ਚਿੱਤਰ ਟੈਗਸ ਦੀ ਅਟੱਲਤਾ ਨੂੰ ਕਾਇਮ ਰੱਖਦਾ ਹੈ; ਅਸੀਂ ਸਿਫ਼ਾਰਿਸ਼ ਕਰਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ ਆਪਣੇ ਆਪ ਨੂੰ ਇਸ ਕਮਾਲ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਤੋਂ ਜਾਣੂ ਕਰਵਾਓ।

ਸੰਖੇਪ

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

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

ਜਿਹੜੇ ਲੋਕ ਇਸ ਲੇਖ ਵਿੱਚ ਦਿੱਤੀਆਂ ਗਈਆਂ ਗਲਤੀਆਂ ਦੀ ਸੂਚੀ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ ਉਹ ਸਾਡੇ ਨਾਲ ਟਵਿੱਟਰ 'ਤੇ ਸੰਪਰਕ ਕਰ ਸਕਦੇ ਹਨ (@MarekBartik, @MstrsObserver).

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

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

• «ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰਾਂ ਨੂੰ ਡਿਜ਼ਾਈਨ ਕਰਨਾ: ਕਿੰਨੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ?";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਸੁਰੱਖਿਆ ਦਾ ਏਬੀਸੀ: ਪ੍ਰਮਾਣੀਕਰਨ, ਅਧਿਕਾਰ, ਆਡਿਟਿੰਗ";
• «ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਆਟੋਸਕੇਲਿੰਗ ਅਤੇ ਸਰੋਤ ਪ੍ਰਬੰਧਨ"(ਸਮੀਖਿਆ ਅਤੇ ਵੀਡੀਓ ਰਿਪੋਰਟ);
• «Kubernetes ਵਿੱਚ ConfigMaps: ਬਾਰੇ ਜਾਣਨ ਦੇ ਯੋਗ ਸੂਖਮਤਾ".

ਸਰੋਤ: www.habr.com