ಸೂಚನೆ. ಅನುವಾದ.: GitLab ನಲ್ಲಿ Kubernetes ಅಳವಡಿಕೆಯು ಕಂಪನಿಯ ಬೆಳವಣಿಗೆಗೆ ಕೊಡುಗೆ ನೀಡುವ ಎರಡು ಪ್ರಮುಖ ಅಂಶಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಇತ್ತೀಚಿನವರೆಗೂ, GitLab.com ಆನ್‌ಲೈನ್ ಸೇವೆಯ ಮೂಲಸೌಕರ್ಯವನ್ನು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಕೇವಲ ಒಂದು ವರ್ಷದ ಹಿಂದೆ K8 ಗಳಿಗೆ ಅದರ ವಲಸೆ ಪ್ರಾರಂಭವಾಯಿತು, ಅದು ಇನ್ನೂ ಪೂರ್ಣಗೊಂಡಿಲ್ಲ. ಇದು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಮತ್ತು ಯೋಜನೆಯಲ್ಲಿ ಭಾಗವಹಿಸುವ ಎಂಜಿನಿಯರ್‌ಗಳು ಯಾವ ತೀರ್ಮಾನಗಳನ್ನು ಮಾಡುತ್ತಾರೆ ಎಂಬುದರ ಕುರಿತು GitLab SRE ಇಂಜಿನಿಯರ್‌ನ ಇತ್ತೀಚಿನ ಲೇಖನದ ಅನುವಾದವನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ.
ಈಗ ಸುಮಾರು ಒಂದು ವರ್ಷದಿಂದ, ನಮ್ಮ ಮೂಲಸೌಕರ್ಯ ವಿಭಾಗವು GitLab.com ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು Kubernetes ಗೆ ಸ್ಥಳಾಂತರಿಸುತ್ತಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಸೇವೆಗಳನ್ನು ಸರಿಸಲು ಮಾತ್ರವಲ್ಲದೆ, ಪರಿವರ್ತನೆಯ ಸಮಯದಲ್ಲಿ ಹೈಬ್ರಿಡ್ ನಿಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸಲು ನಾವು ಸವಾಲುಗಳನ್ನು ಎದುರಿಸಿದ್ದೇವೆ. ನಾವು ಕಲಿತ ಅಮೂಲ್ಯವಾದ ಪಾಠಗಳನ್ನು ಈ ಲೇಖನದಲ್ಲಿ ಚರ್ಚಿಸಲಾಗುವುದು.
GitLab.com ನ ಆರಂಭದಿಂದಲೂ, ಅದರ ಸರ್ವರ್‌ಗಳು ವರ್ಚುವಲ್ ಗಣಕಗಳಲ್ಲಿ ಕ್ಲೌಡ್‌ನಲ್ಲಿ ಓಡಿದವು. ಈ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳನ್ನು ಬಾಣಸಿಗರಿಂದ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಬಳಸಿ ಸ್ಥಾಪಿಸಲಾಗಿದೆ . ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನವೀಕರಿಸಬೇಕಾದರೆ, CI ಪೈಪ್‌ಲೈನ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಸರ್ವರ್ ಫ್ಲೀಟ್ ಅನ್ನು ಸಂಘಟಿತ, ಅನುಕ್ರಮ ರೀತಿಯಲ್ಲಿ ಸರಳವಾಗಿ ನವೀಕರಿಸುವುದನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಈ ವಿಧಾನ - ನಿಧಾನ ಮತ್ತು ಸ್ವಲ್ಪ ಆದರೂ - GitLab.com ಆಫ್‌ಲೈನ್ ಬಳಕೆದಾರರಂತೆ ಅದೇ ಅನುಸ್ಥಾಪನೆ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಅಭ್ಯಾಸಗಳನ್ನು ಬಳಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ (ಸ್ವಯಂ ನಿರ್ವಹಣೆ) ಇದಕ್ಕಾಗಿ ನಮ್ಮ ಲಿನಕ್ಸ್ ಪ್ಯಾಕೇಜ್‌ಗಳನ್ನು ಬಳಸಿಕೊಂಡು GitLab ಸ್ಥಾಪನೆಗಳು.
ನಾವು ಈ ವಿಧಾನವನ್ನು ಬಳಸುತ್ತೇವೆ ಏಕೆಂದರೆ GitLab ನ ಪ್ರತಿಗಳನ್ನು ಸ್ಥಾಪಿಸುವಾಗ ಮತ್ತು ಕಾನ್ಫಿಗರ್ ಮಾಡುವಾಗ ಸಮುದಾಯದ ಸಾಮಾನ್ಯ ಸದಸ್ಯರು ಅನುಭವಿಸುವ ಎಲ್ಲಾ ದುಃಖಗಳು ಮತ್ತು ಸಂತೋಷಗಳನ್ನು ಅನುಭವಿಸುವುದು ಬಹಳ ಮುಖ್ಯ. ಈ ವಿಧಾನವು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಿತು, ಆದರೆ GitLab ನಲ್ಲಿನ ಯೋಜನೆಗಳ ಸಂಖ್ಯೆ 10 ಮಿಲಿಯನ್ ಮೀರಿದಾಗ, ಅದು ಇನ್ನು ಮುಂದೆ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ನಿಯೋಜನೆಗಾಗಿ ನಮ್ಮ ಅಗತ್ಯಗಳನ್ನು ಪೂರೈಸುವುದಿಲ್ಲ ಎಂದು ನಾವು ಅರಿತುಕೊಂಡೆವು.
ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಕ್ಲೌಡ್-ನೇಟಿವ್ GitLab ಗೆ ಮೊದಲ ಹಂತಗಳು
ಯೋಜನೆಯನ್ನು 2017 ರಲ್ಲಿ ರಚಿಸಲಾಗಿದೆ ಕ್ಲೌಡ್ ನಿಯೋಜನೆಗಾಗಿ GitLab ಅನ್ನು ಸಿದ್ಧಪಡಿಸಲು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ GitLab ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಬಳಕೆದಾರರನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲು. GitLab ಅನ್ನು Kubernetes ಗೆ ಸ್ಥಳಾಂತರಿಸುವುದು SaaS ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನ ಸ್ಕೇಲೆಬಿಲಿಟಿಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, ನಿಯೋಜನೆಗಳನ್ನು ಸರಳಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕಂಪ್ಯೂಟಿಂಗ್ ಸಂಪನ್ಮೂಲಗಳ ದಕ್ಷತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ ಎಂದು ನಮಗೆ ಆಗ ತಿಳಿದಿತ್ತು. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಅನೇಕ ಕಾರ್ಯಗಳು ಆರೋಹಿತವಾದ NFS ವಿಭಾಗಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ, ಇದು ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಿಂದ ಪರಿವರ್ತನೆಯನ್ನು ನಿಧಾನಗೊಳಿಸುತ್ತದೆ.
ಕ್ಲೌಡ್ ಸ್ಥಳೀಯ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳ ಕಡೆಗೆ ತಳ್ಳುವಿಕೆಯು ನಮ್ಮ ಇಂಜಿನಿಯರ್‌ಗಳಿಗೆ ಕ್ರಮೇಣ ಪರಿವರ್ತನೆಯನ್ನು ಯೋಜಿಸಲು ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿತು, ಈ ಸಮಯದಲ್ಲಿ ನಾವು ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವುದನ್ನು ಮುಂದುವರಿಸುವಾಗ ನೆಟ್‌ವರ್ಕ್ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಕೆಲವು ಅವಲಂಬನೆಗಳನ್ನು ತ್ಯಜಿಸಿದ್ದೇವೆ. ನಾವು 2019 ರ ಬೇಸಿಗೆಯಲ್ಲಿ ವಲಸೆಯನ್ನು ಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗಿನಿಂದ, ಈ ಹಲವಾರು ಮಿತಿಗಳನ್ನು ಪರಿಹರಿಸಲಾಗಿದೆ ಮತ್ತು GitLab.com ಅನ್ನು Kubernetes ಗೆ ಸ್ಥಳಾಂತರಿಸುವ ಪ್ರಕ್ರಿಯೆಯು ಈಗ ಚೆನ್ನಾಗಿ ನಡೆಯುತ್ತಿದೆ!
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ GitLab.com ನ ವೈಶಿಷ್ಟ್ಯಗಳು
GitLab.com ಗಾಗಿ, ನಾವು ಎಲ್ಲಾ ಅಪ್ಲಿಕೇಶನ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಏಕೈಕ ಪ್ರಾದೇಶಿಕ GKE ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ. (ಈಗಾಗಲೇ ಟ್ರಿಕಿ) ವಲಸೆಯ ಸಂಕೀರ್ಣತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನಾವು ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆ ಅಥವಾ NFS ಅನ್ನು ಅವಲಂಬಿಸದ ಸೇವೆಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತೇವೆ. GitLab.com ಪ್ರಧಾನವಾಗಿ ಏಕಶಿಲೆಯ ರೈಲ್‌ಗಳ ಕೋಡ್‌ಬೇಸ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಮತ್ತು ನಾವು ಕೆಲಸದ ಹೊರೆ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಆಧರಿಸಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ತಮ್ಮದೇ ಆದ ನೋಡ್ ಪೂಲ್‌ಗಳಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿರುವ ವಿಭಿನ್ನ ಅಂತಿಮ ಬಿಂದುಗಳಿಗೆ ಮಾರ್ಗಗೊಳಿಸುತ್ತೇವೆ.
ಮುಂಭಾಗದ ಸಂದರ್ಭದಲ್ಲಿ, ಈ ಪ್ರಕಾರಗಳನ್ನು ವೆಬ್, API, Git SSH/HTTPS ಮತ್ತು ರಿಜಿಸ್ಟ್ರಿಗೆ ವಿನಂತಿಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ. ಬ್ಯಾಕೆಂಡ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಅವಲಂಬಿಸಿ ವಿವಿಧ ಗುಣಲಕ್ಷಣಗಳ ಪ್ರಕಾರ ಸರದಿಯಲ್ಲಿರುವ ಉದ್ಯೋಗಗಳನ್ನು ವಿಭಜಿಸುತ್ತೇವೆ , ಇದು ವಿವಿಧ ಕೆಲಸದ ಹೊರೆಗಳಿಗಾಗಿ ಸೇವಾ ಮಟ್ಟದ ಉದ್ದೇಶಗಳನ್ನು (SLO ಗಳು) ಹೊಂದಿಸಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಈ ಎಲ್ಲಾ GitLab.com ಸೇವೆಗಳನ್ನು ಮಾರ್ಪಡಿಸದ GitLab ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಬಳಸಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಬ್‌ಚಾರ್ಟ್‌ಗಳಲ್ಲಿ ಕೈಗೊಳ್ಳಲಾಗುತ್ತದೆ, ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇವೆಗಳನ್ನು ಕ್ರಮೇಣವಾಗಿ ಸ್ಥಳಾಂತರಿಸುವುದರಿಂದ ಅದನ್ನು ಆಯ್ದವಾಗಿ ಸಕ್ರಿಯಗೊಳಿಸಬಹುದು. ರೆಡಿಸ್, ಪೋಸ್ಟ್‌ಗ್ರೆಸ್, ಗಿಟ್ಲ್ಯಾಬ್ ಪುಟಗಳು ಮತ್ತು ಗಿಟಾಲಿಯಂತಹ ನಮ್ಮ ಕೆಲವು ರಾಜ್ಯಪೂರ್ಣ ಸೇವೆಗಳನ್ನು ವಲಸೆಯಲ್ಲಿ ಸೇರಿಸದಿರಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದರೂ, ಕುಬರ್ನೆಟ್ಗಳನ್ನು ಬಳಸುವುದರಿಂದ ಬಾಣಸಿಗರು ಪ್ರಸ್ತುತ ನಿರ್ವಹಿಸುತ್ತಿರುವ VM ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಆಮೂಲಾಗ್ರವಾಗಿ ಕಡಿಮೆ ಮಾಡಲು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಗೋಚರತೆ ಮತ್ತು ನಿರ್ವಹಣೆ
ಎಲ್ಲಾ ಸೆಟ್ಟಿಂಗ್‌ಗಳನ್ನು GitLab ಸ್ವತಃ ನಿರ್ವಹಿಸುತ್ತದೆ. ಇದಕ್ಕಾಗಿ, ಟೆರ್ರಾಫಾರ್ಮ್ ಮತ್ತು ಹೆಲ್ಮ್ ಆಧಾರಿತ ಮೂರು ಕಾನ್ಫಿಗರೇಶನ್ ಯೋಜನೆಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. GitLab ಅನ್ನು ಚಲಾಯಿಸಲು ಸಾಧ್ಯವಾದಾಗಲೆಲ್ಲಾ ನಾವು GitLab ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ, ಆದರೆ ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯಗಳಿಗಾಗಿ ನಾವು ಪ್ರತ್ಯೇಕ GitLab ಸ್ಥಾಪನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. GitLab.com ನಿಯೋಜನೆಗಳು ಮತ್ತು ನವೀಕರಣಗಳನ್ನು ನಿರ್ವಹಿಸುವಾಗ ನೀವು GitLab.com ಲಭ್ಯತೆಯ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದು ಅಗತ್ಯವಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ನಮ್ಮ ಪೈಪ್‌ಲೈನ್‌ಗಳು ಪ್ರತ್ಯೇಕ GitLab ಸ್ಥಾಪನೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದ್ದರೂ, ಈ ಕೆಳಗಿನ ವಿಳಾಸಗಳಲ್ಲಿ ಸಾರ್ವಜನಿಕವಾಗಿ ಲಭ್ಯವಿರುವ ಕೋಡ್ ರೆಪೊಸಿಟರಿಗಳ ಕನ್ನಡಿಗಳು ಇವೆ:
- - GitLab ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಾಗಿ GitLab.com ಕಾನ್ಫಿಗರೇಶನ್ ಫ್ರೇಮ್‌ವರ್ಕ್;
- - GitLab ಅಪ್ಲಿಕೇಶನ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಸಂಬಂಧಿಸದ ಸೇವೆಗಳಿಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ಇವುಗಳು ಲಾಗಿಂಗ್ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಮಾನಿಟರಿಂಗ್‌ಗಾಗಿ ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿವೆ, ಜೊತೆಗೆ PlantUML ನಂತಹ ಸಂಯೋಜಿತ ಸಾಧನಗಳನ್ನು ಒಳಗೊಂಡಿವೆ;
- - ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಲೆಗಸಿ VM ಮೂಲಸೌಕರ್ಯಕ್ಕಾಗಿ ಟೆರಾಫಾರ್ಮ್ ಕಾನ್ಫಿಗರೇಶನ್. ಕ್ಲಸ್ಟರ್, ನೋಡ್ ಪೂಲ್‌ಗಳು, ಸೇವಾ ಖಾತೆಗಳು ಮತ್ತು IP ವಿಳಾಸ ಕಾಯ್ದಿರಿಸುವಿಕೆ ಸೇರಿದಂತೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಚಲಾಯಿಸಲು ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಇಲ್ಲಿ ನೀವು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೀರಿ.
ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡಿದಾಗ ಸಾರ್ವಜನಿಕ ವೀಕ್ಷಣೆಯನ್ನು ತೋರಿಸಲಾಗುತ್ತದೆ. ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಮೊದಲು SRE ವಿಶ್ಲೇಷಿಸುವ ವಿವರವಾದ ವ್ಯತ್ಯಾಸದ ಲಿಂಕ್‌ನೊಂದಿಗೆ.
SRE ಗಾಗಿ, ಲಿಂಕ್ GitLab ಅನುಸ್ಥಾಪನೆಯಲ್ಲಿ ವಿವರವಾದ ವ್ಯತ್ಯಾಸಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ, ಇದನ್ನು ಉತ್ಪಾದನೆಗೆ ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಪ್ರವೇಶವನ್ನು ಸೀಮಿತಗೊಳಿಸಲಾಗಿದೆ. ಉದ್ದೇಶಿತ ಕಾನ್ಫಿಗರೇಶನ್ ಬದಲಾವಣೆಗಳನ್ನು ವೀಕ್ಷಿಸಲು, ಕಾರ್ಯಾಚರಣಾ ಯೋಜನೆಗೆ (ಇದು SRE ಗಳಿಗೆ ಮಾತ್ರ ತೆರೆದಿರುತ್ತದೆ) ಪ್ರವೇಶವಿಲ್ಲದೆ ಉದ್ಯೋಗಿಗಳು ಮತ್ತು ಸಮುದಾಯವನ್ನು ಅನುಮತಿಸುತ್ತದೆ. CI ಪೈಪ್‌ಲೈನ್‌ಗಳಿಗಾಗಿ ಖಾಸಗಿ ನಿದರ್ಶನದೊಂದಿಗೆ ಕೋಡ್‌ಗಾಗಿ ಸಾರ್ವಜನಿಕ GitLab ನಿದರ್ಶನವನ್ನು ಸಂಯೋಜಿಸುವ ಮೂಲಕ, ಕಾನ್ಫಿಗರೇಶನ್ ನವೀಕರಣಗಳಿಗಾಗಿ GitLab.com ನಿಂದ ಸ್ವಾತಂತ್ರ್ಯವನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವಾಗ ನಾವು ಒಂದೇ ಕೆಲಸದ ಹರಿವನ್ನು ನಿರ್ವಹಿಸುತ್ತೇವೆ.
ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ಕಂಡುಕೊಂಡದ್ದು
ಚಲನೆಯ ಸಮಯದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಹೊಸ ವಲಸೆಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳಿಗೆ ನಾವು ಅನ್ವಯಿಸುವ ಅನುಭವವನ್ನು ಪಡೆಯಲಾಗಿದೆ.
1. ಲಭ್ಯತೆಯ ವಲಯಗಳ ನಡುವಿನ ಸಂಚಾರದಿಂದಾಗಿ ಹೆಚ್ಚಿದ ವೆಚ್ಚಗಳು
GitLab.com ನಲ್ಲಿ Git ರೆಪೊಸಿಟರಿ ಫ್ಲೀಟ್‌ಗಾಗಿ ದೈನಂದಿನ ಹೊರಹೊಮ್ಮುವಿಕೆಯ ಅಂಕಿಅಂಶಗಳು (ದಿನಕ್ಕೆ ಬೈಟ್‌ಗಳು)
ಗೂಗಲ್ ತನ್ನ ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಪ್ರದೇಶಗಳಾಗಿ ವಿಂಗಡಿಸುತ್ತದೆ. ಅವುಗಳನ್ನು ಪ್ರವೇಶಿಸುವಿಕೆ ವಲಯಗಳಾಗಿ (AZ) ವಿಂಗಡಿಸಲಾಗಿದೆ. Git ಹೋಸ್ಟಿಂಗ್ ದೊಡ್ಡ ಪ್ರಮಾಣದ ಡೇಟಾದೊಂದಿಗೆ ಸಂಬಂಧಿಸಿದೆ, ಆದ್ದರಿಂದ ನೆಟ್‌ವರ್ಕ್ ಹೊರಹೊಮ್ಮುವಿಕೆಯನ್ನು ನಿಯಂತ್ರಿಸುವುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಆಂತರಿಕ ಸಂಚಾರಕ್ಕಾಗಿ, ಅದೇ ಲಭ್ಯತೆಯ ವಲಯದಲ್ಲಿ ಉಳಿದುಕೊಂಡರೆ ಮಾತ್ರ ಹೊರಹೋಗುವಿಕೆ ಉಚಿತವಾಗಿರುತ್ತದೆ. ಈ ಬರವಣಿಗೆಯ ಪ್ರಕಾರ, ನಾವು ಸಾಮಾನ್ಯ ಕೆಲಸದ ದಿನದಲ್ಲಿ ಸರಿಸುಮಾರು 100 TB ಡೇಟಾವನ್ನು ಒದಗಿಸುತ್ತಿದ್ದೇವೆ (ಮತ್ತು ಅದು ಕೇವಲ Git ರೆಪೊಸಿಟರಿಗಳಿಗೆ ಮಾತ್ರ). ನಮ್ಮ ಹಳೆಯ VM-ಆಧಾರಿತ ಟೋಪೋಲಜಿಯಲ್ಲಿ ಅದೇ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳಲ್ಲಿ ವಾಸಿಸುವ ಸೇವೆಗಳು ಈಗ ವಿಭಿನ್ನ ಕುಬರ್ನೆಟ್ಸ್ ಪಾಡ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಇದರರ್ಥ VM ಗೆ ಹಿಂದೆ ಸ್ಥಳೀಯವಾಗಿದ್ದ ಕೆಲವು ದಟ್ಟಣೆಯು ಲಭ್ಯತೆಯ ವಲಯಗಳ ಹೊರಗೆ ಸಂಭಾವ್ಯವಾಗಿ ಪ್ರಯಾಣಿಸಬಹುದು.
ಪ್ರಾದೇಶಿಕ GKE ಕ್ಲಸ್ಟರ್‌ಗಳು ಪುನರಾವರ್ತನೆಗಾಗಿ ಬಹು ಲಭ್ಯತೆಯ ವಲಯಗಳನ್ನು ವ್ಯಾಪಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ನಾವು ಸಾಧ್ಯತೆಯನ್ನು ಪರಿಗಣಿಸುತ್ತಿದ್ದೇವೆ ದೊಡ್ಡ ಪ್ರಮಾಣದ ದಟ್ಟಣೆಯನ್ನು ಉಂಟುಮಾಡುವ ಸೇವೆಗಳಿಗಾಗಿ. ಇದು ಕ್ಲಸ್ಟರ್-ಲೆವೆಲ್ ರಿಡಂಡೆನ್ಸಿಯನ್ನು ಉಳಿಸಿಕೊಂಡು ಹೊರಹೋಗುವ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ.
2. ಮಿತಿಗಳು, ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು ಮತ್ತು ಸ್ಕೇಲಿಂಗ್
registry.gitlab.com ನಲ್ಲಿ ಉತ್ಪಾದನಾ ದಟ್ಟಣೆಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸುವ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ. ~15:00 UTC ಯಲ್ಲಿ ದಟ್ಟಣೆಯು ಉತ್ತುಂಗಕ್ಕೇರುತ್ತದೆ.
ನಮ್ಮ ವಲಸೆಯ ಕಥೆಯು ಆಗಸ್ಟ್ 2019 ರಲ್ಲಿ ಪ್ರಾರಂಭವಾಯಿತು, ನಾವು ನಮ್ಮ ಮೊದಲ ಸೇವೆಯಾದ GitLab ಕಂಟೈನರ್ ರಿಜಿಸ್ಟ್ರಿಯನ್ನು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಸ್ಥಳಾಂತರಿಸಿದಾಗ. ಈ ಮಿಷನ್-ಕ್ರಿಟಿಕಲ್, ಹೈ-ಟ್ರಾಫಿಕ್ ಸೇವೆಯು ಮೊದಲ ವಲಸೆಗೆ ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ ಏಕೆಂದರೆ ಇದು ಕೆಲವು ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳೊಂದಿಗೆ ಸ್ಥಿತಿಯಿಲ್ಲದ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ. ನಾವು ಎದುರಿಸಿದ ಮೊದಲ ಸಮಸ್ಯೆಯು ನೋಡ್‌ಗಳಲ್ಲಿ ಮೆಮೊರಿ ಕೊರತೆಯಿಂದಾಗಿ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಹೊರಹಾಕಲ್ಪಟ್ಟ ಪಾಡ್‌ಗಳು. ಈ ಕಾರಣದಿಂದಾಗಿ, ನಾವು ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಬದಲಾಯಿಸಬೇಕಾಗಿತ್ತು.
ಕಾಲಾನಂತರದಲ್ಲಿ ಮೆಮೊರಿ ಬಳಕೆ ಹೆಚ್ಚಾಗುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ವಿನಂತಿಗಳಿಗೆ ಕಡಿಮೆ ಮೌಲ್ಯಗಳು (ಪ್ರತಿ ಪಾಡ್‌ಗೆ ಮೆಮೊರಿಯನ್ನು ಕಾಯ್ದಿರಿಸುವುದು) ಜೊತೆಗೆ ಬಳಕೆಯ ಮೇಲಿನ “ಉದಾರವಾದ” ಕಠಿಣ ಮಿತಿಯೊಂದಿಗೆ ಸ್ಯಾಚುರೇಶನ್‌ಗೆ ಕಾರಣವಾಯಿತು ಎಂದು ಕಂಡುಹಿಡಿಯಲಾಯಿತು. (ಶುದ್ಧತ್ವ) ನೋಡ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನ ಮಟ್ಟದ ಹೊರಹಾಕುವಿಕೆ. ಈ ಸಮಸ್ಯೆಯನ್ನು ನಿಭಾಯಿಸಲು, ಅದು . ಇದು ನೋಡ್‌ಗಳ ಮೇಲಿನ ಒತ್ತಡವನ್ನು ತೆಗೆದುಕೊಂಡಿತು ಮತ್ತು ನೋಡ್‌ನ ಮೇಲೆ ಹೆಚ್ಚು ಒತ್ತಡವನ್ನು ಬೀರದ ಜೀವನಚಕ್ರವನ್ನು ಹೊಂದಿರುವುದನ್ನು ಖಚಿತಪಡಿಸುತ್ತದೆ. ಈಗ ನಾವು ಉದಾರವಾದ (ಮತ್ತು ಬಹುತೇಕ ಒಂದೇ ರೀತಿಯ) ವಿನಂತಿಯೊಂದಿಗೆ ವಲಸೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ ಮತ್ತು ಮೌಲ್ಯಗಳನ್ನು ಮಿತಿಗೊಳಿಸುತ್ತೇವೆ, ಅವುಗಳನ್ನು ಅಗತ್ಯವಿರುವಂತೆ ಸರಿಹೊಂದಿಸುತ್ತೇವೆ.
3. ಮೆಟ್ರಿಕ್ಸ್ ಮತ್ತು ಲಾಗ್‌ಗಳು
ಮೂಲಸೌಕರ್ಯ ವಿಭಾಗವು ಸುಪ್ತತೆ, ದೋಷ ದರಗಳು ಮತ್ತು ಸ್ಥಾಪಿಸಲಾದ ಶುದ್ಧತ್ವದ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ (SLO) ಗೆ ಲಿಂಕ್ ಮಾಡಲಾಗಿದೆ .
ಕಳೆದ ವರ್ಷದಲ್ಲಿ, ಮೂಲಸೌಕರ್ಯ ವಿಭಾಗದ ಪ್ರಮುಖ ಘಟನೆಗಳಲ್ಲಿ ಒಂದಾದ SLOಗಳ ಮೇಲ್ವಿಚಾರಣೆ ಮತ್ತು ಕೆಲಸದಲ್ಲಿ ಸುಧಾರಣೆಯಾಗಿದೆ. ವಲಸೆಯ ಸಮಯದಲ್ಲಿ ನಾವು ನಿಕಟವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವ ವೈಯಕ್ತಿಕ ಸೇವೆಗಳಿಗೆ ಗುರಿಗಳನ್ನು ಹೊಂದಿಸಲು SLO ಗಳು ನಮಗೆ ಅವಕಾಶ ಮಾಡಿಕೊಟ್ಟಿವೆ. ಆದರೆ ಈ ಸುಧಾರಿತ ವೀಕ್ಷಣೆಯೊಂದಿಗೆ, ಮೆಟ್ರಿಕ್‌ಗಳು ಮತ್ತು ಎಚ್ಚರಿಕೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಮಸ್ಯೆಗಳನ್ನು ತಕ್ಷಣವೇ ನೋಡಲು ಯಾವಾಗಲೂ ಸಾಧ್ಯವಿಲ್ಲ. ಉದಾಹರಣೆಗೆ, ಲೇಟೆನ್ಸಿ ಮತ್ತು ದೋಷ ದರಗಳ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುವ ಮೂಲಕ, ವಲಸೆಗೆ ಒಳಗಾಗುವ ಸೇವೆಗಾಗಿ ನಾವು ಎಲ್ಲಾ ಬಳಕೆಯ ಸಂದರ್ಭಗಳನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಒಳಗೊಳ್ಳುವುದಿಲ್ಲ.
ಕೆಲವು ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ ಈ ಸಮಸ್ಯೆಯನ್ನು ತಕ್ಷಣವೇ ಕಂಡುಹಿಡಿಯಲಾಯಿತು. ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು ಚಿಕ್ಕದಾಗಿದೆ, ಆದರೆ ನಿರ್ದಿಷ್ಟ ಕಾನ್ಫಿಗರೇಶನ್ ಅವಲಂಬನೆಗಳನ್ನು ಹೊಂದಿರುವ ಕಾರ್ಯಗಳನ್ನು ನಾವು ಪರಿಶೀಲಿಸಬೇಕಾದಾಗ ಇದು ವಿಶೇಷವಾಗಿ ತೀವ್ರವಾಯಿತು. ವಲಸೆಯ ಪ್ರಮುಖ ಪಾಠವೆಂದರೆ ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡುವಾಗ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಮಾತ್ರವಲ್ಲದೆ ಲಾಗ್‌ಗಳು ಮತ್ತು “ಉದ್ದನೆಯ ಬಾಲ” ವನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುವ ಅಗತ್ಯತೆ. (ಇದು ಸುಮಾರು ಚಾರ್ಟ್ನಲ್ಲಿ - ಅಂದಾಜು. ಅನುವಾದ.) ದೋಷಗಳು. ಈಗ ಪ್ರತಿ ವಲಸೆಗೆ ನಾವು ಲಾಗ್ ಪ್ರಶ್ನೆಗಳ ವಿವರವಾದ ಪಟ್ಟಿಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ (ಲಾಗ್ ಪ್ರಶ್ನೆಗಳು) ಮತ್ತು ಸಮಸ್ಯೆಗಳು ಉದ್ಭವಿಸಿದರೆ ಒಂದು ಶಿಫ್ಟ್‌ನಿಂದ ಇನ್ನೊಂದಕ್ಕೆ ವರ್ಗಾಯಿಸಬಹುದಾದ ಸ್ಪಷ್ಟ ರೋಲ್‌ಬ್ಯಾಕ್ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಯೋಜಿಸಿ.
ಹಳೆಯ VM ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಹೊಸ ಕುಬರ್ನೆಟ್-ಆಧಾರಿತ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಸಮಾನಾಂತರವಾಗಿ ಅದೇ ವಿನಂತಿಗಳನ್ನು ಒದಗಿಸುವುದು ಒಂದು ಅನನ್ಯ ಸವಾಲನ್ನು ಪ್ರಸ್ತುತಪಡಿಸಿತು. ಲಿಫ್ಟ್ ಮತ್ತು ಶಿಫ್ಟ್ ವಲಸೆಯಂತಲ್ಲದೆ (ಹೊಸ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ "ಇರುವಂತೆ" ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ತ್ವರಿತ ವರ್ಗಾವಣೆ; ಹೆಚ್ಚಿನ ವಿವರಗಳನ್ನು ಓದಬಹುದು, ಉದಾಹರಣೆಗೆ, - ಅಂದಾಜು ಅನುವಾದ.), "ಹಳೆಯ" VM ಗಳು ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಲ್ಲಿ ಸಮಾನಾಂತರ ಕೆಲಸವು ಮಾನಿಟರಿಂಗ್ ಪರಿಕರಗಳು ಎರಡೂ ಪರಿಸರಗಳೊಂದಿಗೆ ಹೊಂದಿಕೆಯಾಗಬೇಕು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಒಂದು ವೀಕ್ಷಣೆಗೆ ಸಂಯೋಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ಪರಿವರ್ತನೆಯ ಅವಧಿಯಲ್ಲಿ ಸ್ಥಿರವಾದ ವೀಕ್ಷಣೆಯನ್ನು ಸಾಧಿಸಲು ನಾವು ಅದೇ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್‌ಗಳು ಮತ್ತು ಲಾಗ್ ಪ್ರಶ್ನೆಗಳನ್ನು ಬಳಸುವುದು ಮುಖ್ಯವಾಗಿದೆ.
4. ಟ್ರಾಫಿಕ್ ಅನ್ನು ಹೊಸ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬದಲಾಯಿಸುವುದು
GitLab.com ಗಾಗಿ, ಸರ್ವರ್‌ಗಳ ಭಾಗವನ್ನು ಮೀಸಲಿಡಲಾಗಿದೆ . ಕ್ಯಾನರಿ ಪಾರ್ಕ್ ನಮ್ಮ ಆಂತರಿಕ ಯೋಜನೆಗಳಿಗೆ ಸೇವೆ ಸಲ್ಲಿಸುತ್ತದೆ ಮತ್ತು ಮಾಡಬಹುದು . ಆದರೆ ಇದು ಪ್ರಾಥಮಿಕವಾಗಿ ಮೂಲಸೌಕರ್ಯ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಮಾಡಿದ ಬದಲಾವಣೆಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ಸೀಮಿತ ಪ್ರಮಾಣದ ಆಂತರಿಕ ದಟ್ಟಣೆಯನ್ನು ಸ್ವೀಕರಿಸುವ ಮೂಲಕ ಮೊದಲ ವಲಸೆ ಸೇವೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ಗೆ ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಕಳುಹಿಸುವ ಮೊದಲು SLO ಗಳನ್ನು ಪೂರೈಸಲಾಗಿದೆಯೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನಾವು ಈ ವಿಧಾನವನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ.
ವಲಸೆಯ ಸಂದರ್ಭದಲ್ಲಿ, ಆಂತರಿಕ ಯೋಜನೆಗಳಿಗೆ ವಿನಂತಿಗಳನ್ನು ಮೊದಲು ಕುಬರ್ನೆಟ್ಸ್ಗೆ ಕಳುಹಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ನಂತರ ನಾವು HAProxy ಮೂಲಕ ಬ್ಯಾಕೆಂಡ್‌ಗೆ ತೂಕವನ್ನು ಬದಲಾಯಿಸುವ ಮೂಲಕ ಕ್ಲಸ್ಟರ್‌ನ ಉಳಿದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಕ್ರಮೇಣವಾಗಿ ಬದಲಾಯಿಸುತ್ತೇವೆ ಎಂದರ್ಥ. VM ನಿಂದ Kubernetes ಗೆ ವಲಸೆಯ ಸಮಯದಲ್ಲಿ, ಹಳೆಯ ಮತ್ತು ಹೊಸ ಮೂಲಸೌಕರ್ಯಗಳ ನಡುವೆ ಸಂಚಾರವನ್ನು ಮರುನಿರ್ದೇಶಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವನ್ನು ಹೊಂದಲು ಇದು ತುಂಬಾ ಪ್ರಯೋಜನಕಾರಿಯಾಗಿದೆ ಎಂದು ಸ್ಪಷ್ಟವಾಯಿತು ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ವಲಸೆಯ ನಂತರದ ಮೊದಲ ಕೆಲವು ದಿನಗಳಲ್ಲಿ ಹಳೆಯ ಮೂಲಸೌಕರ್ಯವನ್ನು ರೋಲ್‌ಬ್ಯಾಕ್‌ಗೆ ಸಿದ್ಧವಾಗಿರಿಸಿಕೊಳ್ಳಿ.
5. ಪಾಡ್‌ಗಳ ಮೀಸಲು ಸಾಮರ್ಥ್ಯಗಳು ಮತ್ತು ಅವುಗಳ ಬಳಕೆ
ತಕ್ಷಣವೇ ಈ ಕೆಳಗಿನ ಸಮಸ್ಯೆಯನ್ನು ಗುರುತಿಸಲಾಗಿದೆ: ರಿಜಿಸ್ಟ್ರಿ ಸೇವೆಗಾಗಿ ಪಾಡ್‌ಗಳು ತ್ವರಿತವಾಗಿ ಪ್ರಾರಂಭವಾಯಿತು, ಆದರೆ ಸೈಡ್ಕಿಕ್‌ಗಾಗಿ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು . ಕೆಲಸಗಳನ್ನು ತ್ವರಿತವಾಗಿ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಮತ್ತು ತ್ವರಿತವಾಗಿ ಅಳೆಯಲು ಅಗತ್ಯವಿರುವ ಕಾರ್ಮಿಕರಿಗಾಗಿ ನಾವು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ Sidekiq ಪಾಡ್‌ಗಳಿಗೆ ದೀರ್ಘವಾದ ಪ್ರಾರಂಭದ ಸಮಯವು ಸಮಸ್ಯೆಯಾಯಿತು.
ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಪಾಠವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ನ ಹಾರಿಜಾಂಟಲ್ ಪಾಡ್ ಆಟೋಸ್ಕೇಲರ್ (HPA) ಟ್ರಾಫಿಕ್ ಬೆಳವಣಿಗೆಯನ್ನು ಚೆನ್ನಾಗಿ ನಿಭಾಯಿಸುತ್ತದೆ, ಕೆಲಸದ ಹೊರೆಗಳ ಗುಣಲಕ್ಷಣಗಳನ್ನು ಪರಿಗಣಿಸುವುದು ಮತ್ತು ಪಾಡ್‌ಗಳಿಗೆ ಬಿಡಿ ಸಾಮರ್ಥ್ಯವನ್ನು ನಿಯೋಜಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ (ವಿಶೇಷವಾಗಿ ಬೇಡಿಕೆಯು ಅಸಮಾನವಾಗಿ ವಿತರಿಸಿದಾಗ). ನಮ್ಮ ಸಂದರ್ಭದಲ್ಲಿ, ಉದ್ಯೋಗಗಳಲ್ಲಿ ಹಠಾತ್ ಉಲ್ಬಣವು ಕಂಡುಬಂದಿದೆ, ಇದು ಕ್ಷಿಪ್ರ ಸ್ಕೇಲಿಂಗ್‌ಗೆ ಕಾರಣವಾಯಿತು, ಇದು ನೋಡ್ ಪೂಲ್ ಅನ್ನು ಅಳೆಯುವ ಸಮಯವನ್ನು ಹೊಂದುವ ಮೊದಲು CPU ಸಂಪನ್ಮೂಲಗಳ ಶುದ್ಧತ್ವಕ್ಕೆ ಕಾರಣವಾಯಿತು.
ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸಾಧ್ಯವಾದಷ್ಟು ಹಿಂಡುವ ಪ್ರಲೋಭನೆ ಯಾವಾಗಲೂ ಇರುತ್ತದೆ, ಆದಾಗ್ಯೂ, ಆರಂಭದಲ್ಲಿ ಕಾರ್ಯಕ್ಷಮತೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸಿದ ನಂತರ, ನಾವು ಈಗ ಉದಾರವಾದ ಪಾಡ್ ಬಜೆಟ್‌ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಂತರ ಅದನ್ನು ಕಡಿಮೆ ಮಾಡುತ್ತೇವೆ, SLO ಗಳ ಮೇಲೆ ನಿಕಟವಾಗಿ ಕಣ್ಣಿಡುತ್ತೇವೆ. Sidekiq ಸೇವೆಗಾಗಿ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಗಮನಾರ್ಹವಾಗಿ ವೇಗಗೊಂಡಿದೆ ಮತ್ತು ಈಗ ಸರಾಸರಿ 40 ಸೆಕೆಂಡುಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. GitLab.com ಮತ್ತು ಅಧಿಕೃತ GitLab ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸ್ವಯಂ-ನಿರ್ವಹಣೆಯ ಸ್ಥಾಪನೆಗಳ ನಮ್ಮ ಬಳಕೆದಾರರು ಎರಡನ್ನೂ ಗೆದ್ದಿದ್ದಾರೆ.
ತೀರ್ಮಾನಕ್ಕೆ
ಪ್ರತಿ ಸೇವೆಯನ್ನು ಸ್ಥಳಾಂತರಿಸಿದ ನಂತರ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವ ಪ್ರಯೋಜನಗಳ ಬಗ್ಗೆ ನಾವು ಸಂತೋಷಪಟ್ಟಿದ್ದೇವೆ: ವೇಗವಾದ ಮತ್ತು ಸುರಕ್ಷಿತ ಅಪ್ಲಿಕೇಶನ್ ನಿಯೋಜನೆ, ಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿ ಸಂಪನ್ಮೂಲ ಹಂಚಿಕೆ. ಇದಲ್ಲದೆ, ವಲಸೆಯ ಅನುಕೂಲಗಳು GitLab.com ಸೇವೆಯನ್ನು ಮೀರಿವೆ. ಅಧಿಕೃತ ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗೆ ಪ್ರತಿ ಸುಧಾರಣೆಯು ಅದರ ಬಳಕೆದಾರರಿಗೆ ಪ್ರಯೋಜನವನ್ನು ನೀಡುತ್ತದೆ.
ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ವಲಸೆ ಸಾಹಸಗಳ ಕಥೆಯನ್ನು ನೀವು ಆನಂದಿಸಿದ್ದೀರಿ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ. ನಾವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಎಲ್ಲಾ ಹೊಸ ಸೇವೆಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ಹೆಚ್ಚುವರಿ ಮಾಹಿತಿಯನ್ನು ಕೆಳಗಿನ ಪ್ರಕಟಣೆಗಳಲ್ಲಿ ಕಾಣಬಹುದು:
- «";
- «";
- .
ಅನುವಾದಕರಿಂದ PS
ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:
- «";
- «";
- «";
- «».
ಮೂಲ: www.habr.com