ਕੁਬਰਨੇਟਸ ਪੋਡ ਸਰੋਤਾਂ ਤੱਕ ਕਿਵੇਂ ਪਹੁੰਚਣਾ ਹੈ

ਤੋਹਦ ਦੁਆਰਾ ਇਨਾਮ

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

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

ਦੀ ਟੀਮ Mail.ru ਤੋਂ Kubernetes aaS ਕੰਟੇਨਰ ਸਰੋਤਾਂ (CPU ਅਤੇ MEM), ਬੇਨਤੀਆਂ ਅਤੇ ਸਰੋਤ ਸੀਮਾਵਾਂ ਬਾਰੇ ਇੱਕ ਲੇਖ ਦਾ ਅਨੁਵਾਦ ਕੀਤਾ। ਤੁਸੀਂ ਇਹਨਾਂ ਸੈਟਿੰਗਾਂ ਦੇ ਲਾਭਾਂ ਬਾਰੇ ਸਿੱਖੋਗੇ ਅਤੇ ਜੇ ਤੁਸੀਂ ਇਹਨਾਂ ਨੂੰ ਸੈੱਟ ਨਹੀਂ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ।

ਕੰਪਿਊਟਿੰਗ ਸਰੋਤ

ਸਾਡੇ ਕੋਲ ਹੇਠ ਲਿਖੀਆਂ ਇਕਾਈਆਂ ਵਾਲੇ ਦੋ ਕਿਸਮ ਦੇ ਸਰੋਤ ਹਨ:

• ਕੇਂਦਰੀ ਪ੍ਰੋਸੈਸਿੰਗ ਯੂਨਿਟ (CPU) - ਕੋਰ;
• ਮੈਮੋਰੀ (MEM) - ਬਾਈਟਸ।

ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਸਰੋਤ ਨਿਰਧਾਰਤ ਕੀਤੇ ਗਏ ਹਨ। ਹੇਠਾਂ ਦਿੱਤੀ Pod YAML ਫਾਈਲ ਵਿੱਚ, ਤੁਸੀਂ ਇੱਕ ਸਰੋਤ ਭਾਗ ਵੇਖੋਗੇ ਜਿਸ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੇ ਗਏ ਅਤੇ ਸੀਮਿਤ ਸਰੋਤ ਸ਼ਾਮਲ ਹਨ:

• ਬੇਨਤੀ ਕੀਤੇ ਪੌਡ ਸਰੋਤ = ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਦੇ ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ ਦਾ ਜੋੜ;
• ਪੌਡ ਸਰੋਤ ਸੀਮਾ = ਸਾਰੀਆਂ ਪੌਡ ਸਰੋਤ ਸੀਮਾਵਾਂ ਦਾ ਜੋੜ।

apiVersion: v1
kind: Pod
metadata:
  name: backend-pod-name
  labels:
    application: backend
spec:
  containers:
    — name: main-container
      image: my-backend
      tag: v1
      ports:
      — containerPort: 8080
      resources:
        requests:
          cpu: 0.2 # REQUESTED CPU: 200m cores
          memory: "1Gi" # REQUESTED MEM: 1Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi
    — name: other-container
      image: other-app
      tag: v1
      ports:
      — containerPort: 8000
      resources:
        requests:
          cpu: "200m" # REQUESTED CPU: 200m cores
          memory: "0.5Gi" # REQUESTED MEM: 0.5Gi
        limits:
          cpu: 1 # MAX CPU USAGE: 1 core
          memory: "1Gi" # MAX MEM USAGE:  1Gi

ਬੇਨਤੀ ਕੀਤੇ ਅਤੇ ਸੀਮਤ ਸਰੋਤਾਂ ਦੀ ਉਦਾਹਰਨ

ਖੇਤਰ resources.requested ਨਿਰਧਾਰਨ ਤੋਂ ਪੋਡ ਉਹਨਾਂ ਤੱਤਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ ਜੋ ਲੋੜੀਂਦੇ ਨੋਡ ਨੂੰ ਲੱਭਣ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਸੀਂ ਇਸਦੇ ਲਈ ਪਹਿਲਾਂ ਹੀ ਪੋਡ ਤੈਨਾਤੀ ਦੀ ਯੋਜਨਾ ਬਣਾ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਇੱਕ ਢੁਕਵਾਂ ਨੋਡ ਕਿਵੇਂ ਲੱਭਦੇ ਹੋ?

ਕੁਬਰਨੇਟਸ ਵਿੱਚ ਇੱਕ ਮਾਸਟਰ ਨੋਡ ਜਾਂ ਮਾਸਟਰ ਨੋਡ (ਕੁਬਰਨੇਟਸ ਕੰਟਰੋਲ ਪਲੇਨ) ਸਮੇਤ ਕਈ ਭਾਗ ਹੁੰਦੇ ਹਨ। ਮਾਸਟਰ ਨੋਡ ਦੀਆਂ ਕਈ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ: kube-apiserver, kube-controller-manager ਅਤੇ kube-scheduler।

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

ਜਾਮਨੀ ਪੋਡ ਕਿੱਥੇ ਰੱਖਿਆ ਜਾਵੇਗਾ?

ਤਸਵੀਰ ਵਿੱਚ ਤੁਸੀਂ ਦੇਖ ਸਕਦੇ ਹੋ ਕਿ ਕੁਬੇ-ਸਡਿਊਲਰ ਨੂੰ ਇੱਕ ਨਵਾਂ ਜਾਮਨੀ ਪੋਡ ਤਹਿ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਵਿੱਚ ਦੋ ਨੋਡ ਹੁੰਦੇ ਹਨ: A ਅਤੇ B। ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਵੇਖ ਸਕਦੇ ਹੋ, ਕਿਊਬ-ਸ਼ਡਿਊਲਰ ਨੋਡ A ਉੱਤੇ ਇੱਕ Pod ਨੂੰ ਤਹਿ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ - ਉਪਲਬਧ (ਬੇਨਤੀ ਕੀਤੇ) ਸਰੋਤ ਜਾਮਨੀ ਪੋਡ ਦੀਆਂ ਬੇਨਤੀਆਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦੇ ਹਨ। ਇਸ ਲਈ, ਜਾਮਨੀ ਪੋਡ ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ ਗਈ 1 GB ਮੈਮੋਰੀ ਨੋਡ A 'ਤੇ ਫਿੱਟ ਨਹੀਂ ਹੋਵੇਗੀ, ਕਿਉਂਕਿ ਉਪਲਬਧ ਮੈਮੋਰੀ 0,5 GB ਹੈ। ਪਰ ਨੋਡ ਬੀ ਕੋਲ ਕਾਫ਼ੀ ਸਰੋਤ ਹਨ. ਨਤੀਜੇ ਵਜੋਂ, ਕਿਊਬ-ਸਡਿਊਲਰ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਜਾਮਨੀ ਪੋਡ ਦੀ ਮੰਜ਼ਿਲ ਨੋਡ ਬੀ ਹੈ।

ਹੁਣ ਅਸੀਂ ਜਾਣਦੇ ਹਾਂ ਕਿ ਕਿਵੇਂ ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤ ਪੋਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਨੋਡ ਦੀ ਚੋਣ ਨੂੰ ਪ੍ਰਭਾਵਤ ਕਰਦੇ ਹਨ। ਪਰ ਮਾਮੂਲੀ ਸਰੋਤਾਂ ਦਾ ਕੀ ਪ੍ਰਭਾਵ ਹੈ?

ਸਰੋਤ ਸੀਮਾ ਇੱਕ ਸੀਮਾ ਹੈ ਜਿਸਨੂੰ CPU/MEM ਪਾਰ ਨਹੀਂ ਕਰ ਸਕਦਾ ਹੈ। ਹਾਲਾਂਕਿ, CPU ਸਰੋਤ ਲਚਕਦਾਰ ਹੈ, ਇਸਲਈ ਕੰਟੇਨਰ ਜੋ ਆਪਣੀ CPU ਸੀਮਾਵਾਂ ਤੱਕ ਪਹੁੰਚਦੇ ਹਨ, Pod ਨੂੰ ਬਾਹਰ ਨਹੀਂ ਆਉਣ ਦਿੰਦੇ। ਇਸਦੀ ਬਜਾਏ, CPU ਥ੍ਰੋਟਲਿੰਗ ਸ਼ੁਰੂ ਹੋ ਜਾਵੇਗੀ। ਜੇਕਰ MEM ਵਰਤੋਂ ਦੀ ਸੀਮਾ ਪੂਰੀ ਹੋ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਕੰਟੇਨਰ ਨੂੰ OOM-Killer ਦੇ ਕਾਰਨ ਰੋਕ ਦਿੱਤਾ ਜਾਵੇਗਾ ਅਤੇ ਜੇਕਰ RestartPolicy ਸੈਟਿੰਗ ਦੁਆਰਾ ਇਜਾਜ਼ਤ ਦਿੱਤੀ ਜਾਂਦੀ ਹੈ ਤਾਂ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਵਿਸਥਾਰ ਵਿੱਚ ਬੇਨਤੀ ਕੀਤੀ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਸਰੋਤ

ਡੌਕਰ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਿਚਕਾਰ ਸਰੋਤ ਸੰਚਾਰ

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

ਮੈਮੋਰੀ: ਬੇਨਤੀ ਅਤੇ ਸੀਮਾ

containers:
...
 resources:
   requests:
     memory: "0.5Gi"
   limits:
     memory: "1Gi"

ਜਿਵੇਂ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਮੈਮੋਰੀ ਨੂੰ ਬਾਈਟਾਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ। ਦੇ ਅਧਾਰ ਤੇ ਕੁਬਰਨੇਟਸ ਦਸਤਾਵੇਜ਼, ਅਸੀਂ ਮੈਮੋਰੀ ਨੂੰ ਇੱਕ ਨੰਬਰ ਦੇ ਤੌਰ ਤੇ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹਾਂ। ਆਮ ਤੌਰ 'ਤੇ ਇਹ ਪੂਰਨ ਅੰਕ ਹੁੰਦਾ ਹੈ, ਉਦਾਹਰਨ ਲਈ 2678 - ਯਾਨੀ 2678 ਬਾਈਟਸ। ਤੁਸੀਂ ਪਿਛੇਤਰ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ G и Gi, ਮੁੱਖ ਗੱਲ ਇਹ ਹੈ ਕਿ ਇਹ ਯਾਦ ਰੱਖਣਾ ਹੈ ਕਿ ਉਹ ਬਰਾਬਰ ਨਹੀਂ ਹਨ। ਪਹਿਲਾ ਦਸ਼ਮਲਵ ਹੈ ਅਤੇ ਦੂਜਾ ਬਾਈਨਰੀ ਹੈ। k8s ਦਸਤਾਵੇਜ਼ਾਂ ਵਿੱਚ ਜ਼ਿਕਰ ਕੀਤੀ ਉਦਾਹਰਣ ਵਾਂਗ: 128974848, 129e6, 129M, 123Mi - ਉਹ ਅਮਲੀ ਤੌਰ 'ਤੇ ਬਰਾਬਰ ਹਨ।

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

ਜੇਕਰ ਤੁਸੀਂ ਬੇਨਤੀ ਲਈ ਨਾਕਾਫ਼ੀ ਮੈਮੋਰੀ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

ਜੇਕਰ ਤੁਸੀਂ ਮੈਮੋਰੀ ਸੀਮਾ ਬਹੁਤ ਘੱਟ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਜੇਕਰ ਕੰਟੇਨਰ ਮੈਮੋਰੀ ਸੀਮਾ ਤੋਂ ਵੱਧ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਸਨੂੰ OOM-ਕਿਲਡ ਦੇ ਕਾਰਨ ਬੰਦ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ। ਅਤੇ ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਰੀਸਟਾਰਟ ਪਾਲਿਸੀ ਦੇ ਆਧਾਰ 'ਤੇ ਰੀਸਟਾਰਟ ਹੋਵੇਗਾ ਜਿੱਥੇ ਡਿਫੌਲਟ ਮੁੱਲ ਹੈ Always.

ਜੇਕਰ ਤੁਸੀਂ ਬੇਨਤੀ ਕੀਤੀ ਮੈਮੋਰੀ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

Kubernetes ਸੀਮਾ ਮੁੱਲ ਲਵੇਗਾ ਅਤੇ ਇਸਨੂੰ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਮੁੱਲ ਵਜੋਂ ਸੈੱਟ ਕਰੇਗਾ।

ਜੇਕਰ ਤੁਸੀਂ ਮੈਮੋਰੀ ਸੀਮਾ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੋ ਸਕਦਾ ਹੈ?

ਕੰਟੇਨਰ ਵਿੱਚ ਕੋਈ ਪਾਬੰਦੀਆਂ ਨਹੀਂ ਹਨ; ਇਹ ਜਿੰਨੀ ਚਾਹੇ ਮੈਮੋਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਉਹ ਨੋਡ ਦੀ ਉਪਲਬਧ ਸਾਰੀ ਮੈਮੋਰੀ ਵਰਤਣਾ ਸ਼ੁਰੂ ਕਰ ਦਿੰਦਾ ਹੈ, ਤਾਂ OOM ਉਸਨੂੰ ਮਾਰ ਦੇਵੇਗਾ। ਜੇਕਰ ਸੰਭਵ ਹੋਵੇ ਤਾਂ RestartPolicy ਦੇ ਆਧਾਰ 'ਤੇ ਕੰਟੇਨਰ ਨੂੰ ਮੁੜ ਚਾਲੂ ਕੀਤਾ ਜਾਵੇਗਾ।

ਜੇਕਰ ਤੁਸੀਂ ਮੈਮੋਰੀ ਸੀਮਾਵਾਂ ਨੂੰ ਨਿਸ਼ਚਿਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

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

ਇਹ ਆਮ ਤੌਰ 'ਤੇ ਲਈ ਇੱਕੋ ਮੁੱਲ ਸੈੱਟ ਕਰਨ ਦੀ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਹੈ request.memory и limit.memory. ਇਹ ਸੁਨਿਸ਼ਚਿਤ ਕਰਦਾ ਹੈ ਕਿ ਕੁਬਰਨੇਟਸ ਇੱਕ ਪੋਡ ਨੂੰ ਇੱਕ ਨੋਡ 'ਤੇ ਤਹਿ ਨਹੀਂ ਕਰੇਗਾ ਜਿਸ ਕੋਲ ਪੌਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਕਾਫ਼ੀ ਮੈਮੋਰੀ ਹੈ ਪਰ ਇਸਨੂੰ ਚਲਾਉਣ ਲਈ ਕਾਫ਼ੀ ਨਹੀਂ ਹੈ। ਧਿਆਨ ਵਿੱਚ ਰੱਖੋ: ਕੁਬਰਨੇਟਸ ਪੋਡ ਦੀ ਯੋਜਨਾ ਸਿਰਫ ਧਿਆਨ ਵਿੱਚ ਰੱਖਦੀ ਹੈ requests.memoryਅਤੇ limits.memory ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਨਹੀਂ ਰੱਖਦਾ।

CPU: ਬੇਨਤੀ ਅਤੇ ਸੀਮਾ

containers:
...
 resources:
   requests:
     cpu: 1
   limits:
     cpu: "1200m"

ਇੱਕ CPU ਨਾਲ ਸਭ ਕੁਝ ਥੋੜਾ ਹੋਰ ਗੁੰਝਲਦਾਰ ਹੈ. ਕੁਬਰਨੇਟਸ ਅਤੇ ਡੌਕਰ ਵਿਚਕਾਰ ਸਬੰਧਾਂ ਦੀ ਤਸਵੀਰ 'ਤੇ ਵਾਪਸ ਆਉਣਾ, ਤੁਸੀਂ ਇਹ ਦੇਖ ਸਕਦੇ ਹੋ request.cpu ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ --cpu-shares, ਜਦਕਿ limit.cpu ਝੰਡੇ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ cpus ਡੌਕਰ ਵਿੱਚ.

ਕੁਬਰਨੇਟਸ ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ CPU ਨੂੰ 1024 ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, CPU ਚੱਕਰਾਂ ਦਾ ਅਨੁਪਾਤ। ਜੇਕਰ ਤੁਸੀਂ 1 ਪੂਰੇ ਕੋਰ ਦੀ ਬੇਨਤੀ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਸ਼ਾਮਲ ਕਰਨਾ ਪਵੇਗਾ cpu: 1ਜਿਵੇਂ ਉੱਪਰ ਦਿਖਾਇਆ ਗਿਆ ਹੈ।

ਪੂਰੇ ਕਰਨਲ (ਅਨੁਪਾਤ = 1024) ਦੀ ਬੇਨਤੀ ਕਰਨ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਤੁਹਾਡੇ ਕੰਟੇਨਰ ਨੂੰ ਇਹ ਪ੍ਰਾਪਤ ਹੋਵੇਗਾ। ਜੇਕਰ ਤੁਹਾਡੀ ਹੋਸਟ ਮਸ਼ੀਨ ਵਿੱਚ ਸਿਰਫ਼ ਇੱਕ ਕੋਰ ਹੈ ਅਤੇ ਤੁਸੀਂ ਇੱਕ ਤੋਂ ਵੱਧ ਕੰਟੇਨਰ ਚਲਾ ਰਹੇ ਹੋ, ਤਾਂ ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਨੂੰ ਉਹਨਾਂ ਵਿਚਕਾਰ ਉਪਲਬਧ CPU ਨੂੰ ਸਾਂਝਾ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ ਕਿਵੇਂ ਹੁੰਦਾ ਹੈ? ਆਓ ਤਸਵੀਰ ਨੂੰ ਵੇਖੀਏ.

CPU ਬੇਨਤੀ - ਸਿੰਗਲ ਕੋਰ ਸਿਸਟਮ

ਚਲੋ ਕਲਪਨਾ ਕਰੀਏ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਿੰਗਲ-ਕੋਰ ਹੋਸਟ ਸਿਸਟਮ ਚੱਲ ਰਹੇ ਕੰਟੇਨਰ ਹਨ। ਮੰਮੀ (ਕੁਬਰਨੇਟਸ) ਨੇ ਇੱਕ ਪਾਈ (CPU) ਪਕਾਇਆ ਅਤੇ ਇਸਨੂੰ ਬੱਚਿਆਂ (ਕੰਟੇਨਰਾਂ) ਵਿੱਚ ਵੰਡਣਾ ਚਾਹੁੰਦੀ ਹੈ। ਤਿੰਨ ਬੱਚੇ ਇੱਕ ਪੂਰੀ ਪਾਈ (ਅਨੁਪਾਤ = 1024) ਚਾਹੁੰਦੇ ਹਨ, ਦੂਜੇ ਬੱਚੇ ਨੂੰ ਅੱਧੀ ਪਾਈ (512) ਚਾਹੀਦੀ ਹੈ। ਮੰਮੀ ਨਿਰਪੱਖ ਹੋਣਾ ਚਾਹੁੰਦੀ ਹੈ ਅਤੇ ਇੱਕ ਸਧਾਰਨ ਗਣਨਾ ਕਰਦੀ ਹੈ.

# Сколько пирогов хотят дети?
# 3 ребенка хотят по целому пирогу и еще один хочет половину пирога
cakesNumberKidsWant = (3 * 1) + (1 * 0.5) = 3.5
# Выражение получается так:
3 (ребенка/контейнера) * 1 (целый пирог/полное ядро) + 1 (ребенок/контейнер) * 0.5 (половина пирога/половина ядра)
# Сколько пирогов испечено?
availableCakesNumber = 1
# Сколько пирога (максимально) дети реально могут получить?
newMaxRequest = 1 / 3.5 =~ 28%

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

CPU ਬੇਨਤੀ - ਮਲਟੀ-ਕੋਰ (4) ਸਿਸਟਮ

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

ਉਪਰੋਕਤ ਗਣਨਾਵਾਂ ਨੂੰ ਇਹ ਸਮਝਣ ਲਈ ਸਰਲ ਬਣਾਇਆ ਗਿਆ ਹੈ ਕਿ CPU ਨੂੰ ਕੰਟੇਨਰਾਂ ਵਿੱਚ ਕਿਵੇਂ ਵੰਡਿਆ ਜਾਂਦਾ ਹੈ। ਬੇਸ਼ੱਕ, ਕੰਟੇਨਰਾਂ ਤੋਂ ਇਲਾਵਾ, ਹੋਰ ਪ੍ਰਕਿਰਿਆਵਾਂ ਹਨ ਜੋ CPU ਸਰੋਤਾਂ ਦੀ ਵਰਤੋਂ ਵੀ ਕਰਦੀਆਂ ਹਨ। ਜਦੋਂ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਪ੍ਰਕਿਰਿਆਵਾਂ ਨਿਸ਼ਕਿਰਿਆ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਦੂਸਰੇ ਇਸਦੇ ਸਰੋਤ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹਨ। CPU: "200m" ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ CPU: 0,2, ਜਿਸਦਾ ਮਤਲਬ ਇੱਕ ਕੋਰ ਦਾ ਲਗਭਗ 20% ਹੈ।

ਹੁਣ ਗੱਲ ਕਰੀਏ limit.cpu. ਕੁਬਰਨੇਟਸ ਦੀ ਸੀਮਾ ਨੂੰ 100 ਨਾਲ ਗੁਣਾ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਕੰਟੇਨਰ ਹਰ 100 µs (cpu-period).

limit.cpu ਡੌਕਰ ਫਲੈਗ ਨਾਲ ਮੇਲ ਖਾਂਦਾ ਹੈ --cpus. ਇਹ ਪੁਰਾਣੇ ਦਾ ਨਵਾਂ ਸੁਮੇਲ ਹੈ --cpu-period и --cpu-quota. ਇਸਨੂੰ ਸੈੱਟ ਕਰਕੇ, ਅਸੀਂ ਇਹ ਦਰਸਾਉਂਦੇ ਹਾਂ ਕਿ ਥ੍ਰੋਟਲਿੰਗ ਸ਼ੁਰੂ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ ਕੰਟੇਨਰ ਕਿੰਨੇ ਉਪਲਬਧ CPU ਸਰੋਤਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ:

• cpus - ਸੁਮੇਲ cpu-period и cpu-quota. cpus = 1.5 ਸੈਟਿੰਗ ਦੇ ਬਰਾਬਰ cpu-period = 100000 и cpu-quota = 150000;
• CPU-ਅਵਧੀ - ਮਿਆਦ CPU CFS ਸ਼ਡਿਊਲਰ, ਡਿਫੌਲਟ 100 ਮਾਈਕ੍ਰੋਸੈਕਿੰਡ;
• cpu-ਕੋਟਾ - ਅੰਦਰ ਮਾਈਕ੍ਰੋਸਕਿੰਟਾਂ ਦੀ ਗਿਣਤੀ cpu-period, ਜੋ ਕਿ ਕੰਟੇਨਰ ਨਾਲ ਘਿਰਿਆ ਹੋਇਆ ਹੈ।

ਜੇਕਰ ਤੁਸੀਂ ਨਾਕਾਫ਼ੀ ਬੇਨਤੀ ਕੀਤੇ CPU ਨੂੰ ਸਥਾਪਿਤ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

ਜੇਕਰ ਤੁਸੀਂ CPU ਸੀਮਾ ਬਹੁਤ ਘੱਟ ਸੈਟ ਕਰਦੇ ਹੋ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਕਿਉਂਕਿ CPU ਸਰੋਤ ਵਿਵਸਥਿਤ ਹੈ, ਥ੍ਰੋਟਲਿੰਗ ਚਾਲੂ ਹੋ ਜਾਵੇਗੀ।

ਜੇਕਰ ਤੁਸੀਂ ਇੱਕ CPU ਬੇਨਤੀ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

ਮੈਮੋਰੀ ਦੇ ਨਾਲ, ਬੇਨਤੀ ਮੁੱਲ ਸੀਮਾ ਦੇ ਬਰਾਬਰ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ CPU ਸੀਮਾ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

ਜੇਕਰ ਤੁਸੀਂ ਕੋਈ ਬੇਨਤੀ ਜਾਂ CPU ਸੀਮਾ ਨਿਰਧਾਰਤ ਨਹੀਂ ਕਰਦੇ ਤਾਂ ਕੀ ਹੁੰਦਾ ਹੈ?

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

ਯਾਦ ਰੱਖੋ: ਜੇਕਰ ਤੁਸੀਂ ਨੋਡਸ ਤੋਂ ਵੱਧ CPU ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹੋ, ਤਾਂ Pod ਨੂੰ ਤਹਿ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ। Requests.cpu - ਨਿਊਨਤਮ ਮੁੱਲ ਨਹੀਂ, ਪਰ ਇੱਕ ਮੁੱਲ ਜੋ ਪੌਡ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਅਸਫਲਤਾ ਦੇ ਬਿਨਾਂ ਕੰਮ ਕਰਨ ਲਈ ਕਾਫੀ ਹੈ। ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਗੁੰਝਲਦਾਰ ਗਣਨਾਵਾਂ ਨਹੀਂ ਕਰਦੀ ਹੈ, ਤਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਵਿਕਲਪ ਇੰਸਟਾਲ ਕਰਨਾ ਹੈ request.cpu <= 1 ਅਤੇ ਜਿੰਨੇ ਲੋੜੀਂਦੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਲਾਂਚ ਕਰੋ।

ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ ਜਾਂ ਸਰੋਤ ਸੀਮਾ ਦੀ ਆਦਰਸ਼ ਮਾਤਰਾ

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

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

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

ਇੱਕ ਉਦਾਹਰਣ ਦੇ ਤੌਰ ਤੇ ਇਸ ਨੂੰ ਵੇਖੋ Grafana ਡੈਸ਼ਬੋਰਡ. ਇਹ ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ ਜਾਂ ਸਰੋਤ ਸੀਮਾ ਅਤੇ ਮੌਜੂਦਾ ਸਰੋਤ ਵਰਤੋਂ ਵਿੱਚ ਅੰਤਰ ਦਰਸਾਉਂਦਾ ਹੈ।

ਸਿੱਟਾ

ਸਰੋਤਾਂ ਦੀ ਬੇਨਤੀ ਅਤੇ ਸੀਮਤ ਕਰਨਾ ਤੁਹਾਡੇ ਕੁਬਰਨੇਟਸ ਕਲੱਸਟਰ ਨੂੰ ਸਿਹਤਮੰਦ ਰੱਖਣ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਉਚਿਤ ਸੀਮਾ ਸੰਰਚਨਾ ਲਾਗਤਾਂ ਨੂੰ ਘੱਟ ਕਰਦੀ ਹੈ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਹਰ ਸਮੇਂ ਚੱਲਦੀ ਰੱਖਦੀ ਹੈ।

ਸੰਖੇਪ ਵਿੱਚ, ਧਿਆਨ ਵਿੱਚ ਰੱਖਣ ਲਈ ਕੁਝ ਗੱਲਾਂ ਹਨ:

1. ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤ ਇੱਕ ਸੰਰਚਨਾ ਹਨ ਜੋ ਸ਼ੁਰੂਆਤੀ ਸਮੇਂ (ਜਦੋਂ ਕੁਬਰਨੇਟਸ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਮੇਜ਼ਬਾਨੀ ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਉਂਦੇ ਹਨ) ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਇਸ ਦੇ ਉਲਟ, ਰਨਟਾਈਮ 'ਤੇ ਸਰੋਤਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੁੰਦਾ ਹੈ - ਜਦੋਂ ਐਪਲੀਕੇਸ਼ਨ ਪਹਿਲਾਂ ਹੀ ਨੋਡ 'ਤੇ ਚੱਲ ਰਹੀ ਹੁੰਦੀ ਹੈ।
2. ਮੈਮੋਰੀ ਦੀ ਤੁਲਨਾ ਵਿੱਚ, CPU ਇੱਕ ਨਿਯੰਤ੍ਰਿਤ ਸਰੋਤ ਹੈ। ਜੇਕਰ ਕਾਫ਼ੀ CPU ਨਹੀਂ ਹੈ, ਤਾਂ ਤੁਹਾਡਾ Pod ਬੰਦ ਨਹੀਂ ਹੋਵੇਗਾ ਅਤੇ ਥ੍ਰੋਟਲਿੰਗ ਵਿਧੀ ਚਾਲੂ ਹੋ ਜਾਵੇਗੀ।
3. ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤ ਅਤੇ ਸਰੋਤ ਸੀਮਾ ਘੱਟੋ-ਘੱਟ ਅਤੇ ਵੱਧ ਤੋਂ ਵੱਧ ਮੁੱਲ ਨਹੀਂ ਹਨ! ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਕੇ, ਤੁਸੀਂ ਇਹ ਯਕੀਨੀ ਬਣਾਉਂਦੇ ਹੋ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਬਿਨਾਂ ਕਿਸੇ ਸਮੱਸਿਆ ਦੇ ਚੱਲੇਗੀ।
4. ਇੱਕ ਚੰਗਾ ਅਭਿਆਸ ਮੈਮੋਰੀ ਬੇਨਤੀ ਨੂੰ ਮੈਮੋਰੀ ਸੀਮਾ ਦੇ ਬਰਾਬਰ ਸੈੱਟ ਕਰਨਾ ਹੈ।
5. ਠੀਕ ਹੈ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਬੇਨਤੀ ਕੀਤੀ CPU <=1, ਜੇਕਰ ਐਪਲੀਕੇਸ਼ਨ ਗੁੰਝਲਦਾਰ ਗਣਨਾਵਾਂ ਨਹੀਂ ਕਰਦੀ ਹੈ।
6. ਜੇਕਰ ਤੁਸੀਂ ਨੋਡ 'ਤੇ ਉਪਲਬਧ ਹੋਣ ਤੋਂ ਵੱਧ ਸਰੋਤਾਂ ਦੀ ਬੇਨਤੀ ਕਰਦੇ ਹੋ, ਤਾਂ Pod ਨੂੰ ਕਦੇ ਵੀ ਉਸ ਨੋਡ ਲਈ ਤਹਿ ਨਹੀਂ ਕੀਤਾ ਜਾਵੇਗਾ।
7. ਬੇਨਤੀ ਕੀਤੇ ਸਰੋਤਾਂ/ਸਰੋਤ ਸੀਮਾਵਾਂ ਦੀ ਸਹੀ ਮਾਤਰਾ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ, ਲੋਡ ਟੈਸਟਿੰਗ ਅਤੇ ਨਿਗਰਾਨੀ ਦੀ ਵਰਤੋਂ ਕਰੋ।

ਮੈਨੂੰ ਉਮੀਦ ਹੈ ਕਿ ਇਹ ਲੇਖ ਤੁਹਾਨੂੰ ਸਰੋਤ ਸੀਮਾ ਦੀ ਮੂਲ ਧਾਰਨਾ ਨੂੰ ਸਮਝਣ ਵਿੱਚ ਮਦਦ ਕਰੇਗਾ। ਅਤੇ ਤੁਸੀਂ ਇਸ ਗਿਆਨ ਨੂੰ ਆਪਣੇ ਕੰਮ ਵਿੱਚ ਲਾਗੂ ਕਰਨ ਦੇ ਯੋਗ ਹੋਵੋਗੇ.

ਕਾਮਯਾਬੀਆਂ!

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

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

ਸਰੋਤ: www.habr.com