ਨੌਂ ਕੁਬਰਨੇਟਸ ਪ੍ਰਦਰਸ਼ਨ ਸੁਝਾਅ

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

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

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

1. ਟੀਮ ਅਤੇ ਐਪਲੀਕੇਸ਼ਨ ਸਰੋਤਾਂ ਦੀ ਨਿਗਰਾਨੀ ਕਰੋ

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

resources:
   requests:
     memory: 2Gi
     cpu: 250m
   limits:
     memory: 4Gi
     cpu: 500m

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

ਇਸ ਦੇ ਨਾਲ, ਦੀ ਮਦਦ ਨਾਲ limitranges ਸ਼ੁਰੂ ਵਿੱਚ, ਤੁਸੀਂ ਕੰਟੇਨਰ ਲਈ ਸਰੋਤ ਮੁੱਲ ਸੈੱਟ ਕਰ ਸਕਦੇ ਹੋ - ਘੱਟੋ-ਘੱਟ, ਅਧਿਕਤਮ ਅਤੇ ਡਿਫੌਲਟ:

➜  ~ kubectl describe limitranges --namespace ops
Name:       limit-range
Namespace:  ops
Type        Resource           Min   Max   Default Request  Default Limit  Max Limit/Request Ratio
----        --------           ---   ---   ---------------  -------------  -----------------------
Container   cpu                50m   10    100m             100m           2
Container   ephemeral-storage  12Mi  8Gi   128Mi            4Gi            -
Container   memory             64Mi  40Gi  128Mi            128Mi          2

ਨੇਮਸਪੇਸ ਸਰੋਤਾਂ ਨੂੰ ਸੀਮਤ ਕਰਨਾ ਨਾ ਭੁੱਲੋ ਤਾਂ ਕਿ ਇੱਕ ਟੀਮ ਕਲੱਸਟਰ ਦੇ ਸਾਰੇ ਸਰੋਤਾਂ ਨੂੰ ਆਪਣੇ ਕਬਜ਼ੇ ਵਿੱਚ ਨਾ ਲੈ ਸਕੇ:

➜  ~ kubectl describe resourcequotas --namespace ops
Name:                   resource-quota
Namespace:              ops
Resource                Used          Hard
--------                ----          ----
limits.cpu              77250m        80
limits.memory           124814367488  150Gi
pods                    31            45
requests.cpu            53850m        80
requests.memory         75613234944   150Gi
services                26            50
services.loadbalancers  0             0
services.nodeports      0             0

ਜਿਵੇਂ ਕਿ ਵਰਣਨ ਤੋਂ ਦੇਖਿਆ ਜਾ ਸਕਦਾ ਹੈ resourcequotas, ਜੇਕਰ ਓਪਸ ਟੀਮ ਪੌਡਾਂ ਨੂੰ ਤੈਨਾਤ ਕਰਨਾ ਚਾਹੁੰਦੀ ਹੈ ਜੋ ਹੋਰ 10 ਸੀਪੀਯੂ ਦੀ ਖਪਤ ਕਰੇਗੀ, ਤਾਂ ਸ਼ਡਿਊਲਰ ਇਸਦੀ ਇਜਾਜ਼ਤ ਨਹੀਂ ਦੇਵੇਗਾ ਅਤੇ ਇੱਕ ਗਲਤੀ ਕਰੇਗਾ:

Error creating: pods "nginx-proxy-9967d8d78-nh4fs" is forbidden: exceeded quota: resource-quota, requested: limits.cpu=5,requests.cpu=5, used: limits.cpu=77250m,requests.cpu=53850m, limited: limits.cpu=10,requests.cpu=10

ਅਜਿਹੀ ਸਮੱਸਿਆ ਨੂੰ ਹੱਲ ਕਰਨ ਲਈ, ਤੁਸੀਂ ਇੱਕ ਸੰਦ ਲਿਖ ਸਕਦੇ ਹੋ, ਉਦਾਹਰਨ ਲਈ, ਜਿਵੇਂ ਇਹ, ਕਮਾਂਡ ਸਰੋਤਾਂ ਦੀ ਸਥਿਤੀ ਨੂੰ ਸਟੋਰ ਕਰਨ ਅਤੇ ਪ੍ਰਤੀਬੱਧ ਕਰਨ ਦੇ ਯੋਗ।

2. ਸਰਵੋਤਮ ਫਾਈਲ ਸਟੋਰੇਜ ਚੁਣੋ

ਇੱਥੇ ਮੈਂ ਸਥਾਈ ਵਾਲੀਅਮ ਅਤੇ ਕੁਬਰਨੇਟਸ ਵਰਕਰ ਨੋਡਸ ਦੇ ਡਿਸਕ ਸਬ-ਸਿਸਟਮ ਦੇ ਵਿਸ਼ੇ 'ਤੇ ਛੂਹਣਾ ਚਾਹਾਂਗਾ। ਮੈਂ ਉਮੀਦ ਕਰਦਾ ਹਾਂ ਕਿ ਕੋਈ ਵੀ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ ਐਚਡੀਡੀ 'ਤੇ "ਕਿਊਬ" ਦੀ ਵਰਤੋਂ ਨਹੀਂ ਕਰਦਾ, ਪਰ ਕਈ ਵਾਰ ਇੱਕ ਨਿਯਮਤ SSD ਹੁਣ ਕਾਫ਼ੀ ਨਹੀਂ ਹੁੰਦਾ. ਸਾਨੂੰ ਇੱਕ ਸਮੱਸਿਆ ਆਈ ਹੈ ਜਿੱਥੇ ਲੌਗ I/O ਓਪਰੇਸ਼ਨਾਂ ਦੇ ਕਾਰਨ ਡਿਸਕ ਨੂੰ ਖਤਮ ਕਰ ਰਹੇ ਸਨ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਹੱਲ ਨਹੀਂ ਹਨ:

• ਉੱਚ-ਪ੍ਰਦਰਸ਼ਨ ਵਾਲੇ SSDs ਦੀ ਵਰਤੋਂ ਕਰੋ ਜਾਂ NVMe 'ਤੇ ਸਵਿਚ ਕਰੋ (ਜੇ ਤੁਸੀਂ ਆਪਣੇ ਹਾਰਡਵੇਅਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਦੇ ਹੋ)।

• ਲਾਗਿੰਗ ਪੱਧਰ ਨੂੰ ਘਟਾਓ.

• ਫਲੀਆਂ ਦਾ "ਸਮਾਰਟ" ਸੰਤੁਲਨ ਕਰੋ ਜੋ ਡਿਸਕ ਨਾਲ ਬਲਾਤਕਾਰ ਕਰਦੇ ਹਨ (podAntiAffinity).

ਉਪਰੋਕਤ ਸਕਰੀਨ ਦਿਖਾਉਂਦਾ ਹੈ ਕਿ ਡਿਸਕ 'ਤੇ nginx-ingress-controller ਦੇ ਅਧੀਨ ਕੀ ਹੁੰਦਾ ਹੈ ਜਦੋਂ access_logs ਲੌਗਿੰਗ ਸਮਰੱਥ ਹੁੰਦੀ ਹੈ (~ 12 ਹਜ਼ਾਰ ਲੌਗਸ/ਸੈਕੰਡ)। ਇਹ ਸਥਿਤੀ, ਬੇਸ਼ੱਕ, ਇਸ ਨੋਡ 'ਤੇ ਸਾਰੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਦੇ ਪਤਨ ਦਾ ਕਾਰਨ ਬਣ ਸਕਦੀ ਹੈ।

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

3. ਅਨੁਕੂਲਿਤ ਚਿੱਤਰ ਇਕੱਠੇ ਕਰੋ

ਕੰਟੇਨਰ-ਅਨੁਕੂਲ ਚਿੱਤਰਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨਾ ਸਭ ਤੋਂ ਵਧੀਆ ਹੈ ਤਾਂ ਕਿ ਕੁਬਰਨੇਟਸ ਉਹਨਾਂ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਪ੍ਰਾਪਤ ਕਰ ਸਕਣ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਹੋਰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਚਲਾ ਸਕਣ। 

ਅਨੁਕੂਲਿਤ ਦਾ ਮਤਲਬ ਹੈ ਕਿ ਚਿੱਤਰ:

• ਸਿਰਫ ਇੱਕ ਐਪਲੀਕੇਸ਼ਨ ਸ਼ਾਮਲ ਕਰੋ ਜਾਂ ਸਿਰਫ ਇੱਕ ਫੰਕਸ਼ਨ ਕਰੋ;

• ਆਕਾਰ ਵਿਚ ਛੋਟਾ, ਕਿਉਂਕਿ ਵੱਡੀਆਂ ਤਸਵੀਰਾਂ ਨੈੱਟਵਰਕ 'ਤੇ ਬਦਤਰ ਪ੍ਰਸਾਰਿਤ ਹੁੰਦੀਆਂ ਹਨ;

• ਸਿਹਤ ਅਤੇ ਤਿਆਰੀ ਦੇ ਅੰਤ ਬਿੰਦੂ ਹਨ ਜੋ ਕੁਬਰਨੇਟਸ ਨੂੰ ਡਾਊਨਟਾਈਮ ਦੀ ਸਥਿਤੀ ਵਿੱਚ ਕਾਰਵਾਈ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦੇ ਹਨ;

• ਕੰਟੇਨਰ-ਅਨੁਕੂਲ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮਾਂ ਦੀ ਵਰਤੋਂ ਕਰੋ (ਜਿਵੇਂ ਕਿ ਐਲਪਾਈਨ ਜਾਂ CoreOS), ਜੋ ਕਿ ਕੌਂਫਿਗਰੇਸ਼ਨ ਗਲਤੀਆਂ ਪ੍ਰਤੀ ਵਧੇਰੇ ਰੋਧਕ ਹਨ;

• ਮਲਟੀ-ਸਟੇਜ ਬਿਲਡਸ ਦੀ ਵਰਤੋਂ ਕਰੋ ਤਾਂ ਜੋ ਤੁਸੀਂ ਸਿਰਫ ਕੰਪਾਇਲ ਕੀਤੀਆਂ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਲਾਗੂ ਕਰ ਸਕੋ ਨਾ ਕਿ ਨਾਲ ਵਾਲੇ ਸਰੋਤਾਂ ਨੂੰ।

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

1. ਪੂਰੇ ਕਲੱਸਟਰ 'ਤੇ ਘਟਾਇਆ ਨੈੱਟਵਰਕ ਲੋਡ।

2. ਕੰਟੇਨਰ ਸ਼ੁਰੂ ਹੋਣ ਦਾ ਸਮਾਂ ਘਟਾਉਣਾ।

3. ਤੁਹਾਡੀ ਪੂਰੀ ਡੌਕਰ ਰਜਿਸਟਰੀ ਦਾ ਛੋਟਾ ਆਕਾਰ।

4. DNS ਕੈਸ਼ ਦੀ ਵਰਤੋਂ ਕਰੋ

ਜੇ ਅਸੀਂ ਉੱਚ ਲੋਡਾਂ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਕਲੱਸਟਰ ਦੇ DNS ਸਿਸਟਮ ਨੂੰ ਟਿਊਨ ਕੀਤੇ ਬਿਨਾਂ ਜੀਵਨ ਬਹੁਤ ਘਟੀਆ ਹੈ. ਇੱਕ ਵਾਰ, Kubernetes ਡਿਵੈਲਪਰਾਂ ਨੇ ਆਪਣੇ kube-dns ਹੱਲ ਦਾ ਸਮਰਥਨ ਕੀਤਾ। ਇਸ ਨੂੰ ਇੱਥੇ ਵੀ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਸੀ, ਪਰ ਇਹ ਸਾਫਟਵੇਅਰ ਖਾਸ ਤੌਰ 'ਤੇ ਟਿਊਨ ਨਹੀਂ ਕੀਤਾ ਗਿਆ ਸੀ ਅਤੇ ਲੋੜੀਂਦੀ ਕਾਰਗੁਜ਼ਾਰੀ ਪੈਦਾ ਨਹੀਂ ਕਰ ਸਕਿਆ ਸੀ, ਹਾਲਾਂਕਿ ਇਹ ਇੱਕ ਸਧਾਰਨ ਕੰਮ ਜਾਪਦਾ ਸੀ। ਫਿਰ ਕੋਰਡਨ ਦਿਖਾਈ ਦਿੱਤੇ, ਜਿਸ ਨੂੰ ਅਸੀਂ ਬਦਲਿਆ ਅਤੇ ਕੋਈ ਦੁੱਖ ਨਹੀਂ ਸੀ; ਇਹ ਬਾਅਦ ਵਿੱਚ K8s ਵਿੱਚ ਡਿਫਾਲਟ DNS ਸੇਵਾ ਬਣ ਗਈ। ਕਿਸੇ ਸਮੇਂ, ਅਸੀਂ DNS ਸਿਸਟਮ ਲਈ 40 ਹਜ਼ਾਰ ਆਰਪੀਐਸ ਤੱਕ ਵਧ ਗਏ, ਅਤੇ ਇਹ ਹੱਲ ਵੀ ਨਾਕਾਫ਼ੀ ਹੋ ਗਿਆ। ਪਰ, ਕਿਸਮਤ ਨਾਲ, ਨੋਡੇਲੋਕਲਡਨਸ ਬਾਹਰ ਆਇਆ, ਉਰਫ ਨੋਡ ਲੋਕਲ ਕੈਸ਼, ਉਰਫ ਨੋਡਲੋਕਲ DNScache.

ਅਸੀਂ ਇਸਦੀ ਵਰਤੋਂ ਕਿਉਂ ਕਰਦੇ ਹਾਂ? ਲੀਨਕਸ ਕਰਨਲ ਵਿੱਚ ਇੱਕ ਬੱਗ ਹੈ ਜੋ, ਜਦੋਂ UDP ਉੱਤੇ ਕਨਟਰੈਕ NAT ਰਾਹੀਂ ਕਈ ਕਾਲਾਂ ਹੁੰਦੀਆਂ ਹਨ, ਤਾਂ ਕੰਟਰੈਕ ਟੇਬਲ ਵਿੱਚ ਐਂਟਰੀਆਂ ਲਈ ਦੌੜ ਦੀ ਸਥਿਤੀ ਪੈਦਾ ਹੋ ਜਾਂਦੀ ਹੈ, ਅਤੇ NAT ਰਾਹੀਂ ਟ੍ਰੈਫਿਕ ਦਾ ਕੁਝ ਹਿੱਸਾ ਖਤਮ ਹੋ ਜਾਂਦਾ ਹੈ (ਸੇਵਾ ਰਾਹੀਂ ਹਰੇਕ ਯਾਤਰਾ NAT ਹੁੰਦੀ ਹੈ)। Nodelocaldns NAT ਤੋਂ ਛੁਟਕਾਰਾ ਪਾ ਕੇ ਅਤੇ TCP ਨੂੰ ਅੱਪਸਟ੍ਰੀਮ DNS ਨਾਲ ਕਨੈਕਸ਼ਨ ਨੂੰ ਅੱਪਗ੍ਰੇਡ ਕਰਕੇ, ਨਾਲ ਹੀ ਸਥਾਨਕ ਤੌਰ 'ਤੇ ਅੱਪਸਟ੍ਰੀਮ DNS ਸਵਾਲਾਂ (ਇੱਕ ਛੋਟਾ 5-ਸਕਿੰਟ ਨੈਗੇਟਿਵ ਕੈਸ਼ ਸਮੇਤ) ਨੂੰ ਕੈਚ ਕਰਕੇ ਇਸ ਸਮੱਸਿਆ ਦਾ ਹੱਲ ਕਰਦਾ ਹੈ।

5. ਪੌਡਾਂ ਨੂੰ ਖਿਤਿਜੀ ਅਤੇ ਲੰਬਕਾਰੀ ਤੌਰ 'ਤੇ ਆਪਣੇ ਆਪ ਸਕੇਲ ਕਰੋ

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

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

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 ਤੋਂ ਲਿਆ ਗਿਆ ਚਿੱਤਰ

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

ਉਦਾਹਰਨ ਲਈ, ਇੱਥੇ ਆਮ ਪੌਡ ਸੈਟਿੰਗਾਂ ਹਨ:

resources:
   requests:
     memory: 250Mi
     cpu: 200m
   limits:
     memory: 500Mi
     cpu: 350m

ਸਿਫ਼ਾਰਿਸ਼ ਇੰਜਣ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਤੁਹਾਡੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਸਹੀ ਢੰਗ ਨਾਲ ਚੱਲਣ ਲਈ 300m CPU ਅਤੇ 500Mi ਦੀ ਲੋੜ ਹੈ। ਤੁਹਾਨੂੰ ਹੇਠ ਲਿਖੀਆਂ ਸੈਟਿੰਗਾਂ ਮਿਲਣਗੀਆਂ:

resources:
   requests:
     memory: 500Mi
     cpu: 300m
   limits:
     memory: 1000Mi
     cpu: 525m

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਇਹ ਮੈਨੀਫੈਸਟ ਵਿੱਚ ਬੇਨਤੀਆਂ/ਸੀਮਾ ਅਨੁਪਾਤ ਦੇ ਅਧਾਰ ਤੇ ਅਨੁਪਾਤਕ ਸਕੇਲਿੰਗ ਹੈ:

• CPU: 200m → 300m: ਅਨੁਪਾਤ 1:1.75;

• ਮੈਮੋਰੀ: 250Mi → 500Mi: ਅਨੁਪਾਤ 1:2।

ਦੇ ਸੰਬੰਧ ਵਿਚ HPA, ਫਿਰ ਕਾਰਵਾਈ ਦੀ ਵਿਧੀ ਵਧੇਰੇ ਪਾਰਦਰਸ਼ੀ ਹੈ. ਮੈਟ੍ਰਿਕਸ ਜਿਵੇਂ ਕਿ CPU ਅਤੇ ਮੈਮੋਰੀ ਨੂੰ ਥ੍ਰੈਸ਼ਹੋਲਡ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਅਤੇ ਜੇਕਰ ਸਾਰੀਆਂ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਔਸਤ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਵੱਧ ਜਾਂਦੀ ਹੈ, ਤਾਂ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ +1 ਸਬ ਦੁਆਰਾ ਸਕੇਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਦੋਂ ਤੱਕ ਮੁੱਲ ਥ੍ਰੈਸ਼ਹੋਲਡ ਤੋਂ ਹੇਠਾਂ ਨਹੀਂ ਆਉਂਦਾ ਜਾਂ ਜਦੋਂ ਤੱਕ ਪ੍ਰਤੀਕ੍ਰਿਤੀਆਂ ਦੀ ਅਧਿਕਤਮ ਸੰਖਿਆ ਤੱਕ ਨਹੀਂ ਪਹੁੰਚ ਜਾਂਦੀ।

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 ਤੋਂ ਲਿਆ ਗਿਆ ਚਿੱਤਰ

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

6. ਨੋਡ ਐਫੀਨਿਟੀ ਅਤੇ ਪੋਡ ਐਫੀਨਿਟੀ ਬਾਰੇ ਨਾ ਭੁੱਲੋ

ਸਾਰੇ ਨੋਡ ਇੱਕੋ ਹਾਰਡਵੇਅਰ 'ਤੇ ਨਹੀਂ ਚੱਲਦੇ, ਅਤੇ ਸਾਰੇ ਪੌਡਾਂ ਨੂੰ ਕੰਪਿਊਟ-ਇੰਟੈਂਸਿਵ ਐਪਲੀਕੇਸ਼ਨ ਚਲਾਉਣ ਦੀ ਲੋੜ ਨਹੀਂ ਹੁੰਦੀ। ਕੁਬਰਨੇਟਸ ਤੁਹਾਨੂੰ ਨੋਡਸ ਅਤੇ ਪੌਡਸ ਦੀ ਵਿਸ਼ੇਸ਼ਤਾ ਨੂੰ ਸੈਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ ਨੋਡ ਐਫੀਨਿਟੀ и ਪੌਡ ਐਫੀਨਿਟੀ.

ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਨੋਡਸ ਹਨ ਜੋ ਗਣਨਾ-ਇੰਟੈਂਸਿਵ ਓਪਰੇਸ਼ਨਾਂ ਲਈ ਢੁਕਵੇਂ ਹਨ, ਤਾਂ ਵੱਧ ਤੋਂ ਵੱਧ ਕੁਸ਼ਲਤਾ ਲਈ ਐਪਲੀਕੇਸ਼ਨਾਂ ਨੂੰ ਸੰਬੰਧਿਤ ਨੋਡਾਂ ਨਾਲ ਜੋੜਨਾ ਬਿਹਤਰ ਹੈ. ਇਸ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ nodeSelector ਇੱਕ ਨੋਡ ਲੇਬਲ ਦੇ ਨਾਲ.

ਮੰਨ ਲਓ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਦੋ ਨੋਡ ਹਨ: ਇੱਕ ਨਾਲ CPUType=HIGHFREQ ਅਤੇ ਤੇਜ਼ ਕੋਰ ਦੀ ਇੱਕ ਵੱਡੀ ਗਿਣਤੀ, ਇੱਕ ਹੋਰ ਨਾਲ MemoryType=HIGHMEMORY ਵਧੇਰੇ ਮੈਮੋਰੀ ਅਤੇ ਤੇਜ਼ ਪ੍ਰਦਰਸ਼ਨ. ਨੋਡ ਨੂੰ ਤੈਨਾਤੀ ਨਿਰਧਾਰਤ ਕਰਨਾ ਸਭ ਤੋਂ ਆਸਾਨ ਤਰੀਕਾ ਹੈ HIGHFREQਭਾਗ ਵਿੱਚ ਜੋੜ ਕੇ spec ਇਹ ਚੋਣਕਾਰ:

…
nodeSelector:
	CPUType: HIGHFREQ

ਅਜਿਹਾ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਮਹਿੰਗਾ ਅਤੇ ਖਾਸ ਤਰੀਕਾ ਹੈ ਵਰਤਣਾ nodeAffinity ਖੇਤਰ ਵਿਚ affinity ਅਨੁਭਾਗ spec. ਦੋ ਵਿਕਲਪ ਹਨ:

• requiredDuringSchedulingIgnoredDuringExecution: ਹਾਰਡ ਸੈਟਿੰਗ (ਸ਼ਡਿਊਲਰ ਸਿਰਫ ਖਾਸ ਨੋਡਾਂ (ਅਤੇ ਹੋਰ ਕਿਤੇ ਨਹੀਂ) 'ਤੇ ਪੌਡਾਂ ਨੂੰ ਤਾਇਨਾਤ ਕਰੇਗਾ);

• preferredDuringSchedulingIgnoredDuringExecution: ਸਾਫਟ ਸੈਟਿੰਗ (ਸ਼ਡਿਊਲਰ ਖਾਸ ਨੋਡਾਂ 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ, ਅਤੇ ਜੇਕਰ ਇਹ ਅਸਫਲ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਇਹ ਅਗਲੇ ਉਪਲਬਧ ਨੋਡ 'ਤੇ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ)।

ਤੁਸੀਂ ਨੋਡ ਲੇਬਲ ਦੇ ਪ੍ਰਬੰਧਨ ਲਈ ਇੱਕ ਖਾਸ ਸੰਟੈਕਸ ਨਿਰਧਾਰਤ ਕਰ ਸਕਦੇ ਹੋ, ਜਿਵੇਂ ਕਿ In, NotIn, Exists, DoesNotExist, Gt ਜ Lt. ਹਾਲਾਂਕਿ, ਯਾਦ ਰੱਖੋ ਕਿ ਲੇਬਲਾਂ ਦੀਆਂ ਲੰਬੀਆਂ ਸੂਚੀਆਂ ਵਿੱਚ ਗੁੰਝਲਦਾਰ ਵਿਧੀਆਂ ਗੰਭੀਰ ਸਥਿਤੀਆਂ ਵਿੱਚ ਫੈਸਲੇ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਹੌਲੀ ਕਰ ਦੇਣਗੀਆਂ। ਦੂਜੇ ਸ਼ਬਦਾਂ ਵਿੱਚ, ਇਸਨੂੰ ਸਧਾਰਨ ਰੱਖੋ.

ਜਿਵੇਂ ਕਿ ਉੱਪਰ ਦੱਸਿਆ ਗਿਆ ਹੈ, ਕੁਬਰਨੇਟਸ ਤੁਹਾਨੂੰ ਮੌਜੂਦਾ ਪੌਡਾਂ ਦੀ ਸਾਂਝ ਨੂੰ ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ। ਭਾਵ, ਤੁਸੀਂ ਕੁਝ ਪੌਡਾਂ ਨੂੰ ਉਸੇ ਉਪਲਬਧਤਾ ਜ਼ੋਨ (ਕਲਾਊਡਜ਼ ਲਈ ਢੁਕਵੇਂ) ਜਾਂ ਨੋਡਾਂ ਵਿੱਚ ਦੂਜੇ ਪੌਡਾਂ ਨਾਲ ਮਿਲ ਕੇ ਕੰਮ ਕਰ ਸਕਦੇ ਹੋ।

В podAffinity ਖੇਤਰ affinity ਅਨੁਭਾਗ spec ਦੇ ਮਾਮਲੇ ਵਿੱਚ ਉਹੀ ਖੇਤਰ ਉਪਲਬਧ ਹਨ nodeAffinity: requiredDuringSchedulingIgnoredDuringExecution и preferredDuringSchedulingIgnoredDuringExecution. ਫਰਕ ਸਿਰਫ ਇਹ ਹੈ ਕਿ matchExpressions ਪੌਡਸ ਨੂੰ ਇੱਕ ਨੋਡ ਨਾਲ ਬੰਨ੍ਹੇਗਾ ਜੋ ਪਹਿਲਾਂ ਹੀ ਉਸ ਲੇਬਲ ਨਾਲ ਇੱਕ ਪੌਡ ਚਲਾ ਰਿਹਾ ਹੈ।

Kubernetes ਵੀ ਇੱਕ ਖੇਤਰ ਦੀ ਪੇਸ਼ਕਸ਼ ਕਰਦਾ ਹੈ podAntiAffinity, ਜੋ, ਇਸਦੇ ਉਲਟ, ਪੌਡ ਨੂੰ ਖਾਸ ਪੌਡਾਂ ਦੇ ਨਾਲ ਇੱਕ ਨੋਡ ਨਾਲ ਨਹੀਂ ਜੋੜਦਾ ਹੈ।

ਸਮੀਕਰਨ ਬਾਰੇ nodeAffinity ਇਹੀ ਸਲਾਹ ਦਿੱਤੀ ਜਾ ਸਕਦੀ ਹੈ: ਨਿਯਮਾਂ ਨੂੰ ਸਰਲ ਅਤੇ ਤਰਕਪੂਰਨ ਰੱਖਣ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋ, ਨਿਯਮਾਂ ਦੇ ਇੱਕ ਗੁੰਝਲਦਾਰ ਸਮੂਹ ਦੇ ਨਾਲ ਪੌਡ ਨਿਰਧਾਰਨ ਨੂੰ ਓਵਰਲੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਨਾ ਕਰੋ। ਇੱਕ ਨਿਯਮ ਬਣਾਉਣਾ ਬਹੁਤ ਆਸਾਨ ਹੈ ਜੋ ਕਲੱਸਟਰ ਦੀਆਂ ਸਥਿਤੀਆਂ ਨਾਲ ਮੇਲ ਨਹੀਂ ਖਾਂਦਾ, ਸ਼ਡਿਊਲਰ 'ਤੇ ਬੇਲੋੜਾ ਲੋਡ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਸਮੁੱਚੀ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਘਟਾਉਂਦਾ ਹੈ.

7. ਦਾਗ਼ ਅਤੇ ਸਹਿਣਸ਼ੀਲਤਾ

ਸ਼ਡਿਊਲਰ ਦਾ ਪ੍ਰਬੰਧਨ ਕਰਨ ਦਾ ਇੱਕ ਹੋਰ ਤਰੀਕਾ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਸੈਂਕੜੇ ਨੋਡਾਂ ਅਤੇ ਹਜ਼ਾਰਾਂ ਮਾਈਕ੍ਰੋਸਰਵਿਸਿਜ਼ ਦੇ ਨਾਲ ਇੱਕ ਵੱਡਾ ਕਲੱਸਟਰ ਹੈ, ਤਾਂ ਕੁਝ ਨੋਡਾਂ 'ਤੇ ਕੁਝ ਪੌਡਾਂ ਨੂੰ ਹੋਸਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਨਾ ਦੇਣਾ ਬਹੁਤ ਮੁਸ਼ਕਲ ਹੈ।

ਦਾਗ਼ਾਂ ਦੀ ਵਿਧੀ - ਮਨਾਹੀ ਦੇ ਨਿਯਮ - ਇਸ ਵਿੱਚ ਮਦਦ ਕਰਦੇ ਹਨ। ਉਦਾਹਰਨ ਲਈ, ਕੁਝ ਸਥਿਤੀਆਂ ਵਿੱਚ ਤੁਸੀਂ ਕੁਝ ਨੋਡਾਂ ਨੂੰ ਪੌਡ ਚਲਾਉਣ ਤੋਂ ਮਨ੍ਹਾ ਕਰ ਸਕਦੇ ਹੋ। ਕਿਸੇ ਖਾਸ ਨੋਡ 'ਤੇ ਦਾਗ ਲਗਾਉਣ ਲਈ ਤੁਹਾਨੂੰ ਵਿਕਲਪ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ taint kubectl ਵਿੱਚ. ਕੁੰਜੀ ਅਤੇ ਮੁੱਲ ਨਿਰਧਾਰਤ ਕਰੋ ਅਤੇ ਫਿਰ ਇਸ ਤਰ੍ਹਾਂ ਦਾਗ ਕਰੋ NoSchedule ਜ NoExecute:

$ kubectl taint nodes node10 node-role.kubernetes.io/ingress=true:NoSchedule

ਇਹ ਵੀ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੈ ਕਿ ਰੰਗਤ ਵਿਧੀ ਤਿੰਨ ਮੁੱਖ ਪ੍ਰਭਾਵਾਂ ਦਾ ਸਮਰਥਨ ਕਰਦੀ ਹੈ: NoSchedule, NoExecute и PreferNoSchedule.

• NoSchedule ਮਤਲਬ ਕਿ ਹੁਣ ਲਈ ਪੌਡ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਵਿੱਚ ਕੋਈ ਅਨੁਸਾਰੀ ਐਂਟਰੀ ਨਹੀਂ ਹੋਵੇਗੀ tolerations, ਇਹ ਨੋਡ 'ਤੇ ਤੈਨਾਤ ਕਰਨ ਦੇ ਯੋਗ ਨਹੀਂ ਹੋਵੇਗਾ (ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ node10).

• PreferNoSchedule - ਸਰਲ ਸੰਸਕਰਣ NoSchedule. ਇਸ ਸਥਿਤੀ ਵਿੱਚ, ਸ਼ਡਿਊਲਰ ਉਹਨਾਂ ਪੌਡਾਂ ਨੂੰ ਅਲਾਟ ਨਾ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ ਜਿਹਨਾਂ ਵਿੱਚ ਮੇਲ ਖਾਂਦੀ ਐਂਟਰੀ ਨਹੀਂ ਹੈ tolerations ਪ੍ਰਤੀ ਨੋਡ, ਪਰ ਇਹ ਇੱਕ ਸਖ਼ਤ ਸੀਮਾ ਨਹੀਂ ਹੈ। ਜੇਕਰ ਕਲੱਸਟਰ ਵਿੱਚ ਕੋਈ ਸਰੋਤ ਨਹੀਂ ਹਨ, ਤਾਂ ਪੌਡ ਇਸ ਨੋਡ 'ਤੇ ਤਾਇਨਾਤ ਹੋਣੇ ਸ਼ੁਰੂ ਹੋ ਜਾਣਗੇ।

• NoExecute - ਇਹ ਪ੍ਰਭਾਵ ਉਹਨਾਂ ਪੌਡਾਂ ਦੇ ਤੁਰੰਤ ਨਿਕਾਸੀ ਨੂੰ ਚਾਲੂ ਕਰਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਵਿੱਚ ਕੋਈ ਅਨੁਸਾਰੀ ਐਂਟਰੀ ਨਹੀਂ ਹੈ tolerations.

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

ਇੱਥੇ ਇਹ ਹੈ ਕਿ ਪੌਡ ਸਪੈਸੀਫਿਕੇਸ਼ਨ ਕਿਸ ਤਰ੍ਹਾਂ ਦਾ ਦਿਖਾਈ ਦੇਵੇਗਾ:

spec:
   tolerations:
     - key: "node-role.kubernetes.io/ingress"
        operator: "Equal"
        value: "true"
        effect: "NoSchedule"

ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਹੈ ਕਿ ਅਗਲਾ ਰੀਡੈਪਲਾਇ ਇਸ ਖਾਸ ਨੋਡ 'ਤੇ ਆਵੇਗਾ, ਇਹ ਨੋਡ ਐਫੀਨਿਟੀ ਵਿਧੀ ਨਹੀਂ ਹੈ ਅਤੇ nodeSelector. ਪਰ ਕਈ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਨੂੰ ਜੋੜ ਕੇ, ਤੁਸੀਂ ਬਹੁਤ ਲਚਕਦਾਰ ਸ਼ਡਿਊਲਰ ਸੈਟਿੰਗਾਂ ਨੂੰ ਪ੍ਰਾਪਤ ਕਰ ਸਕਦੇ ਹੋ।

8. ਪੌਡ ਤੈਨਾਤੀ ਤਰਜੀਹ ਸੈੱਟ ਕਰੋ

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

ਕੁਬਰਨੇਟਸ ਪੌਡ ਪ੍ਰਾਥਮਿਕਤਾ ਅਤੇ ਪ੍ਰੀਮਪਸ਼ਨ ਨੂੰ ਕੌਂਫਿਗਰ ਕਰਨ ਦੇ ਵੱਖ-ਵੱਖ ਤਰੀਕੇ ਪੇਸ਼ ਕਰਦਾ ਹੈ। ਸੈਟਿੰਗ ਵਿੱਚ ਕਈ ਭਾਗ ਹੁੰਦੇ ਹਨ: ਵਸਤੂ PriorityClass ਅਤੇ ਖੇਤਰ ਦੇ ਵਰਣਨ priorityClassName ਪੌਡ ਨਿਰਧਾਰਨ ਵਿੱਚ. ਆਓ ਇੱਕ ਉਦਾਹਰਨ ਵੇਖੀਏ:

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: high-priority
value: 99999
globalDefault: false
description: "This priority class should be used for very important pods only"

ਅਸੀਂ ਬਣਾਉਂਦੇ ਹਾਂ PriorityClass, ਇਸਨੂੰ ਇੱਕ ਨਾਮ, ਵਰਣਨ ਅਤੇ ਮੁੱਲ ਦਿਓ। ਉੱਚਾ value, ਤਰਜੀਹ ਜਿੰਨੀ ਉੱਚੀ ਹੋਵੇਗੀ। ਮੁੱਲ 32 ਤੋਂ ਘੱਟ ਜਾਂ ਇਸ ਦੇ ਬਰਾਬਰ ਕੋਈ ਵੀ 1-ਬਿੱਟ ਪੂਰਨ ਅੰਕ ਹੋ ਸਕਦਾ ਹੈ। ਉੱਚੇ ਮੁੱਲ ਮਿਸ਼ਨ-ਨਾਜ਼ੁਕ ਸਿਸਟਮ ਪੌਡਾਂ ਲਈ ਰਾਖਵੇਂ ਹਨ ਜਿਨ੍ਹਾਂ ਨੂੰ ਆਮ ਤੌਰ 'ਤੇ ਪ੍ਰੀਮੇਂਟ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ। ਵਿਸਥਾਪਨ ਤਾਂ ਹੀ ਹੋਵੇਗਾ ਜੇਕਰ ਇੱਕ ਉੱਚ-ਪ੍ਰਾਥਮਿਕਤਾ ਵਾਲੇ ਪੌਡ ਨੂੰ ਮੋੜਨ ਲਈ ਕੋਈ ਥਾਂ ਨਹੀਂ ਹੈ, ਤਾਂ ਇੱਕ ਖਾਸ ਨੋਡ ਤੋਂ ਕੁਝ ਪੌਡਾਂ ਨੂੰ ਬਾਹਰ ਕੱਢਿਆ ਜਾਵੇਗਾ। ਜੇ ਇਹ ਵਿਧੀ ਤੁਹਾਡੇ ਲਈ ਬਹੁਤ ਸਖ਼ਤ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਵਿਕਲਪ ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ preemptionPolicy: Never, ਅਤੇ ਫਿਰ ਕੋਈ ਪ੍ਰੈਮਪਸ਼ਨ ਨਹੀਂ ਹੋਵੇਗਾ, ਪੌਡ ਕਤਾਰ ਵਿੱਚ ਪਹਿਲਾਂ ਖੜ੍ਹਾ ਹੋਵੇਗਾ ਅਤੇ ਇਸਦੇ ਲਈ ਮੁਫਤ ਸਰੋਤ ਲੱਭਣ ਲਈ ਸ਼ਡਿਊਲਰ ਦੀ ਉਡੀਕ ਕਰੇਗਾ।

ਅੱਗੇ, ਅਸੀਂ ਇੱਕ ਪੋਡ ਬਣਾਉਂਦੇ ਹਾਂ ਜਿਸ ਵਿੱਚ ਅਸੀਂ ਨਾਮ ਦਰਸਾਉਂਦੇ ਹਾਂ priorityClassName:

apiVersion: v1
kind: Pod
metadata:
  name: static-web
  labels:
    role: myrole
 spec:
  containers:
    - name: web
      image: nginx
      ports:
        - name: web
          containerPort: 80
          protocol: TCP
  priorityClassName: high-priority
          

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

ਇਸ ਤਰ੍ਹਾਂ, ਜੇ ਜਰੂਰੀ ਹੋਵੇ, ਤੁਸੀਂ ਨਾਜ਼ੁਕ ਸੇਵਾਵਾਂ ਜਿਵੇਂ ਕਿ nginx-ingress-controller, coredns, ਆਦਿ ਨੂੰ ਤਾਇਨਾਤ ਕਰਨ ਦੀ ਕੁਸ਼ਲਤਾ ਵਧਾ ਸਕਦੇ ਹੋ।

9. ETCD ਕਲੱਸਟਰ ਨੂੰ ਅਨੁਕੂਲ ਬਣਾਓ

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

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

ਜੇ ਅਸੀਂ ਸੇਵਾ ਸਥਾਪਤ ਕਰਨ ਬਾਰੇ ਗੱਲ ਕਰਦੇ ਹਾਂ, ਤਾਂ ਇੱਥੇ ਕੁਝ ਸਿਫ਼ਾਰਸ਼ਾਂ ਹਨ:

1. ਕਲੱਸਟਰ ਦੇ ਆਕਾਰ ਦੇ ਆਧਾਰ 'ਤੇ ਵਧੀਆ ਹਾਰਡਵੇਅਰ ਰੱਖੋ (ਤੁਸੀਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ).

2. ਕੁਝ ਮਾਪਦੰਡਾਂ ਨੂੰ ਟਵੀਕ ਕਰੋ ਜੇਕਰ ਤੁਸੀਂ DCs ਜਾਂ ਤੁਹਾਡੇ ਨੈੱਟਵਰਕ ਦੇ ਵਿਚਕਾਰ ਇੱਕ ਕਲੱਸਟਰ ਫੈਲਾਇਆ ਹੈ ਅਤੇ ਡਿਸਕਾਂ ਨੂੰ ਲੋੜੀਂਦਾ ਬਹੁਤ ਕੁਝ ਛੱਡ ਦਿੱਤਾ ਹੈ (ਤੁਸੀਂ ਪੜ੍ਹ ਸਕਦੇ ਹੋ ਇੱਥੇ).

ਸਿੱਟਾ

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

ਸਰੋਤ: www.habr.com