ಹಲೋ, ಹಬ್ರ್!
ನಾವು ಎಕ್ಸ್‌ನೆಸ್ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ತಂಡವನ್ನು ಪ್ರತಿನಿಧಿಸುತ್ತೇವೆ. ಹಿಂದೆ, ನಮ್ಮ ಸಹೋದ್ಯೋಗಿಗಳು ಈಗಾಗಲೇ ಲೇಖನವನ್ನು ಬರೆದಿದ್ದಾರೆ . ಇಂದು ನಾವು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಸೇವೆಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸುವ ನಮ್ಮ ಅನುಭವವನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ಬಯಸುತ್ತೇವೆ.
ಮೊದಲಿಗೆ, ಏನನ್ನು ಚರ್ಚಿಸಲಾಗುವುದು ಎಂಬುದರ ಉತ್ತಮ ತಿಳುವಳಿಕೆಗಾಗಿ ನಾವು ನಿಮಗೆ ಕೆಲವು ಸಂಖ್ಯೆಗಳನ್ನು ನೀಡುತ್ತೇವೆ:
- ನಮ್ಮ ಅಭಿವೃದ್ಧಿ ವಿಭಾಗವು ಸ್ವಾವಲಂಬಿ QA, DevOps ಮತ್ತು Scrum ಪ್ರಕ್ರಿಯೆಗಳೊಂದಿಗೆ 100 ಕ್ಕೂ ಹೆಚ್ಚು ವಿಭಿನ್ನ ತಂಡಗಳನ್ನು ಒಳಗೊಂಡಂತೆ 10+ ಜನರನ್ನು ಒಳಗೊಂಡಿದೆ. ಡೆವಲಪ್‌ಮೆಂಟ್ ಸ್ಟಾಕ್ - ಪೈಥಾನ್, ಪಿಎಚ್‌ಪಿ, ಸಿ++, ಜಾವಾ ಮತ್ತು ಗೋಲಾಂಗ್.
- ಪರೀಕ್ಷೆ ಮತ್ತು ಉತ್ಪಾದನಾ ಪರಿಸರದ ಗಾತ್ರವು ಪ್ರತಿಯೊಂದೂ ಸುಮಾರು 2000 ಕಂಟೇನರ್‌ಗಳು. ಅವರು ತಮ್ಮ ಸ್ವಂತ ವರ್ಚುವಲೈಸೇಶನ್‌ನಲ್ಲಿ ಮತ್ತು VMware ಅಡಿಯಲ್ಲಿ Rancher v1.6 ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದಾರೆ.
ಪ್ರೇರಣೆ
ಅವರು ಹೇಳಿದಂತೆ, ಯಾವುದೂ ಶಾಶ್ವತವಾಗಿ ಉಳಿಯುವುದಿಲ್ಲ, ಮತ್ತು ರಾಂಚರ್ ಆವೃತ್ತಿ 1.6 ಗೆ ಬೆಂಬಲದ ಅಂತ್ಯವನ್ನು ಬಹಳ ಹಿಂದೆಯೇ ಘೋಷಿಸಿದರು. ಹೌದು, ಮೂರು ವರ್ಷಗಳಲ್ಲಿ ನಾವು ಅದನ್ನು ಹೇಗೆ ತಯಾರಿಸಬೇಕೆಂದು ಕಲಿತಿದ್ದೇವೆ ಮತ್ತು ಉದ್ಭವಿಸುವ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸುತ್ತೇವೆ, ಆದರೆ ಹೆಚ್ಚಾಗಿ ನಾವು ಎಂದಿಗೂ ಸರಿಪಡಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳನ್ನು ಎದುರಿಸುತ್ತೇವೆ. ರಾಂಚರ್ 1.6 ಹಕ್ಕುಗಳನ್ನು ವಿತರಿಸಲು ಒಸ್ಸಿಫೈಡ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಸಹ ಹೊಂದಿದೆ, ಅಲ್ಲಿ ನೀವು ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ಮಾಡಬಹುದು ಅಥವಾ ಏನನ್ನೂ ಮಾಡಬಹುದು.
ಸ್ವಾಮ್ಯದ ವರ್ಚುವಲೈಸೇಶನ್ ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಮತ್ತು ಅದರ ಸುರಕ್ಷತೆಯ ಮೇಲೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣವನ್ನು ಒದಗಿಸಿದರೂ, ಕಂಪನಿಯ ನಿರಂತರ ಬೆಳವಣಿಗೆ, ಯೋಜನೆಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಅವುಗಳಿಗೆ ಅಗತ್ಯತೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಕಷ್ಟಕರವಾದ ನಿರ್ವಹಣಾ ವೆಚ್ಚಗಳನ್ನು ವಿಧಿಸಿತು.
ನಾವು IaC ಮಾನದಂಡಗಳನ್ನು ಅನುಸರಿಸಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ಅಗತ್ಯವಿದ್ದಲ್ಲಿ, ಯಾವುದೇ ಭೌಗೋಳಿಕ ಸ್ಥಳದಲ್ಲಿ ಮತ್ತು ಮಾರಾಟಗಾರರ ಲಾಕ್ ಇಲ್ಲದೆ ತ್ವರಿತವಾಗಿ ಸಾಮರ್ಥ್ಯವನ್ನು ಪಡೆದುಕೊಳ್ಳಲು ಮತ್ತು ಅದನ್ನು ತ್ವರಿತವಾಗಿ ತ್ಯಜಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಮೊದಲ ಕ್ರಮಗಳನ್ನು
ಮೊದಲನೆಯದಾಗಿ, ನಾವು ಆಧುನಿಕ ತಂತ್ರಜ್ಞಾನಗಳು ಮತ್ತು ಪರಿಹಾರಗಳ ಮೇಲೆ ಅವಲಂಬಿತರಾಗಲು ಬಯಸುತ್ತೇವೆ ಅದು ತಂಡಗಳು ವೇಗವಾದ ಅಭಿವೃದ್ಧಿ ಚಕ್ರವನ್ನು ಹೊಂದಲು ಮತ್ತು ಶಕ್ತಿಯನ್ನು ಒದಗಿಸುವ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಕಾರ್ಯಾಚರಣೆಯ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಅನುವು ಮಾಡಿಕೊಡುತ್ತದೆ.
ಸಹಜವಾಗಿ, ನಮ್ಮ ಮನಸ್ಸಿಗೆ ಬಂದ ಮೊದಲ ವಿಷಯವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್, ಆದರೆ ನಾವು ಉತ್ಸುಕರಾಗಲಿಲ್ಲ ಮತ್ತು ಇದು ಸರಿಯಾದ ಆಯ್ಕೆಯಾಗಿದೆಯೇ ಎಂದು ನೋಡಲು ಸ್ವಲ್ಪ ಸಂಶೋಧನೆ ಮಾಡಿದೆವು. ನಾವು ಮುಕ್ತ ಮೂಲ ಪರಿಹಾರಗಳನ್ನು ಮಾತ್ರ ಮೌಲ್ಯಮಾಪನ ಮಾಡಿದ್ದೇವೆ ಮತ್ತು ಅನ್ಯಾಯದ ಯುದ್ಧದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಬೇಷರತ್ತಾಗಿ ಗೆದ್ದರು.
ಮುಂದೆ ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ರಚಿಸಲು ಉಪಕರಣವನ್ನು ಆಯ್ಕೆ ಮಾಡುವ ಪ್ರಶ್ನೆ ಬಂದಿತು. ನಾವು ಹೆಚ್ಚು ಜನಪ್ರಿಯ ಪರಿಹಾರಗಳನ್ನು ಹೋಲಿಸಿದ್ದೇವೆ: kops, kubespray, kubeadm.
ಪ್ರಾರಂಭಿಸಲು, kubeadm ನಮಗೆ ತುಂಬಾ ಸಂಕೀರ್ಣವಾದ ಮಾರ್ಗವೆಂದು ತೋರುತ್ತದೆ, ಬದಲಿಗೆ "ಬೈಸಿಕಲ್" ನ ಸಂಶೋಧಕರಂತೆ ಮತ್ತು ಕಾಪ್ಸ್ ಸಾಕಷ್ಟು ನಮ್ಯತೆಯನ್ನು ಹೊಂದಿರಲಿಲ್ಲ.
ಮತ್ತು ವಿಜೇತರು:
ನಾವು ನಮ್ಮದೇ ಆದ ವರ್ಚುವಲೈಸೇಶನ್ ಮತ್ತು AWS ನೊಂದಿಗೆ ಪ್ರಯೋಗವನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ನಮ್ಮ ಹಿಂದಿನ ಸಂಪನ್ಮೂಲ ನಿರ್ವಹಣಾ ಮಾದರಿಯನ್ನು ಸರಿಸುಮಾರು ಹೋಲುವ ಏನನ್ನಾದರೂ ಮರುಸೃಷ್ಟಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಅಲ್ಲಿ ಎಲ್ಲರೂ ಒಂದೇ "ಕ್ಲಸ್ಟರ್" ಅನ್ನು ಹಂಚಿಕೊಂಡಿದ್ದೇವೆ. ಮತ್ತು ಈಗ ನಾವು 10 ಸಣ್ಣ ವರ್ಚುವಲ್ ಯಂತ್ರಗಳ ನಮ್ಮ ಮೊದಲ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅವುಗಳಲ್ಲಿ ಒಂದೆರಡು AWS ನಲ್ಲಿವೆ. ನಾವು ಅಲ್ಲಿಗೆ ತಂಡಗಳನ್ನು ಸ್ಥಳಾಂತರಿಸಲು ಪ್ರಯತ್ನಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ, ಎಲ್ಲವೂ "ಒಳ್ಳೆಯದು" ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ಕಥೆಯನ್ನು ಮುಗಿಸಬಹುದು, ಆದರೆ...
ಮೊದಲ ತೊಂದರೆಗಳು
ಅನ್ಸಿಬಲ್ ಎಂದರೆ ಕುಬೆಸ್ಪ್ರೇ ಅನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇದು IaC ಅನ್ನು ಅನುಸರಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಧನವಲ್ಲ: ನೋಡ್‌ಗಳನ್ನು ಕಮಿಷನ್ ಮಾಡುವಾಗ/ಡಿಕಮಿಷನ್ ಮಾಡುವಾಗ, ನಿರಂತರವಾಗಿ ಏನಾದರೂ ತಪ್ಪಾಗಿದೆ ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಹಸ್ತಕ್ಷೇಪದ ಅಗತ್ಯವಿದೆ, ಮತ್ತು ವಿಭಿನ್ನ OS ಗಳನ್ನು ಬಳಸುವಾಗ, ಪ್ಲೇಬುಕ್ ವಿಭಿನ್ನವಾಗಿ ವರ್ತಿಸುತ್ತದೆ. . ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ತಂಡಗಳು ಮತ್ತು ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯು ಹೆಚ್ಚಾದಂತೆ, ಪ್ಲೇಬುಕ್ ಪೂರ್ಣಗೊಳ್ಳಲು ಹೆಚ್ಚು ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತಿದೆ ಎಂದು ನಾವು ಗಮನಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ, ನಮ್ಮ ದಾಖಲೆಯು 3,5 ಗಂಟೆಗಳಾಗಿತ್ತು, ನಿಮ್ಮದೇನು? 🙂
ಮತ್ತು ಕುಬೆಸ್ಪ್ರೇ ಕೇವಲ ಅನ್ಸಿಬಲ್ ಎಂದು ತೋರುತ್ತದೆ, ಮತ್ತು ಎಲ್ಲವೂ ಮೊದಲ ನೋಟದಲ್ಲಿ ಸ್ಪಷ್ಟವಾಗಿದೆ, ಆದರೆ:
ಪ್ರಯಾಣದ ಆರಂಭದಲ್ಲಿ, AWS ಮತ್ತು ವರ್ಚುವಲೈಸೇಶನ್‌ನಲ್ಲಿ ಮಾತ್ರ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದು ಕಾರ್ಯವಾಗಿತ್ತು, ಆದರೆ ನಂತರ, ಆಗಾಗ್ಗೆ ಸಂಭವಿಸಿದಂತೆ, ಅವಶ್ಯಕತೆಗಳು ಬದಲಾಗುತ್ತವೆ.
ಇದರ ಬೆಳಕಿನಲ್ಲಿ, ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒಂದು ಆರ್ಕೆಸ್ಟ್ರೇಶನ್ ವ್ಯವಸ್ಥೆಯಲ್ಲಿ ಸಂಯೋಜಿಸುವ ನಮ್ಮ ಹಳೆಯ ಮಾದರಿಯು ಸೂಕ್ತವಲ್ಲ ಎಂಬುದು ಸ್ಪಷ್ಟವಾಯಿತು - ಕ್ಲಸ್ಟರ್‌ಗಳು ತುಂಬಾ ದೂರದಲ್ಲಿರುವಾಗ ಮತ್ತು ವಿಭಿನ್ನ ಪೂರೈಕೆದಾರರಿಂದ ನಿರ್ವಹಿಸಲ್ಪಡುವ ಸಂದರ್ಭದಲ್ಲಿ.
ಮತ್ತಷ್ಟು ಹೆಚ್ಚು. ಎಲ್ಲಾ ತಂಡಗಳು ಒಂದೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕೆಲಸ ಮಾಡುವಾಗ, ತಪ್ಪಾಗಿ ಸ್ಥಾಪಿಸಲಾದ ನೋಡ್‌ಸೆಲೆಕ್ಟರ್‌ಗಳೊಂದಿಗಿನ ವಿವಿಧ ಸೇವೆಗಳು ಮತ್ತೊಂದು ತಂಡದ "ವಿದೇಶಿ" ಹೋಸ್ಟ್‌ಗೆ ಹಾರಿಹೋಗಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬಳಸಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ಕಳಂಕವನ್ನು ಹೊಂದಿಸಿದರೆ, ಒಂದು ಅಥವಾ ಇನ್ನೊಂದು ಸೇವೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿಲ್ಲ ಎಂದು ನಿರಂತರ ವಿನಂತಿಗಳು ಇದ್ದವು, ಮಾನವ ಅಂಶದಿಂದಾಗಿ ಸರಿಯಾಗಿ ವಿತರಿಸಲಾಗಿಲ್ಲ. ಮತ್ತೊಂದು ಸಮಸ್ಯೆಯು ವೆಚ್ಚವನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡುವುದು, ವಿಶೇಷವಾಗಿ ನೋಡ್‌ಗಳಾದ್ಯಂತ ಸೇವೆಗಳನ್ನು ವಿತರಿಸುವಲ್ಲಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಗಣಿಸುವುದು.
ಉದ್ಯೋಗಿಗಳಿಗೆ ಹಕ್ಕುಗಳನ್ನು ನೀಡುವುದು ಒಂದು ಪ್ರತ್ಯೇಕ ಕಥೆಯಾಗಿದೆ: ಪ್ರತಿ ತಂಡವು ಕ್ಲಸ್ಟರ್‌ನ "ತಲೆಯಲ್ಲಿ" ಇರಲು ಮತ್ತು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ನಿರ್ವಹಿಸಲು ಬಯಸಿದೆ, ಇದು ಸಂಪೂರ್ಣ ಕುಸಿತಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು, ಏಕೆಂದರೆ ತಂಡಗಳು ಮೂಲತಃ ಪರಸ್ಪರ ಸ್ವತಂತ್ರವಾಗಿರುತ್ತವೆ.
ಹೇಗೆ ಇರಬೇಕು?
ಮೇಲಿನ ಮತ್ತು ಹೆಚ್ಚು ಸ್ವತಂತ್ರವಾಗಿರಲು ತಂಡಗಳ ಆಶಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಂಡು, ನಾವು ಸರಳವಾದ ತೀರ್ಮಾನವನ್ನು ಮಾಡಿದ್ದೇವೆ: ಒಂದು ತಂಡ - ಒಂದು ಕ್ಲಸ್ಟರ್.
ಆದ್ದರಿಂದ ನಾವು ಎರಡನೆಯದನ್ನು ಪಡೆದುಕೊಂಡಿದ್ದೇವೆ:
ತದನಂತರ ಮೂರನೇ ಕ್ಲಸ್ಟರ್:
ನಂತರ ನಾವು ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ: ಒಂದು ವರ್ಷದಲ್ಲಿ ನಮ್ಮ ತಂಡಗಳು ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ ಎಂದು ಹೇಳೋಣ? ವಿವಿಧ ಭೌಗೋಳಿಕ ಪ್ರದೇಶಗಳಲ್ಲಿ, ಉದಾಹರಣೆಗೆ, ಅಥವಾ ವಿವಿಧ ಪೂರೈಕೆದಾರರ ನಿಯಂತ್ರಣದಲ್ಲಿ? ಮತ್ತು ಅವರಲ್ಲಿ ಕೆಲವರು ಕೆಲವು ಪರೀಕ್ಷೆಗಳಿಗೆ ತಾತ್ಕಾಲಿಕ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ತ್ವರಿತವಾಗಿ ನಿಯೋಜಿಸಲು ಬಯಸುತ್ತಾರೆ.
ಪೂರ್ಣ ಕುಬರ್ನೆಟ್ಸ್ ಬರುತ್ತಾರೆ! ಇದು ಕೆಲವು ರೀತಿಯ ಮಲ್ಟಿಕುಬರ್ನೆಟ್ಗಳು, ಅದು ತಿರುಗುತ್ತದೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ನಾವೆಲ್ಲರೂ ಈ ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಹೇಗಾದರೂ ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ, ಅವುಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಸುಲಭವಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಜೊತೆಗೆ ಹೊಸದನ್ನು ರಚಿಸುವುದು ಮತ್ತು ಹಸ್ತಚಾಲಿತ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ಹಳೆಯದನ್ನು ರದ್ದುಗೊಳಿಸುವುದು.
ಕುಬರ್ನೆಟ್ಸ್ ಜಗತ್ತಿನಲ್ಲಿ ನಮ್ಮ ಪ್ರಯಾಣದ ಪ್ರಾರಂಭದಿಂದ ಸ್ವಲ್ಪ ಸಮಯ ಕಳೆದಿದೆ ಮತ್ತು ಲಭ್ಯವಿರುವ ಪರಿಹಾರಗಳನ್ನು ಮರುಪರಿಶೀಲಿಸಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಇದು ಈಗಾಗಲೇ ಮಾರುಕಟ್ಟೆಯಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ ಎಂದು ಬದಲಾಯಿತು - ರಾಂಚರ್ 2.2.
ನಮ್ಮ ಸಂಶೋಧನೆಯ ಮೊದಲ ಹಂತದಲ್ಲಿ, ರಾಂಚರ್ ಲ್ಯಾಬ್ಸ್ ಈಗಾಗಲೇ ಆವೃತ್ತಿ 2 ರ ಮೊದಲ ಬಿಡುಗಡೆಯನ್ನು ಮಾಡಿತ್ತು, ಆದರೆ ಕೆಲವು ನಿಯತಾಂಕಗಳೊಂದಿಗೆ ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳಿಲ್ಲದೆ ಅಥವಾ ಅಧಿಕೃತ HELM ಚಾರ್ಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಧಾರಕವನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೂಲಕ ಅದನ್ನು ತ್ವರಿತವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದಾದರೂ, ಅದು ಕಚ್ಚಾ ಎಂದು ತೋರುತ್ತದೆ. ನಮಗೆ, ಮತ್ತು ನಾವು ಈ ನಿರ್ಧಾರವನ್ನು ಅವಲಂಬಿಸಬಹುದೇ ಎಂದು ನಮಗೆ ತಿಳಿದಿರಲಿಲ್ಲ, ಅದನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆಯೇ ಅಥವಾ ತ್ವರಿತವಾಗಿ ಕೈಬಿಡುತ್ತದೆ. UI ನಲ್ಲಿನ ಕ್ಲಸ್ಟರ್ = ಕ್ಲಿಕ್‌ಗಳ ಮಾದರಿಯು ಸಹ ನಮಗೆ ಸರಿಹೊಂದುವುದಿಲ್ಲ, ಮತ್ತು RKE ಯೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಇದು ಕಿರಿದಾದ ಕೇಂದ್ರೀಕೃತ ಸಾಧನವಾಗಿದೆ.
ಆವೃತ್ತಿ Rancher 2.2 ಈಗಾಗಲೇ ಹೆಚ್ಚು ಕಾರ್ಯಸಾಧ್ಯವಾದ ನೋಟವನ್ನು ಹೊಂದಿತ್ತು ಮತ್ತು ಹಿಂದಿನವುಗಳೊಂದಿಗೆ, ಅನೇಕ ಬಾಹ್ಯ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ ಏಕೀಕರಣ, ಹಕ್ಕುಗಳ ವಿತರಣೆ ಮತ್ತು kubeconfig ಫೈಲ್‌ಗಳ ಒಂದು ಬಿಂದು, kubectl ಅನ್ನು ಪ್ರಾರಂಭಿಸುವಂತಹ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯಗಳ ಗುಂಪನ್ನು ಹೊಂದಿತ್ತು. UI ನಲ್ಲಿ ನಿಮ್ಮ ಹಕ್ಕುಗಳೊಂದಿಗೆ ಚಿತ್ರ, ನೆಸ್ಟೆಡ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು ಅಕಾ ಯೋಜನೆಗಳು.
Rancher 2 ರ ಸುತ್ತಲೂ ಈಗಾಗಲೇ ಒಂದು ಸಮುದಾಯವನ್ನು ರಚಿಸಲಾಗಿದೆ ಮತ್ತು ಅದನ್ನು ನಿರ್ವಹಿಸಲು HashiCorp Terraform ಎಂಬ ಪೂರೈಕೆದಾರರನ್ನು ರಚಿಸಲಾಗಿದೆ, ಅದು ನಮಗೆ ಎಲ್ಲವನ್ನೂ ಒಟ್ಟಿಗೆ ಸೇರಿಸಲು ಸಹಾಯ ಮಾಡಿತು.
ಏನಾಯಿತು
ಇದರ ಪರಿಣಾಮವಾಗಿ, ನಾವು ಒಂದು ಸಣ್ಣ ಕ್ಲಸ್ಟರ್ ಚಾಲನೆಯಲ್ಲಿರುವ Rancher ನೊಂದಿಗೆ ಕೊನೆಗೊಂಡಿದ್ದೇವೆ, ಎಲ್ಲಾ ಇತರ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಪ್ರವೇಶಿಸಬಹುದು, ಜೊತೆಗೆ ಅದಕ್ಕೆ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಅನೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳು, ಇವುಗಳಲ್ಲಿ ಯಾವುದಾದರೂ ಪ್ರವೇಶವನ್ನು ldap ಡೈರೆಕ್ಟರಿಗೆ ಬಳಕೆದಾರರನ್ನು ಸೇರಿಸುವಂತೆಯೇ ನೀಡಬಹುದು. ಅದು ಎಲ್ಲಿದೆ ಮತ್ತು ಯಾವ ಪೂರೈಕೆದಾರರ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಅದು ಬಳಸುತ್ತದೆ.
gitlab-ci ಮತ್ತು Terraform ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಕ್ಲೌಡ್ ಪೂರೈಕೆದಾರರು ಅಥವಾ ನಮ್ಮ ಸ್ವಂತ ಮೂಲಸೌಕರ್ಯದಲ್ಲಿ ಯಾವುದೇ ಕಾನ್ಫಿಗರೇಶನ್‌ನ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ಮತ್ತು ಅವುಗಳನ್ನು ರಾಂಚರ್‌ಗೆ ಸಂಪರ್ಕಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ವ್ಯವಸ್ಥೆಯನ್ನು ರಚಿಸಲಾಗಿದೆ. ಇದೆಲ್ಲವನ್ನೂ IaC ಶೈಲಿಯಲ್ಲಿ ಮಾಡಲಾಗುತ್ತದೆ, ಅಲ್ಲಿ ಪ್ರತಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರೆಪೊಸಿಟರಿಯಿಂದ ವಿವರಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಅದರ ಸ್ಥಿತಿಯನ್ನು ಆವೃತ್ತಿ ಮಾಡಲಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಹೆಚ್ಚಿನ ಮಾಡ್ಯೂಲ್‌ಗಳು ಬಾಹ್ಯ ರೆಪೊಸಿಟರಿಗಳಿಂದ ಸಂಪರ್ಕಗೊಂಡಿವೆ, ಇದರಿಂದಾಗಿ ವೇರಿಯಬಲ್‌ಗಳನ್ನು ರವಾನಿಸಲು ಅಥವಾ ನಿದರ್ಶನಗಳಿಗಾಗಿ ನಿಮ್ಮ ಕಸ್ಟಮ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ವಿವರಿಸಲು ಉಳಿದಿದೆ, ಇದು ಕೋಡ್ ಪುನರಾವರ್ತನೆಯ ಶೇಕಡಾವಾರು ಪ್ರಮಾಣವನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಸಹಜವಾಗಿ, ನಮ್ಮ ಪ್ರಯಾಣವು ಇನ್ನೂ ದೂರದಲ್ಲಿದೆ ಮತ್ತು ಯಾವುದೇ ಕ್ಲಸ್ಟರ್‌ಗಳ ಲಾಗ್‌ಗಳು ಮತ್ತು ಮೆಟ್ರಿಕ್‌ಗಳೊಂದಿಗಿನ ಒಂದೇ ಹಂತದ ಕೆಲಸ, ಸೇವಾ ಜಾಲರಿ, ಮಲ್ಟಿಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಲೋಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಗಿಟಾಪ್‌ಗಳು ಮತ್ತು ಹೆಚ್ಚಿನವುಗಳಂತಹ ಅನೇಕ ಆಸಕ್ತಿದಾಯಕ ಕಾರ್ಯಗಳು ಮುಂದೆ ಇವೆ. ನಮ್ಮ ಅನುಭವವು ನಿಮಗೆ ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ ಎಂದು ನಾವು ಭಾವಿಸುತ್ತೇವೆ!
ಲೇಖನವನ್ನು ಎ. ಆಂಟಿಪೋವ್, ಎ. ಗನುಷ್, ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಬರೆದಿದ್ದಾರೆ.
ಮೂಲ: www.habr.com