ಡೊಮ್‌ಕ್ಲಿಕ್‌ನಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್: 1000 ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ಶಾಂತಿಯುತವಾಗಿ ನಿರ್ವಹಿಸುವುದು

ನನ್ನ ಹೆಸರು Viktor Yagofarov, ಮತ್ತು ನಾನು Ops (ಕಾರ್ಯಾಚರಣೆ) ತಂಡದಲ್ಲಿ ತಾಂತ್ರಿಕ ಅಭಿವೃದ್ಧಿ ವ್ಯವಸ್ಥಾಪಕರಾಗಿ DomClick ನಲ್ಲಿ Kubernetes ವೇದಿಕೆಯನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತಿದ್ದೇನೆ. ನಮ್ಮ Dev <-> Ops ಪ್ರಕ್ರಿಯೆಗಳ ರಚನೆ, ರಷ್ಯಾದಲ್ಲಿ ಅತಿದೊಡ್ಡ k8s ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಒಂದನ್ನು ನಿರ್ವಹಿಸುವ ವೈಶಿಷ್ಟ್ಯಗಳು ಮತ್ತು ನಮ್ಮ ತಂಡವು ಅನ್ವಯಿಸುವ DevOps/SRE ಅಭ್ಯಾಸಗಳ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನಾನು ಬಯಸುತ್ತೇನೆ.

ಆಪ್ಸ್ ತಂಡ

ಆಪ್ಸ್ ತಂಡವು ಪ್ರಸ್ತುತ 15 ಜನರನ್ನು ಹೊಂದಿದೆ. ಅವರಲ್ಲಿ ಮೂವರು ಕಚೇರಿಯ ಜವಾಬ್ದಾರಿಯನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಇಬ್ಬರು ಬೇರೆ ಬೇರೆ ಸಮಯ ವಲಯದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ ಮತ್ತು ರಾತ್ರಿಯೂ ಸೇರಿದಂತೆ ಲಭ್ಯವಿರುತ್ತಾರೆ. ಹೀಗಾಗಿ, Ops ನಿಂದ ಯಾರಾದರೂ ಯಾವಾಗಲೂ ಮಾನಿಟರ್‌ನಲ್ಲಿರುತ್ತಾರೆ ಮತ್ತು ಯಾವುದೇ ಸಂಕೀರ್ಣತೆಯ ಘಟನೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಿದ್ಧರಾಗಿದ್ದಾರೆ. ನಾವು ರಾತ್ರಿ ಪಾಳಿಗಳನ್ನು ಹೊಂದಿಲ್ಲ, ಇದು ನಮ್ಮ ಮನಸ್ಸನ್ನು ಸಂರಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಎಲ್ಲರಿಗೂ ಸಾಕಷ್ಟು ನಿದ್ರೆ ಪಡೆಯಲು ಮತ್ತು ಕಂಪ್ಯೂಟರ್ನಲ್ಲಿ ಮಾತ್ರ ವಿರಾಮ ಸಮಯವನ್ನು ಕಳೆಯಲು ಅವಕಾಶವನ್ನು ನೀಡುತ್ತದೆ.

ಪ್ರತಿಯೊಬ್ಬರೂ ವಿಭಿನ್ನ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ: ನೆಟ್‌ವರ್ಕರ್‌ಗಳು, DBAಗಳು, ELK ಸ್ಟಾಕ್ ತಜ್ಞರು, ಕುಬರ್ನೆಟ್ಸ್ ನಿರ್ವಾಹಕರು/ಡೆವಲಪರ್‌ಗಳು, ಮೇಲ್ವಿಚಾರಣೆ, ವರ್ಚುವಲೈಸೇಶನ್, ಹಾರ್ಡ್‌ವೇರ್ ತಜ್ಞರು, ಇತ್ಯಾದಿ. ಒಂದು ವಿಷಯ ಎಲ್ಲರನ್ನೂ ಒಂದುಗೂಡಿಸುತ್ತದೆ - ಪ್ರತಿಯೊಬ್ಬರೂ ನಮ್ಮಲ್ಲಿ ಯಾರನ್ನಾದರೂ ಸ್ವಲ್ಪ ಮಟ್ಟಿಗೆ ಬದಲಾಯಿಸಬಹುದು: ಉದಾಹರಣೆಗೆ, k8s ಕ್ಲಸ್ಟರ್‌ಗೆ ಹೊಸ ನೋಡ್‌ಗಳನ್ನು ಪರಿಚಯಿಸಿ, PostgreSQL ಅನ್ನು ನವೀಕರಿಸಿ, CI/CD + Ansible ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಬರೆಯಿರಿ, ಪೈಥಾನ್/ಬ್ಯಾಶ್/ಗೋದಲ್ಲಿ ಏನನ್ನಾದರೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿ, ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಿ ಡೇಟಾ ಸೆಂಟರ್. ಯಾವುದೇ ಪ್ರದೇಶದಲ್ಲಿನ ಬಲವಾದ ಸಾಮರ್ಥ್ಯಗಳು ನಿಮ್ಮ ಚಟುವಟಿಕೆಯ ದಿಕ್ಕನ್ನು ಬದಲಾಯಿಸುವುದನ್ನು ಮತ್ತು ಇತರ ಕೆಲವು ಕ್ಷೇತ್ರದಲ್ಲಿ ಸುಧಾರಿಸಲು ಪ್ರಾರಂಭಿಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ನಾನು PostgreSQL ತಜ್ಞರಾಗಿ ಕಂಪನಿಗೆ ಸೇರಿಕೊಂಡೆ, ಮತ್ತು ಈಗ ನನ್ನ ಮುಖ್ಯ ಜವಾಬ್ದಾರಿಯ ಕ್ಷೇತ್ರವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳು. ತಂಡದಲ್ಲಿ, ಯಾವುದೇ ಎತ್ತರವು ಸ್ವಾಗತಾರ್ಹ ಮತ್ತು ಹತೋಟಿಯ ಅರ್ಥವು ಬಹಳ ಅಭಿವೃದ್ಧಿಗೊಂಡಿದೆ.

ಮೂಲಕ, ನಾವು ಬೇಟೆಯಾಡುತ್ತಿದ್ದೇವೆ. ಅಭ್ಯರ್ಥಿಗಳಿಗೆ ಅಗತ್ಯತೆಗಳು ಸಾಕಷ್ಟು ಪ್ರಮಾಣಿತವಾಗಿವೆ. ವೈಯಕ್ತಿಕವಾಗಿ, ಒಬ್ಬ ವ್ಯಕ್ತಿಯು ತಂಡಕ್ಕೆ ಹೊಂದಿಕೊಳ್ಳುವುದು, ಸಂಘರ್ಷವಿಲ್ಲದವನು, ಆದರೆ ತನ್ನ ದೃಷ್ಟಿಕೋನವನ್ನು ಹೇಗೆ ಸಮರ್ಥಿಸಿಕೊಳ್ಳಬೇಕೆಂದು ತಿಳಿದಿರುವುದು, ಅಭಿವೃದ್ಧಿಪಡಿಸಲು ಬಯಸುತ್ತಾನೆ ಮತ್ತು ಹೊಸದನ್ನು ಮಾಡಲು ಹೆದರುವುದಿಲ್ಲ ಮತ್ತು ಅವನ ಆಲೋಚನೆಗಳನ್ನು ನೀಡುವುದು ನನಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಅಲ್ಲದೆ, ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ಭಾಷೆಗಳಲ್ಲಿ ಪ್ರೋಗ್ರಾಮಿಂಗ್ ಕೌಶಲ್ಯಗಳು, ಲಿನಕ್ಸ್ ಮತ್ತು ಇಂಗ್ಲಿಷ್‌ನ ಮೂಲಭೂತ ಜ್ಞಾನದ ಅಗತ್ಯವಿದೆ. ಇಂಗ್ಲಿಷ್ ಸರಳವಾಗಿ ಅಗತ್ಯವಿದೆ ಆದ್ದರಿಂದ ಫಕಾಪ್ ಸಂದರ್ಭದಲ್ಲಿ ವ್ಯಕ್ತಿಯು 10 ಸೆಕೆಂಡುಗಳಲ್ಲಿ ಸಮಸ್ಯೆಗೆ ಪರಿಹಾರವನ್ನು ಗೂಗಲ್ ಮಾಡಬಹುದು ಮತ್ತು 10 ನಿಮಿಷಗಳಲ್ಲಿ ಅಲ್ಲ. ಲಿನಕ್ಸ್‌ನ ಆಳವಾದ ಜ್ಞಾನವನ್ನು ಹೊಂದಿರುವ ತಜ್ಞರನ್ನು ಕಂಡುಹಿಡಿಯುವುದು ಈಗ ತುಂಬಾ ಕಷ್ಟ: ಇದು ತಮಾಷೆಯಾಗಿದೆ, ಆದರೆ ಮೂವರಲ್ಲಿ ಇಬ್ಬರು ಅಭ್ಯರ್ಥಿಗಳು “ಲೋಡ್ ಸರಾಸರಿ ಎಂದರೇನು? ಇದು ಏನು ಮಾಡಲ್ಪಟ್ಟಿದೆ?", ಮತ್ತು "ಸಿ ಪ್ರೋಗ್ರಾಂನಿಂದ ಕೋರ್ ಡಂಪ್ ಅನ್ನು ಹೇಗೆ ಜೋಡಿಸುವುದು" ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಸೂಪರ್‌ಮೆನ್ ... ಅಥವಾ ಡೈನೋಸಾರ್‌ಗಳ ಪ್ರಪಂಚದಿಂದ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ. ನಾವು ಇದನ್ನು ಸಹಿಸಿಕೊಳ್ಳಬೇಕು, ಏಕೆಂದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಜನರು ಇತರ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಹೆಚ್ಚು ಅಭಿವೃದ್ಧಿಪಡಿಸಿದ್ದಾರೆ, ಆದರೆ ನಾವು ಲಿನಕ್ಸ್ ಅನ್ನು ಕಲಿಸುತ್ತೇವೆ. "ಆಧುನಿಕ ಮೋಡಗಳ ಜಗತ್ತಿನಲ್ಲಿ DevOps ಎಂಜಿನಿಯರ್‌ಗಳು ಇದನ್ನೆಲ್ಲ ಏಕೆ ತಿಳಿದುಕೊಳ್ಳಬೇಕು" ಎಂಬ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವನ್ನು ಲೇಖನದ ವ್ಯಾಪ್ತಿಯಿಂದ ಹೊರಗೆ ಬಿಡಬೇಕಾಗುತ್ತದೆ, ಆದರೆ ಮೂರು ಪದಗಳಲ್ಲಿ: ಇದೆಲ್ಲವೂ ಅಗತ್ಯವಿದೆ.

ತಂಡದ ಪರಿಕರಗಳು

ಯಾಂತ್ರೀಕರಣದಲ್ಲಿ ಪರಿಕರಗಳ ತಂಡವು ಮಹತ್ವದ ಪಾತ್ರವನ್ನು ವಹಿಸುತ್ತದೆ. ಅಭಿವರ್ಧಕರಿಗೆ ಅನುಕೂಲಕರವಾದ ಚಿತ್ರಾತ್ಮಕ ಮತ್ತು CLI ಪರಿಕರಗಳನ್ನು ರಚಿಸುವುದು ಅವರ ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ. ಉದಾಹರಣೆಗೆ, ನಮ್ಮ ಆಂತರಿಕ ಅಭಿವೃದ್ಧಿ ಸಮ್ಮೇಳನವು ಕೆಲವೇ ಮೌಸ್ ಕ್ಲಿಕ್‌ಗಳೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಕ್ಷರಶಃ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ರೋಲ್ ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ, ಅದರ ಸಂಪನ್ಮೂಲಗಳು, ವಾಲ್ಟ್‌ನಿಂದ ಕೀಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ. ಹಿಂದೆ, ಜೆಂಕಿನ್ಸ್ + ಹೆಲ್ಮ್ 2 ಇತ್ತು, ಆದರೆ ಕಾಪಿ-ಪೇಸ್ಟ್ ಅನ್ನು ತೊಡೆದುಹಾಕಲು ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರಕ್ಕೆ ಏಕರೂಪತೆಯನ್ನು ತರಲು ನಾನು ನನ್ನ ಸ್ವಂತ ಸಾಧನವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಬೇಕಾಗಿತ್ತು.

Ops ತಂಡವು ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ಪೈಪ್‌ಲೈನ್‌ಗಳನ್ನು ಬರೆಯುವುದಿಲ್ಲ, ಆದರೆ ಅವರ ಬರವಣಿಗೆಯಲ್ಲಿ ಯಾವುದೇ ಸಮಸ್ಯೆಗಳ ಬಗ್ಗೆ ಸಲಹೆ ನೀಡಬಹುದು (ಕೆಲವರು ಇನ್ನೂ ಹೆಲ್ಮ್ 3 ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ).

DevOps

DevOps ಗಾಗಿ, ನಾವು ಇದನ್ನು ಈ ರೀತಿ ನೋಡುತ್ತೇವೆ:

ದೇವ್ ತಂಡಗಳು ಕೋಡ್ ಅನ್ನು ಬರೆಯುತ್ತವೆ, ಅದನ್ನು ಕಾನ್ಫರ್ ಟು dev -> qa/stage -> prod ಮೂಲಕ ಹೊರತರುತ್ತವೆ. ಕೋಡ್ ನಿಧಾನವಾಗುವುದಿಲ್ಲ ಮತ್ತು ದೋಷಗಳನ್ನು ಹೊಂದಿರುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವ ಜವಾಬ್ದಾರಿಯು Dev ಮತ್ತು Ops ತಂಡಗಳ ಮೇಲಿರುತ್ತದೆ. ಹಗಲಿನ ವೇಳೆಯಲ್ಲಿ, ಓಪ್ಸ್ ತಂಡದಿಂದ ಕರ್ತವ್ಯದಲ್ಲಿರುವ ವ್ಯಕ್ತಿಯು ಮೊದಲು ತನ್ನ ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ಘಟನೆಗೆ ಪ್ರತಿಕ್ರಿಯಿಸಬೇಕು ಮತ್ತು ಸಂಜೆ ಮತ್ತು ರಾತ್ರಿಯಲ್ಲಿ, ಕರ್ತವ್ಯದಲ್ಲಿರುವ ನಿರ್ವಾಹಕರು (ಆಪ್ಸ್) ಡೆವಲಪರ್‌ಗೆ ತಿಳಿದಿದ್ದರೆ ಕರ್ತವ್ಯದಲ್ಲಿರುವ ಡೆವಲಪರ್ ಅನ್ನು ಎಚ್ಚರಗೊಳಿಸಬೇಕು. ಸಮಸ್ಯೆ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿಲ್ಲ ಎಂಬುದು ಖಚಿತ. ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಎಲ್ಲಾ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅಥವಾ ಅರೆ-ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಗೋಚರಿಸುತ್ತವೆ.

ಆಪ್ಸ್‌ನ ಜವಾಬ್ದಾರಿಯ ಪ್ರದೇಶವು ಅಪ್ಲಿಕೇಶನ್ ಉತ್ಪಾದನೆಗೆ ಹೊರತಂದ ಕ್ಷಣದಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಆದರೆ ದೇವ್‌ನ ಜವಾಬ್ದಾರಿಯು ಅಲ್ಲಿಗೆ ಕೊನೆಗೊಳ್ಳುವುದಿಲ್ಲ - ನಾವು ಅದೇ ಕೆಲಸವನ್ನು ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಒಂದೇ ದೋಣಿಯಲ್ಲಿದ್ದೇವೆ.

ಡೆವಲಪರ್‌ಗಳು ನಿರ್ವಾಹಕರಿಗೆ ನಿರ್ವಾಹಕರು ಮೈಕ್ರೋಸರ್ವಿಸ್ ಬರೆಯಲು ಸಹಾಯ ಮಾಡಲು ಸಲಹೆ ನೀಡುತ್ತಾರೆ (ಉದಾಹರಣೆಗೆ, ಗೋ ಬ್ಯಾಕೆಂಡ್ + HTML5), ಮತ್ತು ನಿರ್ವಾಹಕರು ಡೆವಲಪರ್‌ಗಳಿಗೆ ಯಾವುದೇ ಮೂಲಸೌಕರ್ಯ ಸಮಸ್ಯೆಗಳು ಅಥವಾ k8s ಗೆ ಸಂಬಂಧಿಸಿದ ಸಮಸ್ಯೆಗಳಿಗೆ ಸಲಹೆ ನೀಡುತ್ತಾರೆ.

ಅಂದಹಾಗೆ, ನಮ್ಮಲ್ಲಿ ಏಕಶಿಲೆ ಇಲ್ಲ, ಮೈಕ್ರೋ ಸರ್ವೀಸ್ ಮಾತ್ರ. ಸಂಖ್ಯೆಯಿಂದ ಮಾಪನ ಮಾಡಿದರೆ ಪ್ರಾಡ್ k900s ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಅವರ ಸಂಖ್ಯೆ ಇದುವರೆಗೆ 1000 ಮತ್ತು 8 ನಡುವೆ ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ ನಿಯೋಜನೆಗಳು. ಕಾಯಿಗಳ ಸಂಖ್ಯೆಯು 1700 ಮತ್ತು 2000 ನಡುವೆ ಏರಿಳಿತಗೊಳ್ಳುತ್ತದೆ. ಪ್ರಸ್ತುತ 2000 ಕಾಯಿಗಳು ಪ್ರಾಡ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿವೆ.

ನಾನು ನಿಖರವಾದ ಸಂಖ್ಯೆಗಳನ್ನು ನೀಡಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಅನಗತ್ಯ ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ ಮತ್ತು ಅವುಗಳನ್ನು ಅರೆ-ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕತ್ತರಿಸುತ್ತೇವೆ. K8s ನಮಗೆ ಅನಗತ್ಯ ಘಟಕಗಳನ್ನು ಟ್ರ್ಯಾಕ್ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಅನುಪಯುಕ್ತ-ಆಪರೇಟರ್, ಇದು ಬಹಳಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಹಣವನ್ನು ಉಳಿಸುತ್ತದೆ.

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

ಮಾನಿಟರಿಂಗ್

ಉತ್ತಮ-ರಚನಾತ್ಮಕ ಮತ್ತು ತಿಳಿವಳಿಕೆ ಮೇಲ್ವಿಚಾರಣೆಯು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್‌ನ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಮೂಲಾಧಾರವಾಗುತ್ತದೆ. ಎಲ್ಲಾ ಮೇಲ್ವಿಚಾರಣಾ ಅಗತ್ಯಗಳ 100% ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವನ್ನು ನಾವು ಇನ್ನೂ ಕಂಡುಕೊಂಡಿಲ್ಲ, ಆದ್ದರಿಂದ ನಾವು ಈ ಪರಿಸರದಲ್ಲಿ ನಿಯತಕಾಲಿಕವಾಗಿ ವಿಭಿನ್ನ ಕಸ್ಟಮ್ ಪರಿಹಾರಗಳನ್ನು ರಚಿಸುತ್ತೇವೆ.

• ಜಬ್ಬಿಕ್ಸ್. ಉತ್ತಮ ಹಳೆಯ ಮೇಲ್ವಿಚಾರಣೆ, ಇದು ಪ್ರಾಥಮಿಕವಾಗಿ ಮೂಲಸೌಕರ್ಯದ ಒಟ್ಟಾರೆ ಸ್ಥಿತಿಯನ್ನು ಪತ್ತೆಹಚ್ಚಲು ಉದ್ದೇಶಿಸಲಾಗಿದೆ. ಸಂಸ್ಕರಣೆ, ಮೆಮೊರಿ, ಡಿಸ್ಕ್ಗಳು, ನೆಟ್‌ವರ್ಕ್ ಇತ್ಯಾದಿಗಳ ವಿಷಯದಲ್ಲಿ ನೋಡ್ ಸಾಯುವಾಗ ಅದು ನಮಗೆ ಹೇಳುತ್ತದೆ. ಅಲೌಕಿಕ ಏನೂ ಇಲ್ಲ, ಆದರೆ ನಾವು ಏಜೆಂಟ್‌ಗಳ ಪ್ರತ್ಯೇಕ ಡೇಮನ್‌ಸೆಟ್ ಅನ್ನು ಸಹ ಹೊಂದಿದ್ದೇವೆ, ಅದರ ಸಹಾಯದಿಂದ, ಉದಾಹರಣೆಗೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಾವು ಡಿಎನ್‌ಎಸ್ ಸ್ಥಿತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುತ್ತೇವೆ: ನಾವು ಸ್ಟುಪಿಡ್ ಕೋರೆಡ್ನ್ಸ್ ಪಾಡ್‌ಗಳನ್ನು ಹುಡುಕುತ್ತೇವೆ, ಬಾಹ್ಯ ಹೋಸ್ಟ್‌ಗಳ ಲಭ್ಯತೆಯನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಇದರ ಬಗ್ಗೆ ಏಕೆ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳಬೇಕು ಎಂದು ತೋರುತ್ತದೆ, ಆದರೆ ದೊಡ್ಡ ಪ್ರಮಾಣದ ದಟ್ಟಣೆಯೊಂದಿಗೆ ಈ ಘಟಕವು ವೈಫಲ್ಯದ ಗಂಭೀರ ಅಂಶವಾಗಿದೆ. ಈಗಾಗಲೇ ನಾನು ವಿವರಿಸಲಾಗಿದೆ, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ DNS ಕಾರ್ಯಕ್ಷಮತೆಯೊಂದಿಗೆ ನಾನು ಹೇಗೆ ಹೋರಾಡಿದೆ.
• ಪ್ರಮೀತಿಯಸ್ ಆಪರೇಟರ್. ವಿವಿಧ ರಫ್ತುದಾರರ ಒಂದು ಸೆಟ್ ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ಘಟಕಗಳ ದೊಡ್ಡ ಅವಲೋಕನವನ್ನು ನೀಡುತ್ತದೆ. ಮುಂದೆ, ನಾವು ಗ್ರಾಫನಾದಲ್ಲಿನ ದೊಡ್ಡ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳಲ್ಲಿ ಇದನ್ನೆಲ್ಲ ದೃಶ್ಯೀಕರಿಸುತ್ತೇವೆ ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳಿಗಾಗಿ ಅಲರ್ಟ್‌ಮ್ಯಾನೇಜರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ.

ನಮಗೆ ಮತ್ತೊಂದು ಉಪಯುಕ್ತ ಸಾಧನವಾಗಿತ್ತು ಪಟ್ಟಿ-ಪ್ರವೇಶ. ಒಂದು ತಂಡವು ಮತ್ತೊಂದು ತಂಡದ ಪ್ರವೇಶ ಮಾರ್ಗಗಳನ್ನು ಅತಿಕ್ರಮಿಸುವಂತಹ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಹಲವಾರು ಬಾರಿ ಎದುರಿಸಿದ ನಂತರ ನಾವು ಅದನ್ನು ಬರೆದಿದ್ದೇವೆ, ಇದರ ಪರಿಣಾಮವಾಗಿ 50x ದೋಷಗಳು ಉಂಟಾಗುತ್ತವೆ. ಈಗ ಉತ್ಪಾದನೆಗೆ ನಿಯೋಜಿಸುವ ಮೊದಲು, ಡೆವಲಪರ್‌ಗಳು ಯಾರೂ ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತಾರೆ ಮತ್ತು ನನ್ನ ತಂಡಕ್ಕೆ ಇದು ಪ್ರವೇಶದೊಂದಿಗಿನ ಸಮಸ್ಯೆಗಳ ಆರಂಭಿಕ ರೋಗನಿರ್ಣಯಕ್ಕೆ ಉತ್ತಮ ಸಾಧನವಾಗಿದೆ. ಮೊದಲಿಗೆ ಇದನ್ನು ನಿರ್ವಾಹಕರಿಗಾಗಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಅದು "ಬೃಹದಾಕಾರದ" ಎಂದು ತೋರುತ್ತಿತ್ತು, ಆದರೆ ದೇವ್ ತಂಡಗಳು ಉಪಕರಣವನ್ನು ಪ್ರೀತಿಸಿದ ನಂತರ, ಅದು ಬಹಳಷ್ಟು ಬದಲಾಗಿದೆ ಮತ್ತು "ನಿರ್ವಾಹಕರು ನಿರ್ವಾಹಕರಿಗಾಗಿ ವೆಬ್ ಮುಖವನ್ನು ಮಾಡಿದ್ದಾರೆ" ಎಂದು ತೋರುತ್ತಿಲ್ಲ. ” ಶೀಘ್ರದಲ್ಲೇ ನಾವು ಈ ಉಪಕರಣವನ್ನು ತ್ಯಜಿಸುತ್ತೇವೆ ಮತ್ತು ಪೈಪ್‌ಲೈನ್ ಹೊರತರುವ ಮೊದಲೇ ಅಂತಹ ಸಂದರ್ಭಗಳನ್ನು ಮೌಲ್ಯೀಕರಿಸಲಾಗುತ್ತದೆ.

ಕ್ಯೂಬ್‌ನಲ್ಲಿ ತಂಡದ ಸಂಪನ್ಮೂಲಗಳು

ನಾವು ಉದಾಹರಣೆಗಳಿಗೆ ಪ್ರವೇಶಿಸುವ ಮೊದಲು, ನಾವು ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೇಗೆ ನಿಯೋಜಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ವಿವರಿಸುವುದು ಯೋಗ್ಯವಾಗಿದೆ ಸೂಕ್ಷ್ಮ ಸೇವೆಗಳು.

ಯಾವ ತಂಡಗಳು ಮತ್ತು ಯಾವ ಪ್ರಮಾಣದಲ್ಲಿ ಅವುಗಳನ್ನು ಬಳಸುತ್ತವೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಸಂಪನ್ಮೂಲಗಳು (ಪ್ರೊಸೆಸರ್, ಮೆಮೊರಿ, ಸ್ಥಳೀಯ ಎಸ್‌ಎಸ್‌ಡಿ), ನಾವು ಪ್ರತಿಯೊಂದು ಆಜ್ಞೆಯನ್ನು ತನ್ನದೇ ಆದ ರೀತಿಯಲ್ಲಿ ನಿಯೋಜಿಸುತ್ತೇವೆ ನೇಮ್‌ಸ್ಪೇಸ್ "ಕ್ಯೂಬ್" ನಲ್ಲಿ ಮತ್ತು ಪ್ರೊಸೆಸರ್, ಮೆಮೊರಿ ಮತ್ತು ಡಿಸ್ಕ್ನ ವಿಷಯದಲ್ಲಿ ಅದರ ಗರಿಷ್ಟ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಮಿತಿಗೊಳಿಸಿ, ಹಿಂದೆ ತಂಡಗಳ ಅಗತ್ಯತೆಗಳನ್ನು ಚರ್ಚಿಸಲಾಗಿದೆ. ಅಂತೆಯೇ, ಒಂದು ಆಜ್ಞೆಯು, ಸಾಮಾನ್ಯವಾಗಿ, ನಿಯೋಜನೆಗಾಗಿ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಬಂಧಿಸುವುದಿಲ್ಲ, ಸಾವಿರಾರು ಕೋರ್ಗಳು ಮತ್ತು ಟೆರಾಬೈಟ್ ಮೆಮೊರಿಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಪ್ರವೇಶವನ್ನು AD ಮೂಲಕ ನೀಡಲಾಗುತ್ತದೆ (ನಾವು RBAC ಅನ್ನು ಬಳಸುತ್ತೇವೆ). ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು ಮತ್ತು ಅವುಗಳ ಮಿತಿಗಳನ್ನು ಜಿಐಟಿ ರೆಪೊಸಿಟರಿಗೆ ಪುಲ್ ವಿನಂತಿಯ ಮೂಲಕ ಸೇರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ಎಲ್ಲವನ್ನೂ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಅನ್ಸಿಬಲ್ ಪೈಪ್‌ಲೈನ್ ಮೂಲಕ ಹೊರತೆಗೆಯಲಾಗುತ್ತದೆ.

ತಂಡಕ್ಕೆ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚುವ ಉದಾಹರಣೆ:

namespaces:

  chat-team:
    pods: 23
    limits:
      cpu: 11
      memory: 20Gi
    requests:
      cpu: 11
      memory: 20Gi

ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು

ಘನ ವಿನಂತಿ ಖಾತರಿಪಡಿಸಿದ ಕಾಯ್ದಿರಿಸಲಾದ ಸಂಪನ್ಮೂಲಗಳ ಸಂಖ್ಯೆ ಅಡಿಯಲ್ಲಿ (ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಡಾಕರ್ ಕಂಟೈನರ್) ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ. ಮಿತಿಯು ಖಾತರಿಯಿಲ್ಲದ ಗರಿಷ್ಠವಾಗಿದೆ. ಕೆಲವು ತಂಡವು ತನ್ನ ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಹಲವಾರು ವಿನಂತಿಗಳನ್ನು ಹೇಗೆ ಹೊಂದಿಸಿದೆ ಮತ್ತು "ಕ್ಯೂಬ್" ಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ, ಏಕೆಂದರೆ ಅವರ ಹೆಸರಿನಲ್ಲಿರುವ ಎಲ್ಲಾ ವಿನಂತಿಗಳನ್ನು ಈಗಾಗಲೇ "ಖರ್ಚು ಮಾಡಲಾಗಿದೆ" ಎಂದು ನೀವು ಆಗಾಗ್ಗೆ ಗ್ರಾಫ್‌ಗಳಲ್ಲಿ ನೋಡಬಹುದು.

ಈ ಪರಿಸ್ಥಿತಿಯಿಂದ ಹೊರಬರುವ ಸರಿಯಾದ ಮಾರ್ಗವೆಂದರೆ ನಿಜವಾದ ಸಂಪನ್ಮೂಲ ಬಳಕೆಯನ್ನು ನೋಡುವುದು ಮತ್ತು ಅದನ್ನು ವಿನಂತಿಸಿದ ಮೊತ್ತದೊಂದಿಗೆ ಹೋಲಿಸುವುದು (ವಿನಂತಿ).

ಮೇಲಿನ ಸ್ಕ್ರೀನ್‌ಶಾಟ್‌ಗಳಲ್ಲಿ "ವಿನಂತಿಸಿದ" CPUಗಳು ನೈಜ ಸಂಖ್ಯೆಯ ಥ್ರೆಡ್‌ಗಳಿಗೆ ಹೊಂದಿಕೆಯಾಗಿರುವುದನ್ನು ನೀವು ನೋಡಬಹುದು ಮತ್ತು ಮಿತಿಗಳು CPU ಥ್ರೆಡ್‌ಗಳ ನೈಜ ಸಂಖ್ಯೆಯನ್ನು ಮೀರಬಹುದು =)

ಈಗ ನಾವು ಕೆಲವು ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ವಿವರವಾಗಿ ನೋಡೋಣ (ನಾನು ನೇಮ್‌ಸ್ಪೇಸ್ ಕ್ಯೂಬ್-ಸಿಸ್ಟಮ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡಿದ್ದೇನೆ - “ಕ್ಯೂಬ್” ನ ಘಟಕಗಳಿಗೆ ಸಿಸ್ಟಮ್ ನೇಮ್‌ಸ್ಪೇಸ್) ಮತ್ತು ವಿನಂತಿಸಿದ ಒಂದಕ್ಕೆ ವಾಸ್ತವವಾಗಿ ಬಳಸಿದ ಪ್ರೊಸೆಸರ್ ಸಮಯ ಮತ್ತು ಮೆಮೊರಿಯ ಅನುಪಾತವನ್ನು ನೋಡಿ:

ವಾಸ್ತವವಾಗಿ ಬಳಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೆಮೊರಿ ಮತ್ತು ಸಿಪಿಯು ಸಿಸ್ಟಮ್ ಸೇವೆಗಳಿಗಾಗಿ ಕಾಯ್ದಿರಿಸಲಾಗಿದೆ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಗಿದೆ. ಕ್ಯೂಬ್-ಸಿಸ್ಟಮ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ಇದು ಸಮರ್ಥನೆಯಾಗಿದೆ: nginx ಪ್ರವೇಶ ನಿಯಂತ್ರಕ ಅಥವಾ ನೋಡೆಲೋಕಾಲ್ಡ್‌ಗಳು ಅವುಗಳ ಉತ್ತುಂಗದಲ್ಲಿ CPU ಅನ್ನು ಹೊಡೆದು ಸಾಕಷ್ಟು RAM ಅನ್ನು ಸೇವಿಸಿದವು, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಅಂತಹ ಮೀಸಲು ಸಮರ್ಥನೆಯಾಗಿದೆ. ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಾವು ಕಳೆದ 3 ಗಂಟೆಗಳ ಕಾಲ ಚಾರ್ಟ್‌ಗಳನ್ನು ಅವಲಂಬಿಸಲಾಗುವುದಿಲ್ಲ: ದೊಡ್ಡ ಅವಧಿಯಲ್ಲಿ ಐತಿಹಾಸಿಕ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ನೋಡಲು ಅಪೇಕ್ಷಣೀಯವಾಗಿದೆ.

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

ಮತ್ತು ಅವರ ಹಸಿವನ್ನು ನಿಗ್ರಹಿಸುವ ಪಾಡ್‌ಗಳು ಇಲ್ಲಿವೆ:

ಮೇಲೆ ಥ್ರೊಟ್ಲಿಂಗ್ + ಸಂಪನ್ಮೂಲ ಮೇಲ್ವಿಚಾರಣೆ, ನೀವು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಲೇಖನಗಳನ್ನು ಬರೆಯಬಹುದು, ಆದ್ದರಿಂದ ಕಾಮೆಂಟ್‌ಗಳಲ್ಲಿ ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಿ. ಕೆಲವು ಪದಗಳಲ್ಲಿ, ಅಂತಹ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ಕಾರ್ಯವು ತುಂಬಾ ಕಷ್ಟಕರವಾಗಿದೆ ಮತ್ತು “ವಿಂಡೋ” ಕಾರ್ಯಗಳು ಮತ್ತು “ಸಿಟಿಇ” ಪ್ರಮೀತಿಯಸ್ / ವಿಕ್ಟೋರಿಯಾಮೆಟ್ರಿಕ್ಸ್‌ನೊಂದಿಗೆ ಸಾಕಷ್ಟು ಸಮಯ ಮತ್ತು ಸಮತೋಲನ ಕ್ರಿಯೆಯ ಅಗತ್ಯವಿದೆ ಎಂದು ನಾನು ಹೇಳಬಲ್ಲೆ (ಈ ನಿಯಮಗಳು ಉಲ್ಲೇಖಗಳಲ್ಲಿವೆ, ಏಕೆಂದರೆ ಬಹುತೇಕ ಇವೆ PromQL ನಲ್ಲಿ ಈ ರೀತಿ ಏನೂ ಇಲ್ಲ, ಮತ್ತು ನೀವು ಭಯಾನಕ ಪ್ರಶ್ನೆಗಳನ್ನು ಪಠ್ಯದ ಹಲವಾರು ಪರದೆಗಳಾಗಿ ವಿಂಗಡಿಸಬೇಕು ಮತ್ತು ಅವುಗಳನ್ನು ಉತ್ತಮಗೊಳಿಸಬೇಕು).

ಇದರ ಪರಿಣಾಮವಾಗಿ, ಡೆವಲಪರ್‌ಗಳು ಕ್ಯೂಬ್‌ನಲ್ಲಿ ತಮ್ಮ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಪರಿಕರಗಳನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಎಲ್ಲಿ ಮತ್ತು ಯಾವ ಸಮಯದಲ್ಲಿ ತಮ್ಮ ಸಂಪನ್ಮೂಲಗಳನ್ನು "ಕಟ್" ಮಾಡಬಹುದು ಮತ್ತು ಯಾವ ಸರ್ವರ್‌ಗಳಿಗೆ ಸಂಪೂರ್ಣ CPU ಅನ್ನು ರಾತ್ರಿಯಿಡೀ ನೀಡಬಹುದು ಎಂಬುದನ್ನು ಸ್ವತಃ ಆಯ್ಕೆ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ವಿಧಾನಗಳು

ಈಗಿನಂತೆ ಕಂಪನಿಯಲ್ಲಿ ಫ್ಯಾಶನ್, ನಾವು DevOps- ಮತ್ತು ಎಸ್.ಆರ್.ಇ.- ಅಭ್ಯಾಸಕಾರ ಕಂಪನಿಯು 1000 ಮೈಕ್ರೊ ಸರ್ವೀಸ್‌ಗಳು, ಸುಮಾರು 350 ಡೆವಲಪರ್‌ಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ 15 ನಿರ್ವಾಹಕರನ್ನು ಹೊಂದಿರುವಾಗ, ನೀವು “ಫ್ಯಾಶನ್” ಆಗಿರಬೇಕು: ಈ ಎಲ್ಲಾ “ಬಾಸ್‌ವರ್ಡ್‌ಗಳ” ಹಿಂದೆ ಎಲ್ಲವನ್ನೂ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುವ ತುರ್ತು ಅವಶ್ಯಕತೆಯಿದೆ ಮತ್ತು ನಿರ್ವಾಹಕರು ಅಡಚಣೆಯಾಗಬಾರದು. ಪ್ರಕ್ರಿಯೆಗಳಲ್ಲಿ.

Ops ಆಗಿ, ಸೇವಾ ಪ್ರತಿಕ್ರಿಯೆ ದರಗಳು ಮತ್ತು ದೋಷಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಡೆವಲಪರ್‌ಗಳಿಗಾಗಿ ನಾವು ವಿವಿಧ ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳನ್ನು ಒದಗಿಸುತ್ತೇವೆ.

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

ನಾನು ಒಂದು ತಿಂಗಳಿಂದ ಗ್ರಾಫ್‌ಗಳನ್ನು ಚಿತ್ರಿಸಿಲ್ಲ. ಇದು ಬಹುಶಃ ಒಳ್ಳೆಯ ಸಂಕೇತವಾಗಿದೆ: ಇದರರ್ಥ ಹೆಚ್ಚಿನ "ಬಯಕೆಗಳು" ಈಗಾಗಲೇ ಅರಿತುಕೊಂಡಿವೆ. ವಾರದಲ್ಲಿ ನಾನು ದಿನಕ್ಕೆ ಒಮ್ಮೆಯಾದರೂ ಹೊಸ ಗ್ರಾಫ್ ಅನ್ನು ಸೆಳೆಯುತ್ತೇನೆ.

ಫಲಿತಾಂಶವು ಮೌಲ್ಯಯುತವಾಗಿದೆ ಏಕೆಂದರೆ ಈಗ ಡೆವಲಪರ್‌ಗಳು "ಕೆಲವು ರೀತಿಯ ಮೆಟ್ರಿಕ್ ಅನ್ನು ಎಲ್ಲಿ ನೋಡಬೇಕು" ಎಂಬ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನಿರ್ವಾಹಕರ ಬಳಿಗೆ ಹೋಗುವುದು ಅಪರೂಪ.

ಅನುಷ್ಠಾನ ಸೇವೆ ಮೆಶ್ ಇದು ಕೇವಲ ಮೂಲೆಯಲ್ಲಿದೆ ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರಿಗೂ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸಬೇಕು, ಪರಿಕರಗಳ ಸಹೋದ್ಯೋಗಿಗಳು ಈಗಾಗಲೇ ಅಮೂರ್ತವಾದ "ಆರೋಗ್ಯಕರ ಇಸ್ಟಿಯೊ" ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹತ್ತಿರವಾಗಿದ್ದಾರೆ: ಪ್ರತಿ HTTP(ಗಳು) ವಿನಂತಿಯ ಜೀವನ ಚಕ್ರವು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಗೋಚರಿಸುತ್ತದೆ, ಮತ್ತು ಅಂತರ-ಸೇವಾ (ಮತ್ತು ಮಾತ್ರವಲ್ಲ) ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಸಮಯದಲ್ಲಿ "ಯಾವ ಹಂತದಲ್ಲಿ ಎಲ್ಲವೂ ಮುರಿದುಹೋಯಿತು" ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಾಗುತ್ತದೆ. DomClick ಹಬ್‌ನಿಂದ ಸುದ್ದಿಗೆ ಚಂದಾದಾರರಾಗಿ. =)

ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಸೌಕರ್ಯ ಬೆಂಬಲ

ಐತಿಹಾಸಿಕವಾಗಿ, ನಾವು ಪ್ಯಾಚ್ ಮಾಡಿದ ಆವೃತ್ತಿಯನ್ನು ಬಳಸುತ್ತೇವೆ ಕುಬೆಸ್ಪ್ರೇ - ಕುಬರ್ನೆಟ್‌ಗಳನ್ನು ನಿಯೋಜಿಸಲು, ವಿಸ್ತರಿಸಲು ಮತ್ತು ನವೀಕರಿಸಲು ಪ್ರಮುಖ ಪಾತ್ರ. ಕೆಲವು ಹಂತದಲ್ಲಿ, kubeadm ಅಲ್ಲದ ಸ್ಥಾಪನೆಗಳಿಗೆ ಬೆಂಬಲವನ್ನು ಮುಖ್ಯ ಶಾಖೆಯಿಂದ ಕಡಿತಗೊಳಿಸಲಾಯಿತು ಮತ್ತು kubeadm ಗೆ ಬದಲಾಯಿಸುವ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಪ್ರಸ್ತಾಪಿಸಲಾಗಿಲ್ಲ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಸೌತ್‌ಬ್ರಿಡ್ಜ್ ಕಂಪನಿಯು ತನ್ನದೇ ಆದ ಫೋರ್ಕ್ ಅನ್ನು ತಯಾರಿಸಿತು (kubeadm ಬೆಂಬಲದೊಂದಿಗೆ ಮತ್ತು ನಿರ್ಣಾಯಕ ಸಮಸ್ಯೆಗಳಿಗೆ ತ್ವರಿತ ಪರಿಹಾರದೊಂದಿಗೆ).

ಎಲ್ಲಾ k8s ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನವೀಕರಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ:

• ತೆಗೆದುಕೊಳ್ಳಿ ಕುಬೆಸ್ಪ್ರೇ ಸೌತ್‌ಬ್ರಿಡ್ಜ್‌ನಿಂದ, ನಮ್ಮ ಥ್ರೆಡ್‌ನೊಂದಿಗೆ ಪರಿಶೀಲಿಸಿ, ಮೆರ್ಜಿಮ್.
• ನಾವು ನವೀಕರಣವನ್ನು ಹೊರತರುತ್ತಿದ್ದೇವೆ ಒತ್ತಡ- "ಕ್ಯೂಬ್".
• ನಾವು ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ನೋಡ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡುತ್ತೇವೆ (ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಇದು “ಸೀರಿಯಲ್: 1”) ದೇವ್- "ಕ್ಯೂಬ್".
• ನಾವು ನವೀಕರಿಸುತ್ತೇವೆ ಉತ್ಪನ್ನ ಶನಿವಾರ ಸಂಜೆ ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದು ನೋಡ್.

ಭವಿಷ್ಯದಲ್ಲಿ ಅದನ್ನು ಬದಲಾಯಿಸುವ ಯೋಜನೆ ಇದೆ ಕುಬೆಸ್ಪ್ರೇ ಏನಾದರೂ ವೇಗವಾಗಿ ಮತ್ತು ಹೋಗಿ kubeadm.

ಒಟ್ಟಾರೆಯಾಗಿ ನಾವು ಮೂರು "ಕ್ಯೂಬ್ಸ್" ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ: ಒತ್ತಡ, ದೇವ್ ಮತ್ತು ಪ್ರೊಡ್. ನಾವು ಇನ್ನೊಂದನ್ನು ಪ್ರಾರಂಭಿಸಲು ಯೋಜಿಸುತ್ತಿದ್ದೇವೆ (ಬಿಸಿ ಸ್ಟ್ಯಾಂಡ್ಬೈ) ಎರಡನೇ ಡೇಟಾ ಕೇಂದ್ರದಲ್ಲಿ ಉತ್ಪನ್ನ-“ಕ್ಯೂಬ್”. ಒತ್ತಡ и ದೇವ್ "ವರ್ಚುವಲ್ ಮೆಷಿನ್‌ಗಳಲ್ಲಿ" ಲೈವ್ (ಒತ್ತಡಕ್ಕಾಗಿ oVirt ಮತ್ತು ದೇವ್‌ಗಾಗಿ VMWare ಕ್ಲೌಡ್). ಉತ್ಪನ್ನ- "ಕ್ಯೂಬ್" "ಬೇರ್ ಮೆಟಲ್" ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ: ಇವುಗಳು 32 CPU ಥ್ರೆಡ್‌ಗಳು, 64-128 GB ಮೆಮೊರಿ ಮತ್ತು 300 GB SSD RAID 10 ನೊಂದಿಗೆ ಒಂದೇ ನೋಡ್‌ಗಳಾಗಿವೆ - ಅವುಗಳಲ್ಲಿ ಒಟ್ಟು 50 ಇವೆ. ಮೂರು "ತೆಳುವಾದ" ನೋಡ್‌ಗಳನ್ನು "ಮಾಸ್ಟರ್ಸ್" ಗೆ ಸಮರ್ಪಿಸಲಾಗಿದೆ ಉತ್ಪನ್ನ- "ಕ್ಯೂಬಾ": 16 GB ಮೆಮೊರಿ, 12 CPU ಎಳೆಗಳು.

ಮಾರಾಟಕ್ಕಾಗಿ, ನಾವು "ಬೇರ್ ಮೆಟಲ್" ಅನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಅನಗತ್ಯ ಪದರಗಳನ್ನು ತಪ್ಪಿಸಲು ಬಯಸುತ್ತೇವೆ ಓಪನ್ ಸ್ಟ್ಯಾಕ್: ನಮಗೆ "ಗದ್ದಲದ ನೆರೆಹೊರೆಯವರು" ಮತ್ತು CPU ಅಗತ್ಯವಿಲ್ಲ ಸಮಯವನ್ನು ಕದಿಯಿರಿ. ಮತ್ತು ಆಂತರಿಕ ಓಪನ್‌ಸ್ಟ್ಯಾಕ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ ಆಡಳಿತದ ಸಂಕೀರ್ಣತೆಯು ಸರಿಸುಮಾರು ದ್ವಿಗುಣಗೊಳ್ಳುತ್ತದೆ.

CI/CD "ಕ್ಯೂಬಿಕ್" ಮತ್ತು ಇತರ ಮೂಲಸೌಕರ್ಯ ಘಟಕಗಳಿಗಾಗಿ ನಾವು ಪ್ರತ್ಯೇಕ GIT ಸರ್ವರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಹೆಲ್ಮ್ 3 (ಇದು ಹೆಲ್ಮ್ 2 ನಿಂದ ನೋವಿನ ಪರಿವರ್ತನೆಯಾಗಿದೆ, ಆದರೆ ಆಯ್ಕೆಗಳೊಂದಿಗೆ ನಾವು ತುಂಬಾ ಸಂತೋಷಪಡುತ್ತೇವೆ ಪರಮಾಣು), ಜೆಂಕಿನ್ಸ್, ಅನ್ಸಿಬಲ್ ಮತ್ತು ಡಾಕರ್. ಒಂದು ರೆಪೊಸಿಟರಿಯಿಂದ ವಿಭಿನ್ನ ಪರಿಸರಗಳಿಗೆ ವೈಶಿಷ್ಟ್ಯ ಶಾಖೆಗಳು ಮತ್ತು ನಿಯೋಜನೆಯನ್ನು ನಾವು ಇಷ್ಟಪಡುತ್ತೇವೆ.

ತೀರ್ಮಾನಕ್ಕೆ

ಇದು ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಕಾರ್ಯಾಚರಣೆಯ ಎಂಜಿನಿಯರ್‌ನ ದೃಷ್ಟಿಕೋನದಿಂದ DomClick ನಲ್ಲಿ DevOps ಪ್ರಕ್ರಿಯೆಯು ಹೇಗೆ ಕಾಣುತ್ತದೆ. ಲೇಖನವು ನಾನು ನಿರೀಕ್ಷಿಸಿದ್ದಕ್ಕಿಂತ ಕಡಿಮೆ ತಾಂತ್ರಿಕವಾಗಿ ಹೊರಹೊಮ್ಮಿದೆ: ಆದ್ದರಿಂದ, Habré ನಲ್ಲಿ DomClick ಸುದ್ದಿಗಳನ್ನು ಅನುಸರಿಸಿ: ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳ ಬಗ್ಗೆ ಹೆಚ್ಚು "ಹಾರ್ಡ್ಕೋರ್" ಲೇಖನಗಳು ಇರುತ್ತವೆ.

ಮೂಲ: www.habr.com