ਕੁਬਰਨੇਟਸ: ਸਿਸਟਮ ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨਾ ਇੰਨਾ ਮਹੱਤਵਪੂਰਨ ਕਿਉਂ ਹੈ?

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

ਤੁਹਾਨੂੰ ਇਸ ਨਾਲ ਸ਼ੁਰੂ ਕਰਨ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸਿਸਟਮ ਵਿੱਚ ਕਿਹੜੇ ਮੁੱਖ ਕਿਸਮ ਦੇ ਸਰੋਤ ਮੌਜੂਦ ਹਨ - ਇਹ, ਬੇਸ਼ਕ, ਪ੍ਰੋਸੈਸਰ ਸਮਾਂ ਅਤੇ ਰੈਮ ਹੈ. k8s ਵਿੱਚ ਇਹ ਸਰੋਤ ਕਿਸਮਾਂ ਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਇਕਾਈਆਂ ਵਿੱਚ ਮਾਪਿਆ ਜਾਂਦਾ ਹੈ:

• CPU - ਕੋਰ ਵਿੱਚ
• RAM - ਬਾਈਟ ਵਿੱਚ

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

ਇਹ ਸਮਝਣਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿ ਮੈਨੀਫੈਸਟ ਨੂੰ ਸਪੱਸ਼ਟ ਤੌਰ 'ਤੇ ਦੋਵਾਂ ਕਿਸਮਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰਨ ਦੀ ਲੋੜ ਨਹੀਂ ਹੈ, ਪਰ ਵਿਹਾਰ ਇਸ ਤਰ੍ਹਾਂ ਹੋਵੇਗਾ:

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

ਸਰੋਤ ਪ੍ਰਬੰਧਨ ਨੂੰ ਨਾ ਸਿਰਫ਼ ਕਿਸੇ ਖਾਸ ਕੰਟੇਨਰ ਦੇ ਪੱਧਰ 'ਤੇ, ਸਗੋਂ ਨਿਮਨਲਿਖਤ ਇਕਾਈਆਂ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਨੇਮਸਪੇਸ ਪੱਧਰ 'ਤੇ ਵੀ ਸੰਰਚਿਤ ਕਰਨਾ ਸੰਭਵ ਹੈ:

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

ਹੇਠਾਂ ਦਿੱਤੇ ਮੈਨੀਫੈਸਟ ਦੀਆਂ ਉਦਾਹਰਨਾਂ ਹਨ ਜੋ ਸਰੋਤ ਸੀਮਾਵਾਂ ਨੂੰ ਸੈੱਟ ਕਰਦੀਆਂ ਹਨ:

• ਖਾਸ ਕੰਟੇਨਰ ਪੱਧਰ 'ਤੇ:

  containers:
  - name: app-nginx
    image: nginx
    resources:
      requests:
        memory: 1Gi
      limits:
        cpu: 200m

  ਉਹ. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, nginx ਦੇ ਨਾਲ ਇੱਕ ਕੰਟੇਨਰ ਚਲਾਉਣ ਲਈ, ਤੁਹਾਨੂੰ ਨੋਡ 'ਤੇ ਘੱਟੋ-ਘੱਟ 1G ਮੁਫ਼ਤ RAM ਅਤੇ 0.2 CPU ਦੀ ਲੋੜ ਹੋਵੇਗੀ, ਜਦੋਂ ਕਿ ਵੱਧ ਤੋਂ ਵੱਧ ਕੰਟੇਨਰ 0.2 CPU ਅਤੇ ਨੋਡ 'ਤੇ ਉਪਲਬਧ ਸਾਰੀਆਂ RAM ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

• ਪੂਰਨ ਅੰਕ ਪੱਧਰ 'ਤੇ ns:

  apiVersion: v1
  kind: ResourceQuota
  metadata:
    name: nxs-test
  spec:
    hard:
      requests.cpu: 300m
      requests.memory: 1Gi
      limits.cpu: 700m
      limits.memory: 2Gi

  ਉਹ. ਡਿਫੌਲਟ ns ਵਿੱਚ ਸਾਰੇ ਬੇਨਤੀ ਕੰਟੇਨਰਾਂ ਦਾ ਜੋੜ CPU ਲਈ 300m ਅਤੇ OP ਲਈ 1G ਤੋਂ ਵੱਧ ਨਹੀਂ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਸਾਰੀ ਸੀਮਾ ਦਾ ਜੋੜ CPU ਲਈ 700m ਅਤੇ OP ਲਈ 2G ਹੈ।

• ns ਵਿੱਚ ਕੰਟੇਨਰਾਂ ਲਈ ਡਿਫੌਲਟ ਸੀਮਾਵਾਂ:

  apiVersion: v1
  kind: LimitRange
  metadata:
    name: nxs-limit-per-container
  spec:
   limits:
     - type: Container
       defaultRequest:
         cpu: 100m
         memory: 1Gi
       default:
         cpu: 1
         memory: 2Gi
       min:
         cpu: 50m
         memory: 500Mi
       max:
         cpu: 2
         memory: 4Gi

  ਉਹ. ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਲਈ ਡਿਫੌਲਟ ਨੇਮਸਪੇਸ ਵਿੱਚ, ਬੇਨਤੀ ਨੂੰ CPU ਲਈ 100m ਅਤੇ OP ਲਈ 1G, ਸੀਮਾ - 1 CPU ਅਤੇ 2G ਲਈ ਸੈੱਟ ਕੀਤਾ ਜਾਵੇਗਾ। ਇਸ ਦੇ ਨਾਲ ਹੀ, CPU (50m <x <2) ਅਤੇ RAM (500M <x <4G) ਲਈ ਬੇਨਤੀ/ਸੀਮਾ ਵਿੱਚ ਸੰਭਾਵਿਤ ਮੁੱਲਾਂ 'ਤੇ ਵੀ ਇੱਕ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਗਈ ਹੈ।

• ਪੌਡ-ਪੱਧਰ ਦੀਆਂ ਪਾਬੰਦੀਆਂ ns:

  apiVersion: v1
  kind: LimitRange
  metadata:
   name: nxs-limit-pod
  spec:
   limits:
   - type: Pod
     max:
       cpu: 4
       memory: 1Gi

  ਉਹ. ਡਿਫੌਲਟ ਐਨਐਸ ਵਿੱਚ ਹਰੇਕ ਪੌਡ ਲਈ 4 vCPU ਅਤੇ 1G ਦੀ ਸੀਮਾ ਹੋਵੇਗੀ।

ਹੁਣ ਮੈਂ ਤੁਹਾਨੂੰ ਦੱਸਣਾ ਚਾਹਾਂਗਾ ਕਿ ਇਹ ਪਾਬੰਦੀਆਂ ਲਗਾਉਣ ਨਾਲ ਸਾਨੂੰ ਕਿਹੜੇ ਫਾਇਦੇ ਮਿਲ ਸਕਦੇ ਹਨ।

ਨੋਡਾਂ ਵਿਚਕਾਰ ਲੋਡ ਸੰਤੁਲਨ ਵਿਧੀ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, k8s ਕੰਪੋਨੈਂਟ ਨੋਡਾਂ ਵਿਚਕਾਰ ਪੌਡਾਂ ਦੀ ਵੰਡ ਲਈ ਜ਼ਿੰਮੇਵਾਰ ਹੈ, ਜਿਵੇਂ ਕਿ ਤਹਿ, ਜੋ ਕਿ ਇੱਕ ਖਾਸ ਐਲਗੋਰਿਦਮ ਦੇ ਅਨੁਸਾਰ ਕੰਮ ਕਰਦਾ ਹੈ। ਲਾਂਚ ਕਰਨ ਲਈ ਅਨੁਕੂਲ ਨੋਡ ਦੀ ਚੋਣ ਕਰਦੇ ਸਮੇਂ ਇਹ ਐਲਗੋਰਿਦਮ ਦੋ ਪੜਾਵਾਂ ਵਿੱਚੋਂ ਲੰਘਦਾ ਹੈ:

1. ਫਿਲਟਰ
2. ਰੇਂਜਿੰਗ

ਉਹ. ਵਰਣਿਤ ਨੀਤੀ ਦੇ ਅਨੁਸਾਰ, ਨੋਡਾਂ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਇੱਕ ਸੈੱਟ ਦੇ ਅਧਾਰ ਤੇ ਇੱਕ ਪੌਡ ਲਾਂਚ ਕਰਨਾ ਸੰਭਵ ਹੁੰਦਾ ਹੈ predicates (ਇਹ ਜਾਂਚ ਕਰਨ ਸਮੇਤ ਕਿ ਕੀ ਨੋਡ ਕੋਲ ਪੌਡ ਨੂੰ ਚਲਾਉਣ ਲਈ ਲੋੜੀਂਦੇ ਸਰੋਤ ਹਨ - PodFitsResources), ਅਤੇ ਫਿਰ ਇਹਨਾਂ ਨੋਡਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ, ਅਨੁਸਾਰ ਤਰਜੀਹਾਂ ਪੁਆਇੰਟ ਦਿੱਤੇ ਜਾਂਦੇ ਹਨ (ਸਮੇਤ, ਇੱਕ ਨੋਡ ਵਿੱਚ ਜਿੰਨੇ ਜ਼ਿਆਦਾ ਮੁਫਤ ਸਰੋਤ ਹੁੰਦੇ ਹਨ, ਓਨੇ ਹੀ ਜ਼ਿਆਦਾ ਪੁਆਇੰਟ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ਅਤੇ ਪੌਡ ਨੂੰ ਨੋਡ 'ਤੇ ਸਭ ਤੋਂ ਵੱਧ ਪੁਆਇੰਟਾਂ ਨਾਲ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਜੇ ਕਈ ਨੋਡ ਇੱਕ ਵਾਰ ਵਿੱਚ ਇਸ ਸ਼ਰਤ ਨੂੰ ਪੂਰਾ ਕਰਦੇ ਹਨ, ਤਾਂ ਇੱਕ ਬੇਤਰਤੀਬ ਚੁਣਿਆ ਗਿਆ ਹੈ)।

ਉਸੇ ਸਮੇਂ, ਤੁਹਾਨੂੰ ਇਹ ਸਮਝਣ ਦੀ ਜ਼ਰੂਰਤ ਹੈ ਕਿ ਸ਼ਡਿਊਲਰ, ਜਦੋਂ ਇੱਕ ਨੋਡ ਦੇ ਉਪਲਬਧ ਸਰੋਤਾਂ ਦਾ ਮੁਲਾਂਕਣ ਕਰਦਾ ਹੈ, ਉਸ ਡੇਟਾ ਦੁਆਰਾ ਸੇਧਿਤ ਹੁੰਦਾ ਹੈ ਜੋ etcd ਵਿੱਚ ਸਟੋਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ - i.e. ਇਸ ਨੋਡ 'ਤੇ ਚੱਲ ਰਹੇ ਹਰੇਕ ਪੌਡ ਦੀ ਬੇਨਤੀ ਕੀਤੀ/ਸੀਮਾ ਸਰੋਤ ਦੀ ਮਾਤਰਾ ਲਈ, ਪਰ ਅਸਲ ਸਰੋਤ ਖਪਤ ਲਈ ਨਹੀਂ। ਇਹ ਜਾਣਕਾਰੀ ਕਮਾਂਡ ਆਉਟਪੁੱਟ ਤੋਂ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ kubectl describe node $NODE, ਉਦਾਹਰਨ ਲਈ:

# kubectl describe nodes nxs-k8s-s1
..
Non-terminated Pods:         (9 in total)
  Namespace                  Name                                         CPU Requests  CPU Limits  Memory Requests  Memory Limits  AGE
  ---------                  ----                                         ------------  ----------  ---------------  -------------  ---
  ingress-nginx              nginx-ingress-controller-754b85bf44-qkt2t    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-flannel-26bl4                           150m (0%)     300m (1%)   64M (0%)         500M (1%)      233d
  kube-system                kube-proxy-exporter-cb629                    0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                kube-proxy-x9fsc                             0 (0%)        0 (0%)      0 (0%)           0 (0%)         233d
  kube-system                nginx-proxy-k8s-worker-s1                    25m (0%)      300m (1%)   32M (0%)         512M (1%)      233d
  nxs-monitoring             alertmanager-main-1                          100m (0%)     100m (0%)   425Mi (1%)       25Mi (0%)      233d
  nxs-logging                filebeat-lmsmp                               100m (0%)     0 (0%)      100Mi (0%)       200Mi (0%)     233d
  nxs-monitoring             node-exporter-v4gdq                          112m (0%)     122m (0%)   200Mi (0%)       220Mi (0%)     233d
Allocated resources:
  (Total limits may be over 100 percent, i.e., overcommitted.)
  Resource           Requests           Limits
  --------           --------           ------
  cpu                487m (3%)          822m (5%)
  memory             15856217600 (2%)  749976320 (3%)
  ephemeral-storage  0 (0%)             0 (0%)

ਇੱਥੇ ਅਸੀਂ ਇੱਕ ਖਾਸ ਨੋਡ 'ਤੇ ਚੱਲ ਰਹੇ ਸਾਰੇ ਪੌਡ ਵੇਖਦੇ ਹਾਂ, ਨਾਲ ਹੀ ਉਹ ਸਰੋਤ ਜੋ ਹਰੇਕ ਪੌਡ ਦੀ ਬੇਨਤੀ ਕਰਦਾ ਹੈ। ਅਤੇ ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਜਦੋਂ cronjob-cron-events-1573793820-xt6q9 ਪੌਡ ਲਾਂਚ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਸ਼ਡਿਊਲਰ ਲੌਗ ਕਿਸ ਤਰ੍ਹਾਂ ਦੇ ਦਿਖਾਈ ਦਿੰਦੇ ਹਨ (ਇਹ ਜਾਣਕਾਰੀ ਸ਼ਡਿਊਲਰ ਲੌਗ ਵਿੱਚ ਦਿਖਾਈ ਦੇਵੇਗੀ ਜਦੋਂ ਤੁਸੀਂ ਸਟਾਰਟਅੱਪ ਕਮਾਂਡ ਆਰਗੂਮੈਂਟਸ -v=10 ਵਿੱਚ 10ਵਾਂ ਲੌਗਿੰਗ ਪੱਧਰ ਸੈਟ ਕਰਦੇ ਹੋ):

ਲੌਗ

I1115 07:57:21.637791       1 scheduling_queue.go:908] About to try and schedule pod nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                           
I1115 07:57:21.637804       1 scheduler.go:453] Attempting to schedule pod: nxs-stage/cronjob-cron-events-1573793820-xt6q9                                                                                                                                                    
I1115 07:57:21.638285       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s5 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638300       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s6 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s3 is allowed, Node is running only 20 out of 110 Pods.                                                                               
I1115 07:57:21.638322       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s4 is allowed, Node is running only 17 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, Node is running only 16 out of 110 Pods.                                                                              
I1115 07:57:21.638365       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s12 is allowed, Node is running only 9 out of 110 Pods.                                                                               
I1115 07:57:21.638334       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s11 is allowed, Node is running only 11 out of 110 Pods.                                                                              
I1115 07:57:21.638385       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s1 is allowed, Node is running only 19 out of 110 Pods.                                                                               
I1115 07:57:21.638402       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s2 is allowed, Node is running only 21 out of 110 Pods.                                                                               
I1115 07:57:21.638383       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, Node is running only 16 out of 110 Pods.                                                                               
I1115 07:57:21.638335       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, Node is running only 18 out of 110 Pods.                                                                               
I1115 07:57:21.638408       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s13 is allowed, Node is running only 8 out of 110 Pods.                                                                               
I1115 07:57:21.638478       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s10 is allowed, existing pods anti-affinity terms satisfied.                                                                         
I1115 07:57:21.638505       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s8 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638577       1 predicates.go:1369] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s9 is allowed, existing pods anti-affinity terms satisfied.                                                                          
I1115 07:57:21.638583       1 predicates.go:829] Schedule Pod nxs-stage/cronjob-cron-events-1573793820-xt6q9 on Node nxs-k8s-s7 is allowed, Node is running only 25 out of 110 Pods.                                                                               
I1115 07:57:21.638932       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 9        
I1115 07:57:21.638946       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 2343 millicores 9640186880 memory bytes, score 8           
I1115 07:57:21.638961       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: BalancedResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 9        
I1115 07:57:21.638971       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: BalancedResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7        
I1115 07:57:21.638975       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: LeastResourceAllocation, capacity 39900 millicores 66620170240 memory bytes, total request 4107 millicores 11307422720 memory bytes, score 8           
I1115 07:57:21.638990       1 resource_allocation.go:78] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: LeastResourceAllocation, capacity 39900 millicores 66620178432 memory bytes, total request 5847 millicores 24333637120 memory bytes, score 7           
I1115 07:57:21.639022       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: TaintTolerationPriority, Score: (10)                                                                                                        
I1115 07:57:21.639030       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639034       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: TaintTolerationPriority, Score: (10)                                                                                                         
I1115 07:57:21.639041       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: NodeAffinityPriority, Score: (0)                                                                                                            
I1115 07:57:21.639053       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639059       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: NodeAffinityPriority, Score: (0)                                                                                                             
I1115 07:57:21.639061       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: InterPodAffinityPriority, Score: (0)                                                                                                                   
I1115 07:57:21.639063       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                                   
I1115 07:57:21.639073       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639077       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639085       1 interpod_affinity.go:237] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: InterPodAffinityPriority, Score: (0)                                                                                                                    
I1115 07:57:21.639088       1 selector_spreading.go:146] cronjob-cron-events-1573793820-xt6q9 -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                                    
I1115 07:57:21.639103       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s10: SelectorSpreadPriority, Score: (10)                                                                                                         
I1115 07:57:21.639109       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s8: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639114       1 generic_scheduler.go:726] cronjob-cron-events-1573793820-xt6q9_nxs-stage -> nxs-k8s-s9: SelectorSpreadPriority, Score: (10)                                                                                                          
I1115 07:57:21.639127       1 generic_scheduler.go:781] Host nxs-k8s-s10 => Score 100037                                                                                                                                                                            
I1115 07:57:21.639150       1 generic_scheduler.go:781] Host nxs-k8s-s8 => Score 100034                                                                                                                                                                             
I1115 07:57:21.639154       1 generic_scheduler.go:781] Host nxs-k8s-s9 => Score 100037                                                                                                                                                                             
I1115 07:57:21.639267       1 scheduler_binder.go:269] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10"                                                                                                               
I1115 07:57:21.639286       1 scheduler_binder.go:279] AssumePodVolumes for pod "nxs-stage/cronjob-cron-events-1573793820-xt6q9", node "nxs-k8s-s10": all PVCs bound and nothing to do                                                                             
I1115 07:57:21.639333       1 factory.go:733] Attempting to bind cronjob-cron-events-1573793820-xt6q9 to nxs-k8s-s10

ਇੱਥੇ ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਸ਼ੁਰੂ ਵਿੱਚ ਸ਼ਡਿਊਲਰ ਫਿਲਟਰ ਕਰਦਾ ਹੈ ਅਤੇ 3 ਨੋਡਾਂ ਦੀ ਇੱਕ ਸੂਚੀ ਤਿਆਰ ਕਰਦਾ ਹੈ ਜਿਸ ਉੱਤੇ ਇਸਨੂੰ ਲਾਂਚ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (nxs-k8s-s8, nxs-k8s-s9, nxs-k8s-s10)। ਫਿਰ ਇਹ ਸਭ ਤੋਂ ਢੁਕਵੇਂ ਨੋਡ ਨੂੰ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਨੋਡ ਲਈ ਕਈ ਪੈਰਾਮੀਟਰਾਂ (ਸੰਤੁਲਿਤ ਸਰੋਤ ਅਲੋਕੇਸ਼ਨ, LeastResourceAllocation ਸਮੇਤ) ਦੇ ਆਧਾਰ 'ਤੇ ਸਕੋਰਾਂ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ। ਆਖਰਕਾਰ, ਪੌਡ ਨੂੰ ਸਭ ਤੋਂ ਵੱਧ ਅੰਕਾਂ ਵਾਲੇ ਨੋਡ 'ਤੇ ਤਹਿ ਕੀਤਾ ਜਾਂਦਾ ਹੈ (ਇੱਥੇ ਦੋ ਨੋਡਾਂ ਵਿੱਚ ਇੱਕੋ ਸਮੇਂ 100037 ਪੁਆਇੰਟ ਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਇੱਕ ਬੇਤਰਤੀਬ ਚੁਣਿਆ ਜਾਂਦਾ ਹੈ - nxs-k8s-s10)।

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

ਪੋਡ ਦੀ ਬੇਦਖਲੀ

ਜਿਵੇਂ ਕਿ ਤੁਸੀਂ ਜਾਣਦੇ ਹੋ, ਹਰੇਕ ਪੌਡ ਨੂੰ 3 QoS ਕਲਾਸਾਂ ਵਿੱਚੋਂ ਇੱਕ ਨਿਰਧਾਰਤ ਕੀਤਾ ਗਿਆ ਹੈ:

1. ਗਾਰੰਟੀਸ਼ੁਦਾ — ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਪੌਡ ਵਿੱਚ ਹਰੇਕ ਕੰਟੇਨਰ ਲਈ ਮੈਮੋਰੀ ਅਤੇ ਸੀਪੀਯੂ ਲਈ ਇੱਕ ਬੇਨਤੀ ਅਤੇ ਸੀਮਾ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ, ਅਤੇ ਇਹ ਮੁੱਲ ਮੇਲ ਖਾਂਦੇ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ
2. ਫਟਣਯੋਗ - ਪੌਡ ਵਿੱਚ ਘੱਟੋ-ਘੱਟ ਇੱਕ ਕੰਟੇਨਰ ਵਿੱਚ ਇੱਕ ਬੇਨਤੀ ਅਤੇ ਇੱਕ ਸੀਮਾ ਹੈ, ਬੇਨਤੀ < ਸੀਮਾ ਦੇ ਨਾਲ
3. ਵਧੀਆ ਕੋਸ਼ਿਸ਼ - ਜਦੋਂ ਪੌਡ ਵਿੱਚ ਇੱਕ ਵੀ ਕੰਟੇਨਰ ਸਰੋਤ ਸੀਮਤ ਨਹੀਂ ਹੈ

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

• ਗਾਰੰਟੀਸ਼ੁਦਾ:-੪੦
• ਵਧੀਆ ਕੋਸ਼ਿਸ਼: 1000
• ਬਰਸਟਬਲ: min(ਅਧਿਕਤਮ(2, 1000 - (1000 * memoryRequestBytes) / machineMemoryCapacityBytes), 999)

ਉਹ. ਉਸੇ ਤਰਜੀਹ ਦੇ ਨਾਲ, ਕੁਬੇਲੇਟ ਪਹਿਲਾਂ ਨੋਡ ਤੋਂ ਵਧੀਆ ਕੋਸ਼ਿਸ਼ QoS ਕਲਾਸ ਨਾਲ ਪੌਡਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢੇਗਾ।

ਸਿੱਟਾ: ਜੇਕਰ ਤੁਸੀਂ ਲੋੜੀਂਦੇ ਪੌਡ ਨੂੰ ਇਸ 'ਤੇ ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਨੋਡ ਤੋਂ ਬੇਦਖਲ ਕੀਤੇ ਜਾਣ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤਰਜੀਹ ਦੇ ਨਾਲ, ਤੁਹਾਨੂੰ ਇਸ ਲਈ ਬੇਨਤੀ/ਸੀਮਾ ਨਿਰਧਾਰਤ ਕਰਨ ਦਾ ਵੀ ਧਿਆਨ ਰੱਖਣਾ ਚਾਹੀਦਾ ਹੈ।

ਐਪਲੀਕੇਸ਼ਨ ਪੌਡਜ਼ (HPA) ਦੀ ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ ਲਈ ਵਿਧੀ

ਜਦੋਂ ਕੰਮ ਸਰੋਤਾਂ (ਸਿਸਟਮ - CPU/RAM ਜਾਂ ਉਪਭੋਗਤਾ - rps) ਦੀ ਵਰਤੋਂ 'ਤੇ ਨਿਰਭਰ ਕਰਦੇ ਹੋਏ ਪੌਡਾਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਆਪਣੇ ਆਪ ਵਧਾਉਣਾ ਅਤੇ ਘਟਾਉਣਾ ਹੁੰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ k8s ਇਕਾਈ। HPA (ਹਰੀਜ਼ੈਂਟਲ ਪੋਡ ਆਟੋਸਕੇਲਰ)। ਜਿਸ ਦਾ ਐਲਗੋਰਿਦਮ ਹੇਠ ਲਿਖੇ ਅਨੁਸਾਰ ਹੈ:

1. ਨਿਰੀਖਣ ਕੀਤੇ ਸਰੋਤ ਦੀ ਮੌਜੂਦਾ ਰੀਡਿੰਗ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਕਰੰਟਮੈਟ੍ਰਿਕ ਵੈਲਯੂ)
2. ਸਰੋਤ ਲਈ ਲੋੜੀਂਦੇ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕੀਤੇ ਜਾਂਦੇ ਹਨ (desiredMetricValue), ਜੋ ਕਿ ਸਿਸਟਮ ਸਰੋਤਾਂ ਲਈ ਬੇਨਤੀ ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਸੈੱਟ ਕੀਤੇ ਜਾਂਦੇ ਹਨ
3. ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਮੌਜੂਦਾ ਸੰਖਿਆ ਨਿਰਧਾਰਤ ਕੀਤੀ ਜਾਂਦੀ ਹੈ (ਮੌਜੂਦਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ)
4. ਨਿਮਨਲਿਖਤ ਫਾਰਮੂਲਾ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ (ਇੱਛਤ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ) ਦੀ ਲੋੜੀਦੀ ਸੰਖਿਆ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ
   desiredReplicas = [ currentReplicas * (currentMetricValue / desiredMetricValue)]

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸਕੇਲਿੰਗ ਉਦੋਂ ਨਹੀਂ ਹੋਵੇਗੀ ਜਦੋਂ ਗੁਣਾਂਕ (ਕਰੰਟ ਮੈਟ੍ਰਿਕ ਵੈਲਯੂ / ਇੱਛਿਤ ਮੈਟ੍ਰਿਕ ਵੈਲਯੂ) 1 ਦੇ ਨੇੜੇ ਹੈ (ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਅਸੀਂ ਅਨੁਮਤੀਯੋਗ ਗਲਤੀ ਨੂੰ ਆਪਣੇ ਆਪ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹਾਂ; ਮੂਲ ਰੂਪ ਵਿੱਚ ਇਹ 0.1 ਹੈ)।

ਆਉ ਦੇਖੀਏ ਕਿ ਐਪ-ਟੈਸਟ ਐਪਲੀਕੇਸ਼ਨ (ਡਿਪਲਾਇਮੈਂਟ ਦੇ ਤੌਰ ਤੇ ਵਰਣਨ ਕੀਤਾ ਗਿਆ ਹੈ) ਦੀ ਉਦਾਹਰਣ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ hpa ਕਿਵੇਂ ਕੰਮ ਕਰਦਾ ਹੈ, ਜਿੱਥੇ CPU ਖਪਤ ਦੇ ਅਧਾਰ ਤੇ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਸੰਖਿਆ ਨੂੰ ਬਦਲਣਾ ਜ਼ਰੂਰੀ ਹੈ:

• ਐਪਲੀਕੇਸ਼ਨ ਮੈਨੀਫੈਸਟ

  kind: Deployment
  apiVersion: apps/v1beta2
  metadata:
  name: app-test
  spec:
  selector:
  matchLabels:
  app: app-test
  replicas: 2
  template:
  metadata:
  labels:
  app: app-test
  spec:
  containers:
  - name: nginx
  image: registry.nixys.ru/generic-images/nginx
  imagePullPolicy: Always
  resources:
  requests:
  cpu: 60m
  ports:
  - name: http
  containerPort: 80
  - name: nginx-exporter
  image: nginx/nginx-prometheus-exporter
  resources:
  requests:
  cpu: 30m
  ports:
  - name: nginx-exporter
  containerPort: 9113
  args:
  - -nginx.scrape-uri
  - http://127.0.0.1:80/nginx-status

  ਉਹ. ਅਸੀਂ ਦੇਖਦੇ ਹਾਂ ਕਿ ਐਪਲੀਕੇਸ਼ਨ ਪੌਡ ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਦੋ ਮੌਕਿਆਂ ਵਿੱਚ ਲਾਂਚ ਕੀਤਾ ਗਿਆ ਹੈ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਵਿੱਚ ਦੋ nginx ਅਤੇ nginx-exporter ਕੰਟੇਨਰ ਹਨ, ਜਿਨ੍ਹਾਂ ਵਿੱਚੋਂ ਹਰੇਕ ਲਈ ਇੱਕ ਨਿਸ਼ਚਿਤ ਬੇਨਤੀਆਂ CPU ਲਈ.

• HPA ਮੈਨੀਫੈਸਟੋ

  apiVersion: autoscaling/v2beta2
  kind: HorizontalPodAutoscaler
  metadata:
  name: app-test-hpa
  spec:
  maxReplicas: 10
  minReplicas: 2
  scaleTargetRef:
  apiVersion: extensions/v1beta1
  kind: Deployment
  name: app-test
  metrics:
  - type: Resource
  resource:
  name: cpu
  target:
  type: Utilization
  averageUtilization: 30

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

  ਹੁਣ, ਆਓ ਐਚਪੀਏ ਓਪਰੇਸ਼ਨ ਦੀ ਵਿਧੀ ਨੂੰ ਵੇਖੀਏ ਜੇਕਰ ਅਸੀਂ ਕਿਸੇ ਇੱਕ ਚੁੱਲ੍ਹੇ 'ਤੇ ਲੋਡ ਲਾਗੂ ਕਰਦੇ ਹਾਂ:

   # kubectl top pod
  NAME                                                   CPU(cores)   MEMORY(bytes)
  app-test-78559f8f44-pgs58            101m         243Mi
  app-test-78559f8f44-cj4jz            4m           240Mi

ਕੁੱਲ ਮਿਲਾ ਕੇ ਸਾਡੇ ਕੋਲ ਹੇਠ ਲਿਖੇ ਹਨ:

• ਲੋੜੀਦਾ ਮੁੱਲ (desiredMetricValue) - hpa ਸੈਟਿੰਗਾਂ ਦੇ ਅਨੁਸਾਰ, ਸਾਡੇ ਕੋਲ 30% ਹੈ
• ਮੌਜੂਦਾ ਮੁੱਲ (currentMetricValue) - ਗਣਨਾ ਲਈ, ਕੰਟਰੋਲਰ-ਪ੍ਰਬੰਧਕ % ਵਿੱਚ ਸਰੋਤ ਦੀ ਖਪਤ ਦੇ ਔਸਤ ਮੁੱਲ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਯਾਨੀ. ਸ਼ਰਤ ਅਨੁਸਾਰ ਇਹ ਕਰਦਾ ਹੈ:
  1. ਮੈਟ੍ਰਿਕ ਸਰਵਰ ਤੋਂ ਪੌਡ ਮੈਟ੍ਰਿਕਸ ਦੇ ਸੰਪੂਰਨ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ, i.e. 101 ਮੀ ਅਤੇ 4 ਮੀ
  2. ਔਸਤ ਸੰਪੂਰਨ ਮੁੱਲ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ (101m + 4m) / 2 = 53m
  3. ਲੋੜੀਂਦੇ ਸਰੋਤ ਦੀ ਖਪਤ ਲਈ ਸੰਪੂਰਨ ਮੁੱਲ ਪ੍ਰਾਪਤ ਕਰਦਾ ਹੈ (ਇਸਦੇ ਲਈ, ਸਾਰੇ ਕੰਟੇਨਰਾਂ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਸਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ) 60m + 30m = 90m
  4. ਬੇਨਤੀ ਪੌਡ ਦੇ ਮੁਕਾਬਲੇ CPU ਖਪਤ ਦੀ ਔਸਤ ਪ੍ਰਤੀਸ਼ਤ ਦੀ ਗਣਨਾ ਕਰਦਾ ਹੈ, ਜਿਵੇਂ ਕਿ 53m / 90m * 100% = 59%

ਹੁਣ ਸਾਡੇ ਕੋਲ ਉਹ ਸਭ ਕੁਝ ਹੈ ਜੋ ਸਾਨੂੰ ਇਹ ਨਿਰਧਾਰਤ ਕਰਨ ਲਈ ਲੋੜੀਂਦਾ ਹੈ ਕਿ ਕੀ ਸਾਨੂੰ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਗਿਣਤੀ ਨੂੰ ਬਦਲਣ ਦੀ ਲੋੜ ਹੈ; ਅਜਿਹਾ ਕਰਨ ਲਈ, ਅਸੀਂ ਗੁਣਾਂਕ ਦੀ ਗਣਨਾ ਕਰਦੇ ਹਾਂ:

ratio = 59% / 30% = 1.96

ਉਹ. ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਗਿਣਤੀ ~2 ਗੁਣਾ ਅਤੇ ਮਾਤਰਾ [2 * 1.96] = 4 ਤੱਕ ਵਧਾਈ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ।

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

ਨੋਡਸ (ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਰ) ਦੀ ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ ਲਈ ਵਿਧੀ

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

ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਜੇਕਰ ਪ੍ਰਦਾਤਾ ਕੋਲ ਇੱਕ ਅਨੁਸਾਰੀ IaaS/PaaS ਹੈ (ਉਦਾਹਰਨ ਲਈ, GKE/GCE, AKS, EKS, ਆਦਿ), ਇੱਕ ਸਾਧਨ ਜਿਵੇਂ ਕਿ ਨੋਡ ਆਟੋਸਕੇਲਰ. ਇਹ ਤੁਹਾਨੂੰ ਕਲੱਸਟਰ ਵਿੱਚ ਨੋਡਾਂ ਦੀ ਵੱਧ ਤੋਂ ਵੱਧ ਅਤੇ ਘੱਟੋ-ਘੱਟ ਸੰਖਿਆ ਸੈਟ ਕਰਨ ਅਤੇ ਕਲੱਸਟਰ ਅਤੇ ਪੌਡਾਂ ਵਿੱਚ ਸਰੋਤਾਂ ਦੀ ਘਾਟ ਹੋਣ 'ਤੇ ਨੋਡਾਂ ਦੀ ਮੌਜੂਦਾ ਸੰਖਿਆ (ਇੱਕ ਨੋਡ ਨੂੰ ਆਰਡਰ/ਹਟਾਉਣ ਲਈ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ API ਨੂੰ ਕਾਲ ਕਰਕੇ) ਨੂੰ ਆਪਣੇ ਆਪ ਵਿਵਸਥਿਤ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਨਿਯਤ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ (ਬਕਾਇਆ ਸਥਿਤੀ ਵਿੱਚ ਹਨ)।

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

ਸਿੱਟਾ

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

1. k8s ਨੋਡਾਂ ਵਿਚਕਾਰ ਲੋਡ ਸੰਤੁਲਨ ਦੇ ਰੂਪ ਵਿੱਚ ਸ਼ਡਿਊਲਰ ਦੇ ਵਧੇਰੇ ਸਹੀ ਸੰਚਾਲਨ ਲਈ
2. "ਪੋਡ ਬੇਦਖਲੀ" ਘਟਨਾ ਵਾਪਰਨ ਦੀ ਸੰਭਾਵਨਾ ਨੂੰ ਘਟਾਉਣ ਲਈ
3. ਕੰਮ ਕਰਨ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਪੌਡਜ਼ (HPA) ਦੀ ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ ਲਈ
4. ਕਲਾਉਡ ਪ੍ਰਦਾਤਾਵਾਂ ਲਈ ਨੋਡਾਂ ਦੀ ਹਰੀਜੱਟਲ ਆਟੋਸਕੇਲਿੰਗ (ਕਲੱਸਟਰ ਆਟੋਸਕੇਲਿੰਗ) ਲਈ

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

• ਟੇਕਟਨ ਪਾਈਪਲਾਈਨ - ਕੁਬਰਨੇਟਸ-ਦੇਸੀ ਪਾਈਪਲਾਈਨਾਂ
• Nginx ਲਈ ਡਾਇਨਾਮਿਕ ਮੋਡੀਊਲ ਬਣਾਉਣਾ
• ਅਧਿਕਾਰ ਦੇ ਨਾਲ ਕਲਿਕਹਾਊਸ ਤੋਂ ਬਿਨਾਂ ਅਧਿਕਾਰ ਦੇ ਕਲਿੱਕਹਾਊਸ ਵਿੱਚ ਮਾਈਗ੍ਰੇਸ਼ਨ ਕੀ ਹੋਇਆ?
• ਗੋਲੰਗ ਵਿੱਚ ਸੰਦਰਭ ਪੈਕੇਜ ਨੂੰ ਸਮਝਣਾ
• ਡੌਕਰ ਚਿੱਤਰਾਂ ਨੂੰ ਸੁੰਗੜਨ ਲਈ ਤਿੰਨ ਸਧਾਰਨ ਟ੍ਰਿਕਸ
• ਵੱਡੀ ਗਿਣਤੀ ਵਿੱਚ ਵਿਪਰੀਤ ਵੈੱਬ ਪ੍ਰੋਜੈਕਟਾਂ ਦਾ ਬੈਕਅੱਪ

ਸਰੋਤ: www.habr.com