ಕ್ಲಸ್ಟರ್ಡ್ ಉತ್ಪಾದನಾ ಪರಿಸರದಲ್ಲಿ ಡಾಕರ್ ಕಂಟೇನರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಉತ್ತಮ ಸಾಧನವಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಕುಬರ್ನೆಟ್ಸ್ ಪರಿಹರಿಸಲಾಗದ ಸಮಸ್ಯೆಗಳಿವೆ. ಆಗಾಗ್ಗೆ ಉತ್ಪಾದನಾ ನಿಯೋಜನೆಗಳಿಗಾಗಿ, ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಅಲಭ್ಯತೆಯನ್ನು ತಪ್ಪಿಸಲು ನಮಗೆ ಸಂಪೂರ್ಣ ಸ್ವಯಂಚಾಲಿತ ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆಯ ಅಗತ್ಯವಿದೆ, ಇದು ಬಾಹ್ಯ HTTP ವಿನಂತಿಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಮತ್ತು SSL ಆಫ್‌ಲೋಡ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿದೆ. ಇದಕ್ಕೆ ha-proxy ನಂತಹ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನೊಂದಿಗೆ ಏಕೀಕರಣದ ಅಗತ್ಯವಿದೆ. ಕ್ಲೌಡ್ ಪರಿಸರದಲ್ಲಿ ಚಲಿಸುವಾಗ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನ ಅರೆ-ಸ್ವಯಂಚಾಲಿತ ಸ್ಕೇಲಿಂಗ್ ಮತ್ತೊಂದು ಸವಾಲಾಗಿದೆ, ಉದಾಹರಣೆಗೆ ರಾತ್ರಿಯಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಭಾಗಶಃ ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು.
ಕುಬರ್ನೆಟ್ಸ್ ಈ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಬಾಕ್ಸ್‌ನ ಹೊರಗೆ ಹೊಂದಿಲ್ಲದಿದ್ದರೂ, ಇದೇ ರೀತಿಯ ಸಮಸ್ಯೆಗಳನ್ನು ಪರಿಹರಿಸಲು ನೀವು ಬಳಸಬಹುದಾದ API ಅನ್ನು ಇದು ಒದಗಿಸುತ್ತದೆ. ಕ್ಲೌಡ್ ಆರ್‌ಟಿಐ ಯೋಜನೆಯ ಭಾಗವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನ ಸ್ವಯಂಚಾಲಿತ ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ ಮತ್ತು ಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ ಪರಿಕರಗಳನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಲಾಗಿದೆ, ಇದನ್ನು ಮುಕ್ತ ಮೂಲವನ್ನು ಆಧರಿಸಿ ರಚಿಸಲಾಗಿದೆ.
ಈ ಲೇಖನ, ವೀಡಿಯೊ ಪ್ರತಿಲೇಖನ, ಉತ್ಪಾದನೆಯಲ್ಲಿ ಡೌನ್‌ಟೈಮ್ ಇಲ್ಲದೆಯೇ ಗಿಟ್ ಕಮಿಟ್‌ನಿಂದ ಕೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸುವ ಉತ್ಪಾದನಾ-ಸಿದ್ಧ ಪರಿಸರವನ್ನು ರಚಿಸಲು ಇತರ ತೆರೆದ ಮೂಲ ಘಟಕಗಳೊಂದಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೇಗೆ ಹೊಂದಿಸುವುದು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.
ಆದ್ದರಿಂದ, ಒಮ್ಮೆ ನೀವು ಹೊರಗಿನ ಪ್ರಪಂಚದಿಂದ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಪಡೆದರೆ, ನೀವು ಸ್ವಯಂಚಾಲಿತತೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಂದಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು, ಅಂದರೆ, ನೀವು ಜಿಟ್ ಕಮಿಟ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಹಂತಕ್ಕೆ ತರಬಹುದು ಮತ್ತು ಈ ಗಿಟ್ ಕಮಿಟ್ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ಈ ಹಂತಗಳನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ನಿಯೋಜನೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ, ನಾವು ಅಲಭ್ಯತೆಯನ್ನು ಎದುರಿಸಲು ಬಯಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ, ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಯಾವುದೇ ಯಾಂತ್ರೀಕೃತಗೊಂಡ API ನೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಬಾಕ್ಸ್ ಹೊರಗೆ ಉತ್ಪಾದಕವಾಗಿ ಬಳಸಬಹುದಾದ ಸಾಧನವಲ್ಲ. ಸಹಜವಾಗಿ, ನೀವು ಅದನ್ನು ಮಾಡಬಹುದು, kubectl ಅನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಹೀಗೆ ಮಾಡಬಹುದು, ಆದರೆ ಇನ್ನೂ API ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ನಲ್ಲಿ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಮತ್ತು ಉಪಯುಕ್ತ ವಿಷಯವಾಗಿದೆ. API ಅನ್ನು ಫಂಕ್ಷನ್‌ಗಳ ಒಂದು ಸೆಟ್ ಆಗಿ ಬಳಸುವ ಮೂಲಕ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನೀವು ಮಾಡಲು ಬಯಸುವ ಬಹುತೇಕ ಎಲ್ಲವನ್ನೂ ನೀವು ಪ್ರವೇಶಿಸಬಹುದು. kubectl ಸ್ವತಃ REST API ಅನ್ನು ಸಹ ಬಳಸುತ್ತದೆ.
ಇದು REST ಆಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು ಈ API ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಯಾವುದೇ ಭಾಷೆ ಅಥವಾ ಸಾಧನವನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಕಸ್ಟಮ್ ಲೈಬ್ರರಿಗಳಿಂದ ನಿಮ್ಮ ಜೀವನವನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸಲಾಗುತ್ತದೆ. ನನ್ನ ತಂಡವು ಅಂತಹ 2 ಲೈಬ್ರರಿಗಳನ್ನು ಬರೆದಿದೆ: ಒಂದು Java/OSGi ಮತ್ತು ಇನ್ನೊಂದು Go ಗಾಗಿ. ಎರಡನೆಯದನ್ನು ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ, ಆದರೆ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ನಿಮ್ಮ ಇತ್ಯರ್ಥಕ್ಕೆ ನೀವು ಈ ಉಪಯುಕ್ತ ವಸ್ತುಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ. ಅವು ಭಾಗಶಃ ಪರವಾನಗಿ ಪಡೆದ ಮುಕ್ತ-ಮೂಲ ಯೋಜನೆಯಾಗಿದೆ. ವಿವಿಧ ಭಾಷೆಗಳಿಗೆ ಇಂತಹ ಅನೇಕ ಗ್ರಂಥಾಲಯಗಳಿವೆ, ಆದ್ದರಿಂದ ನಿಮಗೆ ಸೂಕ್ತವಾದವುಗಳನ್ನು ನೀವು ಆಯ್ಕೆ ಮಾಡಬಹುದು.
ಆದ್ದರಿಂದ, ನಿಮ್ಮ ನಿಯೋಜನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ಪ್ರಕ್ರಿಯೆಯು ಯಾವುದೇ ಅಲಭ್ಯತೆಗೆ ಒಳಪಡುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಉದಾಹರಣೆಗೆ, ಜನರು ಹೆಚ್ಚಿನ ಪ್ರಮಾಣದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಬಳಸುತ್ತಿರುವಾಗ ನಮ್ಮ ತಂಡವು ದಿನದ ಮಧ್ಯದಲ್ಲಿ ಉತ್ಪಾದನಾ ನಿಯೋಜನೆಗಳನ್ನು ನಡೆಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಈ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ವಿಳಂಬವನ್ನು ತಪ್ಪಿಸುವುದು ಮುಖ್ಯವಾಗಿದೆ. ಅಲಭ್ಯತೆಯನ್ನು ತಪ್ಪಿಸಲು, 2 ವಿಧಾನಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ: ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ ಅಥವಾ ರೋಲಿಂಗ್ ನವೀಕರಣ. ನಂತರದ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಅಪ್ಲಿಕೇಶನ್ ಚಾಲನೆಯಲ್ಲಿರುವ 5 ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಅವುಗಳನ್ನು ಒಂದರ ನಂತರ ಒಂದರಂತೆ ಅನುಕ್ರಮವಾಗಿ ನವೀಕರಿಸಲಾಗುತ್ತದೆ. ಈ ವಿಧಾನವು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ನೀವು ಏಕಕಾಲದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ವಿವಿಧ ಆವೃತ್ತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅದು ಸೂಕ್ತವಲ್ಲ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಬ್ಯಾಕೆಂಡ್ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಚಲಾಯಿಸುತ್ತಿರುವಾಗ ನೀವು ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ, ಪ್ರೋಗ್ರಾಮಿಂಗ್ ದೃಷ್ಟಿಕೋನದಿಂದ, ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಕೆಲಸ ಮಾಡುವುದು ತುಂಬಾ ಕಷ್ಟ.
ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಿಯೋಜನೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆಯನ್ನು ಬಳಸಲು ನಾವು ಆದ್ಯತೆ ನೀಡಲು ಇದು ಒಂದು ಕಾರಣವಾಗಿದೆ. ಈ ವಿಧಾನದೊಂದಿಗೆ, ಒಂದು ಸಮಯದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನ ಒಂದು ಆವೃತ್ತಿ ಮಾತ್ರ ಸಕ್ರಿಯವಾಗಿದೆ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು.
ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ ಕಾರ್ಯವಿಧಾನವು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ನಾವು ha-ಪ್ರಾಕ್ಸಿ ಮೂಲಕ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತೇವೆ, ಅದು ಅದೇ ಆವೃತ್ತಿಯ ಅಪ್ಲಿಕೇಶನ್‌ನ ಚಾಲನೆಯಲ್ಲಿರುವ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ಅದನ್ನು ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ.
ಹೊಸ ನಿಯೋಜನೆಯನ್ನು ಮಾಡಿದಾಗ, ನಾವು ಡಿಪ್ಲೋಯರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಅದು ಹೊಸ ಘಟಕಗಳನ್ನು ನೀಡಲಾಗುತ್ತದೆ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸುವುದು ಎಂದರೆ ಹೊಸ ಪ್ರತಿಕೃತಿಗಳ ಹೊಸ ಸೆಟ್ ಅನ್ನು "ಎತ್ತಲಾಗಿದೆ", ಅದರ ನಂತರ ಹೊಸ ಆವೃತ್ತಿಯ ಈ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪ್ರತ್ಯೇಕ, ಹೊಸ ಪಾಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ. ಆದಾಗ್ಯೂ, ha-proxy ಗೆ ಅವರ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ ಮತ್ತು ಅವರಿಗೆ ಇನ್ನೂ ಯಾವುದೇ ಕೆಲಸದ ಹೊರೆಯನ್ನು ರವಾನಿಸುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ಮೊದಲನೆಯದಾಗಿ, ಪ್ರತಿಕೃತಿಗಳು ಲೋಡ್ ಅನ್ನು ಪೂರೈಸಲು ಸಿದ್ಧವಾಗಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಆರೋಗ್ಯ ತಪಾಸಣೆಯ ಹೊಸ ಆವೃತ್ತಿಗಳ ಕಾರ್ಯಕ್ಷಮತೆಯ ಪರಿಶೀಲನೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು ಅವಶ್ಯಕ.
ಎಲ್ಲಾ ನಿಯೋಜನೆ ಘಟಕಗಳು ಕೆಲವು ರೀತಿಯ ಆರೋಗ್ಯ ತಪಾಸಣೆಯನ್ನು ಬೆಂಬಲಿಸಬೇಕು. ನೀವು ಸ್ಥಿತಿ 200 ನೊಂದಿಗೆ ಕೋಡ್ ಅನ್ನು ಸ್ವೀಕರಿಸಿದಾಗ ಇದು ತುಂಬಾ ಸರಳವಾದ HTTP ಕರೆ ಚೆಕ್ ಆಗಿರಬಹುದು ಅಥವಾ ಡೇಟಾಬೇಸ್ ಮತ್ತು ಇತರ ಸೇವೆಗಳೊಂದಿಗೆ ಪ್ರತಿಕೃತಿಗಳ ಸಂಪರ್ಕವನ್ನು ನೀವು ಪರಿಶೀಲಿಸುವ ಹೆಚ್ಚು ಆಳವಾದ ಪರಿಶೀಲನೆ, ಡೈನಾಮಿಕ್ ಪರಿಸರದ ಸಂಪರ್ಕಗಳ ಸ್ಥಿರತೆ , ಮತ್ತು ಎಲ್ಲವೂ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ ಮತ್ತು ಸರಿಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆಯೇ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಸಾಕಷ್ಟು ಸಂಕೀರ್ಣವಾಗಬಹುದು.
ಎಲ್ಲಾ ನವೀಕರಿಸಿದ ಪ್ರತಿಕೃತಿಗಳು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿವೆ ಎಂದು ಸಿಸ್ಟಮ್ ಪರಿಶೀಲಿಸಿದ ನಂತರ, ಡಿಪ್ಲೋಯರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ಸರಿಯಾದ confd ಅನ್ನು ರವಾನಿಸುತ್ತದೆ, ಅದು ha-proxy ಅನ್ನು ಮರುಸಂರಚಿಸುತ್ತದೆ.
ಇದರ ನಂತರವೇ ಹೊಸ ಆವೃತ್ತಿಯ ಪ್ರತಿಕೃತಿಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗೆ ಸಂಚಾರವನ್ನು ನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ಹಳೆಯ ಪಾಡ್ ಕಣ್ಮರೆಯಾಗುತ್ತದೆ.
ಈ ಕಾರ್ಯವಿಧಾನವು ಕುಬರ್ನೆಟ್ಸ್ನ ಲಕ್ಷಣವಲ್ಲ. ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆಯ ಪರಿಕಲ್ಪನೆಯು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಇದೆ ಮತ್ತು ಇದು ಯಾವಾಗಲೂ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬಳಸುತ್ತದೆ. ಮೊದಲಿಗೆ, ನೀವು ಎಲ್ಲಾ ದಟ್ಟಣೆಯನ್ನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಗೆ ನಿರ್ದೇಶಿಸುತ್ತೀರಿ ಮತ್ತು ನವೀಕರಣದ ನಂತರ, ನೀವು ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಆವೃತ್ತಿಗೆ ವರ್ಗಾಯಿಸುತ್ತೀರಿ. ಈ ತತ್ವವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಮಾತ್ರ ಬಳಸಲಾಗುವುದಿಲ್ಲ.
ಈಗ ನಾನು ನಿಮಗೆ ಹೊಸ ನಿಯೋಜನೆ ಘಟಕವನ್ನು ಪರಿಚಯಿಸುತ್ತೇನೆ - ನಿಯೋಜಕ, ಇದು ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ, ಪ್ರಾಕ್ಸಿಗಳನ್ನು ಮರುಸಂರಚಿಸುತ್ತದೆ, ಇತ್ಯಾದಿ. ಇದು ಹೊರಗಿನ ಪ್ರಪಂಚಕ್ಕೆ ಅನ್ವಯಿಸದ ಪರಿಕಲ್ಪನೆಯಾಗಿದೆ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿದೆ. ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಕರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಿಮ್ಮ ಸ್ವಂತ ಡಿಪ್ಲೋಯರ್ ಪರಿಕಲ್ಪನೆಯನ್ನು ನೀವು ಹೇಗೆ ರಚಿಸಬಹುದು ಎಂಬುದನ್ನು ನಾನು ನಿಮಗೆ ತೋರಿಸುತ್ತೇನೆ.
ಆದ್ದರಿಂದ, ನಿಯೋಜಕರು ಮಾಡುವ ಮೊದಲ ಕೆಲಸವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಬಳಸಿಕೊಂಡು RC ಪ್ರತಿಕೃತಿ ನಿಯಂತ್ರಕವನ್ನು ರಚಿಸುವುದು. ಈ API ಮತ್ತಷ್ಟು ನಿಯೋಜನೆಗಾಗಿ ಪಾಡ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ರಚಿಸುತ್ತದೆ, ಅಂದರೆ, ಇದು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗಾಗಿ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ. ಪ್ರತಿಕೃತಿಗಳು ಪ್ರಾರಂಭವಾಗಿವೆ ಎಂದು ಆರ್‌ಸಿಗೆ ಮನವರಿಕೆಯಾದ ತಕ್ಷಣ, ಅದು ಅವುಗಳ ಕಾರ್ಯನಿರ್ವಹಣೆಯ ಕುರಿತು ಆರೋಗ್ಯ ತಪಾಸಣೆ ನಡೆಸುತ್ತದೆ. ಇದನ್ನು ಮಾಡಲು, ನಿಯೋಜಕರು GET/health ಆಜ್ಞೆಯನ್ನು ಬಳಸುತ್ತಾರೆ. ಇದು ಸೂಕ್ತವಾದ ಸ್ಕ್ಯಾನ್ ಘಟಕಗಳನ್ನು ರನ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಬೆಂಬಲಿಸುವ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ.
ಎಲ್ಲಾ ಪಾಡ್‌ಗಳು ತಮ್ಮ ಆರೋಗ್ಯವನ್ನು ವರದಿ ಮಾಡಿದ ನಂತರ, ನಿಯೋಜಕರು ಹೊಸ ಕಾನ್ಫಿಗರೇಶನ್ ಎಲಿಮೆಂಟ್ ಅನ್ನು ರಚಿಸುತ್ತಾರೆ - etcd ಡಿಸ್ಟ್ರಿಬ್ಯೂಟ್ ಸ್ಟೋರೇಜ್, ಇದನ್ನು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸಂಗ್ರಹಿಸುವುದು ಸೇರಿದಂತೆ ಕುಬರ್ನೆಟ್‌ಗಳು ಆಂತರಿಕವಾಗಿ ಬಳಸುತ್ತಾರೆ. ನಾವು ಇತ್ಯಾದಿಗಳಿಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುತ್ತೇವೆ ಮತ್ತು ಹೊಸ ಡೇಟಾಕ್ಕಾಗಿ confd ಮಾನಿಟರ್ ಇತ್ಯಾದಿ ಎಂಬ ಸಣ್ಣ ಉಪಕರಣವನ್ನು ಬರೆಯುತ್ತೇವೆ.
ಇದು ಆರಂಭಿಕ ಕಾನ್ಫಿಗರೇಶನ್‌ಗೆ ಯಾವುದೇ ಬದಲಾವಣೆಗಳನ್ನು ಪತ್ತೆಮಾಡಿದರೆ, ಅದು ಹೊಸ ಸೆಟ್ಟಿಂಗ್‌ಗಳ ಫೈಲ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ha-ಪ್ರಾಕ್ಸಿಗೆ ವರ್ಗಾಯಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ha-proxy ಯಾವುದೇ ಸಂಪರ್ಕಗಳನ್ನು ಕಳೆದುಕೊಳ್ಳದೆ ರೀಬೂಟ್ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಕೆಲಸ ಮಾಡಲು ಸಕ್ರಿಯಗೊಳಿಸುವ ಹೊಸ ಸೇವೆಗಳಿಗೆ ಲೋಡ್ ಅನ್ನು ತಿಳಿಸುತ್ತದೆ.
ನೀವು ನೋಡುವಂತೆ, ಘಟಕಗಳ ಸಮೃದ್ಧಿಯ ಹೊರತಾಗಿಯೂ, ಇಲ್ಲಿ ಸಂಕೀರ್ಣವಾದ ಏನೂ ಇಲ್ಲ. ನೀವು API ಮತ್ತು ಇತ್ಯಾದಿಗಳಿಗೆ ಹೆಚ್ಚು ಗಮನ ಹರಿಸಬೇಕಾಗಿದೆ. ನಾವೇ ಬಳಸುವ ಓಪನ್ ಸೋರ್ಸ್ ಡಿಪ್ಲೋಯರ್ ಬಗ್ಗೆ ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ - ಅಮ್ದಾಟು ಕುಬರ್ನೆಟ್ಸ್ ಡಿಪ್ಲೋಯರ್.
ಇದು ಕುಬರ್ನೆಟ್ಸ್ ನಿಯೋಜನೆಗಳನ್ನು ಸಂಘಟಿಸಲು ಒಂದು ಸಾಧನವಾಗಿದೆ ಮತ್ತು ಈ ಕೆಳಗಿನ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಹೊಂದಿದೆ:
- ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ;
- ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು;
- ನಿಯೋಜನೆ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ನಿರ್ವಹಣೆ;
- ನಿಜವಾದ ನಿಯೋಜನೆಯನ್ನು ನಿರ್ವಹಿಸುವುದು;
- ನಿಯೋಜನೆಯ ಸಮಯದಲ್ಲಿ ಆರೋಗ್ಯ ತಪಾಸಣೆಯ ಕಾರ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವುದು;
- ಪರಿಸರದ ಅಸ್ಥಿರಗಳನ್ನು ಬೀಜಕೋಶಗಳಾಗಿ ಅಳವಡಿಸುವುದು.
ಈ ನಿಯೋಜಕವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ API ಮೇಲೆ ನಿರ್ಮಿಸಲಾಗಿದೆ ಮತ್ತು ಹ್ಯಾಂಡಲ್‌ಗಳು ಮತ್ತು ನಿಯೋಜನೆಗಳನ್ನು ನಿರ್ವಹಿಸಲು REST API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ, ಹಾಗೆಯೇ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ಲಾಗ್‌ಗಳನ್ನು ಸ್ಟ್ರೀಮಿಂಗ್ ಮಾಡಲು ವೆಬ್‌ಸಾಕೆಟ್ API ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಇದು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಡೇಟಾವನ್ನು ಇತ್ಯಾದಿಗಳಿಗೆ ಇರಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನೀವು ಪೆಟ್ಟಿಗೆಯ ಹೊರಗಿನ ಬೆಂಬಲದೊಂದಿಗೆ ha-ಪ್ರಾಕ್ಸಿಯನ್ನು ಬಳಸಬೇಕಾಗಿಲ್ಲ, ಆದರೆ ನಿಮ್ಮ ಸ್ವಂತ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಫೈಲ್ ಅನ್ನು ಸುಲಭವಾಗಿ ಬಳಸಿ. Amdatu Deployer ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಂತೆಯೇ Go ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ ಮತ್ತು Apache ನಿಂದ ಪರವಾನಗಿ ಪಡೆದಿದೆ.
ನಾನು ನಿಯೋಜನೆಯ ಈ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು ಪ್ರಾರಂಭಿಸುವ ಮೊದಲು, ನಾನು ಈ ಕೆಳಗಿನ ನಿಯೋಜನೆ ವಿವರಣೆಯನ್ನು ಬಳಸಿದ್ದೇನೆ, ಅದು ನನಗೆ ಅಗತ್ಯವಿರುವ ನಿಯತಾಂಕಗಳನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತದೆ.
"useHealthCheck" ಫ್ಲ್ಯಾಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸುವುದು ಈ ಕೋಡ್‌ನ ಪ್ರಮುಖ ನಿಯತಾಂಕಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ. ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯಲ್ಲಿ ವಿವೇಕದ ಪರಿಶೀಲನೆಯನ್ನು ನಡೆಸಬೇಕು ಎಂದು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸಬೇಕಾಗಿದೆ. ನಿಯೋಜನೆಯು ಪರಿಶೀಲಿಸಬೇಕಾದ ಅಗತ್ಯವಿಲ್ಲದ ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಕಂಟೇನರ್‌ಗಳನ್ನು ಬಳಸಿದಾಗ ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬಹುದು. ಈ ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮತ್ತು ಹೆ-ಪ್ರಾಕ್ಸಿಗೆ ಅಗತ್ಯವಿರುವ ಮುಂಭಾಗದ URL ಅನ್ನು ಸಹ ಸೂಚಿಸುತ್ತದೆ. ಕೊನೆಯಲ್ಲಿ ಪಾಡ್ ಸ್ಪೆಸಿಫಿಕೇಶನ್ ಫ್ಲ್ಯಾಗ್ "ಪಾಡ್ಸ್ಪೆಕ್" ಇದೆ, ಇದು ಪೋರ್ಟ್ ಕಾನ್ಫಿಗರೇಶನ್, ಇಮೇಜ್ ಇತ್ಯಾದಿಗಳ ಮಾಹಿತಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಕರೆಯುತ್ತದೆ. ಇದು ಸಾಕಷ್ಟು ಸರಳವಾದ JSON ಡಿಸ್ಕ್ರಿಪ್ಟರ್ ಆಗಿದೆ.
ಓಪನ್ ಸೋರ್ಸ್ Amdatu ಯೋಜನೆಯ ಭಾಗವಾಗಿರುವ ಮತ್ತೊಂದು ಸಾಧನವೆಂದರೆ Deploymentctl. ಇದು ನಿಯೋಜನೆಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು UI ಅನ್ನು ಹೊಂದಿದೆ, ನಿಯೋಜನೆ ಇತಿಹಾಸವನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಮೂರನೇ ವ್ಯಕ್ತಿಯ ಬಳಕೆದಾರರು ಮತ್ತು ಡೆವಲಪರ್‌ಗಳಿಂದ ಕಾಲ್‌ಬ್ಯಾಕ್‌ಗಳಿಗಾಗಿ ವೆಬ್‌ಹೂಕ್‌ಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. Amdatu ಡಿಪ್ಲೋಯರ್ ಸ್ವತಃ REST API ಆಗಿರುವುದರಿಂದ ನೀವು UI ಅನ್ನು ಬಳಸದಿರಬಹುದು, ಆದರೆ ಈ ಇಂಟರ್ಫೇಸ್ ಯಾವುದೇ API ಅನ್ನು ಒಳಗೊಳ್ಳದೆಯೇ ನಿಮಗೆ ನಿಯೋಜನೆಯನ್ನು ಹೆಚ್ಚು ಸುಲಭಗೊಳಿಸುತ್ತದೆ. Deploymentctl ಅನ್ನು OSGi/Vertx ನಲ್ಲಿ ಕೋನೀಯ 2 ಬಳಸಿ ಬರೆಯಲಾಗಿದೆ.
ಮೊದಲೇ ರೆಕಾರ್ಡ್ ಮಾಡಲಾದ ರೆಕಾರ್ಡಿಂಗ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾನು ಈಗ ಮೇಲಿನದನ್ನು ಪರದೆಯ ಮೇಲೆ ಪ್ರದರ್ಶಿಸುತ್ತೇನೆ ಆದ್ದರಿಂದ ನೀವು ಕಾಯಬೇಕಾಗಿಲ್ಲ. ನಾವು ಸರಳವಾದ ಗೋ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೇವೆ. ನೀವು ಮೊದಲು Go ಅನ್ನು ಪ್ರಯತ್ನಿಸದಿದ್ದರೆ ಚಿಂತಿಸಬೇಡಿ, ಇದು ತುಂಬಾ ಸರಳವಾದ ಅಪ್ಲಿಕೇಶನ್ ಆಗಿದೆ ಆದ್ದರಿಂದ ನೀವು ಅದನ್ನು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.
ಇಲ್ಲಿ ನಾವು /ಆರೋಗ್ಯಕ್ಕೆ ಮಾತ್ರ ಪ್ರತಿಕ್ರಿಯಿಸುವ HTTP ಸರ್ವರ್ ಅನ್ನು ರಚಿಸುತ್ತಿದ್ದೇವೆ, ಆದ್ದರಿಂದ ಈ ಅಪ್ಲಿಕೇಶನ್ ಆರೋಗ್ಯ ತಪಾಸಣೆಯನ್ನು ಮಾತ್ರ ಪರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಬೇರೇನೂ ಇಲ್ಲ. ಚೆಕ್ ಪಾಸ್ ಆಗಿದ್ದರೆ, ಕೆಳಗೆ ತೋರಿಸಿರುವ JSON ರಚನೆಯನ್ನು ಬಳಸಲಾಗುತ್ತದೆ. ಇದು ನಿಯೋಜಕರಿಂದ ನಿಯೋಜಿಸಲ್ಪಡುವ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆವೃತ್ತಿ, ಫೈಲ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ನೀವು ನೋಡುವ ಸಂದೇಶ ಮತ್ತು ಬೂಲಿಯನ್ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಒಳಗೊಂಡಿದೆ - ನಮ್ಮ ಅಪ್ಲಿಕೇಶನ್ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರಲಿ ಅಥವಾ ಇಲ್ಲದಿರಲಿ.
ನಾನು ಕೊನೆಯ ಸಾಲಿನೊಂದಿಗೆ ಸ್ವಲ್ಪ ಮೋಸ ಮಾಡಿದ್ದೇನೆ, ಏಕೆಂದರೆ ನಾನು ಫೈಲ್‌ನ ಮೇಲ್ಭಾಗದಲ್ಲಿ ಸ್ಥಿರ ಬೂಲಿಯನ್ ಮೌಲ್ಯವನ್ನು ಇರಿಸಿದ್ದೇನೆ, ಭವಿಷ್ಯದಲ್ಲಿ ಇದು "ಅನಾರೋಗ್ಯಕರ" ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಸಹ ನಿಯೋಜಿಸಲು ನನಗೆ ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಾವು ಇದನ್ನು ನಂತರ ವ್ಯವಹರಿಸುತ್ತೇವೆ.
ಆದ್ದರಿಂದ ಪ್ರಾರಂಭಿಸೋಣ. ಮೊದಲಿಗೆ, ~ kubectl get pods ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಚಾಲನೆಯಲ್ಲಿರುವ ಯಾವುದೇ ಪಾಡ್‌ಗಳ ಉಪಸ್ಥಿತಿಯನ್ನು ನಾವು ಪರಿಶೀಲಿಸುತ್ತೇವೆ ಮತ್ತು ಮುಂಭಾಗದ URL ನಿಂದ ಪ್ರತಿಕ್ರಿಯೆಯ ಅನುಪಸ್ಥಿತಿಯ ಆಧಾರದ ಮೇಲೆ, ಪ್ರಸ್ತುತ ಯಾವುದೇ ನಿಯೋಜನೆಗಳನ್ನು ಮಾಡಲಾಗುತ್ತಿಲ್ಲ ಎಂದು ನಾವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುತ್ತೇವೆ.
ಪರದೆಯ ಮೇಲೆ ನೀವು ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದ Deploymentctl ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ನೋಡುತ್ತೀರಿ, ಇದರಲ್ಲಿ ನಿಯೋಜನೆ ನಿಯತಾಂಕಗಳನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ: ನೇಮ್‌ಸ್ಪೇಸ್, ಅಪ್ಲಿಕೇಶನ್ ಹೆಸರು, ನಿಯೋಜನೆ ಆವೃತ್ತಿ, ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ, ಮುಂಭಾಗದ URL, ಕಂಟೇನರ್ ಹೆಸರು, ಚಿತ್ರ, ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು, ಆರೋಗ್ಯ ತಪಾಸಣೆಗಾಗಿ ಪೋರ್ಟ್ ಸಂಖ್ಯೆ, ಇತ್ಯಾದಿ. ಸಂಪನ್ಮೂಲ ಮಿತಿಗಳು ಬಹಳ ಮುಖ್ಯ, ಏಕೆಂದರೆ ಅವುಗಳು ಗರಿಷ್ಠ ಸಂಭವನೀಯ ಪ್ರಮಾಣದ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಬಳಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಇಲ್ಲಿ ನೀವು ನಿಯೋಜನೆ ಲಾಗ್ ಅನ್ನು ಸಹ ವೀಕ್ಷಿಸಬಹುದು.
ನೀವು ಈಗ ~ kubectl ಪಾಡ್‌ಗಳನ್ನು ಪಡೆಯಿರಿ ಎಂಬ ಆಜ್ಞೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿದರೆ, ಸಿಸ್ಟಮ್ 20 ಸೆಕೆಂಡುಗಳ ಕಾಲ "ಫ್ರೀಜ್" ಆಗುವುದನ್ನು ನೀವು ನೋಡಬಹುದು, ಈ ಸಮಯದಲ್ಲಿ ha-proxy ಅನ್ನು ಮರುಸಂರಚಿಸಲಾಗುತ್ತದೆ. ಇದರ ನಂತರ, ಪಾಡ್ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಮತ್ತು ನಮ್ಮ ಪ್ರತಿಕೃತಿಯನ್ನು ನಿಯೋಜನೆ ಲಾಗ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು.
ನಾನು ವೀಡಿಯೊದಿಂದ 20 ಸೆಕೆಂಡ್ ಕಾಯುವಿಕೆಯನ್ನು ಕಡಿತಗೊಳಿಸಿದ್ದೇನೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ಈಗ ಪರದೆಯ ಮೇಲೆ ನೋಡಬಹುದು. ಇದೆಲ್ಲವನ್ನೂ ಕೇವಲ UI ಬಳಸಿ ಮಾಡಲಾಗಿದೆ.
ಈಗ ಎರಡನೇ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಯತ್ನಿಸೋಣ. ಇದನ್ನು ಮಾಡಲು, ನಾನು ಅಪ್ಲಿಕೇಶನ್‌ನ ಸಂದೇಶವನ್ನು "ಹಲೋ, ಕುಬರ್ನೆಟ್ಸ್!" ನಿಂದ ಬದಲಾಯಿಸುತ್ತೇನೆ! "ಹಲೋ, ಡಿಪ್ಲೋಯರ್!" ನಲ್ಲಿ, ಸಿಸ್ಟಮ್ ಈ ಚಿತ್ರವನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ಡಾಕರ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ಇರಿಸುತ್ತದೆ, ಅದರ ನಂತರ ನಾವು ಡಿಪ್ಲೋಯ್ಮೆಂಟ್ಕ್ಟ್ಲ್ ವಿಂಡೋದಲ್ಲಿ ಮತ್ತೆ "ನಿಯೋಜನೆ" ಬಟನ್ ಅನ್ನು ಕ್ಲಿಕ್ ಮಾಡುತ್ತೇವೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೊದಲ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸುವಾಗ ಸಂಭವಿಸಿದ ರೀತಿಯಲ್ಲಿಯೇ ನಿಯೋಜನೆ ಲಾಗ್ ಅನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಪ್ರಾರಂಭಿಸಲಾಗುತ್ತದೆ.
~ kubectl get pods ಆಜ್ಞೆಯು ಪ್ರಸ್ತುತ ಅಪ್ಲಿಕೇಶನ್‌ನ 2 ಆವೃತ್ತಿಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಮುಂಭಾಗವು ನಾವು ಇನ್ನೂ ಆವೃತ್ತಿ 1 ಅನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದೇವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ.
ಹೊಸ ಆವೃತ್ತಿಗೆ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮರುನಿರ್ದೇಶಿಸುವ ಮೊದಲು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಪೂರ್ಣಗೊಳ್ಳಲು ಕಾಯುತ್ತದೆ. 20 ಸೆಕೆಂಡುಗಳ ನಂತರ, ನಾವು ಕರ್ಲ್‌ಗೆ ಬದಲಾಯಿಸುತ್ತೇವೆ ಮತ್ತು ನಾವು ಈಗ ಅಪ್ಲಿಕೇಶನ್‌ನ ಆವೃತ್ತಿ 2 ಅನ್ನು ನಿಯೋಜಿಸಿದ್ದೇವೆ ಮತ್ತು ಮೊದಲನೆಯದನ್ನು ಅಳಿಸಲಾಗಿದೆ ಎಂದು ನೋಡುತ್ತೇವೆ.
ಇದು "ಆರೋಗ್ಯಕರ" ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಯೋಜನೆಯಾಗಿದೆ. ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಗಾಗಿ ನಾನು ಆರೋಗ್ಯಕರ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸರಿಯಿಂದ ತಪ್ಪಾಗಿ ಬದಲಾಯಿಸಿದರೆ ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡೋಣ, ಅಂದರೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆಯಲ್ಲಿ ವಿಫಲವಾದ ಅನಾರೋಗ್ಯಕರ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ನಾನು ಪ್ರಯತ್ನಿಸುತ್ತೇನೆ. ಅಭಿವೃದ್ಧಿ ಹಂತದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ನಲ್ಲಿ ಕೆಲವು ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷಗಳನ್ನು ಮಾಡಿದರೆ ಮತ್ತು ಅದನ್ನು ಈ ರೂಪದಲ್ಲಿ ಉತ್ಪಾದನೆಗೆ ಕಳುಹಿಸಿದರೆ ಇದು ಸಂಭವಿಸಬಹುದು.
ನೀವು ನೋಡುವಂತೆ, ನಿಯೋಜನೆಯು ಮೇಲಿನ ಎಲ್ಲಾ ಹಂತಗಳ ಮೂಲಕ ಹೋಗುತ್ತದೆ ಮತ್ತು ~kubectl get pods ಎರಡೂ ಪಾಡ್‌ಗಳು ಚಾಲನೆಯಲ್ಲಿವೆ ಎಂದು ತೋರಿಸುತ್ತದೆ. ಆದರೆ ಹಿಂದಿನ ನಿಯೋಜನೆಗಿಂತ ಭಿನ್ನವಾಗಿ, ಲಾಗ್ ಸಮಯ ಮೀರುವ ಸ್ಥಿತಿಯನ್ನು ತೋರಿಸುತ್ತದೆ. ಅಂದರೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆ ವಿಫಲವಾದ ಕಾರಣ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ನಿಯೋಜಿಸಲಾಗುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ನ ಹಳೆಯ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು ಸಿಸ್ಟಮ್ ಹಿಂತಿರುಗಿದೆ ಮತ್ತು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಸರಳವಾಗಿ ಅಸ್ಥಾಪಿಸಲಾಗಿದೆ ಎಂದು ನೀವು ನೋಡುತ್ತೀರಿ.
ಇದರ ಬಗ್ಗೆ ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ ನೀವು ಅಪ್ಲಿಕೇಶನ್‌ಗೆ ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಏಕಕಾಲಿಕ ವಿನಂತಿಗಳನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ, ನಿಯೋಜನೆ ಕಾರ್ಯವಿಧಾನವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವಾಗ ಅವರು ಅಲಭ್ಯತೆಯನ್ನು ಗಮನಿಸುವುದಿಲ್ಲ. ನೀವು Gatling ಫ್ರೇಮ್‌ವರ್ಕ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಈ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿದರೆ, ಅದು ಸಾಧ್ಯವಾದಷ್ಟು ಹೆಚ್ಚಿನ ವಿನಂತಿಗಳನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ನಂತರ ಈ ಯಾವುದೇ ವಿನಂತಿಗಳನ್ನು ಕೈಬಿಡಲಾಗುವುದಿಲ್ಲ. ಇದರರ್ಥ ನಮ್ಮ ಬಳಕೆದಾರರು ನೈಜ ಸಮಯದಲ್ಲಿ ಆವೃತ್ತಿ ನವೀಕರಣಗಳನ್ನು ಸಹ ಗಮನಿಸುವುದಿಲ್ಲ. ಅದು ವಿಫಲವಾದರೆ, ಹಳೆಯ ಆವೃತ್ತಿಯಲ್ಲಿ ಕೆಲಸ ಮುಂದುವರಿಯುತ್ತದೆ; ಅದು ಯಶಸ್ವಿಯಾದರೆ, ಬಳಕೆದಾರರು ಹೊಸ ಆವೃತ್ತಿಗೆ ಬದಲಾಯಿಸುತ್ತಾರೆ.
ವಿಫಲಗೊಳ್ಳುವ ಒಂದೇ ಒಂದು ವಿಷಯವಿದೆ - ಆರೋಗ್ಯ ತಪಾಸಣೆ ಯಶಸ್ವಿಯಾದರೆ, ಆದರೆ ಕೆಲಸದ ಹೊರೆ ಅನ್ವಯಿಸಿದ ತಕ್ಷಣ ಅಪ್ಲಿಕೇಶನ್ ವಿಫಲಗೊಳ್ಳುತ್ತದೆ, ಅಂದರೆ, ನಿಯೋಜನೆ ಪೂರ್ಣಗೊಂಡ ನಂತರವೇ ಕುಸಿತ ಸಂಭವಿಸುತ್ತದೆ. ಈ ಸಂದರ್ಭದಲ್ಲಿ, ನೀವು ಹಸ್ತಚಾಲಿತವಾಗಿ ಹಳೆಯ ಆವೃತ್ತಿಗೆ ಹಿಂತಿರುಗಬೇಕಾಗುತ್ತದೆ. ಆದ್ದರಿಂದ, ಅದಕ್ಕಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಓಪನ್ ಸೋರ್ಸ್ ಪರಿಕರಗಳೊಂದಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಹೇಗೆ ಬಳಸುವುದು ಎಂದು ನಾವು ನೋಡಿದ್ದೇವೆ. ನಿಮ್ಮ ಬಿಲ್ಡ್/ಡಿಪ್ಲೋಯ್ ಪೈಪ್‌ಲೈನ್‌ಗಳಲ್ಲಿ ನೀವು ಈ ಪರಿಕರಗಳನ್ನು ನಿರ್ಮಿಸಿದರೆ ನಿಯೋಜನೆ ಪ್ರಕ್ರಿಯೆಯು ಹೆಚ್ಚು ಸುಲಭವಾಗುತ್ತದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ನಿಯೋಜನೆಯನ್ನು ಪ್ರಾರಂಭಿಸಲು, ನೀವು ಬಳಕೆದಾರ ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಬಳಸಬಹುದು ಅಥವಾ ಬಳಸಿಕೊಂಡು ಈ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಮಾಸ್ಟರ್ಗೆ ಬದ್ಧರಾಗಿರಿ.
ನಮ್ಮ ಬಿಲ್ಡ್ ಸರ್ವರ್ ಡಾಕರ್ ಚಿತ್ರವನ್ನು ರಚಿಸುತ್ತದೆ, ಅದನ್ನು ಡಾಕರ್ ಹಬ್ ಅಥವಾ ನೀವು ಬಳಸುವ ಯಾವುದೇ ರಿಜಿಸ್ಟ್ರಿಗೆ ತಳ್ಳುತ್ತದೆ. ಡಾಕರ್ ಹಬ್ ವೆಬ್‌ಹೂಕ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಾವು ಮೇಲೆ ತೋರಿಸಿದ ರೀತಿಯಲ್ಲಿ ಡಿಪ್ಲೋಯರ್ ಮೂಲಕ ರಿಮೋಟ್ ನಿಯೋಜನೆಯನ್ನು ಪ್ರಚೋದಿಸಬಹುದು. ಈ ರೀತಿಯಲ್ಲಿ ನೀವು ಸಂಭಾವ್ಯ ಉತ್ಪಾದನೆಗೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ನಿಯೋಜನೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬಹುದು.
ಮುಂದಿನ ವಿಷಯಕ್ಕೆ ಹೋಗೋಣ - ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು. kubectl ಆಜ್ಞೆಯು ಸ್ಕೇಲಿಂಗ್ ಆಜ್ಞೆಯಾಗಿದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ. ಹೆಚ್ಚಿನ ಸಹಾಯದಿಂದ, ನಾವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸುಲಭವಾಗಿ ಹೆಚ್ಚಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಪ್ರಾಯೋಗಿಕವಾಗಿ, ನಾವು ಸಾಮಾನ್ಯವಾಗಿ ಪಾಡ್‌ಗಳಿಗಿಂತ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಲು ಬಯಸುತ್ತೇವೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಕೆಲಸದ ಸಮಯದಲ್ಲಿ ನೀವು ಹೆಚ್ಚಿಸಬೇಕಾಗಬಹುದು ಮತ್ತು ರಾತ್ರಿಯಲ್ಲಿ, ಅಮೆಜಾನ್ ಸೇವೆಗಳ ವೆಚ್ಚವನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ನೀವು ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್ ನಿದರ್ಶನಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಬೇಕಾಗಬಹುದು. ಇದರರ್ಥ ಕೇವಲ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು ಸಾಕು ಎಂದು ಅರ್ಥವಲ್ಲ, ಏಕೆಂದರೆ ನೋಡ್ಗಳಲ್ಲಿ ಒಂದು ನಿಷ್ಕ್ರಿಯವಾಗಿದ್ದರೂ ಸಹ, ನೀವು ಅದನ್ನು ಅಮೆಜಾನ್‌ಗೆ ಪಾವತಿಸಬೇಕಾಗುತ್ತದೆ. ಅಂದರೆ, ಬೀಜಕೋಶಗಳನ್ನು ಸ್ಕೇಲಿಂಗ್ ಮಾಡುವ ಜೊತೆಗೆ, ನೀವು ಬಳಸಿದ ಯಂತ್ರಗಳ ಸಂಖ್ಯೆಯನ್ನು ಅಳೆಯುವ ಅಗತ್ಯವಿದೆ.
ಇದು ಸವಾಲಾಗಿರಬಹುದು ಏಕೆಂದರೆ ನಾವು ಅಮೆಜಾನ್ ಅಥವಾ ಇನ್ನೊಂದು ಕ್ಲೌಡ್ ಸೇವೆಯನ್ನು ಬಳಸುತ್ತಿರಲಿ, ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಬಳಸಲಾಗುವ ಯಂತ್ರಗಳ ಸಂಖ್ಯೆಯ ಬಗ್ಗೆ ಏನೂ ತಿಳಿದಿಲ್ಲ. ಇದು ನೋಡ್ ಮಟ್ಟದಲ್ಲಿ ಸಿಸ್ಟಮ್ ಅನ್ನು ಅಳೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸಾಧನವನ್ನು ಹೊಂದಿಲ್ಲ.
ಆದ್ದರಿಂದ ನಾವು ನೋಡ್‌ಗಳು ಮತ್ತು ಪಾಡ್‌ಗಳೆರಡನ್ನೂ ನೋಡಿಕೊಳ್ಳಬೇಕು. ಕುಬರ್ನೆಟ್ಸ್ ವರ್ಕರ್ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು AWS API ಮತ್ತು ಸ್ಕೇಲಿಂಗ್ ಗುಂಪು ಯಂತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಹೊಸ ನೋಡ್‌ಗಳ ಉಡಾವಣೆಯನ್ನು ಸುಲಭವಾಗಿ ಅಳೆಯಬಹುದು. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೋಡ್ಗಳನ್ನು ನೋಂದಾಯಿಸಲು ನೀವು ಕ್ಲೌಡ್-ಇನಿಟ್ ಅಥವಾ ಅಂತಹುದೇ ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಸಹ ಬಳಸಬಹುದು.
ಹೊಸ ಯಂತ್ರವು ಸ್ಕೇಲಿಂಗ್ ಗುಂಪಿನಲ್ಲಿ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಸ್ವತಃ ನೋಡ್ ಆಗಿ ಪ್ರಾರಂಭಿಸುತ್ತದೆ, ಮಾಸ್ಟರ್ಸ್ ರಿಜಿಸ್ಟ್ರಿಯಲ್ಲಿ ನೋಂದಾಯಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಇದರ ನಂತರ, ಪರಿಣಾಮವಾಗಿ ನೋಡ್ಗಳಲ್ಲಿ ಬಳಕೆಗಾಗಿ ನೀವು ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಹೆಚ್ಚಿಸಬಹುದು. ಸ್ಕೇಲಿಂಗ್ ಡೌನ್‌ಗೆ ಹೆಚ್ಚಿನ ಶ್ರಮ ಬೇಕಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಅಂತಹ ಹಂತವು "ಅನಗತ್ಯ" ಯಂತ್ರಗಳನ್ನು ಆಫ್ ಮಾಡಿದ ನಂತರ ಈಗಾಗಲೇ ಚಾಲನೆಯಲ್ಲಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ನಾಶಕ್ಕೆ ಕಾರಣವಾಗುವುದಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಅಂತಹ ಸನ್ನಿವೇಶವನ್ನು ತಡೆಗಟ್ಟಲು, ನೀವು ನೋಡ್ಗಳನ್ನು "ಅನಿಯೋಜನೆ ಮಾಡಲಾಗದ" ಸ್ಥಿತಿಗೆ ಹೊಂದಿಸಬೇಕಾಗುತ್ತದೆ. ಇದರರ್ಥ DaemonSet ಪಾಡ್‌ಗಳನ್ನು ನಿಗದಿಪಡಿಸುವಾಗ ಡೀಫಾಲ್ಟ್ ಶೆಡ್ಯೂಲರ್ ಈ ನೋಡ್ಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತದೆ. ಶೆಡ್ಯೂಲರ್ ಈ ಸರ್ವರ್‌ಗಳಿಂದ ಏನನ್ನೂ ಅಳಿಸುವುದಿಲ್ಲ, ಆದರೆ ಅಲ್ಲಿ ಯಾವುದೇ ಹೊಸ ಕಂಟೇನರ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ. ಮುಂದಿನ ಹಂತವೆಂದರೆ ಡ್ರೈನ್ ನೋಡ್ ಅನ್ನು ಹೊರಹಾಕುವುದು, ಅಂದರೆ, ಚಾಲನೆಯಲ್ಲಿರುವ ಪಾಡ್‌ಗಳನ್ನು ಅದರಿಂದ ಮತ್ತೊಂದು ಯಂತ್ರಕ್ಕೆ ವರ್ಗಾಯಿಸುವುದು ಅಥವಾ ಇದಕ್ಕಾಗಿ ಸಾಕಷ್ಟು ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿರುವ ಇತರ ನೋಡ್‌ಗಳು. ಈ ನೋಡ್ಗಳಲ್ಲಿ ಇನ್ನು ಮುಂದೆ ಯಾವುದೇ ಕಂಟೈನರ್‌ಗಳಿಲ್ಲ ಎಂದು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಂಡ ನಂತರ, ನೀವು ಅವುಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ನಿಂದ ತೆಗೆದುಹಾಕಬಹುದು. ಇದರ ನಂತರ, ಅವರು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲ. ಮುಂದೆ, ಅನಗತ್ಯ ನೋಡ್‌ಗಳು ಅಥವಾ ಯಂತ್ರಗಳನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲು ನೀವು AWS API ಅನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ.
ನೀವು Amdatu Scalerd ಅನ್ನು ಬಳಸಬಹುದು, AWS API ಅನ್ನು ಹೋಲುವ ಮತ್ತೊಂದು ತೆರೆದ ಮೂಲ ಸ್ಕೇಲಿಂಗ್ ಸಾಧನ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೋಡ್ಗಳನ್ನು ಸೇರಿಸಲು ಅಥವಾ ತೆಗೆದುಹಾಕಲು ಇದು CLI ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಕೆಳಗಿನ json ಫೈಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯ ಇದರ ಆಸಕ್ತಿದಾಯಕ ವೈಶಿಷ್ಟ್ಯವಾಗಿದೆ.
ತೋರಿಸಲಾದ ಕೋಡ್ ರಾತ್ರಿಯ ಅವಧಿಯಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಸಾಮರ್ಥ್ಯವನ್ನು ಅರ್ಧದಷ್ಟು ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಇದು ಲಭ್ಯವಿರುವ ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆ ಮತ್ತು ಅಮೆಜಾನ್ ಕ್ಲಸ್ಟರ್ನ ಅಪೇಕ್ಷಿತ ಸಾಮರ್ಥ್ಯ ಎರಡನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. ಈ ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ರಾತ್ರಿಯಲ್ಲಿ ನೋಡ್‌ಗಳ ಸಂಖ್ಯೆಯನ್ನು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಬೆಳಿಗ್ಗೆ ಅವುಗಳನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ, Amazon ನಂತಹ ಕ್ಲೌಡ್ ಸೇವೆಯಿಂದ ನೋಡ್ಗಳನ್ನು ಬಳಸುವ ವೆಚ್ಚವನ್ನು ಉಳಿಸುತ್ತದೆ. ಈ ವೈಶಿಷ್ಟ್ಯವನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ಸ್ಕೇಲರ್ಡ್ ಅನ್ನು ಬಳಸುವುದರಿಂದ ನೀವು ಬಯಸಿದಂತೆ ಈ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅನ್ನು ಅಳೆಯಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.
"ಅದೆಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ ಮತ್ತು ಒಳ್ಳೆಯದು, ಆದರೆ ಸಾಮಾನ್ಯವಾಗಿ ಸ್ಥಿರವಾಗಿರುವ ನನ್ನ ಡೇಟಾಬೇಸ್ ಬಗ್ಗೆ ಏನು?" ಎಂದು ಅನೇಕ ಜನರು ನನಗೆ ಹೇಳುವುದನ್ನು ನಾನು ಗಮನಿಸಲು ಬಯಸುತ್ತೇನೆ. ಕುಬರ್ನೆಟ್ಸ್‌ನಂತಹ ಕ್ರಿಯಾತ್ಮಕ ಪರಿಸರದಲ್ಲಿ ನೀವು ಈ ರೀತಿಯದನ್ನು ಹೇಗೆ ಚಲಾಯಿಸಬಹುದು? ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ನೀವು ಇದನ್ನು ಮಾಡಬಾರದು, ನೀವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡೇಟಾ ವೇರ್ಹೌಸ್ ಅನ್ನು ನಡೆಸಲು ಪ್ರಯತ್ನಿಸಬಾರದು. ಇದು ತಾಂತ್ರಿಕವಾಗಿ ಸಾಧ್ಯ, ಮತ್ತು ಈ ವಿಷಯದ ಬಗ್ಗೆ ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಟ್ಯುಟೋರಿಯಲ್ಗಳಿವೆ, ಆದರೆ ಇದು ನಿಮ್ಮ ಜೀವನವನ್ನು ಗಂಭೀರವಾಗಿ ಸಂಕೀರ್ಣಗೊಳಿಸುತ್ತದೆ.
ಹೌದು, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಿರಂತರ ಮಳಿಗೆಗಳ ಪರಿಕಲ್ಪನೆ ಇದೆ, ಮತ್ತು ನೀವು ಮೊಂಗೊ ಅಥವಾ MySQL ನಂತಹ ಡೇಟಾ ಸ್ಟೋರ್‌ಗಳನ್ನು ಚಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಬಹುದು, ಆದರೆ ಇದು ಸಾಕಷ್ಟು ಶ್ರಮದಾಯಕ ಕಾರ್ಯವಾಗಿದೆ. ಡೇಟಾ ವೇರ್‌ಹೌಸ್‌ಗಳು ಡೈನಾಮಿಕ್ ಪರಿಸರದೊಂದಿಗೆ ಸಂವಹನವನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಬೆಂಬಲಿಸುವುದಿಲ್ಲ ಎಂಬುದು ಇದಕ್ಕೆ ಕಾರಣ. ಹೆಚ್ಚಿನ ಡೇಟಾಬೇಸ್‌ಗಳಿಗೆ ಕ್ಲಸ್ಟರ್ನ ಹಸ್ತಚಾಲಿತ ಸಂರಚನೆ ಸೇರಿದಂತೆ ಗಮನಾರ್ಹವಾದ ಸಂರಚನೆಯ ಅಗತ್ಯವಿರುತ್ತದೆ, ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮತ್ತು ಇತರ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಇಷ್ಟಪಡುವುದಿಲ್ಲ.
ಆದ್ದರಿಂದ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡೇಟಾ ವೇರ್ಹೌಸ್ ಅನ್ನು ನಡೆಸಲು ಪ್ರಯತ್ನಿಸುವ ಮೂಲಕ ನಿಮ್ಮ ಜೀವನವನ್ನು ನೀವು ಸಂಕೀರ್ಣಗೊಳಿಸಬಾರದು. ಪರಿಚಿತ ಸೇವೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಸಾಂಪ್ರದಾಯಿಕ ರೀತಿಯಲ್ಲಿ ಅವರ ಕೆಲಸವನ್ನು ಸಂಘಟಿಸಿ ಮತ್ತು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ಅವುಗಳನ್ನು ಬಳಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸರಳವಾಗಿ ಒದಗಿಸಿ.
ವಿಷಯವನ್ನು ಮುಕ್ತಾಯಗೊಳಿಸಲು, ನನ್ನ ತಂಡವು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿರುವ ಕುಬರ್ನೆಟ್ಸ್ ಆಧಾರಿತ ಕ್ಲೌಡ್ ಆರ್‌ಟಿಐ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್‌ಗೆ ನಿಮ್ಮನ್ನು ಪರಿಚಯಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ. ಇದು ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್, ಅಪ್ಲಿಕೇಶನ್ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಮಾನಿಟರಿಂಗ್, ಮತ್ತು ಸೂಕ್ತವಾಗಿ ಬರುವ ಅನೇಕ ಇತರ ಉಪಯುಕ್ತ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಪ್ರದರ್ಶಿಸಲು ಗ್ರಾಫಾನಾದಂತಹ ವಿವಿಧ ತೆರೆದ ಮೂಲ ಸಾಧನಗಳನ್ನು ಬಳಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಹೆ-ಪ್ರಾಕ್ಸಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಏಕೆ ಬಳಸಬೇಕು ಎಂಬ ಪ್ರಶ್ನೆಯಿತ್ತು. ಒಳ್ಳೆಯ ಪ್ರಶ್ನೆ ಏಕೆಂದರೆ ಪ್ರಸ್ತುತ 2 ಹಂತದ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಇದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಗಳು ಇನ್ನೂ ವರ್ಚುವಲ್ IP ವಿಳಾಸಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ. ಅಮೆಜಾನ್ ತನ್ನ ಕ್ಲೌಡ್ ಹೋಸ್ಟ್ ಅನ್ನು ಓವರ್‌ಲೋಡ್ ಮಾಡಿದರೆ, ವಿಳಾಸವು ಬದಲಾಗುತ್ತದೆ ಏಕೆಂದರೆ ನೀವು ಅವುಗಳನ್ನು ಬಾಹ್ಯ ಹೋಸ್ಟ್ ಯಂತ್ರಗಳಲ್ಲಿ ಪೋರ್ಟ್‌ಗಳಿಗಾಗಿ ಬಳಸಲಾಗುವುದಿಲ್ಲ. ಇದಕ್ಕಾಗಿಯೇ ನಾವು ಸೇವೆಗಳ ಮುಂದೆ ಹಾ-ಪ್ರಾಕ್ಸಿಯನ್ನು ಇರಿಸುತ್ತೇವೆ - ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಮನಬಂದಂತೆ ಸಂವಹನ ನಡೆಸಲು ಟ್ರಾಫಿಕ್‌ಗಾಗಿ ಹೆಚ್ಚು ಸ್ಥಿರವಾದ ರಚನೆಯನ್ನು ರಚಿಸಲು.
ನೀಲಿ/ಹಸಿರು ನಿಯೋಜನೆ ಮಾಡುವಾಗ ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾ ಬದಲಾವಣೆಗಳನ್ನು ನೀವು ಹೇಗೆ ಕಾಳಜಿ ವಹಿಸಬಹುದು ಎಂಬುದು ಮತ್ತೊಂದು ಒಳ್ಳೆಯ ಪ್ರಶ್ನೆಯಾಗಿದೆ? ಸತ್ಯವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಬಳಕೆಯ ಹೊರತಾಗಿಯೂ, ಡೇಟಾಬೇಸ್ ಸ್ಕೀಮಾವನ್ನು ಬದಲಾಯಿಸುವುದು ಕಷ್ಟಕರವಾದ ಕೆಲಸವಾಗಿದೆ. ಹಳೆಯ ಮತ್ತು ಹೊಸ ಸ್ಕೀಮಾ ಹೊಂದಾಣಿಕೆಯಾಗಿರುವುದನ್ನು ನೀವು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು, ಅದರ ನಂತರ ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ನವೀಕರಿಸಬಹುದು ಮತ್ತು ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ಸ್ವತಃ ನವೀಕರಿಸಬಹುದು. ನೀವು ಡೇಟಾಬೇಸ್ ಅನ್ನು ಬಿಸಿ ವಿನಿಮಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು ಮತ್ತು ನಂತರ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ನವೀಕರಿಸಬಹುದು. ಹೊಸ ಸ್ಕೀಮಾದೊಂದಿಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಹೊಸ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಬೂಟ್ ಮಾಡಿದ ಜನರ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿದೆ, ನೀವು ಮೊಂಗೊದಂತಹ ಸ್ಕೀಮ್‌ಲೆಸ್ ಡೇಟಾಬೇಸ್ ಹೊಂದಿದ್ದರೆ ಇದು ಒಂದು ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ಇದು ಹೇಗಾದರೂ ಸುಲಭದ ಕೆಲಸವಲ್ಲ. ನೀವು ಯಾವುದೇ ಹೆಚ್ಚಿನ ಪ್ರಶ್ನೆಗಳನ್ನು ಹೊಂದಿಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಗಮನಕ್ಕೆ ಧನ್ಯವಾದಗಳು!
ಕೆಲವು ಜಾಹೀರಾತುಗಳು 🙂
ನಮ್ಮೊಂದಿಗೆ ಇರುವುದಕ್ಕೆ ಧನ್ಯವಾದಗಳು. ನೀವು ನಮ್ಮ ಲೇಖನಗಳನ್ನು ಇಷ್ಟಪಡುತ್ತೀರಾ? ಹೆಚ್ಚು ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ನೋಡಲು ಬಯಸುವಿರಾ? ಆರ್ಡರ್ ಮಾಡುವ ಮೂಲಕ ಅಥವಾ ಸ್ನೇಹಿತರಿಗೆ ಶಿಫಾರಸು ಮಾಡುವ ಮೂಲಕ ನಮ್ಮನ್ನು ಬೆಂಬಲಿಸಿ, , ಪ್ರವೇಶ ಮಟ್ಟದ ಸರ್ವರ್‌ಗಳ ಅನನ್ಯ ಅನಲಾಗ್, ಇದನ್ನು ನಿಮಗಾಗಿ ನಾವು ಕಂಡುಹಿಡಿದಿದ್ದೇವೆ: (RAID1 ಮತ್ತು RAID10, 24 ಕೋರ್‌ಗಳವರೆಗೆ ಮತ್ತು 40GB DDR4 ವರೆಗೆ ಲಭ್ಯವಿದೆ).
ಆಮ್‌ಸ್ಟರ್‌ಡ್ಯಾಮ್‌ನಲ್ಲಿರುವ Equinix Tier IV ಡೇಟಾ ಸೆಂಟರ್‌ನಲ್ಲಿ Dell R730xd 2x ಅಗ್ಗವಾಗಿದೆಯೇ? ಇಲ್ಲಿ ಮಾತ್ರ ನೆದರ್ಲ್ಯಾಂಡ್ಸ್ನಲ್ಲಿ! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - $99 ರಿಂದ! ಬಗ್ಗೆ ಓದು
ಮೂಲ: www.habr.com