ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ (ಅವಲೋಕನ ಮತ್ತು ವೀಡಿಯೊ ವರದಿ)

ಸಮ್ಮೇಳನದಲ್ಲಿ ಏಪ್ರಿಲ್ 27 ಮುಷ್ಕರ 2019, "DevOps" ವಿಭಾಗದ ಭಾಗವಾಗಿ, "ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ" ವರದಿಯನ್ನು ನೀಡಲಾಗಿದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು K8 ಗಳನ್ನು ಹೇಗೆ ಬಳಸಬಹುದು ಎಂಬುದರ ಕುರಿತು ಇದು ಮಾತನಾಡುತ್ತದೆ.

ಸಂಪ್ರದಾಯದ ಮೂಲಕ, ನಾವು ಪ್ರಸ್ತುತಪಡಿಸಲು ಸಂತೋಷಪಡುತ್ತೇವೆ ವರದಿಯ ವೀಡಿಯೊ (44 ನಿಮಿಷಗಳು, ಲೇಖನಕ್ಕಿಂತ ಹೆಚ್ಚು ತಿಳಿವಳಿಕೆ) ಮತ್ತು ಪಠ್ಯ ರೂಪದಲ್ಲಿ ಮುಖ್ಯ ಸಾರಾಂಶ. ಹೋಗು!

ವರದಿಯ ವಿಷಯವನ್ನು ಪದದ ಮೂಲಕ ವಿಶ್ಲೇಷಿಸೋಣ ಮತ್ತು ಅಂತ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸೋಣ.

ಕುಬರ್ನೆಟ್ಸ್

ನಮ್ಮ ಹೋಸ್ಟ್‌ನಲ್ಲಿ ನಾವು ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಎಂದು ಹೇಳೋಣ. ಯಾವುದಕ್ಕಾಗಿ? ಪುನರಾವರ್ತನೆ ಮತ್ತು ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ಇದು ಸರಳ ಮತ್ತು ಉತ್ತಮ ನಿಯೋಜನೆಗೆ ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ, CI/CD. ನಮ್ಮಲ್ಲಿ ಕಂಟೈನರ್‌ಗಳಿರುವ ಇಂತಹ ಹಲವು ವಾಹನಗಳಿವೆ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಏನು ಒದಗಿಸುತ್ತಾನೆ?

1. ನಾವು ಈ ಯಂತ್ರಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತೇವೆ ಮತ್ತು "ಮೋಡ" ದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಧಾರಕಗಳ ಕ್ಲಸ್ಟರ್ ಅಥವಾ ಪಾಡ್ಗಳು (ಧಾರಕಗಳ ಗುಂಪುಗಳು).
2. ಇದಲ್ಲದೆ, ನಾವು ವೈಯಕ್ತಿಕ ಪಾಡ್‌ಗಳ ಬಗ್ಗೆ ಯೋಚಿಸುವುದಿಲ್ಲ, ಆದರೆ ಹೆಚ್ಚಿನದನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆоದೊಡ್ಡ ಗುಂಪುಗಳು. ಅಂತಹ ಉನ್ನತ ಮಟ್ಟದ ಪ್ರಾಚೀನರು ನಿರ್ದಿಷ್ಟ ಕೆಲಸದ ಹೊರೆಯನ್ನು ಚಲಾಯಿಸಲು ಟೆಂಪ್ಲೇಟ್ ಇದೆ ಎಂದು ಹೇಳಲು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಡಿ ಮತ್ತು ಅದನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ ಸಂಖ್ಯೆಯ ನಿದರ್ಶನಗಳು ಇಲ್ಲಿವೆ. ನಾವು ತರುವಾಯ ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿದರೆ, ಎಲ್ಲಾ ನಿದರ್ಶನಗಳು ಬದಲಾಗುತ್ತವೆ.
3. ಸಹಾಯದಿಂದ ಘೋಷಣಾತ್ಮಕ API ನಿರ್ದಿಷ್ಟ ಆಜ್ಞೆಗಳ ಅನುಕ್ರಮವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಬದಲು, ಕುಬರ್ನೆಟ್ಸ್ ರಚಿಸಿದ "ಜಗತ್ತಿನ ರಚನೆ" (YAML ನಲ್ಲಿ) ಅನ್ನು ನಾವು ವಿವರಿಸುತ್ತೇವೆ. ಮತ್ತು ಮತ್ತೊಮ್ಮೆ: ವಿವರಣೆಯು ಬದಲಾದಾಗ, ಅದರ ನಿಜವಾದ ಪ್ರದರ್ಶನವೂ ಬದಲಾಗುತ್ತದೆ.

ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆ

ಸಿಪಿಯು

ನಾವು ಸರ್ವರ್‌ನಲ್ಲಿ nginx, php-fpm ಮತ್ತು mysql ಅನ್ನು ರನ್ ಮಾಡೋಣ. ಈ ಸೇವೆಗಳು ವಾಸ್ತವವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಇನ್ನೂ ಹೆಚ್ಚಿನ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ, ಪ್ರತಿಯೊಂದಕ್ಕೂ ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯವಿರುತ್ತದೆ:

(ಸ್ಲೈಡ್‌ನಲ್ಲಿರುವ ಸಂಖ್ಯೆಗಳು "ಗಿಳಿಗಳು", ಕಂಪ್ಯೂಟಿಂಗ್ ಪವರ್‌ಗಾಗಿ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಯ ಅಮೂರ್ತ ಅಗತ್ಯ)

ಇದರೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸುಲಭವಾಗುವಂತೆ, ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಗುಂಪುಗಳಾಗಿ ಸಂಯೋಜಿಸುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ (ಉದಾಹರಣೆಗೆ, ಎಲ್ಲಾ nginx ಪ್ರಕ್ರಿಯೆಗಳು ಒಂದು ಗುಂಪಿಗೆ "nginx"). ಇದನ್ನು ಮಾಡಲು ಸರಳ ಮತ್ತು ಸ್ಪಷ್ಟವಾದ ಮಾರ್ಗವೆಂದರೆ ಪ್ರತಿ ಗುಂಪನ್ನು ಕಂಟೇನರ್‌ನಲ್ಲಿ ಹಾಕುವುದು:

ಮುಂದುವರಿಸಲು, ಕಂಟೇನರ್ ಎಂದರೇನು (ಲಿನಕ್ಸ್‌ನಲ್ಲಿ) ನೀವು ನೆನಪಿಟ್ಟುಕೊಳ್ಳಬೇಕು. ಕರ್ನಲ್‌ನಲ್ಲಿನ ಮೂರು ಪ್ರಮುಖ ವೈಶಿಷ್ಟ್ಯಗಳಿಂದಾಗಿ ಅವರ ನೋಟವು ಸಾಧ್ಯವಾಯಿತು, ಬಹಳ ಹಿಂದೆಯೇ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗಿದೆ: ಸಾಮರ್ಥ್ಯಗಳು, ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು и cgroups. ಮತ್ತು ಹೆಚ್ಚಿನ ಅಭಿವೃದ್ಧಿಯನ್ನು ಇತರ ತಂತ್ರಜ್ಞಾನಗಳಿಂದ ಸುಗಮಗೊಳಿಸಲಾಯಿತು (ಡಾಕರ್‌ನಂತಹ ಅನುಕೂಲಕರ "ಶೆಲ್‌ಗಳು" ಸೇರಿದಂತೆ):

ವರದಿಯ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಮಾತ್ರ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ cgroups, ಏಕೆಂದರೆ ನಿಯಂತ್ರಣ ಗುಂಪುಗಳು ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಕಂಟೈನರ್‌ಗಳ (ಡಾಕರ್, ಇತ್ಯಾದಿ) ಕ್ರಿಯಾತ್ಮಕತೆಯ ಭಾಗವಾಗಿದೆ. ನಾವು ಬಯಸಿದಂತೆ ಗುಂಪುಗಳಾಗಿ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಪ್ರಕ್ರಿಯೆಗಳು ನಿಯಂತ್ರಣ ಗುಂಪುಗಳಾಗಿವೆ.

ಈ ಪ್ರಕ್ರಿಯೆಗಳಿಗೆ ಮತ್ತು ಈಗ ಪ್ರಕ್ರಿಯೆಗಳ ಗುಂಪುಗಳಿಗೆ CPU ಅವಶ್ಯಕತೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ:

(ಎಲ್ಲಾ ಸಂಖ್ಯೆಗಳು ಸಂಪನ್ಮೂಲಗಳ ಅಗತ್ಯತೆಯ ಅಮೂರ್ತ ಅಭಿವ್ಯಕ್ತಿ ಎಂದು ನಾನು ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ)

ಅದೇ ಸಮಯದಲ್ಲಿ, CPU ಸ್ವತಃ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸೀಮಿತ ಸಂಪನ್ಮೂಲವನ್ನು ಹೊಂದಿದೆ (ಉದಾಹರಣೆಯಲ್ಲಿ ಇದು 1000), ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಕೊರತೆಯಿರಬಹುದು (ಎಲ್ಲಾ ಗುಂಪುಗಳ ಅಗತ್ಯಗಳ ಮೊತ್ತವು 150+850+460=1460 ಆಗಿದೆ). ಈ ಸಂದರ್ಭದಲ್ಲಿ ಏನಾಗುತ್ತದೆ?

ಕರ್ನಲ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿತರಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು "ನ್ಯಾಯಯುತವಾಗಿ" ಮಾಡುತ್ತದೆ, ಪ್ರತಿ ಗುಂಪಿಗೆ ಅದೇ ಪ್ರಮಾಣದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ನೀಡುತ್ತದೆ. ಆದರೆ ಮೊದಲನೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಅವುಗಳಲ್ಲಿ ಅಗತ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚು ಇವೆ (333>150), ಆದ್ದರಿಂದ ಹೆಚ್ಚುವರಿ (333-150=183) ಮೀಸಲು ಉಳಿದಿದೆ, ಇದು ಎರಡು ಇತರ ಪಾತ್ರೆಗಳ ನಡುವೆ ಸಮಾನವಾಗಿ ವಿತರಿಸಲ್ಪಡುತ್ತದೆ:

ಪರಿಣಾಮವಾಗಿ: ಮೊದಲ ಕಂಟೇನರ್ ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿತ್ತು, ಎರಡನೆಯದು - ಇದು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಮೂರನೆಯದು - ಇದು ಸಾಕಷ್ಟು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಲ್ಲ. ಇದು ಕ್ರಿಯೆಗಳ ಫಲಿತಾಂಶವಾಗಿದೆ Linux ನಲ್ಲಿ "ಪ್ರಾಮಾಣಿಕ" ಶೆಡ್ಯೂಲರ್ - CFS. ನಿಯೋಜನೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಅದರ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸರಿಹೊಂದಿಸಬಹುದು ತೂಕ ಪ್ರತಿಯೊಂದು ಪಾತ್ರೆಗಳು. ಉದಾಹರಣೆಗೆ, ಈ ರೀತಿ:

ಎರಡನೇ ಧಾರಕದಲ್ಲಿ (php-fpm) ಸಂಪನ್ಮೂಲಗಳ ಕೊರತೆಯ ಸಂದರ್ಭದಲ್ಲಿ ನೋಡೋಣ. ಎಲ್ಲಾ ಧಾರಕ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಪ್ರಕ್ರಿಯೆಗಳ ನಡುವೆ ಸಮಾನವಾಗಿ ವಿತರಿಸಲಾಗುತ್ತದೆ. ಪರಿಣಾಮವಾಗಿ, ಮಾಸ್ಟರ್ ಪ್ರಕ್ರಿಯೆಯು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಎಲ್ಲಾ ಕೆಲಸಗಾರರು ನಿಧಾನಗೊಳಿಸುತ್ತಾರೆ, ಅವರು ಅಗತ್ಯವಿರುವ ಅರ್ಧಕ್ಕಿಂತ ಕಡಿಮೆ ಪಡೆಯುತ್ತಾರೆ:

ಈ ರೀತಿ CFS ಶೆಡ್ಯೂಲರ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ನಾವು ಕಂಟೇನರ್‌ಗಳಿಗೆ ನಿಯೋಜಿಸುವ ತೂಕವನ್ನು ಮತ್ತಷ್ಟು ಕರೆಯುತ್ತೇವೆ ವಿನಂತಿಗಳನ್ನು. ಇದು ಏಕೆ - ಮುಂದೆ ನೋಡಿ.

ಇಡೀ ಪರಿಸ್ಥಿತಿಯನ್ನು ಇನ್ನೊಂದು ಕಡೆಯಿಂದ ನೋಡೋಣ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಎಲ್ಲಾ ರಸ್ತೆಗಳು ರೋಮ್‌ಗೆ ಮತ್ತು ಕಂಪ್ಯೂಟರ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, CPU ಗೆ ಕಾರಣವಾಗುತ್ತವೆ. ಒಂದು ಸಿಪಿಯು, ಹಲವು ಕಾರ್ಯಗಳು - ನಿಮಗೆ ಟ್ರಾಫಿಕ್ ಲೈಟ್ ಅಗತ್ಯವಿದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಸರಳ ಮಾರ್ಗವೆಂದರೆ "ಟ್ರಾಫಿಕ್ ಲೈಟ್": ಅವರು ಒಂದು ಪ್ರಕ್ರಿಯೆಗೆ CPU ಗೆ ನಿಶ್ಚಿತ ಪ್ರವೇಶ ಸಮಯವನ್ನು ನೀಡಿದರು, ನಂತರ ಮುಂದಿನದು, ಇತ್ಯಾದಿ.

ಈ ವಿಧಾನವನ್ನು ಹಾರ್ಡ್ ಕೋಟಾ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ (ಕಠಿಣ ಮಿತಿ). ಅದನ್ನು ಸರಳವಾಗಿ ನೆನಪಿಟ್ಟುಕೊಳ್ಳೋಣ ಮಿತಿಗಳು. ಆದಾಗ್ಯೂ, ನೀವು ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಮಿತಿಗಳನ್ನು ವಿತರಿಸಿದರೆ, ಸಮಸ್ಯೆ ಉದ್ಭವಿಸುತ್ತದೆ: mysql ರಸ್ತೆಯ ಉದ್ದಕ್ಕೂ ಚಾಲನೆ ಮಾಡುತ್ತಿದೆ ಮತ್ತು ಕೆಲವು ಸಮಯದಲ್ಲಿ ಅದರ CPU ನ ಅಗತ್ಯವು ಕೊನೆಗೊಂಡಿತು, ಆದರೆ ಎಲ್ಲಾ ಇತರ ಪ್ರಕ್ರಿಯೆಗಳು CPU ವರೆಗೆ ಕಾಯಲು ಒತ್ತಾಯಿಸಲಾಗುತ್ತದೆ. ನಿಷ್ಕ್ರಿಯ.

ಲಿನಕ್ಸ್ ಕರ್ನಲ್ ಮತ್ತು CPU ನೊಂದಿಗೆ ಅದರ ಪರಸ್ಪರ ಕ್ರಿಯೆಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ - ಒಟ್ಟಾರೆ ಚಿತ್ರವು ಈ ಕೆಳಗಿನಂತಿದೆ:

cgroup ಎರಡು ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು ಹೊಂದಿದೆ - ಮೂಲಭೂತವಾಗಿ ಇವು ಎರಡು ಸರಳವಾದ "ತಿರುವುಗಳು" ನಿಮಗೆ ನಿರ್ಧರಿಸಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ:

1. ಕಂಟೇನರ್‌ಗೆ ತೂಕ (ವಿನಂತಿಗಳು) ಆಗಿದೆ ಷೇರುಗಳು;
2. ಕಂಟೇನರ್ ಕಾರ್ಯಗಳಲ್ಲಿ (ಮಿತಿಗಳು) ಕೆಲಸ ಮಾಡಲು ಒಟ್ಟು CPU ಸಮಯದ ಶೇಕಡಾವಾರು ಕೋಟಾ.

CPU ಅನ್ನು ಅಳೆಯುವುದು ಹೇಗೆ?

ವಿಭಿನ್ನ ಮಾರ್ಗಗಳಿವೆ:

1. ಏನು ಗಿಳಿಗಳು, ಯಾರಿಗೂ ತಿಳಿದಿಲ್ಲ - ನೀವು ಪ್ರತಿ ಬಾರಿಯೂ ಮಾತುಕತೆ ನಡೆಸಬೇಕು.
2. ಆಸಕ್ತಿ ಸ್ಪಷ್ಟ, ಆದರೆ ಸಾಪೇಕ್ಷ: 50 ಕೋರ್‌ಗಳೊಂದಿಗೆ ಮತ್ತು 4 ಕೋರ್‌ಗಳೊಂದಿಗೆ ಸರ್ವರ್‌ನ 20% ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಷಯಗಳಾಗಿವೆ.
3. ನೀವು ಈಗಾಗಲೇ ಉಲ್ಲೇಖಿಸಿರುವಂತಹವುಗಳನ್ನು ಬಳಸಬಹುದು ತೂಕ, ಇದು Linux ಗೆ ತಿಳಿದಿದೆ, ಆದರೆ ಅವುಗಳು ಸಹ ಸಂಬಂಧಿತವಾಗಿವೆ.
4. ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅಳೆಯುವುದು ಅತ್ಯಂತ ಸಮರ್ಪಕವಾದ ಆಯ್ಕೆಯಾಗಿದೆ ಸೆಕೆಂಡುಗಳು. ಆ. ನೈಜ ಸಮಯದ ಸೆಕೆಂಡುಗಳಿಗೆ ಹೋಲಿಸಿದರೆ ಪ್ರೊಸೆಸರ್ ಸಮಯದ ಸೆಕೆಂಡುಗಳಲ್ಲಿ: 1 ನೈಜ ಸೆಕೆಂಡಿಗೆ 1 ಸೆಕೆಂಡ್ ಪ್ರೊಸೆಸರ್ ಸಮಯವನ್ನು ನೀಡಲಾಗಿದೆ - ಇದು ಒಂದು ಸಂಪೂರ್ಣ CPU ಕೋರ್ ಆಗಿದೆ.

ಮಾತನಾಡುವುದನ್ನು ಇನ್ನಷ್ಟು ಸುಲಭಗೊಳಿಸಲು, ಅವರು ನೇರವಾಗಿ ಅಳೆಯಲು ಪ್ರಾರಂಭಿಸಿದರು ಕರ್ನಲ್ಗಳು, ನಿಜವಾದ ಒಂದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ಅದೇ CPU ಸಮಯವನ್ನು ಅವರಿಂದ ಅರ್ಥೈಸಲಾಗುತ್ತದೆ. Linux ತೂಕವನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಆದರೆ ಹೆಚ್ಚು CPU ಸಮಯ/ಕೋರ್‌ಗಳಿಲ್ಲದ ಕಾರಣ, ಒಂದರಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ಭಾಷಾಂತರಿಸಲು ಯಾಂತ್ರಿಕತೆಯ ಅಗತ್ಯವಿತ್ತು.

3 CPU ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿರುವ ಸರ್ವರ್‌ನೊಂದಿಗೆ ಸರಳ ಉದಾಹರಣೆಯನ್ನು ಪರಿಗಣಿಸೋಣ, ಅಲ್ಲಿ ಮೂರು ಪಾಡ್‌ಗಳಿಗೆ ತೂಕವನ್ನು (500, 1000 ಮತ್ತು 1500) ನೀಡಲಾಗುವುದು, ಅದನ್ನು ಅವುಗಳಿಗೆ ನಿಯೋಜಿಸಲಾದ ಕೋರ್‌ಗಳ ಅನುಗುಣವಾದ ಭಾಗಗಳಿಗೆ ಸುಲಭವಾಗಿ ಪರಿವರ್ತಿಸಲಾಗುತ್ತದೆ (0,5, 1 ಮತ್ತು 1,5).

ನೀವು ಎರಡನೇ ಸರ್ವರ್ ಅನ್ನು ತೆಗೆದುಕೊಂಡರೆ, ಅಲ್ಲಿ ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಕೋರ್ಗಳು (6) ಇರುತ್ತವೆ ಮತ್ತು ಅದೇ ಪಾಡ್ಗಳನ್ನು ಅಲ್ಲಿ ಇರಿಸಿದರೆ, ಕೋರ್ಗಳ ವಿತರಣೆಯನ್ನು ಸರಳವಾಗಿ 2 (1, 2 ಮತ್ತು 3, ಕ್ರಮವಾಗಿ) ಗುಣಿಸುವ ಮೂಲಕ ಸುಲಭವಾಗಿ ಲೆಕ್ಕಾಚಾರ ಮಾಡಬಹುದು. ಆದರೆ ಈ ಸರ್ವರ್‌ನಲ್ಲಿ ನಾಲ್ಕನೇ ಪಾಡ್ ಕಾಣಿಸಿಕೊಂಡಾಗ ಒಂದು ಪ್ರಮುಖ ಕ್ಷಣ ಸಂಭವಿಸುತ್ತದೆ, ಅದರ ತೂಕವು ಅನುಕೂಲಕ್ಕಾಗಿ 3000 ಆಗಿರುತ್ತದೆ. ಇದು CPU ಸಂಪನ್ಮೂಲಗಳ (ಅರ್ಧ ಕೋರ್‌ಗಳು) ಭಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ ಮತ್ತು ಉಳಿದ ಪಾಡ್‌ಗಳಿಗೆ ಅವುಗಳನ್ನು ಮರು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲಾಗುತ್ತದೆ (ಅರ್ಧಕಡಿತ):

ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು CPU ಸಂಪನ್ಮೂಲಗಳು

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ, CPU ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಅಳೆಯಲಾಗುತ್ತದೆ ಮಿಲಿಯಡ್ರಾಕ್ಸ್, ಅಂದರೆ 0,001 ಕೋರ್ಗಳನ್ನು ಮೂಲ ತೂಕವಾಗಿ ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ. (Linux/cgroups ಪರಿಭಾಷೆಯಲ್ಲಿ ಅದೇ ವಿಷಯವನ್ನು CPU ಹಂಚಿಕೆ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಆದಾಗ್ಯೂ, ಹೆಚ್ಚು ನಿಖರವಾಗಿ, 1000 ಮಿಲಿಕೋರ್‌ಗಳು = 1024 CPU ಷೇರುಗಳು.) ಎಲ್ಲಾ ಪಾಡ್‌ಗಳ ತೂಕದ ಮೊತ್ತಕ್ಕೆ CPU ಸಂಪನ್ಮೂಲಗಳು ಇರುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಪಾಡ್‌ಗಳನ್ನು ಸರ್ವರ್‌ನಲ್ಲಿ ಇರಿಸುವುದಿಲ್ಲ ಎಂದು K8s ಖಚಿತಪಡಿಸುತ್ತದೆ.

ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ? ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಸರ್ವರ್ ಅನ್ನು ಸೇರಿಸಿದಾಗ, ಅದು ಎಷ್ಟು CPU ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿದೆ ಎಂಬುದನ್ನು ವರದಿ ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ಹೊಸ ಪಾಡ್ ಅನ್ನು ರಚಿಸುವಾಗ, ಈ ಪಾಡ್‌ಗೆ ಎಷ್ಟು ಕೋರ್‌ಗಳು ಬೇಕಾಗುತ್ತವೆ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ ಶೆಡ್ಯೂಲರ್‌ಗೆ ತಿಳಿದಿದೆ. ಹೀಗಾಗಿ, ಸಾಕಷ್ಟು ಕೋರ್‌ಗಳಿರುವ ಸರ್ವರ್‌ಗೆ ಪಾಡ್ ಅನ್ನು ನಿಯೋಜಿಸಲಾಗುತ್ತದೆ.

ಒಂದು ವೇಳೆ ಏನಾಗುತ್ತದೆ ಕೇವಲ ವಿನಂತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಲಾಗಿದೆ (ಅಂದರೆ ಪಾಡ್ ಅದಕ್ಕೆ ಅಗತ್ಯವಿರುವ ನಿರ್ದಿಷ್ಟ ಸಂಖ್ಯೆಯ ಕೋರ್‌ಗಳನ್ನು ಹೊಂದಿಲ್ಲ)? ಕುಬರ್ನೆಟ್ಸ್ ಸಾಮಾನ್ಯವಾಗಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಎಣಿಸುತ್ತಾರೆ ಎಂಬುದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡೋಣ.

ಪಾಡ್‌ಗಾಗಿ ನೀವು ವಿನಂತಿಗಳನ್ನು (CFS ಶೆಡ್ಯೂಲರ್) ಮತ್ತು ಮಿತಿಗಳನ್ನು (ಟ್ರಾಫಿಕ್ ಲೈಟ್ ಅನ್ನು ನೆನಪಿದೆಯೇ?):

• ಅವುಗಳನ್ನು ಸಮಾನವಾಗಿ ನಿರ್ದಿಷ್ಟಪಡಿಸಿದರೆ, ನಂತರ ಪಾಡ್‌ಗೆ QoS ವರ್ಗವನ್ನು ನಿಗದಿಪಡಿಸಲಾಗಿದೆ ಭರವಸೆ. ಇದಕ್ಕೆ ಯಾವಾಗಲೂ ಲಭ್ಯವಿರುವ ಕೋರ್‌ಗಳ ಸಂಖ್ಯೆಯು ಖಾತರಿಪಡಿಸುತ್ತದೆ.
• ವಿನಂತಿಯು ಮಿತಿಗಿಂತ ಕಡಿಮೆಯಿದ್ದರೆ - QoS ವರ್ಗ ಸಿಡಿಯಬಲ್ಲ. ಆ. ಉದಾಹರಣೆಗೆ, ಯಾವಾಗಲೂ 1 ಕೋರ್ ಅನ್ನು ಬಳಸಬೇಕೆಂದು ನಾವು ನಿರೀಕ್ಷಿಸುತ್ತೇವೆ, ಆದರೆ ಈ ಮೌಲ್ಯವು ಅದಕ್ಕೆ ಮಿತಿಯಾಗಿಲ್ಲ: ಕೆಲವೊಮ್ಮೆ ಪಾಡ್ ಹೆಚ್ಚು ಬಳಸಬಹುದು (ಸರ್ವರ್ ಇದಕ್ಕಾಗಿ ಉಚಿತ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿರುವಾಗ).
• QoS ವರ್ಗವೂ ಇದೆ ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನ - ಇದು ವಿನಂತಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸದ ಪಾಡ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅವರಿಗೆ ಕೊನೆಯದಾಗಿ ನೀಡಲಾಗುತ್ತದೆ.

ಮೆಮೊರಿ

ಸ್ಮರಣೆಯೊಂದಿಗೆ, ಪರಿಸ್ಥಿತಿಯು ಹೋಲುತ್ತದೆ, ಆದರೆ ಸ್ವಲ್ಪ ವಿಭಿನ್ನವಾಗಿದೆ - ಎಲ್ಲಾ ನಂತರ, ಈ ಸಂಪನ್ಮೂಲಗಳ ಸ್ವರೂಪವು ವಿಭಿನ್ನವಾಗಿದೆ. ಸಾಮಾನ್ಯವಾಗಿ, ಸಾದೃಶ್ಯವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:

ಮೆಮೊರಿಯಲ್ಲಿ ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡೋಣ. ಪಾಡ್‌ಗಳು ಸರ್ವರ್‌ನಲ್ಲಿ ಜೀವಿಸಲಿ, ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತವೆ, ಅವುಗಳಲ್ಲಿ ಒಂದು ದೊಡ್ಡದಾಗುವವರೆಗೆ ಅದು ಮೆಮೊರಿ ಖಾಲಿಯಾಗುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, OOM ಕೊಲೆಗಾರ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ದೊಡ್ಡ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಕೊಲ್ಲುತ್ತಾನೆ:

ಇದು ಯಾವಾಗಲೂ ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಯಾವ ಪ್ರಕ್ರಿಯೆಗಳು ನಮಗೆ ಮುಖ್ಯ ಮತ್ತು ಕೊಲ್ಲಬಾರದು ಎಂಬುದನ್ನು ನಿಯಂತ್ರಿಸಲು ಸಾಧ್ಯವಿದೆ. ಇದನ್ನು ಮಾಡಲು, ನಿಯತಾಂಕವನ್ನು ಬಳಸಿ oom_ಸ್ಕೋರ್_adj.

CPU ನ QoS ತರಗತಿಗಳಿಗೆ ಹಿಂತಿರುಗಿ ಮತ್ತು ಪಾಡ್‌ಗಳಿಗೆ ಮೆಮೊರಿ ಬಳಕೆಯ ಆದ್ಯತೆಗಳನ್ನು ನಿರ್ಧರಿಸುವ oom_score_adj ಮೌಲ್ಯಗಳೊಂದಿಗೆ ಸಾದೃಶ್ಯವನ್ನು ಸೆಳೆಯೋಣ:

• ಪಾಡ್‌ಗೆ ಕಡಿಮೆ oom_score_adj ಮೌಲ್ಯ - -998 - ಅಂದರೆ ಅಂತಹ ಪಾಡ್ ಅನ್ನು ಕೊನೆಯದಾಗಿ ಕೊಲ್ಲಬೇಕು, ಇದು ಭರವಸೆ.
• ಅತ್ಯಧಿಕ - 1000 - ಆಗಿದೆ ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನ, ಅಂತಹ ಬೀಜಗಳನ್ನು ಮೊದಲು ಕೊಲ್ಲಲಾಗುತ್ತದೆ.
• ಉಳಿದ ಮೌಲ್ಯಗಳನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು (ಸಿಡಿಯಬಲ್ಲ) ಒಂದು ಸೂತ್ರವಿದೆ, ಅದರ ಸಾರವು ಒಂದು ಪಾಡ್ ಹೆಚ್ಚು ಸಂಪನ್ಮೂಲಗಳನ್ನು ವಿನಂತಿಸಿದೆ ಎಂಬ ಅಂಶಕ್ಕೆ ಕುದಿಯುತ್ತದೆ, ಅದು ಕೊಲ್ಲಲ್ಪಡುವ ಸಾಧ್ಯತೆ ಕಡಿಮೆ.

ಎರಡನೇ "ಟ್ವಿಸ್ಟ್" - ಮಿತಿ_ಇನ್_ಬೈಟ್ಸ್ - ಮಿತಿಗಳಿಗಾಗಿ. ಇದರೊಂದಿಗೆ, ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ: ನಾವು ನೀಡಲಾದ ಗರಿಷ್ಠ ಪ್ರಮಾಣದ ಮೆಮೊರಿಯನ್ನು ಸರಳವಾಗಿ ನಿಯೋಜಿಸುತ್ತೇವೆ ಮತ್ತು ಇಲ್ಲಿ (ಸಿಪಿಯುಗಿಂತ ಭಿನ್ನವಾಗಿ) ಅದನ್ನು ಹೇಗೆ ಅಳೆಯುವುದು (ಮೆಮೊರಿ) ಎಂಬ ಪ್ರಶ್ನೆಯಿಲ್ಲ.

ಒಟ್ಟು

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪ್ರತಿ ಪಾಡ್ ನೀಡಲಾಗಿದೆ requests и limits - CPU ಮತ್ತು ಮೆಮೊರಿಗಾಗಿ ಎರಡೂ ನಿಯತಾಂಕಗಳು:

1. ವಿನಂತಿಗಳ ಆಧಾರದ ಮೇಲೆ, ಕುಬರ್ನೆಟ್ಸ್ ಶೆಡ್ಯೂಲರ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಇದು ಸರ್ವರ್‌ಗಳ ನಡುವೆ ಪಾಡ್‌ಗಳನ್ನು ವಿತರಿಸುತ್ತದೆ;
2. ಎಲ್ಲಾ ನಿಯತಾಂಕಗಳನ್ನು ಆಧರಿಸಿ, ಪಾಡ್‌ನ QoS ವರ್ಗವನ್ನು ನಿರ್ಧರಿಸಲಾಗುತ್ತದೆ;
3. CPU ವಿನಂತಿಗಳ ಆಧಾರದ ಮೇಲೆ ಸಂಬಂಧಿತ ತೂಕವನ್ನು ಲೆಕ್ಕಹಾಕಲಾಗುತ್ತದೆ;
4. CPU ವಿನಂತಿಗಳ ಆಧಾರದ ಮೇಲೆ CFS ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ;
5. OOM ಕಿಲ್ಲರ್ ಅನ್ನು ಮೆಮೊರಿ ವಿನಂತಿಗಳ ಆಧಾರದ ಮೇಲೆ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ;
6. CPU ಮಿತಿಗಳ ಆಧಾರದ ಮೇಲೆ "ಟ್ರಾಫಿಕ್ ಲೈಟ್" ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ;
7. ಮೆಮೊರಿ ಮಿತಿಗಳನ್ನು ಆಧರಿಸಿ, cgroup ಗೆ ಮಿತಿಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ಸಾಮಾನ್ಯವಾಗಿ, ಈ ಚಿತ್ರವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣೆಯ ಮುಖ್ಯ ಭಾಗವು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಎಲ್ಲಾ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸುತ್ತದೆ.

ಆಟೋಸ್ಕೇಲಿಂಗ್

K8s ಕ್ಲಸ್ಟರ್-ಆಟೋಸ್ಕೇಲರ್

ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಈಗಾಗಲೇ ಆಕ್ರಮಿಸಿಕೊಂಡಿದೆ ಮತ್ತು ಹೊಸ ಪಾಡ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಎಂದು ಊಹಿಸೋಣ. ಪಾಡ್ ಕಾಣಿಸದಿದ್ದರೂ, ಅದು ಸ್ಥಿತಿಯಲ್ಲಿ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ ಬಾಕಿ. ಇದು ಕಾಣಿಸಿಕೊಳ್ಳಲು, ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೊಸ ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು ಅಥವಾ... ಕ್ಲಸ್ಟರ್-ಆಟೋಸ್ಕೇಲರ್ ಅನ್ನು ಸ್ಥಾಪಿಸಬಹುದು, ಅದು ನಮಗೆ ಅದನ್ನು ಮಾಡುತ್ತದೆ: ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರಿಂದ ವರ್ಚುವಲ್ ಯಂತ್ರವನ್ನು ಆರ್ಡರ್ ಮಾಡಿ (API ವಿನಂತಿಯನ್ನು ಬಳಸಿ) ಮತ್ತು ಅದನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪರ್ಕಪಡಿಸಿ , ಅದರ ನಂತರ ಪಾಡ್ ಅನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ.

ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಆಟೋಸ್ಕೇಲಿಂಗ್ ಆಗಿದೆ, ಇದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ (ನಮ್ಮ ಅನುಭವದಲ್ಲಿ). ಆದಾಗ್ಯೂ, ಬೇರೆಡೆಯಂತೆ, ಇಲ್ಲಿ ಕೆಲವು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸಗಳಿವೆ ...

ಎಲ್ಲಿಯವರೆಗೆ ನಾವು ಕ್ಲಸ್ಟರ್ ಗಾತ್ರವನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ, ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ, ಆದರೆ ಕ್ಲಸ್ಟರ್ ಮಾಡಿದಾಗ ಏನಾಗುತ್ತದೆ ತನ್ನನ್ನು ಮುಕ್ತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಿದನು? ಸಮಸ್ಯೆಯೆಂದರೆ ಪಾಡ್‌ಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವುದು (ಹೋಸ್ಟ್‌ಗಳನ್ನು ಮುಕ್ತಗೊಳಿಸಲು) ಸಂಪನ್ಮೂಲಗಳ ವಿಷಯದಲ್ಲಿ ತುಂಬಾ ತಾಂತ್ರಿಕವಾಗಿ ಕಷ್ಟಕರ ಮತ್ತು ದುಬಾರಿಯಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪೂರ್ಣವಾಗಿ ವಿಭಿನ್ನ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತಾರೆ.

ನಿಯೋಜನೆಯನ್ನು ಹೊಂದಿರುವ 3 ಸರ್ವರ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪರಿಗಣಿಸಿ. ಇದು 6 ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದೆ: ಈಗ ಪ್ರತಿ ಸರ್ವರ್‌ಗೆ 2 ಇವೆ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನಾವು ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಫ್ ಮಾಡಲು ಬಯಸಿದ್ದೇವೆ. ಇದನ್ನು ಮಾಡಲು ನಾವು ಆಜ್ಞೆಯನ್ನು ಬಳಸುತ್ತೇವೆ kubectl drain, ಇದು:

• ಈ ಸರ್ವರ್‌ಗೆ ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ಕಳುಹಿಸುವುದನ್ನು ನಿಷೇಧಿಸುತ್ತದೆ;
• ಸರ್ವರ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪಾಡ್‌ಗಳನ್ನು ಅಳಿಸುತ್ತದೆ.

ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು (6) ನಿರ್ವಹಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಜವಾಬ್ದಾರನಾಗಿರುವುದರಿಂದ, ಅದು ಸರಳವಾಗಿದೆ ಮರುಸೃಷ್ಟಿಸುತ್ತದೆ ಅವುಗಳನ್ನು ಇತರ ನೋಡ್‌ಗಳಲ್ಲಿ, ಆದರೆ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಿದ ಮೇಲೆ ಅಲ್ಲ, ಏಕೆಂದರೆ ಹೊಸ ಪಾಡ್‌ಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡಲು ಇದು ಈಗಾಗಲೇ ಲಭ್ಯವಿಲ್ಲ ಎಂದು ಗುರುತಿಸಲಾಗಿದೆ. ಇದು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಮೂಲಭೂತ ಮೆಕ್ಯಾನಿಕ್ ಆಗಿದೆ.

ಆದಾಗ್ಯೂ, ಇಲ್ಲಿಯೂ ಒಂದು ಸೂಕ್ಷ್ಮ ವ್ಯತ್ಯಾಸವಿದೆ. ಇದೇ ರೀತಿಯ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗೆ (ನಿಯೋಜನೆಯ ಬದಲಿಗೆ), ಕ್ರಮಗಳು ವಿಭಿನ್ನವಾಗಿರುತ್ತದೆ. ಈಗ ನಾವು ಈಗಾಗಲೇ ಸ್ಟೇಟ್‌ಫುಲ್ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಉದಾಹರಣೆಗೆ, ಮೊಂಗೊಡಿಬಿಯೊಂದಿಗೆ ಮೂರು ಪಾಡ್‌ಗಳು, ಅವುಗಳಲ್ಲಿ ಒಂದು ಕೆಲವು ರೀತಿಯ ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ (ಡೇಟಾ ದೋಷಪೂರಿತವಾಗಿದೆ ಅಥವಾ ಪಾಡ್ ಸರಿಯಾಗಿ ಪ್ರಾರಂಭವಾಗುವುದನ್ನು ತಡೆಯುವ ಇನ್ನೊಂದು ದೋಷ). ಮತ್ತು ನಾವು ಮತ್ತೊಮ್ಮೆ ಒಂದು ಸರ್ವರ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ನಿರ್ಧರಿಸುತ್ತೇವೆ. ಏನಾಗುವುದೆಂದು?

ಮೊಂಗೋಡಬ್ಬಿ ಸಾಧ್ಯವೋ ಸಾಯುವ ಕಾರಣ ಇದಕ್ಕೆ ಕೋರಂ ಅಗತ್ಯವಿದೆ: ಮೂರು ಸ್ಥಾಪನೆಗಳ ಕ್ಲಸ್ಟರ್‌ಗೆ, ಕನಿಷ್ಠ ಎರಡು ಕಾರ್ಯನಿರ್ವಹಿಸಬೇಕು. ಆದಾಗ್ಯೂ, ಈ ನಡೆಯುತ್ತಿಲ್ಲ - ಇವರಿಗೆ ಧನ್ಯವಾದಗಳು PodDisruptionBudget. ಈ ಪ್ಯಾರಾಮೀಟರ್ ಅಗತ್ಯವಿರುವ ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಕೆಲಸದ ಪಾಡ್‌ಗಳನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ. MongoDB ಪಾಡ್‌ಗಳಲ್ಲಿ ಒಂದು ಇನ್ನು ಮುಂದೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂದು ತಿಳಿದುಕೊಂಡು, PodDisruptionBudget ಅನ್ನು MongoDB ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ minAvailable: 2, ಕುಬರ್ನೆಟ್ಸ್ ನಿಮಗೆ ಪಾಡ್ ಅನ್ನು ಅಳಿಸಲು ಅನುಮತಿಸುವುದಿಲ್ಲ.

ಬಾಟಮ್ ಲೈನ್: ಕ್ಲಸ್ಟರ್ ಬಿಡುಗಡೆಯಾದಾಗ ಪಾಡ್‌ಗಳ ಚಲನೆ (ಮತ್ತು ವಾಸ್ತವವಾಗಿ, ಮರು-ಸೃಷ್ಟಿ) ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡಲು, PodDisruptionBudget ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದು ಅವಶ್ಯಕ.

ಸಮತಲ ಸ್ಕೇಲಿಂಗ್

ಇನ್ನೊಂದು ಸನ್ನಿವೇಶವನ್ನು ಪರಿಗಣಿಸೋಣ. ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ನಿಯೋಜನೆಯಂತೆ ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿದೆ. ಬಳಕೆದಾರರ ದಟ್ಟಣೆಯು ಅದರ ಪಾಡ್‌ಗಳಿಗೆ ಬರುತ್ತದೆ (ಉದಾಹರಣೆಗೆ, ಅವುಗಳಲ್ಲಿ ಮೂರು ಇವೆ), ಮತ್ತು ನಾವು ಅವುಗಳಲ್ಲಿ ಒಂದು ನಿರ್ದಿಷ್ಟ ಸೂಚಕವನ್ನು ಅಳೆಯುತ್ತೇವೆ (ಸೇ, ಸಿಪಿಯು ಲೋಡ್). ಲೋಡ್ ಹೆಚ್ಚಾದಾಗ, ನಾವು ಇದನ್ನು ವೇಳಾಪಟ್ಟಿಯಲ್ಲಿ ರೆಕಾರ್ಡ್ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ವಿನಂತಿಗಳನ್ನು ವಿತರಿಸಲು ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತೇವೆ.

ಇಂದು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಇದನ್ನು ಕೈಯಾರೆ ಮಾಡಬೇಕಾಗಿಲ್ಲ: ಅಳತೆ ಮಾಡಿದ ಲೋಡ್ ಸೂಚಕಗಳ ಮೌಲ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತ ಹೆಚ್ಚಳ / ಇಳಿಕೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ.

ಇಲ್ಲಿ ಮುಖ್ಯ ಪ್ರಶ್ನೆಗಳು: ನಿಖರವಾಗಿ ಏನು ಅಳೆಯಬೇಕು и ಹೇಗೆ ಅರ್ಥೈಸುವುದು ಪಡೆದ ಮೌಲ್ಯಗಳು (ಪಾಡ್ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಬದಲಾಯಿಸುವ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲು). ನೀವು ಬಹಳಷ್ಟು ಅಳೆಯಬಹುದು:

ತಾಂತ್ರಿಕವಾಗಿ ಇದನ್ನು ಹೇಗೆ ಮಾಡುವುದು - ಮಾಪನಗಳನ್ನು ಸಂಗ್ರಹಿಸಿ, ಇತ್ಯಾದಿ. - ನಾನು ವರದಿಯಲ್ಲಿ ವಿವರವಾಗಿ ಮಾತನಾಡಿದ್ದೇನೆ ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್. ಮತ್ತು ಸೂಕ್ತವಾದ ನಿಯತಾಂಕಗಳನ್ನು ಆಯ್ಕೆಮಾಡುವ ಮುಖ್ಯ ಸಲಹೆ ಪ್ರಯೋಗ!

ಇವೆ ವಿಧಾನವನ್ನು ಬಳಸಿ (ಬಳಕೆಯ ಶುದ್ಧತ್ವ ಮತ್ತು ದೋಷಗಳು), ಇದರ ಅರ್ಥವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ. ಯಾವ ಆಧಾರದ ಮೇಲೆ ಅಳೆಯಲು ಇದು ಅರ್ಥಪೂರ್ಣವಾಗಿದೆ, ಉದಾಹರಣೆಗೆ, php-fpm? ಕಾರ್ಮಿಕರು ಖಾಲಿಯಾಗುತ್ತಿದ್ದಾರೆ ಎಂಬ ಅಂಶವನ್ನು ಆಧರಿಸಿ, ಇದು ಬಳಕೆ. ಮತ್ತು ಕೆಲಸಗಾರರು ಮುಗಿದಿದ್ದರೆ ಮತ್ತು ಹೊಸ ಸಂಪರ್ಕಗಳನ್ನು ಸ್ವೀಕರಿಸದಿದ್ದರೆ, ಇದು ಈಗಾಗಲೇ ಆಗಿದೆ ಶುದ್ಧತ್ವ. ಈ ಎರಡೂ ನಿಯತಾಂಕಗಳನ್ನು ಅಳೆಯಬೇಕು, ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಅವಲಂಬಿಸಿ, ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ಕೈಗೊಳ್ಳಬೇಕು.

ಬದಲಿಗೆ ತೀರ್ಮಾನದ

ವರದಿಯು ಮುಂದುವರಿಕೆಯನ್ನು ಹೊಂದಿದೆ: ಲಂಬ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಸರಿಯಾದ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ಆಯ್ಕೆ ಮಾಡುವುದು. ಮುಂದಿನ ವೀಡಿಯೊಗಳಲ್ಲಿ ನಾನು ಇದರ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ ನಮ್ಮ YouTube - ಚಂದಾದಾರರಾಗಿ ಆದ್ದರಿಂದ ನೀವು ತಪ್ಪಿಸಿಕೊಳ್ಳಬೇಡಿ!

ವೀಡಿಯೊಗಳು ಮತ್ತು ಸ್ಲೈಡ್‌ಗಳು

ಪ್ರದರ್ಶನದ ವೀಡಿಯೊ (44 ನಿಮಿಷಗಳು):

ವರದಿಯ ಮಂಡನೆ:

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಕುರಿತು ಇತರ ವರದಿಗಳು:

• «ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ವಿಸ್ತರಿಸುವುದು ಮತ್ತು ಪೂರಕಗೊಳಿಸುವುದು» (ಆಂಡ್ರೆ ಪೊಲೊವೊವ್; ಏಪ್ರಿಲ್ 8, 2019 ಸೇಂಟ್ ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಡೇಟಾಬೇಸ್‌ಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 8, 2018 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಮಾನಿಟರಿಂಗ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಮೇ 28, 2018 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ);
• «ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು GitLab ನೊಂದಿಗೆ CI/CD ಅತ್ಯುತ್ತಮ ಅಭ್ಯಾಸಗಳು» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ನವೆಂಬರ್ 7, 2017 ಹೈಲೋಡ್++ ನಲ್ಲಿ);
• «ಸಣ್ಣ ಯೋಜನೆಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಜೊತೆಗಿನ ನಮ್ಮ ಅನುಭವ» (ಡಿಮಿಟ್ರಿ ಸ್ಟೋಲಿಯಾರೋವ್; ಜೂನ್ 6, 2017 ರೂಟ್‌ಕಾನ್ಫ್‌ನಲ್ಲಿ).

ಮೂಲ: www.habr.com