ಒಂದೇ ಒಂದು ಕಂಟೇನರ್ ಅನ್ನು ನಿಯೋಜಿಸುವುದು (deploy) ಸುಲಭ. ಹತ್ತು ಕಂಟೇನರ್ಗಳನ್ನು ನಿಯೋಜಿಸುವುದು ನಿರ್ವಹಣೆಗೆ ಒಳಗೆ ಬರುತ್ತದೆ. ಆದರೆ ನೀವು ಡಜನ್ಗಟ್ಟಲೆ ಯಂತ್ರಗಳಲ್ಲಿ ನೂರಾರು ಕಂಟೇನರ್ಗಳನ್ನು ನಡೆಸಲು ಪ್ರಾರಂಭಿಸಿದಾಗ, ಮ್ಯಾನುಯಲ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಕಷ್ಟವಾಗುವುದಲ್ಲದೆ ಅಸಾಧ್ಯವಾಗುತ್ತದೆ. ಯಾವ ಕಂಟೇನರ್ ಎಲ್ಲಿ ಇದೆ ಎಂಬುದು ನಿಮ್ಮ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ. ಒಂದು ಸರ್ವರ್ ವೈಫಲ್ಯ ಅನುಭವಿಸಿದರೆ, ಯಾರಾದರೂ ಎಚ್ಚರಗೊಂಡು ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವವರೆಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಮಾಯವಾಗುತ್ತದೆ. ನೀವು ಹೊಸ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲೇ ಟ್ರಾಫಿಕ್ ಏರಿಕೆ ನಿಮ್ಮ ಸೆಟಪ್ ಅನ್ನು ಅತಿಯಾಗಿ ಒತ್ತಡಕ್ಕೆ ತಳ್ಳುತ್ತದೆ. ಇದೇ ಸರಿಯಾಗಿ Kubernetes ಪ್ರವೇಶಿಸುವ ಸಂದರ್ಭ. ಇದು ಕೇವಲ ಮತ್ತೊಂದು DevOps ಟೂಲ್ ಅಲ್ಲ. ಇದು ಕಂಟೇನರ್ ಮ್ಯಾನೇಜ್ಮೆಂಟ್ ಅನ್ನು ಸ್ಕ್ರಿಪ್ಟಿಂಗ್ ವ್ಯಾಯಾಮಕ್ಕಿಂತ ಹೆಚ್ಚಾಗಿ ಒಂದು ನಿಯಂತ್ರಣದ ಸಮಸ್ಯೆ (control problem) ಎಂದು ಪರಿಗಣಿಸುವ ಒಂದು ऑर्ಕೆಸ್ಟ್ರೇಶನ್ ಲೇಯರ್ ಆಗಿದೆ.
ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಅಂತಿಮವಾಗಿ ಏಕೆ ವಿಫಲವಾಗುತ್ತವೆ
ಹೆಚ್ಚಿನ ತಂಡಗಳು ಶೆಲ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಅಥವಾ ಮೂಲಭೂತ ಆಟೊಮೇಷನ್ನೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಅವರು ಇಮೇಜ್ಗಳನ್ನು ಪಡೆಯಲು (pull), ಕಂಟೇನರ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು, ಲಾಗ್ಗಳನ್ನು ಗಮನಿಸಲು ಮತ್ತು ವಿಫಲವಾದ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಕಮಾಂಡ್ಗಳನ್ನು ಬರೆಯುತ್ತಾರೆ. ಅಂತಹ ವಿಧಾನವು ಒಂದು ಪ್ರೂಫ್ ಆಫ್ ಕಾನ್ಸೆಪ್ಟ್ಗೆ (proof of concept) ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಆದರೆ ನೈಜ ಪ್ರಪಂಚದ ಲೋಡ್ ಅಡಿಯಲ್ಲಿ ಅದು ಕುಸಿಯುತ್ತದೆ. ಮೈಕ್ರೋಸರ್ವಿಸಸ್ (Microservices) ವಿವಿಧ ಹೋಸ್ಟ್ಗಳ ನಡುವೆ ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುತ್ತವೆ, ನಿರ್ದಿಷ್ಟ ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ಗಳ ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿರುತ್ತವೆ, ಕಂಟೇನರ್ ಮರುಪ್ರಾರಂಭವಾದರೂ ಉಳಿಯುವ ಪರ್ಸಿಸ್ಟೆಂಟ್ ಸ್ಟೋರೇಜ್ ಅಗತ್ಯವಿರುತ್ತದೆ ಮತ್ತು ವಿವಿಧ ವರ್ಷನ್ಗಳ ನಡುವೆ ಸ್ಥಿರವಾದ ನೆಟ್ವರ್ಕಿಂಗ್ ಅನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತವೆ. ವರ್ಚುವಲ್ ಮೆಷಿನ್ ಮಾಯವಾದಾಗ ಒಂದು ಸ್ಕ್ರಿಪ್ಟ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವರ್ಕ್ಲೋಡ್ ಅನ್ನು ಮರು-ನಿಯೋಜಿಸಲು (reschedule) ಸಾಧ್ಯವಿಲ್ಲ. ಕ್ರ್ಯಾಶ್ ಲೂಪ್ನಲ್ಲಿ ಸಿಲುಕಿರುವ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳನ್ನು ಬಿಟ್ಟು, ಆರೋಗ್ಯಕರ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳ ನಡುವೆ ನೆಟ್ವರ್ಕ್ ಟ್ರಾಫಿಕ್ ಅನ್ನು ವಿತರಿಸಲು ಅದಕ್ಕೆ ಸಾಧ್ಯವಿಲ್ಲ. Kubernetes ಈ ನಿರ್ಧಾರಗಳನ್ನು ಕ್ಲಸ್ಟರ್ನಲ್ಲೇ ಜವಾಬ್ದಾರೀಕರಿಸುವ ಮೂಲಕ ಇದನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ನೀವು ಏನನ್ನು ಬಯಸುತ್ತೀರಿ ಎಂಬುದನ್ನು ವಿವರಿಸಿದರೆ ಸಾಕು, ಸಿಸ್ಟಮ್ ಆ ಸ್ಥಿತಿಯನ್ನು (state) ನಿರಂತರವಾಗಿ ಜಾರಿಗೆ ತರುತ್ತದೆ.
ಇದು ನಿಮಗೆ ನೀಡುವ ಮೂರು ವಿಷಯಗಳು
Kubernetes ಮೂರು ಪ್ರಮುಖ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುತ್ತದೆ, ಇವು ಮ್ಯಾನುಯಲ್ ಫೈರ್ಫೈಟಿಂಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತ ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನಾಗಿ ಬದಲಾಯಿಸುತ್ತವೆ.
High availability ಎಂದರೆ ನಿಮ್ಮ ಮೂಲಸೌಕರ್ಯದ ಭಾಗಗಳು ವಿಫಲವಾದರೂ ಸಹ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಆನ್ಲೈನ್ನಲ್ಲಿರುತ್ತವೆ ಎಂದರ್ಥ. ಒಂದು ಕಂಟೇನರ್ ಕ್ರ್ಯಾಶ್ ಆದರೆ, Kubernetes ಅದನ್ನು ಸೆಕೆಂಡುಗಳ ಒಳಗೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಒಂದು ಸಂಪೂರ್ಣ ವರ್ಕರ್ ನೋಡ್ (worker node) ಸ್ಥಗಿತಗೊಂಡರೆ, ಶೆಡ್ಯೂಲರ್ (scheduler) ಆ缺失 ಹಾರ್ಟ್ಬೀಟ್ ಅನ್ನು ಗಮನಿಸುತ್ತದೆ ಮತ್ತು ಬಾಧಿತ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಕ್ಲಸ್ಟರ್ನ ಇತರ ಆರೋಗ್ಯಕರ ಯಂತ್ರಗಳಿಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಿದ ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಯ ಮೇಲೆ ಸಿಸ್ಟಮ್ ನಿರಂತರ ನಿಗಾ ಇಡುತ್ತದೆ ಮತ್ತು ಮಾನವ ಹಸ್ತಕ್ಷೇಪವಿಲ್ಲದೆ ವ್ಯತ್ಯಾಸಗಳನ್ನು ಸರಿಪಡಿಸುತ್ತದೆ.
Scalability ಎಂದರೆ ನಿಮ್ಮ ಬಳಕೆದಾರರ ಸಂಖ್ಯೆಯೊಂದಿಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ಗಳು ಬೆಳೆಯುತ್ತವೆ ಎಂದರ್ಥ. ಕೇವಲ ಎರಡು ಗಂಟೆಯ ಟ್ರಾಫಿಕ್ ಪೀಕ್ ಅನ್ನು ತಡೆದುಕೊಳ್ಳಲು ಇಪ್ಪತ್ತು ಸರ್ವರ್ಗಳನ್ನು ಸಿದ್ಧಪಡಿಸುವ ಬದಲು, ನೀವು CPU ಬಳಕೆ ಅಥವಾ ರಿಕ್ವೆಸ್ಟ್ ಲೇಟೆನ್ಸಿ (request latency) ನಂತಹ ಪ್ರಮುಖ ಮೆಟ್ರಿಕ್ಗಳನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು ಮತ್ತು ಮಿತಿಗಳನ್ನು ಮೀರಿದಾಗ ಕ್ಲಸ್ಟರ್ ಹೆಚ್ಚಿನ ಕಂಟೇನರ್ ಇನ್ಸ್ಟೆನ್ಸ್ಗಳನ್ನು ಸೇರಿಸಲು ಬಿಡಬಹುದು. ಬೇಡಿಕೆ ಕಡಿಮೆಯಾದಾಗ, ರೆಪ್ಲಿಕಾ ಕೌಂಟ್ (replica count) ಮತ್ತೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ. ನಿಮಗೆ ಬೇಕಾದಾಗ, ಎಷ್ಟು ಬೇಕೋ ಅಷ್ಟನ್ನು ಮಾತ್ರ ನೀವು ಪಾವತಿಸುತ್ತೀರಿ.
Disaster recovery ಎಂದರೆ ವೈಫಲ್ಯದ ನಂತರ ನಿಮ್ಮ ಡೇಟಾ ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ ಮರಳಿ ಬರುತ್ತದೆ ಎಂದರ್ಥ. Kubernetes ಇಡೀ ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಕೀ-ವ್ಯಾಲ್ಯೂ ಸ್ಟೋರ್ನಲ್ಲಿ (distributed key-value store) ಸಂಗ್ರಹಿಸುತ್ತದೆ. ಒಂದು ಭೀಕರ ವೈಫಲ್ಯವು ವರ್ಕರ್ ನೋಡ್ಗಳನ್ನು ಅಥವಾ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ನ ಭಾಗವನ್ನು ಅಳಿಸಿಹಾಕಿದರೂ ಸಹ, ಆ ಸಂಗ್ರಹಿಸಿದ ಸ್ಥಿತಿಯು ನಿಮ್ಮ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ಅವುಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದಂತೆಯೇ ಮರುನಿರ್ಮಿಸಲು ಸಿಸ್ಟಮ್ಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ತನ್ನ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗಿರಬೇಕೆಂದು ನೆನಪಿಟ್ಟುಕೊಂಡಿರುವುದರಿಂದ ನಿಮ್ಮ ಡೇಟಾ ಮರಳಿ ಬರುತ್ತದೆ.
ಸೆಟಪ್: ಮೆದುಳು ಮತ್ತು ಸ್ನಾಯುಗಳು
Kubernetes ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ಎರಡು ಮೂಲಭೂತ ಪಾತ್ರಗಳಿವೆ (roles), ಇವುಗಳನ್ನು ಮೆದುಳು ಮತ್ತು ಸ್ನಾಯು ಎಂದು ವಿವರಿಸಬಹುದು ಮತ್ತು ಈ ಹೋಲಿಕೆಯು ಪ್ರಾಯೋಗಿಕವಾಗಿ ಸರಿಯಾಗಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ.
Master Node ಮೆದುಳಿನಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಗ್ರಾಹಕರಿಗೆ ನೇರವಾಗಿ ಕಾಣುವ ಅಪ್ಲಿಕೇಶನ್ಗಳನ್ನು ನಡೆಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಇದು ಕಾರ್ಯಗಳನ್ನು ಶೆಡ್ಯೂಲ್ ಮಾಡುವ, ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯನ್ನು ನಿರ್ವಹಿಸುವ ಮತ್ತು ಬದಲಾವಣೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಘಟಕಗಳನ್ನು ಹೋಸ್ಟ್ ಮಾಡುತ್ತದೆ. ನೀವು ಒಂದು ಕಮಾಂಡ್ ನೀಡಿದಾಗ ಅಥವಾ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಸಲ್ಲಿಸಿದಾಗ, ವರ್ಕ್ಲೋಡ್ ಎಲ್ಲಿ ಇರಬೇಕು, ಅದು ಆರೋಗ್ಯಕರವಾಗಿದೆಯೇ ಮತ್ತು ಅದು ಸರಿಯಿಲ್ಲದಿದ್ದಾಗ ಏನು ಮಾಡಬೇಕು ಎಂಬುದನ್ನು ಮಾಸ್ಟರ್ ನೋಡ್ ನಿರ್ಧರಿಸುತ್ತದೆ.
Worker Nodes ಸ್ನಾಯುಗಳಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ. ಪ್ರತಿಯೊಂದು ವರ್ಕರ್ ಮಾಸ್ಟರ್ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವ ಮತ್ತು ನಿಜವಾದ ಪಾಡ್ಗಳನ್ನು (pods) ಕಾರ್ಯಗತಗೊಳಿಸಲು ಕಂಟೇನರ್ ರನ್ಟೈಮ್ ಅನ್ನು ಬಳಸುವ ಲೈಟ್ವೇಯ್ಟ್ ಏಜೆಂಟ್ ಅನ್ನು ರನ್ ಮಾಡುತ್ತದೆ. ಈ ನೋಡ್ಗಳೇ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕೋಡ್ CPU ಮತ್ತು ಮೆಮೊರಿಯನ್ನು ಬಳಸುವ ಸ್ಥಳಗಳಾಗಿವೆ. ಹೆಚ್ಚಿನ ವರ್ಕರ್ ನೋಡ್ಗಳನ್ನು ಸೇರಿಸಿದರೆ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ನ ಸಾಮರ್ಥ್ಯ ಹೆಚ್ಚಾಗುತ್ತದೆ. ರಿಡಂಡನ್ಸಿಗಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾದ ಹೆಚ್ಚಿನ ಮಾಸ್ಟರ್ ನೋಡ್ಗಳನ್ನು ಸೇರಿಸಿದರೆ, ನಿಮ್ಮ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ವೈಯಕ್ತಿಕ ಹಾರ್ಡ್ವೇರ್ ವೈಫಲ್ಯಗಳಿಗೆ ತಡೆದುಕೊಳ್ಳುವ ಶಕ್ತಿಯನ್ನು ಪಡೆಯುತ್ತದೆ.
Pods, Containers, ಮತ್ತು Services
Kubernetes ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು, ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಹೇಗೆ ಪ್ಯಾಕೇಜ್ ಮಾಡಲಾಗುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಹೇಗೆ ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸುವ ಮೂರು ಪದಗಳನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಬೇಕಾಗುತ್ತದೆ.
Containers ಎಂಬವು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅದರ ಅವಲಂಬಿತಗಳು (dependencies), ಲೈಬ್ರರಿಗಳು ಮತ್ತು ಕಾನ್ಫಿಗರೇಶನ್ನೊಂದಿಗೆ ಒಟ್ಟಿಗೆ ಸೇರಿಸುವ ಪ್ಯಾಕೇಜ್ಗಳಾಗಿವೆ. ಅವು ಸಾಫ್ಟ್ವೇರ್ ಅನ್ನು ಅಡಿಯಲ್ಲಿರುವ ಹೋಸ್ಟ್ನಿಂದ ಪ್ರತ್ಯೇಕಿಸುತ್ತವೆ, ಇದರಿಂದಾಗಿ ಅದು ಡೆವಲಪ್ಮೆಂಟ್, ಸ್ಟೇಜಿಂಗ್ ಮತ್ತು ಪ್ರೊಡಕ್ಷನ್ನಲ್ಲಿ ಒಂದೇ ರೀತಿಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.
Pods ಎಂಬುದು Kubernetes ನಲ್ಲಿ ಅತ್ಯಂತ ಚಿಕ್ಕದಾದ ನಿಯೋಜಿಸಬಹುದಾದ (deployable) ಘಟಕವಾಗಿದೆ. ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಬೇಕಾದ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕಂಟೇನರ್ಗಳನ್ನು (containers) ಒಂದು ಪಾಡ್ ಒಳಗೊಂಡಿರುತ್ತದೆ. ಅವು ಒಂದೇ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ ಮತ್ತು ಒಂದೇ ಸ್ಥಳೀಯ ಸ್ಟೋರೇಜ್ ವಾಲ್ಯೂಮ್ಗಳನ್ನು ಪ್ರವೇಶಿಸಬಲ್ಲವು. ಇದು ಮುಖ್ಯವಾದುದು: ನೀವು ಕೇವಲ ಕಂಟೇನರ್ ಅನ್ನು ನೇರವಾಗಿ ನಿಯೋಜಿಸುವುದಿಲ್ಲ. ಬದಲಾಗಿ, ಅದನ್ನು ಒಳಗೊಂಡಿರುವ ಒಂದು ಪಾಡ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೀರಿ. ಪಾಡ್ಗಳು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿಯೇ ಅಲ್ಪಕಾಲಿಕ (ephemeral) ಆಗಿರುತ್ತವೆ. ಪರಿಸ್ಥಿತಿಗಳು ಬದಲಾದಂತೆ ಅವು ಸೃಷ್ಟಿಯಾಗುತ್ತವೆ, ನಾಶವಾಗುತ್ತವೆ ಮತ್ತು ಬದಲಾಗುತ್ತವೆ. ಅವುಗಳ ಜೀವಿತಾವಧಿಯು ವಿನ್ಯಾಸದ ಮೂಲಕವೇ ಡೈನಾಮಿಕ್ ಆಗಿರುತ್ತದೆ.
ಪಾಡ್ಗಳು ತಾತ್ಕಾಲಿಕವಾಗಿರುವುದರಿಂದ (transient) Services ಅಸ್ತಿತ್ವದಲ್ಲಿವೆ. ಪ್ರತಿ ಬಾರಿ ಪಾಡ್ ಮರುಪ್ರಾರಂಭವಾದಾಗ, ಅದು ಹೊಸ ಆಂತರಿಕ IP ವಿಳಾಸವನ್ನು ಪಡೆಯುವ ಸಾಧ್ಯತೆ ಇರುತ್ತದೆ. ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ನ ಇತರ ಭಾಗಗಳು ನೇರವಾಗಿ ಆ ಬದಲಾಗುತ್ತಿರುವ ವಿಳಾಸಗಳಿಗೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಅವು ಪದೇ ಪದೇ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತವೆ. ಸರ್ವಿಸ್ ನಿಮ್ಮ ಪಾಡ್ಗಳಿಗೆ ಸ್ಥಿರವಾದ IP ವಿಳಾಸ ಮತ್ತು DNS ಹೆಸರನ್ನು ನೀಡುತ್ತದೆ. ಇದು ಒಂದು ಸ್ಥಿರವಾದ ಮುಂಭಾಗದ ದ್ವಾರದಂತೆ (front door) ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ತನ್ನ ಸೆಲೆಕ್ಟರ್ಗೆ ಹೊಂದಿಕೆಯಾಗುವ ಎಲ್ಲಾ ಆರೋಗ್ಯಕರ ಪಾಡ್ಗಳ ನಡುವೆ ಬರುವ ವಿನಂತಿಗಳನ್ನು (requests) ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸ್ ಮಾಡುತ್ತದೆ. ಇದು ನಿಮ್ಮ ಕ್ಲೈಂಟ್ಗಳನ್ನು ಪ್ರತ್ಯೇಕ ಕಂಟೇನರ್ಗಳ ಜೀವನ ಚಕ್ರದ ಗೊಂದಲದಿಂದ ಮುಕ್ತಗೊಳಿಸುತ್ತದೆ.
ದೊಡ್ಡ ಮಟ್ಟದಲ್ಲಿ Kubernetes: Netflix ಉದಾಹರಣೆ
Netflix ತನ್ನ ಕಂಟೆಂಟ್ ಡೆಲಿವರಿ ನೆಟ್ವರ್ಕ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು Kubernetes ಅನ್ನು ಬಳಸುತ್ತದೆ. ಈ ಮೂಲಸೌಕರ್ಯವು ಪ್ರಪಂಚದಾದ್ಯಂತದ ಲಕ್ಷಾಂತರ ವೀಕ್ಷಕರಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ವಿಡಿಯೋ ಸ್ಟ್ರೀಮ್ಗಳನ್ನು ತಲುಪಿಸುತ್ತದೆ. ಒಂದು ಜನಪ್ರಿಯ ಶೋ ಬಿಡುಗಡೆಯಾದಾಗ ಮತ್ತು ಬೇಡಿಕೆ ಹೆಚ್ಚಾದಾಗ, ಕ್ಲಸ್ಟರ್ ಬಳಕೆದಾರರಿಗೆ ಹತ್ತಿರದಲ್ಲಿರುವ ವಿಡಿಯೋ ಸೆಗ್ಮೆಂಟ್ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ ಕ್ಯಾಶ್ ನೋಡ್ಗಳನ್ನು (cache nodes) ವಿಸ್ತರಿಸುತ್ತದೆ (scales out). ಒಂದು ವೇಳೆ ಪ್ರಾದೇಶಿಕ ನೋಡ್ ವೈಫಲ್ಯಕ್ಕೊಳಗಾದರೆ, ಟ್ರಾಫಿಕ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಬೇರೆ ಮಾರ್ಗಕ್ಕೆ ತಿರುಗುತ್ತದೆ. ಇದರ ಪರಿಣಾಮವಾಗಿ, ಎಂಜಿನಿಯರ್ಗೆ ಯಾವುದೇ ತುರ್ತು ಕರೆ ಅಥವಾ ಸಂದೇಶ ಕಳುಹಿಸುವ ಅಗತ್ಯವಿಲ್ಲದೆ ಲಕ್ಷಾಂತರ ಜನರಿಗೆ ಚಲನಚಿತ್ರಗಳು ತಡೆರಹಿತವಾಗಿ ಸಾಗುತ್ತವೆ. ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ (orchestrator) ಪ್ರಮಾಣ ಮತ್ತು ವೈಫಲ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಇದರಿಂದ ಸೇವೆ ಅಡೆತಡೆಯಿಲ್ಲದೆ ಮುಂದುವರಿಯುತ್ತದೆ.
ಪ್ರಾರಂಭಿಸುವುದು: YAML, JSON ಮತ್ತು API ಸರ್ವರ್
Kubernetes ಪ್ರಾರಂಭಿಸುವುದು ಎಂದರೆ ಇಂಪೆರೇಟಿವ್ ಕ್ಲಿಕ್-ಆಪ್ಸ್ (imperative click-ops) ಅನ್ನು ಬಿಟ್ಟುប្រಕಟಾತ್ಮಕ ಕಾನ್ಫಿಗರೇಶನ್ (declarative configuration) ಅನ್ನು ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ಎಂದರ್ಥ. ನೀವು ಬಯಸುವಿದ್ದನ್ನು YAML ಅಥವಾ JSON ಫೈಲ್ಗಳಲ್ಲಿ ಬರೆಯುತ್ತೀರಿ. ಈ ಮ್ಯಾನಿಫೆಸ್ಟ್ಗಳು (manifests) ಕಂಟೇನರ್ ಇಮೇಜ್ನಿಂದ ಹಿಡಿದು ರೆಪ್ಲಿಕಾಗಳ ಸಂಖ್ಯೆ, ಎಕ್ಸ್ಪೋಸ್ಡ್ ಪೋರ್ಟ್ಗಳು, ಎನ್ವಿರಾನ್ಮೆಂಟ್ ವೇರಿಯೇಬಲ್ಗಳು ಮತ್ತು ಸ್ಟೋರೇಜ್ ಮೌಂಟ್ಗಳವರೆಗೆ ಎಲ್ಲವನ್ನೂ ವಿವರಿಸುತ್ತವೆ. ನಿಮ್ಮ ಫೈಲ್ ಸಿದ್ಧವಾದ ನಂತರ, ನೀವು ಅದನ್ನು ಮಾಸ್ಟರ್ ನೋಡ್ನಲ್ಲಿರುವ API ಸರ್ವರ್ಗೆ ಕಳುಹಿಸುತ್ತೀರಿ. ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಆ ಘೋಷಣೆಯನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಅದನ್ನು ಕ್ಲಸ್ಟರ್ ಸ್ಟೇಟ್ ಡೇಟಾಬೇಸ್ನಲ್ಲಿ ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ನಂತರ ವಾಸ್ತವವು ನಿಮ್ಮ ವಿವರಣೆಗೆ ಅನುಗುಣವಾಗಿರುವಂತೆ ಮಾಡಲು ಕೆಲಸ ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ನೀವು Kubernetes ಗೆ ಅದರ ಕೆಲಸವನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ನಿಖರವಾಗಿ ಹೇಳುವುದಿಲ್ಲ. ಅಂತಿಮ ಫಲಿತಾಂಶ ಹೇಗಿರಬೇಕು ಎಂದು ನೀವು ಹೇಳುತ್ತೀರಿ, ಮತ್ತು ಅದು ಅಗತ್ಯ ಕ್ರಮಗಳನ್ನು ತಾನೇ ಕಂಡುಕೊಳ್ಳುತ್ತದೆ.
ನಿಜವಾದ ಸಾರಾಂಶ
Kubernetes ಕಲಿಯಲು ಸ್ವಲ್ಪ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ. ಆರಂಭದಲ್ಲಿ ಪದಕೋಶವು (terminology) ಕಠಿಣವೆನಿಸಬಹುದು. ಇದರಲ್ಲಿ ಅನೇಕ ಚಲಿಸುವ ಭಾಗಗಳಿವೆ ಮತ್ತು ಡಿಸ್ಟ್ರಿಬ್ಯೂಟೆಡ್ ಸಿಸ್ಟಮ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದು ಏಕೈಕ ಸರ್ವರ್ ಅನ್ನು ಡಿಬಗ್ ಮಾಡುವುದಕ್ಕಿಂತ ಸಹಜವಾಗಿಯೇ ಕಷ್ಟಕರವಾಗಿದೆ. ಆದರೆ ಇದರ ಪ್ರತಿಫಲವು ಕಾರ್ಯಾಚರಣೆಯ ಶಾಂತತೆ (operational calm). ನೀವು ಪ್ರತ್ಯೇಕ ಯಂತ್ರಗಳನ್ನು ನಿರಂತರವಾಗಿ ಗಮನಿಸುವ ಅಗತ್ಯವಿರುವುದಿಲ್ಲ. ಬೆಳಗಿನ 3 ಗಂಟೆಯ ಸಮಯದಲ್ಲಿ ಸೇವೆಯಲ್ಲಿ ವ್ಯತ್ಯಯವಾದಾಗ ನಿಮ್ಮ ಸ್ಟಾರ್ಟಪ್ ಸ್ಕ್ರಿಪ್ಟ್ಗಳು ಕೆಲಸ ಮಾಡುತ್ತವೆ ಎಂದು ಪ್ರಾರ್ಥಿಸುವುದನ್ನು ನೀವು ನಿಲ್ಲಿಸುತ್ತೀರಿ. ನೋಡ್ಗಳು ವೈಫಲ್ಯಕ್ಕೊಳಗಾಗಬಹುದು ಎಂದು ಭಾವಿಸಿ, ನೀವು ಡಿಫಾಲ್ಟ್ ಆಗಿ ವೈಫಲ್ಯಗಳಿಗಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ ಮತ್ತು ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಅಖಂಡವಾಗಿಡಲು ಆರ್ಕೆಸ್ಟ್ರೇಟರ್ ಅನ್ನು ನಂಬುತ್ತೀರಿ. ಏನೂ ಮುರಿಯಬಾರದು ಎಂದು ಆಶಿಸುವುದರಿಂದ, ವ್ಯವಸ್ಥೆಯು ಮುರಿಯುವಿಕೆಯನ್ನು ನಿಭಾಯಿಸಬಲ್ಲದು ಎಂದು ತಿಳಿದುಕೊಳ್ಳುವವರೆಗೆ ಮನಸ್ಥಿತಿಯಲ್ಲಿ ಆಗುವ ಆ ಬದಲಾವಣೆಯೇ ಈ ಪ್ರಯತ್ನವನ್ನು ಯಶಸ್ವಿ ಮಾಡುತ್ತದೆ.
ಮೂಲ: What Is Kubernetes? Kubernetes Explained in 15 Mins
ಐಚ್ಛಿಕ ಕಲಿಕಾ ಸಮುದಾಯ: GyaanSetu AI on Telegram