ಒಂಬತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕಾರ್ಯಕ್ಷಮತೆ ಸಲಹೆಗಳು

ಎಲ್ಲರಿಗು ನಮಸ್ಖರ! ನನ್ನ ಹೆಸರು ಒಲೆಗ್ ಸಿಡೊರೆಂಕೋವ್, ನಾನು ಮೂಲಸೌಕರ್ಯ ತಂಡದ ಮುಖ್ಯಸ್ಥನಾಗಿ ಡೊಮ್‌ಕ್ಲಿಕ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತೇನೆ. ನಾವು ಮೂರು ವರ್ಷಗಳಿಗೂ ಹೆಚ್ಚು ಕಾಲ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕುಬಿಕ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಅದರೊಂದಿಗೆ ಹಲವು ವಿಭಿನ್ನ ಆಸಕ್ತಿದಾಯಕ ಕ್ಷಣಗಳನ್ನು ಅನುಭವಿಸಿದ್ದೇವೆ. ಸರಿಯಾದ ವಿಧಾನದೊಂದಿಗೆ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ವೆನಿಲ್ಲಾ ಕುಬರ್ನೆಟ್ಸ್‌ನಿಂದ ನೀವು ಇನ್ನಷ್ಟು ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹೇಗೆ ಹಿಂಡಬಹುದು ಎಂಬುದನ್ನು ಇಂದು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ. ಸಿದ್ದವಾಗಿ ಸ್ಥಿರವಾಗಿ ಹೋಗಿ!

ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟೇನರ್ ಆರ್ಕೆಸ್ಟ್ರೇಶನ್‌ಗಾಗಿ ಸ್ಕೇಲೆಬಲ್ ಓಪನ್ ಸೋರ್ಸ್ ಸಿಸ್ಟಮ್ ಎಂದು ನಿಮಗೆಲ್ಲರಿಗೂ ಚೆನ್ನಾಗಿ ತಿಳಿದಿದೆ; ಸರಿ, ಅಥವಾ ಸರ್ವರ್ ಪರಿಸರದಲ್ಲಿ ನಿಮ್ಮ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಜೀವನ ಚಕ್ರವನ್ನು ನಿರ್ವಹಿಸುವ ಮೂಲಕ ಮ್ಯಾಜಿಕ್ ಕೆಲಸ ಮಾಡುವ 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, ops ತಂಡವು ಮತ್ತೊಂದು 10 cpu ಅನ್ನು ಸೇವಿಸುವ ಪಾಡ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು ಬಯಸಿದರೆ, ಶೆಡ್ಯೂಲರ್ ಇದನ್ನು ಅನುಮತಿಸುವುದಿಲ್ಲ ಮತ್ತು ದೋಷವನ್ನು ಎಸೆಯುತ್ತಾರೆ:

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. ಸೂಕ್ತವಾದ ಫೈಲ್ ಸಂಗ್ರಹಣೆಯನ್ನು ಆರಿಸಿ

ಇಲ್ಲಿ ನಾನು ನಿರಂತರ ಸಂಪುಟಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ವರ್ಕರ್ ನೋಡ್‌ಗಳ ಡಿಸ್ಕ್ ಉಪವ್ಯವಸ್ಥೆಯ ವಿಷಯದ ಮೇಲೆ ಸ್ಪರ್ಶಿಸಲು ಬಯಸುತ್ತೇನೆ. ಉತ್ಪಾದನೆಯಲ್ಲಿ HDD ಯಲ್ಲಿ ಯಾರೂ "ಕ್ಯೂಬ್" ಅನ್ನು ಬಳಸುವುದಿಲ್ಲ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ, ಆದರೆ ಕೆಲವೊಮ್ಮೆ ಸಾಮಾನ್ಯ SSD ಇನ್ನು ಮುಂದೆ ಸಾಕಾಗುವುದಿಲ್ಲ. I/O ಕಾರ್ಯಾಚರಣೆಗಳ ಕಾರಣದಿಂದಾಗಿ ಲಾಗ್‌ಗಳು ಡಿಸ್ಕ್ ಅನ್ನು ಕೊಲ್ಲುತ್ತಿರುವ ಸಮಸ್ಯೆಯನ್ನು ನಾವು ಎದುರಿಸಿದ್ದೇವೆ ಮತ್ತು ಹೆಚ್ಚಿನ ಪರಿಹಾರಗಳಿಲ್ಲ:

• ಹೆಚ್ಚಿನ ಕಾರ್ಯಕ್ಷಮತೆಯ SSD ಗಳನ್ನು ಬಳಸಿ ಅಥವಾ NVMe ಗೆ ಬದಲಿಸಿ (ನೀವು ನಿಮ್ಮ ಸ್ವಂತ ಯಂತ್ರಾಂಶವನ್ನು ನಿರ್ವಹಿಸಿದರೆ).

• ಲಾಗಿಂಗ್ ಮಟ್ಟವನ್ನು ಕಡಿಮೆ ಮಾಡಿ.

• ಡಿಸ್ಕ್ ಅನ್ನು ಅತ್ಯಾಚಾರ ಮಾಡುವ ಪಾಡ್‌ಗಳ "ಸ್ಮಾರ್ಟ್" ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮಾಡಿ (podAntiAffinity).

Access_logs ಲಾಗಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿದಾಗ ಡಿಸ್ಕ್‌ಗೆ nginx-ingress-controller ಅಡಿಯಲ್ಲಿ ಏನಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ಮೇಲಿನ ಪರದೆಯು ತೋರಿಸುತ್ತದೆ (~12 ಸಾವಿರ ಲಾಗ್‌ಗಳು/ಸೆಕೆಂಡು). ಈ ಸ್ಥಿತಿಯು ಸಹಜವಾಗಿ, ಈ ನೋಡ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅವನತಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ಪಿವಿ ಬಗ್ಗೆ, ಅಯ್ಯೋ, ನಾನು ಎಲ್ಲವನ್ನೂ ಪ್ರಯತ್ನಿಸಲಿಲ್ಲ ರೀತಿಯ ನಿರಂತರ ಸಂಪುಟಗಳು. ನಿಮಗೆ ಸೂಕ್ತವಾದ ಅತ್ಯುತ್ತಮ ಆಯ್ಕೆಯನ್ನು ಬಳಸಿ. ಐತಿಹಾಸಿಕವಾಗಿ, ಸೇವೆಗಳ ಒಂದು ಸಣ್ಣ ಭಾಗವು RWX ಸಂಪುಟಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ ಎಂದು ನಮ್ಮ ದೇಶದಲ್ಲಿ ಸಂಭವಿಸಿದೆ ಮತ್ತು ಬಹಳ ಹಿಂದೆಯೇ ಅವರು ಈ ಕಾರ್ಯಕ್ಕಾಗಿ NFS ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದರು. ಅಗ್ಗದ ಮತ್ತು ... ಸಾಕಷ್ಟು. ಸಹಜವಾಗಿ, ಅವನು ಮತ್ತು ನಾನು ಶಿಟ್ ತಿನ್ನುತ್ತಿದ್ದೆವು - ನಿಮ್ಮನ್ನು ಆಶೀರ್ವದಿಸಿ, ಆದರೆ ನಾವು ಅದನ್ನು ಟ್ಯೂನ್ ಮಾಡಲು ಕಲಿತಿದ್ದೇವೆ ಮತ್ತು ನನ್ನ ತಲೆ ಇನ್ನು ಮುಂದೆ ನೋಯಿಸುವುದಿಲ್ಲ. ಮತ್ತು ಸಾಧ್ಯವಾದರೆ, S3 ವಸ್ತು ಸಂಗ್ರಹಣೆಗೆ ಸರಿಸಿ.

3. ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಚಿತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ

ಕಂಟೇನರ್-ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿದ ಚಿತ್ರಗಳನ್ನು ಬಳಸುವುದು ಉತ್ತಮ, ಇದರಿಂದ ಕುಬರ್ನೆಟ್ಸ್ ಅವುಗಳನ್ನು ವೇಗವಾಗಿ ಪಡೆಯಬಹುದು ಮತ್ತು ಅವುಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. 

ಆಪ್ಟಿಮೈಸ್ಡ್ ಎಂದರೆ ಚಿತ್ರಗಳು:

• ಕೇವಲ ಒಂದು ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ ಅಥವಾ ಕೇವಲ ಒಂದು ಕಾರ್ಯವನ್ನು ನಿರ್ವಹಿಸಿ;

• ಗಾತ್ರದಲ್ಲಿ ಚಿಕ್ಕದಾಗಿದೆ, ಏಕೆಂದರೆ ದೊಡ್ಡ ಚಿತ್ರಗಳು ನೆಟ್ವರ್ಕ್ನಲ್ಲಿ ಕೆಟ್ಟದಾಗಿ ಹರಡುತ್ತವೆ;

• ಅಲಭ್ಯತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಲು ಅನುಮತಿಸುವ ಆರೋಗ್ಯ ಮತ್ತು ಸನ್ನದ್ಧತೆಯ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿರಿ;

• ಸಂರಚನಾ ದೋಷಗಳಿಗೆ ಹೆಚ್ಚು ನಿರೋಧಕವಾಗಿರುವ ಕಂಟೇನರ್-ಸ್ನೇಹಿ ಕಾರ್ಯಾಚರಣಾ ವ್ಯವಸ್ಥೆಗಳನ್ನು (Alpine ಅಥವಾ CoreOS ನಂತಹ) ಬಳಸಿ;

• ಬಹು-ಹಂತದ ನಿರ್ಮಾಣಗಳನ್ನು ಬಳಸಿ ಇದರಿಂದ ನೀವು ಸಂಕಲಿಸಿದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಮಾತ್ರ ನಿಯೋಜಿಸಬಹುದು ಮತ್ತು ಅದರ ಜೊತೆಗಿನ ಮೂಲಗಳನ್ನು ಅಲ್ಲ.

ಫ್ಲೈನಲ್ಲಿ ಚಿತ್ರಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಆಪ್ಟಿಮೈಜ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಹಲವು ಪರಿಕರಗಳು ಮತ್ತು ಸೇವೆಗಳಿವೆ. ಅವುಗಳನ್ನು ಯಾವಾಗಲೂ ನವೀಕೃತವಾಗಿರಿಸುವುದು ಮತ್ತು ಸುರಕ್ಷತೆಗಾಗಿ ಪರೀಕ್ಷಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಪರಿಣಾಮವಾಗಿ ನೀವು ಪಡೆಯುತ್ತೀರಿ:

1. ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಡಿಮೆಯಾದ ನೆಟ್‌ವರ್ಕ್ ಲೋಡ್.

2. ಕಂಟೇನರ್ ಪ್ರಾರಂಭದ ಸಮಯವನ್ನು ಕಡಿಮೆಗೊಳಿಸುವುದು.

3. ನಿಮ್ಮ ಸಂಪೂರ್ಣ ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯ ಚಿಕ್ಕ ಗಾತ್ರ.

4. DNS ಸಂಗ್ರಹವನ್ನು ಬಳಸಿ

ನಾವು ಹೆಚ್ಚಿನ ಹೊರೆಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ, ಕ್ಲಸ್ಟರ್ನ DNS ಸಿಸ್ಟಮ್ ಅನ್ನು ಟ್ಯೂನ್ ಮಾಡದೆಯೇ ಜೀವನವು ತುಂಬಾ ಕೊಳಕು. ಒಂದು ಕಾಲದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಡೆವಲಪರ್‌ಗಳು ತಮ್ಮ kube-dns ಪರಿಹಾರವನ್ನು ಬೆಂಬಲಿಸಿದರು. ಇದನ್ನು ಇಲ್ಲಿಯೂ ಅಳವಡಿಸಲಾಗಿದೆ, ಆದರೆ ಈ ಸಾಫ್ಟ್‌ವೇರ್ ನಿರ್ದಿಷ್ಟವಾಗಿ ಟ್ಯೂನ್ ಮಾಡಲಾಗಿಲ್ಲ ಮತ್ತು ಅಗತ್ಯವಿರುವ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಉತ್ಪಾದಿಸಲಿಲ್ಲ, ಆದರೂ ಇದು ಸರಳವಾದ ಕೆಲಸವೆಂದು ತೋರುತ್ತದೆ. ನಂತರ coredns ಕಾಣಿಸಿಕೊಂಡಿತು, ಅದನ್ನು ನಾವು ಬದಲಾಯಿಸಿದ್ದೇವೆ ಮತ್ತು ಯಾವುದೇ ದುಃಖವಿಲ್ಲ; ಅದು ನಂತರ K8 ಗಳಲ್ಲಿ ಡೀಫಾಲ್ಟ್ DNS ಸೇವೆಯಾಯಿತು. ಕೆಲವು ಹಂತದಲ್ಲಿ, ನಾವು DNS ಸಿಸ್ಟಮ್‌ಗೆ 40 ಸಾವಿರ ಆರ್‌ಪಿಎಸ್‌ಗೆ ಬೆಳೆದಿದ್ದೇವೆ ಮತ್ತು ಈ ಪರಿಹಾರವೂ ಸಾಕಷ್ಟಿಲ್ಲ. ಆದರೆ, ಅದೃಷ್ಟದಿಂದ, ನೋಡೆಲೋಕಾಲ್ಡ್ನ್ಸ್ ಹೊರಬಂದಿತು, ಅಕಾ ನೋಡ್ ಸ್ಥಳೀಯ ಸಂಗ್ರಹ, ಅಕಾ ನೋಡ್ಲೋಕಲ್ DNSCache.

ನಾವು ಇದನ್ನು ಏಕೆ ಬಳಸುತ್ತೇವೆ? Linux ಕರ್ನಲ್‌ನಲ್ಲಿ ದೋಷವಿದ್ದು, UDP ಮೂಲಕ ಕಾಂಟ್ರ್ಯಾಕ್ NAT ಮೂಲಕ ಅನೇಕ ಕರೆಗಳು, ಕಾಂಟ್ರ್ಯಾಕ್ ಕೋಷ್ಟಕಗಳಲ್ಲಿನ ನಮೂದುಗಳಿಗೆ ರೇಸ್ ಸ್ಥಿತಿಗೆ ಕಾರಣವಾದಾಗ, ಮತ್ತು NAT ಮೂಲಕ ಸಂಚಾರದ ಭಾಗವು ಕಳೆದುಹೋಗುತ್ತದೆ (ಸೇವೆಯ ಮೂಲಕ ಪ್ರತಿ ಟ್ರಿಪ್ NAT ಆಗಿದೆ). NAT ಅನ್ನು ತೊಡೆದುಹಾಕಲು ಮತ್ತು TCP ಗೆ ಸಂಪರ್ಕವನ್ನು ಅಪ್‌ಸ್ಟ್ರೀಮ್ DNS ಗೆ ಅಪ್‌ಗ್ರೇಡ್ ಮಾಡುವ ಮೂಲಕ Nodelocaldns ಈ ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ, ಹಾಗೆಯೇ ಸ್ಥಳೀಯವಾಗಿ ಅಪ್‌ಸ್ಟ್ರೀಮ್ DNS ಪ್ರಶ್ನೆಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುತ್ತದೆ (ಸಣ್ಣ 5-ಸೆಕೆಂಡ್ ಋಣಾತ್ಮಕ ಸಂಗ್ರಹವನ್ನು ಒಳಗೊಂಡಂತೆ).

5. ಪಾಡ್‌ಗಳನ್ನು ಅಡ್ಡಲಾಗಿ ಮತ್ತು ಲಂಬವಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಳೆಯಿರಿ

ನಿಮ್ಮ ಎಲ್ಲಾ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳು ಲೋಡ್‌ನಲ್ಲಿ ಎರಡರಿಂದ ಮೂರು ಪಟ್ಟು ಹೆಚ್ಚಳಕ್ಕೆ ಸಿದ್ಧವಾಗಿವೆ ಎಂದು ನೀವು ವಿಶ್ವಾಸದಿಂದ ಹೇಳಬಹುದೇ? ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸರಿಯಾಗಿ ನಿಯೋಜಿಸುವುದು ಹೇಗೆ? ಕೆಲಸದ ಹೊರೆಯನ್ನು ಮೀರಿ ಒಂದೆರಡು ಪಾಡ್‌ಗಳನ್ನು ಓಡಿಸುವುದು ಅನಗತ್ಯವಾಗಬಹುದು, ಆದರೆ ಅವುಗಳನ್ನು ಹಿಂದಕ್ಕೆ ಇಡುವುದರಿಂದ ಸೇವೆಗೆ ಹಠಾತ್ ಟ್ರಾಫಿಕ್ ಹೆಚ್ಚಳದಿಂದ ಅಲಭ್ಯತೆಯ ಅಪಾಯವಿದೆ. ಮುಂತಾದ ಸೇವೆಗಳು ಅಡ್ಡಲಾಗಿರುವ ಪಾಡ್ ಆಟೋಸ್ಕೇಲರ್ и ಲಂಬ ಪಾಡ್ ಆಟೋಸ್ಕೇಲರ್.

ವಿಪಿಎ ನಿಜವಾದ ಬಳಕೆಯನ್ನು ಅವಲಂಬಿಸಿ ನಿಮ್ಮ ಕಂಟೇನರ್‌ಗಳ ವಿನಂತಿಗಳು/ಮಿತಿಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇದು ಹೇಗೆ ಉಪಯುಕ್ತವಾಗಬಹುದು? ನೀವು ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಅಡ್ಡಲಾಗಿ ಅಳೆಯಲಾಗದ ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ (ಇದು ಸಂಪೂರ್ಣವಾಗಿ ವಿಶ್ವಾಸಾರ್ಹವಲ್ಲ), ನಂತರ ನೀವು ಅದರ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು 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.

ಸಂಬಂಧಿಸಿದಂತೆ ಎಚ್ಪಿಎ, ನಂತರ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯವಿಧಾನವು ಹೆಚ್ಚು ಪಾರದರ್ಶಕವಾಗಿರುತ್ತದೆ. CPU ಮತ್ತು ಮೆಮೊರಿಯಂತಹ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮಿತಿಗೊಳಿಸಲಾಗಿದೆ ಮತ್ತು ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳ ಸರಾಸರಿ ಮಿತಿಯನ್ನು ಮೀರಿದರೆ, ಮೌಲ್ಯವು ಮಿತಿಗಿಂತ ಕೆಳಗಿರುವವರೆಗೆ ಅಥವಾ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳನ್ನು ತಲುಪುವವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು +1 ಉಪದಿಂದ ಅಳೆಯಲಾಗುತ್ತದೆ.

https://levelup.gitconnected.com/kubernetes-autoscaling-101-cluster-autoscaler-horizontal-pod-autoscaler-and-vertical-pod-2a441d9ad231 ನಿಂದ ಚಿತ್ರ ತೆಗೆದುಕೊಳ್ಳಲಾಗಿದೆ

CPU ಮತ್ತು ಮೆಮೊರಿಯಂತಹ ಸಾಮಾನ್ಯ ಮೆಟ್ರಿಕ್‌ಗಳ ಜೊತೆಗೆ, ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಯಾವಾಗ ಅಳೆಯಬೇಕು ಎಂಬುದಕ್ಕೆ ಇದು ಅತ್ಯಂತ ನಿಖರವಾದ ಸೂಚನೆಯಾಗಿದೆ ಎಂದು ನೀವು ಭಾವಿಸಿದರೆ ನೀವು Prometheus ನಿಂದ ನಿಮ್ಮ ಕಸ್ಟಮ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಮೇಲೆ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಅವರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಬಹುದು. ಒಮ್ಮೆ ಅಪ್ಲಿಕೇಶನ್ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಮೆಟ್ರಿಕ್ ಥ್ರೆಶೋಲ್ಡ್‌ನ ಕೆಳಗೆ ಸ್ಥಿರಗೊಂಡರೆ, 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 ಪಾಡ್‌ಗಳನ್ನು ಆ ಲೇಬಲ್‌ನೊಂದಿಗೆ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ನೋಡ್‌ಗೆ ಬಂಧಿಸುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಸಹ ಕ್ಷೇತ್ರವನ್ನು ನೀಡುತ್ತದೆ 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. ನೀವು ಒಂದು ಜೋಡಿ DC ಗಳು ಅಥವಾ ನಿಮ್ಮ ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಡಿಸ್ಕ್‌ಗಳ ನಡುವೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹರಡಿದ್ದರೆ ಕೆಲವು ನಿಯತಾಂಕಗಳನ್ನು ಟ್ವೀಕ್ ಮಾಡಿ ಮತ್ತು ಡಿಸ್ಕ್‌ಗಳು ಅಪೇಕ್ಷಿತವಾಗಿರುವುದನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತವೆ (ನೀವು ಓದಬಹುದು ಇಲ್ಲಿ).

ತೀರ್ಮಾನಕ್ಕೆ

ಈ ಲೇಖನವು ನಮ್ಮ ತಂಡವು ಅನುಸರಿಸಲು ಪ್ರಯತ್ನಿಸುವ ಅಂಶಗಳನ್ನು ವಿವರಿಸುತ್ತದೆ. ಇದು ಕ್ರಿಯೆಗಳ ಹಂತ-ಹಂತದ ವಿವರಣೆಯಲ್ಲ, ಆದರೆ ಕ್ಲಸ್ಟರ್ ಓವರ್ಹೆಡ್ ಅನ್ನು ಅತ್ಯುತ್ತಮವಾಗಿಸಲು ಉಪಯುಕ್ತವಾದ ಆಯ್ಕೆಗಳು. ಪ್ರತಿಯೊಂದು ಕ್ಲಸ್ಟರ್ ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ವಿಶಿಷ್ಟವಾಗಿದೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಪರಿಹಾರಗಳು ಹೆಚ್ಚು ಬದಲಾಗಬಹುದು ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೀವು ಹೇಗೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಅದರ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ನೀವು ಹೇಗೆ ಸುಧಾರಿಸುತ್ತೀರಿ ಎಂಬುದರ ಕುರಿತು ನಿಮ್ಮ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಪಡೆಯುವುದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ. ಕಾಮೆಂಟ್ಗಳಲ್ಲಿ ನಿಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಿ, ತಿಳಿಯಲು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ.

ಮೂಲ: www.habr.com