ನಿಯಮದಂತೆ, ಅದರ ಸರಿಯಾದ ಮತ್ತು ಸ್ಥಿರ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳ ಮೀಸಲಾದ ಪೂಲ್ ಅನ್ನು ಯಾವಾಗಲೂ ಒದಗಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ. ಆದರೆ ಹಲವಾರು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಒಂದೇ ಶಕ್ತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೆ ಏನು? ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕನಿಷ್ಠ ಅಗತ್ಯ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಒದಗಿಸುವುದು? ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ನೀವು ಹೇಗೆ ಮಿತಿಗೊಳಿಸಬಹುದು? ನೋಡ್ಗಳ ನಡುವೆ ಲೋಡ್ ಅನ್ನು ಸರಿಯಾಗಿ ವಿತರಿಸುವುದು ಹೇಗೆ? ಅಪ್ಲಿಕೇಶನ್ ಲೋಡ್ ಹೆಚ್ಚಾದರೆ ಸಮತಲ ಸ್ಕೇಲಿಂಗ್ ಕಾರ್ಯವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಹೇಗೆ?
ಸಿಸ್ಟಮ್ನಲ್ಲಿ ಯಾವ ಮುಖ್ಯ ರೀತಿಯ ಸಂಪನ್ಮೂಲಗಳು ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ ಎಂಬುದನ್ನು ನೀವು ಪ್ರಾರಂಭಿಸಬೇಕು - ಇದು ಸಹಜವಾಗಿ, ಪ್ರೊಸೆಸರ್ ಸಮಯ ಮತ್ತು RAM ಆಗಿದೆ. 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 ಘಟಕವು ನೋಡ್ಗಳ ನಡುವೆ ಪಾಡ್‌ಗಳ ವಿತರಣೆಗೆ ಕಾರಣವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ವೇಳಾಪಟ್ಟಿ, ಇದು ನಿರ್ದಿಷ್ಟ ಅಲ್ಗಾರಿದಮ್ ಪ್ರಕಾರ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಪ್ರಾರಂಭಿಸಲು ಸೂಕ್ತವಾದ ನೋಡ್ ಅನ್ನು ಆಯ್ಕೆಮಾಡುವಾಗ ಈ ಅಲ್ಗಾರಿದಮ್ ಎರಡು ಹಂತಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ:
- ಶೋಧನೆ
- ರೇಂಜಿಂಗ್
ಆ. ವಿವರಿಸಿದ ನೀತಿಯ ಪ್ರಕಾರ, ನೋಡ್‌ಗಳನ್ನು ಆರಂಭದಲ್ಲಿ ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ, ಅದರ ಮೇಲೆ ಒಂದು ಸೆಟ್ ಅನ್ನು ಆಧರಿಸಿ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿದೆ ಊಹಿಸುತ್ತದೆ (ಪಾಡ್ - PodFitsResources ಅನ್ನು ಚಲಾಯಿಸಲು ನೋಡ್ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುವುದು ಸೇರಿದಂತೆ), ಮತ್ತು ನಂತರ ಈ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ಗಳಿಗೆ, ಪ್ರಕಾರ ಆದ್ಯತೆಗಳು ಅಂಕಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ (ಒಂದು ನೋಡ್ ಹೆಚ್ಚು ಉಚಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿದೆ, ಅದಕ್ಕೆ ಹೆಚ್ಚಿನ ಅಂಕಗಳನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ - LeastResourceAllocation/LeastRequestedPriority/BalancedResourceAllocation) ಮತ್ತು ಹೆಚ್ಚಿನ ಅಂಕಗಳೊಂದಿಗೆ ನೋಡ್‌ನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ (ಹಲವಾರು ನೋಡ್‌ಗಳು ಈ ಸ್ಥಿತಿಯನ್ನು ಏಕಕಾಲದಲ್ಲಿ ಪೂರೈಸಿದರೆ, ನಂತರ ಯಾದೃಚ್ಛಿಕ ಒಂದನ್ನು ಆಯ್ಕೆಮಾಡಲಾಗಿದೆ) .
ಅದೇ ಸಮಯದಲ್ಲಿ, ಶೆಡ್ಯೂಲರ್, ನೋಡ್‌ನ ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ಣಯಿಸುವಾಗ, ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಸಂಗ್ರಹವಾಗಿರುವ ಡೇಟಾದಿಂದ ಮಾರ್ಗದರ್ಶಿಸಲ್ಪಡುತ್ತದೆ ಎಂದು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕು - ಅಂದರೆ. ಈ ನೋಡ್‌ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿ ಪಾಡ್ನ ವಿನಂತಿಸಿದ/ಮಿತಿ ಸಂಪನ್ಮೂಲದ ಮೊತ್ತಕ್ಕೆ, ಆದರೆ ನಿಜವಾದ ಸಂಪನ್ಮೂಲ ಬಳಕೆಗಾಗಿ ಅಲ್ಲ. ಈ ಮಾಹಿತಿಯನ್ನು ಕಮಾಂಡ್ ಔಟ್‌ಪುಟ್‌ನಿಂದ ಪಡೆಯಬಹುದು 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). ನಂತರ ಇದು ಅತ್ಯಂತ ಸೂಕ್ತವಾದ ನೋಡ್ ಅನ್ನು ನಿರ್ಧರಿಸಲು ಈ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ಗಳಿಗೆ ಹಲವಾರು ನಿಯತಾಂಕಗಳನ್ನು (ಸಮತೋಲಿತ ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆ, ಕನಿಷ್ಠ ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆ ಸೇರಿದಂತೆ) ಆಧರಿಸಿ ಸ್ಕೋರ್‌ಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ. ಅಂತಿಮವಾಗಿ, ಪಾಡ್ ಅನ್ನು ಅತ್ಯಧಿಕ ಸಂಖ್ಯೆಯ ಅಂಕಗಳೊಂದಿಗೆ ನೋಡ್‌ನಲ್ಲಿ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ (ಇಲ್ಲಿ ಎರಡು ನೋಡ್‌ಗಳು ಒಂದೇ ಸಂಖ್ಯೆಯ ಅಂಕಗಳನ್ನು 100037 ಹೊಂದಿರುತ್ತವೆ, ಆದ್ದರಿಂದ ಯಾದೃಚ್ಛಿಕ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡಲಾಗುತ್ತದೆ - nxs-k8s-s10).
ತೀರ್ಮಾನಕ್ಕೆ: ಒಂದು ನೋಡ್ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿಸದ ಪಾಡ್‌ಗಳನ್ನು ರನ್ ಮಾಡಿದರೆ, k8s ಗಾಗಿ (ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ದೃಷ್ಟಿಯಿಂದ) ಇದು ಈ ನೋಡ್‌ನಲ್ಲಿ ಅಂತಹ ಯಾವುದೇ ಪಾಡ್‌ಗಳು ಇಲ್ಲದಿದ್ದಕ್ಕೆ ಸಮನಾಗಿರುತ್ತದೆ. ಆದ್ದರಿಂದ, ನೀವು ಷರತ್ತುಬದ್ಧವಾಗಿ, ಹೊಟ್ಟೆಬಾಕತನದ ಪ್ರಕ್ರಿಯೆಯೊಂದಿಗೆ ಪಾಡ್ ಹೊಂದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ, wowza) ಮತ್ತು ಅದಕ್ಕೆ ಯಾವುದೇ ನಿರ್ಬಂಧಗಳನ್ನು ಹೊಂದಿಸದಿದ್ದರೆ, ಈ ಪಾಡ್ ವಾಸ್ತವವಾಗಿ ನೋಡ್‌ನ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸೇವಿಸಿದಾಗ ಪರಿಸ್ಥಿತಿ ಉದ್ಭವಿಸಬಹುದು, ಆದರೆ k8 ಗಳಿಗೆ ಈ ನೋಡ್ ಅನ್‌ಲೋಡ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವರ್ಕಿಂಗ್ ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿರದ ನೋಡ್‌ನಂತೆ ಶ್ರೇಯಾಂಕ ಮಾಡುವಾಗ (ನಿಖರವಾಗಿ ಲಭ್ಯವಿರುವ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ಣಯಿಸುವ ಅಂಕಗಳಲ್ಲಿ) ಅದೇ ಸಂಖ್ಯೆಯ ಅಂಕಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ, ಇದು ಅಂತಿಮವಾಗಿ ನೋಡ್ಗಳ ನಡುವಿನ ಲೋಡ್‌ನ ಅಸಮ ವಿತರಣೆಗೆ ಕಾರಣವಾಗಬಹುದು.
ಪಾಡ್ನ ಹೊರಹಾಕುವಿಕೆ
ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಪ್ರತಿ ಪಾಡ್‌ಗೆ 3 QoS ತರಗತಿಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ:
- ಖಾತರಿಪಡಿಸಲಾಗಿದೆ - ಪಾಡ್‌ನಲ್ಲಿರುವ ಪ್ರತಿ ಕಂಟೇನರ್‌ಗೆ ಮೆಮೊರಿ ಮತ್ತು ಸಿಪಿಯುಗಾಗಿ ವಿನಂತಿ ಮತ್ತು ಮಿತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಿದಾಗ ನಿಗದಿಪಡಿಸಲಾಗಿದೆ ಮತ್ತು ಈ ಮೌಲ್ಯಗಳು ಹೊಂದಿಕೆಯಾಗಬೇಕು
- ಸಿಡಿಯಬಲ್ಲ - ಪಾಡ್‌ನಲ್ಲಿ ಕನಿಷ್ಠ ಒಂದು ಕಂಟೇನರ್ ವಿನಂತಿ ಮತ್ತು ಮಿತಿಯನ್ನು ಹೊಂದಿದೆ, ವಿನಂತಿ < ಮಿತಿಯೊಂದಿಗೆ
- ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನ - ಪಾಡ್‌ನಲ್ಲಿ ಒಂದೇ ಒಂದು ಕಂಟೇನರ್ ಸಂಪನ್ಮೂಲ ಸೀಮಿತವಾಗಿಲ್ಲದಿದ್ದಾಗ
ಅದೇ ಸಮಯದಲ್ಲಿ, ಒಂದು ನೋಡ್ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯನ್ನು ಅನುಭವಿಸಿದಾಗ (ಡಿಸ್ಕ್, ಮೆಮೊರಿ), kubelet ಪಾಡ್ ಮತ್ತು ಅದರ QoS ವರ್ಗದ ಆದ್ಯತೆಯನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ನಿರ್ದಿಷ್ಟ ಅಲ್ಗಾರಿದಮ್ ಪ್ರಕಾರ ಪಾಡ್‌ಗಳನ್ನು ಶ್ರೇಣೀಕರಿಸಲು ಮತ್ತು ಹೊರಹಾಕಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ನಾವು RAM ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದರೆ, QoS ವರ್ಗವನ್ನು ಆಧರಿಸಿ, ಈ ಕೆಳಗಿನ ತತ್ವದ ಪ್ರಕಾರ ಅಂಕಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ:
- ಭರವಸೆ:-998
- ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನ: 1000
- ಸಿಡಿಯಬಲ್ಲ: ಕನಿಷ್ಠ(ಗರಿಷ್ಠ(2, 1000 - (1000 * ಮೆಮೊರಿ ರಿಕ್ವೆಸ್ಟ್‌ಬೈಟ್‌ಗಳು) / ಮೆಷಿನ್‌ಮೆಮೊರಿ ಕ್ಯಾಪಾಸಿಟಿಬೈಟ್ಸ್), 999)
ಆ. ಅದೇ ಆದ್ಯತೆಯೊಂದಿಗೆ, kubelet ಮೊದಲು ನೋಡ್‌ನಿಂದ ಉತ್ತಮ ಪ್ರಯತ್ನದ QoS ವರ್ಗದೊಂದಿಗೆ ಪಾಡ್‌ಗಳನ್ನು ಹೊರಹಾಕುತ್ತದೆ.
ತೀರ್ಮಾನಕ್ಕೆ: ನೀವು ಬಯಸಿದ ಪಾಡ್ನ ಮೇಲೆ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ನೋಡ್‌ನಿಂದ ಹೊರಹಾಕಲ್ಪಡುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಬಯಸಿದರೆ, ಆದ್ಯತೆಯ ಜೊತೆಗೆ, ನೀವು ವಿನಂತಿಯನ್ನು/ಮಿತಿಯನ್ನು ಹೊಂದಿಸುವುದನ್ನು ಸಹ ನೋಡಿಕೊಳ್ಳಬೇಕು.
ಅಪ್ಲಿಕೇಶನ್ ಪಾಡ್‌ಗಳ (HPA) ಸಮತಲ ಆಟೋಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ ಕಾರ್ಯವಿಧಾನ
ಸಂಪನ್ಮೂಲಗಳ (ಸಿಸ್ಟಮ್ - CPU/RAM ಅಥವಾ ಬಳಕೆದಾರ - rps) ಬಳಕೆಯ ಆಧಾರದ ಮೇಲೆ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೆಚ್ಚಿಸುವುದು ಮತ್ತು ಕಡಿಮೆ ಮಾಡುವುದು ಕಾರ್ಯವಾದಾಗ, ಅಂತಹ k8s ಘಟಕ ಎಚ್ಪಿಎ (ಸಮತಲ ಪಾಡ್ ಆಟೋಸ್ಕೇಲರ್). ಇದರ ಅಲ್ಗಾರಿದಮ್ ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:
- ಗಮನಿಸಿದ ಸಂಪನ್ಮೂಲದ ಪ್ರಸ್ತುತ ವಾಚನಗೋಷ್ಠಿಯನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ (ಪ್ರಸ್ತುತ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ)
- ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯಗಳನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ (ಬಯಸಿದ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ), ಇದು ಸಿಸ್ಟಮ್ ಸಂಪನ್ಮೂಲಗಳಿಗೆ ವಿನಂತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ಹೊಂದಿಸಲಾಗಿದೆ
- ಪ್ರಸ್ತುತ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ (ಪ್ರಸ್ತುತ ರೆಪ್ಲಿಕಾಸ್)
- ಕೆಳಗಿನ ಸೂತ್ರವು ಅಪೇಕ್ಷಿತ ಸಂಖ್ಯೆಯ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ (ಅಪೇಕ್ಷಿತ ಪ್ರತಿಕೃತಿಗಳು)
ಅಪೇಕ್ಷಿತ ಪ್ರತಿಕೃತಿಗಳು = [ ಪ್ರಸ್ತುತ ಪ್ರತಿಕೃತಿಗಳು * (ಪ್ರಸ್ತುತ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ / ಬಯಸಿದ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ)]
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಗುಣಾಂಕ (ಪ್ರಸ್ತುತ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ / ಅಪೇಕ್ಷಿತ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ) 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-ರಫ್ತುದಾರ ಕಂಟೇನರ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ ವಿನಂತಿಗಳು 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ಆ. ನಾವು hpa ಅನ್ನು ರಚಿಸಿದ್ದೇವೆ ಅದು ನಿಯೋಜನೆ ಅಪ್ಲಿಕೇಶನ್-ಪರೀಕ್ಷೆಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಸಿಪಿಯು ಸೂಚಕದ ಆಧಾರದ ಮೇಲೆ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸರಿಹೊಂದಿಸುತ್ತದೆ (ಪಾಡ್ ವಿನಂತಿಸುವ CPU ನ 30% ಅನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ), ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ 2-10 ರ ಶ್ರೇಣಿ.
ಈಗ, ನಾವು ಒಲೆಗಳಲ್ಲಿ ಒಂದಕ್ಕೆ ಲೋಡ್ ಅನ್ನು ಅನ್ವಯಿಸಿದರೆ hpa ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯವಿಧಾನವನ್ನು ನೋಡೋಣ:
# kubectl top pod NAME CPU(cores) MEMORY(bytes) app-test-78559f8f44-pgs58 101m 243Mi app-test-78559f8f44-cj4jz 4m 240Mi
ಒಟ್ಟಾರೆಯಾಗಿ ನಾವು ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:
- ಅಪೇಕ್ಷಿತ ಮೌಲ್ಯ (ಬಯಸಿದ ಮೆಟ್ರಿಕ್ ಮೌಲ್ಯ) - hpa ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪ್ರಕಾರ, ನಾವು 30% ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ
- ಪ್ರಸ್ತುತ ಮೌಲ್ಯ (currentMetricValue) - ಲೆಕ್ಕಾಚಾರಕ್ಕಾಗಿ, ನಿಯಂತ್ರಕ-ನಿರ್ವಾಹಕರು ಸಂಪನ್ಮೂಲ ಬಳಕೆಯ ಸರಾಸರಿ ಮೌಲ್ಯವನ್ನು % ನಲ್ಲಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತಾರೆ, ಅಂದರೆ. ಷರತ್ತುಬದ್ಧವಾಗಿ ಈ ಕೆಳಗಿನವುಗಳನ್ನು ಮಾಡುತ್ತದೆ:
- ಮೆಟ್ರಿಕ್ ಸರ್ವರ್‌ನಿಂದ ಪಾಡ್ ಮೆಟ್ರಿಕ್‌ಗಳ ಸಂಪೂರ್ಣ ಮೌಲ್ಯಗಳನ್ನು ಪಡೆಯುತ್ತದೆ, ಅಂದರೆ. 101 ಮೀ ಮತ್ತು 4 ಮೀ
- ಸರಾಸರಿ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ, ಅಂದರೆ. (101m + 4m) / 2 = 53m
- ಅಪೇಕ್ಷಿತ ಸಂಪನ್ಮೂಲ ಬಳಕೆಗೆ ಸಂಪೂರ್ಣ ಮೌಲ್ಯವನ್ನು ಪಡೆಯುತ್ತದೆ (ಇದಕ್ಕಾಗಿ, ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳ ವಿನಂತಿಗಳನ್ನು ಸಂಕ್ಷಿಪ್ತಗೊಳಿಸಲಾಗಿದೆ) 60m + 30m = 90m
- ವಿನಂತಿಯ ಪಾಡ್‌ಗೆ ಸಂಬಂಧಿಸಿದಂತೆ CPU ಬಳಕೆಯ ಸರಾಸರಿ ಶೇಕಡಾವಾರು ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ, ಅಂದರೆ. 53 ಮೀ / 90 ಮೀ * 100% = 59%
ಈಗ ನಾವು ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸಬೇಕೆ ಎಂದು ನಿರ್ಧರಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ನಾವು ಹೊಂದಿದ್ದೇವೆ; ಇದನ್ನು ಮಾಡಲು, ನಾವು ಗುಣಾಂಕವನ್ನು ಲೆಕ್ಕ ಹಾಕುತ್ತೇವೆ:
ratio = 59% / 30% = 1.96
ಆ. ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ~2 ಪಟ್ಟು ಹೆಚ್ಚಿಸಬೇಕು ಮತ್ತು ಮೊತ್ತವನ್ನು [2 * 1.96] = 4 ಗೆ ಹೆಚ್ಚಿಸಬೇಕು.
ತೀರ್ಮಾನ: ನೀವು ನೋಡುವಂತೆ, ಈ ಕಾರ್ಯವಿಧಾನವು ಕಾರ್ಯನಿರ್ವಹಿಸಲು, ಗಮನಿಸಿದ ಪಾಡ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳಿಗೆ ವಿನಂತಿಗಳ ಉಪಸ್ಥಿತಿಯು ಅಗತ್ಯವಾದ ಸ್ಥಿತಿಯಾಗಿದೆ.
ನೋಡ್ಗಳ ಸಮತಲ ಆಟೋಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ ಯಾಂತ್ರಿಕ ವ್ಯವಸ್ಥೆ (ಕ್ಲಸ್ಟರ್ ಆಟೋಸ್ಕೇಲರ್)
ಲೋಡ್ ಉಲ್ಬಣಗಳ ಸಮಯದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಮೇಲೆ ನಕಾರಾತ್ಮಕ ಪ್ರಭಾವವನ್ನು ತಟಸ್ಥಗೊಳಿಸಲು, ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ hpa ಹೊಂದಲು ಸಾಕಾಗುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, hpa ನಿಯಂತ್ರಕ ವ್ಯವಸ್ಥಾಪಕದಲ್ಲಿನ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಪ್ರಕಾರ, ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು 2 ಪಟ್ಟು ಹೆಚ್ಚಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂದು ಅದು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ ನೋಡ್‌ಗಳು ಅಂತಹ ಸಂಖ್ಯೆಯ ಪಾಡ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಉಚಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲ (ಅಂದರೆ ನೋಡ್ ಒದಗಿಸುವುದಿಲ್ಲ ವಿನಂತಿಗಳ ಪಾಡ್‌ಗೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿನಂತಿಸಲಾಗಿದೆ) ಮತ್ತು ಈ ಪಾಡ್‌ಗಳು ಬಾಕಿ ಇರುವ ಸ್ಥಿತಿಗೆ ಬದಲಾಯಿಸುತ್ತವೆ.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪೂರೈಕೆದಾರರು ಅನುಗುಣವಾದ IaaS/PaaS ಹೊಂದಿದ್ದರೆ (ಉದಾಹರಣೆಗೆ, GKE/GCE, AKS, EKS, ಇತ್ಯಾದಿ), ಒಂದು ರೀತಿಯ ಸಾಧನ ನೋಡ್ ಆಟೋಸ್ಕೇಲರ್. ಕ್ಲಸ್ಟರ್ ಮತ್ತು ಪಾಡ್‌ಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆ ಇದ್ದಾಗ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಗರಿಷ್ಠ ಮತ್ತು ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ನೋಡ್‌ಗಳನ್ನು ಹೊಂದಿಸಲು ಮತ್ತು ಪ್ರಸ್ತುತ ನೋಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಹೊಂದಿಸಲು (ನೋಡ್ ಅನ್ನು ಆರ್ಡರ್ ಮಾಡಲು/ತೆಗೆದುಹಾಕಲು ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್ API ಗೆ ಕರೆ ಮಾಡುವ ಮೂಲಕ) ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ನಿಗದಿಪಡಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ (ಬಾಕಿಯ ಸ್ಥಿತಿಯಲ್ಲಿವೆ).
ತೀರ್ಮಾನ: ನೋಡ್‌ಗಳನ್ನು ಆಟೋಸ್ಕೇಲ್ ಮಾಡಲು ಸಾಧ್ಯವಾಗುವಂತೆ, ಪಾಡ್ ಕಂಟೇನರ್‌ಗಳಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿಸುವುದು ಅಗತ್ಯವಾಗಿದೆ, ಇದರಿಂದಾಗಿ k8 ಗಳು ನೋಡ್‌ಗಳಲ್ಲಿನ ಲೋಡ್ ಅನ್ನು ಸರಿಯಾಗಿ ನಿರ್ಣಯಿಸಬಹುದು ಮತ್ತು ಮುಂದಿನ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಸಂಪನ್ಮೂಲಗಳಿಲ್ಲ ಎಂದು ವರದಿ ಮಾಡುತ್ತದೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ಅಪ್ಲಿಕೇಶನ್ ಯಶಸ್ವಿಯಾಗಿ ರನ್ ಆಗಲು ಕಂಟೇನರ್ ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳನ್ನು ಹೊಂದಿಸುವ ಅಗತ್ಯವಿಲ್ಲ ಎಂದು ಗಮನಿಸಬೇಕು, ಆದರೆ ಈ ಕೆಳಗಿನ ಕಾರಣಗಳಿಗಾಗಿ ಅದನ್ನು ಮಾಡುವುದು ಇನ್ನೂ ಉತ್ತಮವಾಗಿದೆ:
- k8s ನೋಡ್ಗಳ ನಡುವೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ವಿಷಯದಲ್ಲಿ ಶೆಡ್ಯೂಲರ್‌ನ ಹೆಚ್ಚು ನಿಖರವಾದ ಕಾರ್ಯಾಚರಣೆಗಾಗಿ
- "ಪಾಡ್ ಎವಿಕ್ಷನ್" ಈವೆಂಟ್ ಸಂಭವಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು
- ಅಪ್ಲಿಕೇಶನ್ ಪಾಡ್‌ಗಳ (HPA) ಸಮತಲ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಕೆಲಸ ಮಾಡಲು
- ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಿಗಾಗಿ ನೋಡ್ಗಳ (ಕ್ಲಸ್ಟರ್ ಆಟೋಸ್ಕೇಲಿಂಗ್) ಸಮತಲವಾದ ಆಟೋಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಇತರ ಲೇಖನಗಳನ್ನು ಸಹ ಓದಿ:
ಮೂಲ: www.habr.com