ವರದಿಯು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಆಪರೇಟರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಗಳಿಗೆ ಮೀಸಲಾಗಿರುತ್ತದೆ, ಅದರ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಮೂಲ ಕಾರ್ಯಾಚರಣೆಯ ತತ್ವಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುತ್ತದೆ.
ವರದಿಯ ಮೊದಲ ಭಾಗದಲ್ಲಿ ನಾವು ಪರಿಗಣಿಸುತ್ತೇವೆ:
- ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಆಪರೇಟರ್ ಎಂದರೇನು ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು;
- ಸಂಕೀರ್ಣ ವ್ಯವಸ್ಥೆಗಳ ನಿರ್ವಹಣೆಯನ್ನು ನಿರ್ವಾಹಕರು ಹೇಗೆ ನಿಖರವಾಗಿ ಸರಳಗೊಳಿಸುತ್ತಾರೆ;
- ಆಪರೇಟರ್ ಏನು ಮಾಡಬಹುದು ಮತ್ತು ಮಾಡಬಾರದು.
ಮುಂದೆ, ಆಪರೇಟರ್ನ ಆಂತರಿಕ ರಚನೆಯನ್ನು ಚರ್ಚಿಸಲು ನಾವು ಹೋಗೋಣ. ಆಪರೇಟರ್ನ ವಾಸ್ತುಶಿಲ್ಪ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಹಂತ ಹಂತವಾಗಿ ನೋಡೋಣ. ಅದನ್ನು ವಿವರವಾಗಿ ನೋಡೋಣ:
- ಆಪರೇಟರ್ ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ನಡುವಿನ ಪರಸ್ಪರ ಕ್ರಿಯೆ;
- ಆಪರೇಟರ್ ಯಾವ ಕಾರ್ಯಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾನೆ ಮತ್ತು ಅದು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಯಾವ ಕಾರ್ಯಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ.
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಚೂರುಗಳು ಮತ್ತು ಡೇಟಾಬೇಸ್ ಪ್ರತಿಕೃತಿಗಳನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ನೋಡೋಣ.
ಮುಂದೆ, ನಾವು ಡೇಟಾ ಸಂಗ್ರಹಣೆ ಸಮಸ್ಯೆಗಳನ್ನು ಚರ್ಚಿಸುತ್ತೇವೆ:
- ಆಪರೇಟರ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ ನಿರಂತರ ಸಂಗ್ರಹಣೆಯೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು;
- ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸುವ ಅಪಾಯಗಳು.
ವರದಿಯ ಅಂತಿಮ ಭಾಗದಲ್ಲಿ, ನಾವು ಅಪ್ಲಿಕೇಶನ್ನ ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಗಳನ್ನು ಪರಿಗಣಿಸುತ್ತೇವೆ Amazon ಅಥವಾ Google ಕ್ಲೌಡ್ ಸೇವೆಯೊಂದಿಗೆ. ವರದಿಯು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ ಆಪರೇಟರ್ನ ಅಭಿವೃದ್ಧಿ ಮತ್ತು ಕಾರ್ಯಾಚರಣೆಯ ಅನುಭವದ ಉದಾಹರಣೆಯನ್ನು ಆಧರಿಸಿದೆ.
ವೀಡಿಯೊ:
ನನ್ನ ಹೆಸರು ವ್ಲಾಡಿಸ್ಲಾವ್ ಕ್ಲಿಮೆಂಕೊ. ಇಂದು ನಾನು ಆಪರೇಟರ್ ಅನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಮತ್ತು ನಿರ್ವಹಿಸುವ ನಮ್ಮ ಅನುಭವದ ಬಗ್ಗೆ ಮಾತನಾಡಲು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ಇದು ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ವಿಶೇಷ ಆಪರೇಟರ್ ಆಗಿದೆ. ಉದಾಹರಣೆಗೆ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ವಹಿಸಲು.
ಆಪರೇಟರ್ ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ಬಗ್ಗೆ ಮಾತನಾಡಲು ನಮಗೆ ಏಕೆ ಅವಕಾಶವಿದೆ?
- ನಾವು ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತೇವೆ ಮತ್ತು ಅಭಿವೃದ್ಧಿಪಡಿಸುತ್ತೇವೆ.
- ಈ ಸಮಯದಲ್ಲಿ, ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಅಭಿವೃದ್ಧಿಗೆ ನಮ್ಮ ಕೊಡುಗೆಯನ್ನು ನಿಧಾನವಾಗಿ ನೀಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ. ಮತ್ತು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಮಾಡಿದ ಬದಲಾವಣೆಗಳ ಪರಿಮಾಣದ ವಿಷಯದಲ್ಲಿ ನಾವು ಯಾಂಡೆಕ್ಸ್ ನಂತರ ಎರಡನೆಯವರಾಗಿದ್ದೇವೆ.
- ಕ್ಲಿಕ್ಹೌಸ್ ಪರಿಸರ ವ್ಯವಸ್ಥೆಗಾಗಿ ನಾವು ಹೆಚ್ಚುವರಿ ಯೋಜನೆಗಳನ್ನು ರಚಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.
ಈ ಯೋಜನೆಗಳಲ್ಲಿ ಒಂದನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ಇದು ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್-ಆಪರೇಟರ್ ಬಗ್ಗೆ.
ನನ್ನ ವರದಿಯಲ್ಲಿ ನಾನು ಎರಡು ವಿಷಯಗಳ ಮೇಲೆ ಸ್ಪರ್ಶಿಸಲು ಬಯಸುತ್ತೇನೆ:
- ನಮ್ಮ ಕ್ಲಿಕ್ಹೌಸ್ ಡೇಟಾಬೇಸ್ ಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಆಪರೇಟರ್ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದು ಮೊದಲ ವಿಷಯವಾಗಿದೆ.
- ಎರಡನೆಯ ವಿಷಯವೆಂದರೆ ಯಾವುದೇ ಆಪರೇಟರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಅಂದರೆ ಅದು ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.
ಆದಾಗ್ಯೂ, ಈ ಎರಡು ಪ್ರಶ್ನೆಗಳು ನನ್ನ ವರದಿಯ ಉದ್ದಕ್ಕೂ ಛೇದಿಸುತ್ತವೆ.
ನಾನು ಹೇಳಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವುದನ್ನು ಕೇಳಲು ಯಾರು ಆಸಕ್ತಿ ಹೊಂದಿರುತ್ತಾರೆ?
- ಆಪರೇಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸುವವರಿಗೆ ಇದು ಹೆಚ್ಚು ಆಸಕ್ತಿಕರವಾಗಿರುತ್ತದೆ.
- ಅಥವಾ ಆಂತರಿಕವಾಗಿ ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ತಮ್ಮದೇ ಆದದನ್ನು ಮಾಡಲು ಬಯಸುವವರಿಗೆ, ಆಪರೇಟರ್ ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ ಮತ್ತು ಯಾವ ಅಪಾಯಗಳು ಕಾಣಿಸಿಕೊಳ್ಳಬಹುದು.
ಇಂದು ನಾವು ಏನು ಚರ್ಚಿಸುತ್ತೇವೆ ಎಂಬುದನ್ನು ಚೆನ್ನಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು, ಕುಬರ್ನೆಟ್ಸ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಕೆಲವು ಮೂಲಭೂತ ಕ್ಲೌಡ್ ತರಬೇತಿಯನ್ನು ಹೊಂದುವುದು ಒಳ್ಳೆಯದು.
ಕ್ಲಿಕ್ಹೌಸ್ ಎಂದರೇನು? ಇದು ವಿಶ್ಲೇಷಣಾತ್ಮಕ ಪ್ರಶ್ನೆಗಳ ಆನ್‌ಲೈನ್ ಪ್ರಕ್ರಿಯೆಗೆ ನಿರ್ದಿಷ್ಟ ವೈಶಿಷ್ಟ್ಯಗಳೊಂದಿಗೆ ಸ್ತಂಭಾಕಾರದ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಮತ್ತು ಇದು ಸಂಪೂರ್ಣವಾಗಿ ಮುಕ್ತ ಮೂಲವಾಗಿದೆ.
ಮತ್ತು ಕೇವಲ ಎರಡು ವಿಷಯಗಳನ್ನು ತಿಳಿದುಕೊಳ್ಳುವುದು ನಮಗೆ ಮುಖ್ಯವಾಗಿದೆ. ಇದು ಡೇಟಾಬೇಸ್ ಎಂದು ನೀವು ತಿಳಿದುಕೊಳ್ಳಬೇಕು, ಆದ್ದರಿಂದ ನಾನು ನಿಮಗೆ ಹೇಳುವುದು ಯಾವುದೇ ಡೇಟಾಬೇಸ್‌ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ. ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ಡಿಬಿಎಂಎಸ್ ಮಾಪಕಗಳು ಉತ್ತಮವಾಗಿರುವುದು, ಬಹುತೇಕ ರೇಖೀಯ ಸ್ಕೇಲೆಬಿಲಿಟಿ ನೀಡುತ್ತದೆ. ಆದ್ದರಿಂದ, ಕ್ಲಸ್ಟರ್ ಸ್ಥಿತಿಯು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ನೈಸರ್ಗಿಕ ಸ್ಥಿತಿಯಾಗಿದೆ. ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ಪೂರೈಸುವುದು ಎಂಬುದನ್ನು ಚರ್ಚಿಸಲು ನಾವು ಹೆಚ್ಚು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ.
ಅವನು ಅಲ್ಲಿ ಏಕೆ ಬೇಕು? ನಾವೇಕೆ ಅದನ್ನು ನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸಬಾರದು? ಮತ್ತು ಉತ್ತರಗಳು ಭಾಗಶಃ ತಾಂತ್ರಿಕ ಮತ್ತು ಭಾಗಶಃ ಸಾಂಸ್ಥಿಕ.
- ಪ್ರಾಯೋಗಿಕವಾಗಿ, ದೊಡ್ಡ ಕಂಪನಿಗಳಲ್ಲಿ ಬಹುತೇಕ ಎಲ್ಲಾ ಘಟಕಗಳು ಈಗಾಗಲೇ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿರುವ ಪರಿಸ್ಥಿತಿಯನ್ನು ನಾವು ಹೆಚ್ಚಾಗಿ ಎದುರಿಸುತ್ತಿದ್ದೇವೆ. ಡೇಟಾಬೇಸ್‌ಗಳು ಹೊರಗೆ ಉಳಿಯುತ್ತವೆ.
- ಮತ್ತು ಪ್ರಶ್ನೆಯನ್ನು ಹೆಚ್ಚಾಗಿ ಕೇಳಲಾಗುತ್ತಿದೆ: "ಇದನ್ನು ಒಳಗೆ ಇರಿಸಬಹುದೇ?" ಆದ್ದರಿಂದ, ದೊಡ್ಡ ಕಂಪನಿಗಳು ತಮ್ಮ ಡೇಟಾ ಗೋದಾಮುಗಳನ್ನು ತ್ವರಿತವಾಗಿ ನಿರ್ವಹಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ನಿರ್ವಹಣೆಯ ಗರಿಷ್ಠ ಏಕೀಕರಣವನ್ನು ಸಾಧಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿವೆ.
- ಮತ್ತು ಹೊಸ ಸ್ಥಳದಲ್ಲಿ ಅದೇ ವಿಷಯವನ್ನು ಪುನರಾವರ್ತಿಸಲು ನಿಮಗೆ ಗರಿಷ್ಠ ಅವಕಾಶ ಅಗತ್ಯವಿದ್ದರೆ ಇದು ವಿಶೇಷವಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಅಂದರೆ ಗರಿಷ್ಠ ಪೋರ್ಟಬಿಲಿಟಿ.
ಇದು ಎಷ್ಟು ಸುಲಭ ಅಥವಾ ಕಷ್ಟ? ಸಹಜವಾಗಿ, ಇದನ್ನು ಕೈಯಿಂದ ಮಾಡಬಹುದು. ಆದರೆ ಇದು ತುಂಬಾ ಸರಳವಲ್ಲ, ಏಕೆಂದರೆ ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಸ್ವತಃ ನಿರ್ವಹಿಸುವ ಸಂಕೀರ್ಣತೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ನಿಶ್ಚಿತಗಳು ಅತಿಯಾಗಿವೆ. ಮತ್ತು ಅಂತಹ ಒಟ್ಟುಗೂಡಿಸುವಿಕೆಯ ಫಲಿತಾಂಶಗಳು.
ಮತ್ತು ಒಟ್ಟಾರೆಯಾಗಿ ಇದು ಸಾಕಷ್ಟು ದೊಡ್ಡ ತಂತ್ರಜ್ಞಾನಗಳನ್ನು ನೀಡುತ್ತದೆ, ಇದು ನಿರ್ವಹಿಸಲು ಸಾಕಷ್ಟು ಕಷ್ಟಕರವಾಗುತ್ತದೆ, ಏಕೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ತನ್ನದೇ ಆದ ದೈನಂದಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಕಾರ್ಯಾಚರಣೆಗೆ ತರುತ್ತದೆ ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ತನ್ನದೇ ಆದ ಸಮಸ್ಯೆಗಳನ್ನು ದೈನಂದಿನ ಕಾರ್ಯಾಚರಣೆಗೆ ತರುತ್ತದೆ. ವಿಶೇಷವಾಗಿ ನಾವು ಹಲವಾರು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ, ಮತ್ತು ನಾವು ಅವರೊಂದಿಗೆ ನಿರಂತರವಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡಬೇಕಾಗಿದೆ.
ಡೈನಾಮಿಕ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ, ಕ್ಲಿಕ್ಹೌಸ್ ಸಾಕಷ್ಟು ದೊಡ್ಡ ಸಂಖ್ಯೆಯ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ ಅದು DevOps ನಲ್ಲಿ ನಿರಂತರ ಲೋಡ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ:
- ನಾವು ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಏನನ್ನಾದರೂ ಬದಲಾಯಿಸಲು ಬಯಸಿದಾಗ, ಉದಾಹರಣೆಗೆ, ಪ್ರತಿಕೃತಿ ಅಥವಾ ಚೂರು ಸೇರಿಸಿ, ನಂತರ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ನಿರ್ವಹಿಸಬೇಕಾಗುತ್ತದೆ.
- ನಂತರ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ಬದಲಾಯಿಸಿ, ಏಕೆಂದರೆ ಕ್ಲಿಕ್ಹೌಸ್ ನಿರ್ದಿಷ್ಟ ಶರ್ಡಿಂಗ್ ವಿಧಾನವನ್ನು ಹೊಂದಿದೆ. ಅಲ್ಲಿ ನೀವು ಡೇಟಾ ರೇಖಾಚಿತ್ರವನ್ನು ಹಾಕಬೇಕು, ಕಾನ್ಫಿಗರೇಶನ್‌ಗಳನ್ನು ಹಾಕಬೇಕು.
- ನೀವು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿಸಬೇಕಾಗಿದೆ.
- ಹೊಸ ಚೂರುಗಳಿಗಾಗಿ, ಹೊಸ ಪ್ರತಿಕೃತಿಗಳಿಗಾಗಿ ದಾಖಲೆಗಳನ್ನು ಸಂಗ್ರಹಿಸುವುದು.
- ಪುನಃಸ್ಥಾಪನೆಯನ್ನು ನೋಡಿಕೊಳ್ಳಿ.
- ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಿ.
ಇವುಗಳು ದಿನನಿತ್ಯದ ಕಾರ್ಯಗಳಾಗಿದ್ದು, ನಾನು ಬಳಸಲು ಸುಲಭವಾಗಿಸಲು ಬಯಸುತ್ತೇನೆ.
ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿ ಚೆನ್ನಾಗಿ ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ಮೂಲಭೂತ ಸಿಸ್ಟಮ್ ವಿಷಯಗಳಲ್ಲಿ.
ಕುಬರ್ನೆಟ್ಸ್ ಈ ರೀತಿಯ ವಿಷಯಗಳನ್ನು ಸುಗಮಗೊಳಿಸಲು ಮತ್ತು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಉತ್ತಮವಾಗಿದೆ:
- ಚೇತರಿಕೆ.
- ಪುನರಾರಂಭದ.
- ಶೇಖರಣಾ ವ್ಯವಸ್ಥೆ ನಿರ್ವಹಣೆ.
ಅದು ಒಳ್ಳೆಯದು, ಅದು ಸರಿಯಾದ ದಿಕ್ಕು, ಆದರೆ ಡೇಟಾಬೇಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂಬುದರ ಕುರಿತು ಅವರು ಸಂಪೂರ್ಣವಾಗಿ ಕ್ಲೂಲೆಸ್ ಆಗಿದ್ದಾರೆ.
ನಾವು ಹೆಚ್ಚಿನದನ್ನು ಬಯಸುತ್ತೇವೆ, ಸಂಪೂರ್ಣ ಡೇಟಾಬೇಸ್ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲು ನಾವು ಬಯಸುತ್ತೇವೆ.
ನೀವು ಒತ್ತುವ ಒಂದು ದೊಡ್ಡ ಮ್ಯಾಜಿಕ್ ಕೆಂಪು ಬಟನ್ ಅನ್ನು ಪಡೆಯಲು ನಾನು ಬಯಸುತ್ತೇನೆ ಮತ್ತು ಪರಿಹರಿಸಬೇಕಾದ ದೈನಂದಿನ ಕಾರ್ಯಗಳನ್ನು ಹೊಂದಿರುವ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಅದರ ಸಂಪೂರ್ಣ ಜೀವನ ಚಕ್ರದಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಮತ್ತು ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್.
ಮತ್ತು ಕೆಲಸವನ್ನು ಸುಲಭಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುವ ಪರಿಹಾರವನ್ನು ಮಾಡಲು ನಾವು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ. ಇದು ಆಲ್ಟಿನಿಟಿಯಿಂದ ಕುಬರ್ನೆಟ್ಸ್‌ಗಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್ ಆಪರೇಟರ್ ಆಗಿದೆ.
ಆಪರೇಟರ್ ಎನ್ನುವುದು ಒಂದು ಪ್ರೋಗ್ರಾಂ ಆಗಿದ್ದು, ಅದರ ಮುಖ್ಯ ಕಾರ್ಯವು ಇತರ ಕಾರ್ಯಕ್ರಮಗಳನ್ನು ನಿರ್ವಹಿಸುವುದು, ಅಂದರೆ ಅದು ಮ್ಯಾನೇಜರ್ ಆಗಿದೆ.
ಮತ್ತು ಇದು ನಡವಳಿಕೆಯ ಮಾದರಿಗಳನ್ನು ಒಳಗೊಂಡಿದೆ. ವಿಷಯದ ಪ್ರದೇಶದ ಬಗ್ಗೆ ಕ್ರೋಡೀಕರಿಸಿದ ಜ್ಞಾನವನ್ನು ನೀವು ಕರೆಯಬಹುದು.
ಮತ್ತು ಅವನ ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ DevOps ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುವುದು ಮತ್ತು ಮೈಕ್ರೋಮ್ಯಾನೇಜ್‌ಮೆಂಟ್ ಅನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು, ಇದರಿಂದ ಅವನು (DevOps) ಈಗಾಗಲೇ ಉನ್ನತ ಮಟ್ಟದ ಪರಿಭಾಷೆಯಲ್ಲಿ ಯೋಚಿಸುತ್ತಾನೆ, ಅಂದರೆ, ಅವನು (DevOps) ಮೈಕ್ರೋಮ್ಯಾನೇಜ್‌ಮೆಂಟ್‌ನಲ್ಲಿ ತೊಡಗಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಅವನು ಕಾನ್ಫಿಗರ್ ಮಾಡುವುದಿಲ್ಲ ಎಲ್ಲಾ ವಿವರಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ.
ಮತ್ತು ಆಪರೇಟರ್ ಕೇವಲ ಮೈಕ್ರೋಟಾಸ್ಕ್‌ಗಳೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಮತ್ತು DevOps ಗೆ ಸಹಾಯ ಮಾಡುವ ರೋಬೋಟಿಕ್ ಸಹಾಯಕ.
ನಿಮಗೆ ಆಪರೇಟರ್ ಏಕೆ ಬೇಕು? ಅವರು ಎರಡು ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ವಿಶೇಷವಾಗಿ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ:
- ಕ್ಲಿಕ್‌ಹೌಸ್‌ನೊಂದಿಗೆ ವ್ಯವಹರಿಸುವ ಪರಿಣಿತರು ಸಾಕಷ್ಟು ಅನುಭವವನ್ನು ಹೊಂದಿಲ್ಲ, ಆದರೆ ಈಗಾಗಲೇ ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ನಿರ್ವಹಿಸುವ ಅಗತ್ಯವಿರುವಾಗ, ಆಪರೇಟರ್ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ಸುಗಮಗೊಳಿಸುತ್ತದೆ ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಕೀರ್ಣವಾದ ಕಾನ್ಫಿಗರೇಶನ್‌ನೊಂದಿಗೆ ನಿರ್ವಹಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಹೆಚ್ಚು ವಿವರವಾಗಿ ಹೋಗುವುದಿಲ್ಲ. ಒಳಗೆ. ನೀವು ಅವನಿಗೆ ಉನ್ನತ ಮಟ್ಟದ ಕಾರ್ಯಗಳನ್ನು ನೀಡುತ್ತೀರಿ ಮತ್ತು ಅದು ಕೆಲಸ ಮಾಡುತ್ತದೆ.
- ಮತ್ತು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಿಶಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಅಗತ್ಯವಾದಾಗ ಅದು ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಎರಡನೇ ಕಾರ್ಯವಾಗಿದೆ. ಸಿಸ್ಟಮ್ ನಿರ್ವಾಹಕರಿಂದ ಮೈಕ್ರೋಟಾಸ್ಕ್ಗಳನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ.
ತಮ್ಮ ಪ್ರಯಾಣವನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಿರುವವರಿಗೆ ಅಥವಾ ಸಾಕಷ್ಟು ಯಾಂತ್ರೀಕರಣವನ್ನು ಮಾಡಬೇಕಾದವರಿಗೆ ಇದು ಅತ್ಯಂತ ಅವಶ್ಯಕವಾಗಿದೆ.
ಆಪರೇಟರ್ ಆಧಾರಿತ ವಿಧಾನವು ಇತರ ವ್ಯವಸ್ಥೆಗಳಿಂದ ಹೇಗೆ ಭಿನ್ನವಾಗಿದೆ? ಹೆಲ್ಮ್ ಇದೆ. ಇದು ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ; ನೀವು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಸೆಳೆಯಬಹುದು, ಅದು ಸಂಪೂರ್ಣ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಹ ಸ್ಥಾಪಿಸುತ್ತದೆ. ಆಪರೇಟರ್ ಮತ್ತು ಅದೇ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೇನು, ಉದಾಹರಣೆಗೆ, ಹೆಲ್ಮ್?
ಮುಖ್ಯ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಹೆಲ್ಮ್ ಪ್ಯಾಕೇಜ್ ನಿರ್ವಹಣೆ ಮತ್ತು ಆಪರೇಟರ್ ಒಂದು ಹೆಜ್ಜೆ ಮುಂದೆ ಹೋಗುತ್ತದೆ. ಇದು ಸಂಪೂರ್ಣ ಜೀವನ ಚಕ್ರಕ್ಕೆ ಬೆಂಬಲವಾಗಿದೆ. ಇದು ಸ್ಥಾಪನೆ ಮಾತ್ರವಲ್ಲ, ಇವುಗಳು ಸ್ಕೇಲಿಂಗ್, ಶಾರ್ಡಿಂಗ್, ಅಂದರೆ ಜೀವನ ಚಕ್ರದಲ್ಲಿ ಮಾಡಬೇಕಾದ ಎಲ್ಲವನ್ನೂ ಒಳಗೊಂಡಿರುವ ದೈನಂದಿನ ಕಾರ್ಯಗಳಾಗಿವೆ (ಅಗತ್ಯವಿದ್ದರೆ, ನಂತರ ಅಳಿಸುವಿಕೆ ಕೂಡ) - ಇದೆಲ್ಲವನ್ನೂ ಆಪರೇಟರ್ ನಿರ್ಧರಿಸುತ್ತಾರೆ. ಇದು ಸಂಪೂರ್ಣ ಸಾಫ್ಟ್‌ವೇರ್ ಜೀವನಚಕ್ರವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಮತ್ತು ನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತದೆ. ಪ್ರಸ್ತುತಪಡಿಸಿದ ಇತರ ಪರಿಹಾರಗಳಿಂದ ಇದು ಅದರ ಮೂಲಭೂತ ವ್ಯತ್ಯಾಸವಾಗಿದೆ.
ಅದು ಪರಿಚಯದ ಭಾಗವಾಗಿತ್ತು, ನಾವು ಮುಂದುವರಿಯೋಣ.
ನಾವು ನಮ್ಮ ಆಪರೇಟರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುತ್ತೇವೆ? ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಒಂದೇ ಸಂಪನ್ಮೂಲವಾಗಿ ನಿರ್ವಹಿಸಲು ನಾವು ಸಮಸ್ಯೆಯನ್ನು ಸಮೀಪಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ.
ಇಲ್ಲಿ ನಾವು ಚಿತ್ರದ ಎಡಭಾಗದಲ್ಲಿ ಇನ್ಪುಟ್ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಇದು ಕ್ಲಸ್ಟರ್ ವಿವರಣೆಯೊಂದಿಗೆ YAML ಆಗಿದೆ, ಇದನ್ನು kubectl ಮೂಲಕ ಕ್ಲಾಸಿಕ್ ರೀತಿಯಲ್ಲಿ Kubernetes ಗೆ ರವಾನಿಸಲಾಗುತ್ತದೆ. ಅಲ್ಲಿ ನಮ್ಮ ಆಪರೇಟರ್ ಅದನ್ನು ಎತ್ತಿಕೊಂಡು ತನ್ನ ಜಾದೂ ಮಾಡುತ್ತಾನೆ. ಮತ್ತು ಔಟ್ಪುಟ್ನಲ್ಲಿ ನಾವು ಈ ಕೆಳಗಿನ ಯೋಜನೆಯನ್ನು ಪಡೆಯುತ್ತೇವೆ. ಇದು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಅನುಷ್ಠಾನವಾಗಿದೆ.
ತದನಂತರ ಆಪರೇಟರ್ ನಿಖರವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಯಾವ ವಿಶಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಪರಿಹರಿಸಬಹುದು ಎಂಬುದನ್ನು ನಾವು ನಿಧಾನವಾಗಿ ನೋಡುತ್ತೇವೆ. ನಮಗೆ ಸೀಮಿತ ಸಮಯ ಇರುವುದರಿಂದ ನಾವು ವಿಶಿಷ್ಟ ಕಾರ್ಯಗಳನ್ನು ಮಾತ್ರ ಪರಿಗಣಿಸುತ್ತೇವೆ. ಮತ್ತು ಆಪರೇಟರ್ ನಿರ್ಧರಿಸಬಹುದಾದ ಎಲ್ಲವನ್ನೂ ಚರ್ಚಿಸಲಾಗುವುದಿಲ್ಲ.
ಅಭ್ಯಾಸದಿಂದ ಪ್ರಾರಂಭಿಸೋಣ. ನಮ್ಮ ಯೋಜನೆಯು ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆದ ಮೂಲವಾಗಿದೆ, ಆದ್ದರಿಂದ ನೀವು GitHub ನಲ್ಲಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಬಹುದು. ಮತ್ತು ನೀವು ಅದನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಯಸಿದರೆ, ನಂತರ ನೀವು ತ್ವರಿತ ಪ್ರಾರಂಭ ಮಾರ್ಗದರ್ಶಿಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸಬಹುದು ಎಂಬ ಪರಿಗಣನೆಗಳಿಂದ ನೀವು ಮುಂದುವರಿಯಬಹುದು.
ನೀವು ವಿವರವಾಗಿ ಅರ್ಥಮಾಡಿಕೊಳ್ಳಲು ಬಯಸಿದರೆ, ನಾವು ದಸ್ತಾವೇಜನ್ನು ಹೆಚ್ಚು ಅಥವಾ ಕಡಿಮೆ ಯೋಗ್ಯ ರೂಪದಲ್ಲಿ ನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ.
ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭಿಸೋಣ. ನಾವೆಲ್ಲರೂ ಪ್ರಾರಂಭಿಸಲು ಬಯಸುವ ಮೊದಲ ಕಾರ್ಯವೆಂದರೆ ಮೊದಲ ಉದಾಹರಣೆಯನ್ನು ಹೇಗಾದರೂ ಚಲಾಯಿಸುವುದು. ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ನಾನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬಹುದು, ಅದು ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನನಗೆ ನಿಜವಾಗಿಯೂ ತಿಳಿದಿಲ್ಲದಿದ್ದರೂ ಸಹ? ನಾವು ಪ್ರಣಾಳಿಕೆಯನ್ನು ಬರೆಯುತ್ತಿದ್ದೇವೆ, ಏಕೆಂದರೆ... k8s ನೊಂದಿಗೆ ಎಲ್ಲಾ ಸಂವಹನವು ಮ್ಯಾನಿಫೆಸ್ಟ್ಗಳ ಮೂಲಕ ಸಂವಹನವಾಗಿದೆ.
ಇದು ಅಂತಹ ಸಂಕೀರ್ಣ ಪ್ರಣಾಳಿಕೆಯಾಗಿದೆ. ನಾವು ಕೆಂಪು ಬಣ್ಣದಲ್ಲಿ ಏನನ್ನು ಹೈಲೈಟ್ ಮಾಡಿದ್ದೇವೆ ಎಂಬುದರ ಮೇಲೆ ನಾವು ಗಮನಹರಿಸಬೇಕಾಗಿದೆ. ಡೆಮೊ ಹೆಸರಿನ ಕ್ಲಸ್ಟರ್ ರಚಿಸಲು ನಾವು ಆಪರೇಟರ್‌ಗೆ ಕೇಳುತ್ತೇವೆ.
ಸದ್ಯಕ್ಕೆ ಇವು ಮೂಲ ಉದಾಹರಣೆಗಳು. ಸಂಗ್ರಹಣೆಯನ್ನು ಇನ್ನೂ ವಿವರಿಸಲಾಗಿಲ್ಲ, ಆದರೆ ನಾವು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಸಂಗ್ರಹಣೆಗೆ ಹಿಂತಿರುಗುತ್ತೇವೆ. ಸದ್ಯಕ್ಕೆ, ನಾವು ಕ್ಲಸ್ಟರ್‌ನ ಅಭಿವೃದ್ಧಿಯ ಡೈನಾಮಿಕ್ಸ್ ಅನ್ನು ಗಮನಿಸುತ್ತೇವೆ.
ನಾವು ಈ ಪ್ರಣಾಳಿಕೆಯನ್ನು ರಚಿಸಿದ್ದೇವೆ. ನಾವು ಅದನ್ನು ನಮ್ಮ ಆಪರೇಟರ್‌ಗೆ ನೀಡುತ್ತೇವೆ. ಅವರು ಕೆಲಸ ಮಾಡಿದರು, ಅವರು ಮ್ಯಾಜಿಕ್ ಮಾಡಿದರು.
ನಾವು ಕನ್ಸೋಲ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ. ಮೂರು ಘಟಕಗಳು ಆಸಕ್ತಿಯನ್ನು ಹೊಂದಿವೆ: ಒಂದು ಪಾಡ್, ಎರಡು ಸೇವೆಗಳು ಮತ್ತು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್.
ಆಪರೇಟರ್ ಕೆಲಸ ಮಾಡಿದ್ದಾರೆ ಮತ್ತು ಅವರು ನಿಖರವಾಗಿ ಏನು ರಚಿಸಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾವು ನೋಡಬಹುದು.
ಅವನು ಅಂತಹದನ್ನು ಸೃಷ್ಟಿಸುತ್ತಾನೆ. ನಾವು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್, ಪಾಡ್, ಪ್ರತಿ ಪ್ರತಿಕೃತಿಗೆ ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್, ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರವೇಶ ಬಿಂದುಗಳಾಗಿ ಸೇವೆಗಳು ಅಗತ್ಯವಿದೆ.
ಸೇವೆಗಳು ಕೇಂದ್ರ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಸೇವೆಯಾಗಿದೆ ಮತ್ತು ಪ್ರತಿ ಪ್ರತಿಕೃತಿಗೆ, ಪ್ರತಿ ಚೂರುಗಳಿಗೆ ಸಹ ಬಳಸಬಹುದು.
ನಮ್ಮ ಮೂಲ ಕ್ಲಸ್ಟರ್ ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ಇದು ಒಂದೇ ನೋಡ್‌ನಿಂದ.
ಮುಂದೆ ಹೋಗಿ ವಿಷಯಗಳನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸೋಣ. ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಚೂರು ಮಾಡಬೇಕಾಗಿದೆ.
ನಮ್ಮ ಕಾರ್ಯಗಳು ಬೆಳೆಯುತ್ತಿವೆ, ಡೈನಾಮಿಕ್ಸ್ ಪ್ರಾರಂಭವಾಗುತ್ತಿದೆ. ನಾವು ಚೂರು ಸೇರಿಸಲು ಬಯಸುತ್ತೇವೆ. ನಾವು ಅಭಿವೃದ್ಧಿಯನ್ನು ಅನುಸರಿಸುತ್ತೇವೆ. ನಾವು ನಮ್ಮ ವಿವರಣೆಯನ್ನು ಬದಲಾಯಿಸುತ್ತಿದ್ದೇವೆ. ನಮಗೆ ಎರಡು ಚೂರುಗಳು ಬೇಕು ಎಂದು ನಾವು ಸೂಚಿಸುತ್ತೇವೆ.
ಸಿಸ್ಟಮ್ನ ಬೆಳವಣಿಗೆಯೊಂದಿಗೆ ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಅಭಿವೃದ್ಧಿಪಡಿಸುವ ಅದೇ ಫೈಲ್ ಆಗಿದೆ. ಶೇಖರಣಾ ಸಂಖ್ಯೆ, ಸಂಗ್ರಹಣೆಯನ್ನು ಮತ್ತಷ್ಟು ಚರ್ಚಿಸಲಾಗುವುದು, ಇದು ಪ್ರತ್ಯೇಕ ವಿಷಯವಾಗಿದೆ.
ನಾವು YAML ಆಪರೇಟರ್‌ಗೆ ಆಹಾರವನ್ನು ನೀಡುತ್ತೇವೆ ಮತ್ತು ಏನಾಗುತ್ತದೆ ಎಂದು ನೋಡುತ್ತೇವೆ.
ನಿರ್ವಾಹಕರು ಯೋಚಿಸಿದರು ಮತ್ತು ಕೆಳಗಿನ ಘಟಕಗಳನ್ನು ಮಾಡಿದರು. ನಾವು ಈಗಾಗಲೇ ಎರಡು ಪಾಡ್‌ಗಳು, ಮೂರು ಸೇವೆಗಳು ಮತ್ತು ಇದ್ದಕ್ಕಿದ್ದಂತೆ 2 ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಏಕೆ 2 ಸ್ಟೇಟ್‌ಫುಲ್ ಸೆಟ್‌ಗಳು?
ರೇಖಾಚಿತ್ರದಲ್ಲಿ ಅದು ಹೀಗಿತ್ತು - ಇದು ನಮ್ಮ ಆರಂಭಿಕ ಸ್ಥಿತಿ, ನಾವು ಒಂದು ಪಾಡ್ ಹೊಂದಿರುವಾಗ.
ಹೀಗೇ ಆಯಿತು. ಇಲ್ಲಿಯವರೆಗೆ ಎಲ್ಲವೂ ಸರಳವಾಗಿದೆ, ಅದನ್ನು ನಕಲು ಮಾಡಲಾಗಿದೆ.
ಮತ್ತು ಎರಡು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳು ಏಕೆ ಆಯಿತು? ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಪಾಡ್ಗಳನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ ಎಂಬ ಪ್ರಶ್ನೆಯನ್ನು ಇಲ್ಲಿ ನಾವು ವಿಮುಖಗೊಳಿಸಬೇಕು ಮತ್ತು ಚರ್ಚಿಸಬೇಕು.
ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ಪಾಡ್‌ಗಳ ಸೆಟ್ ಅನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್ ಎಂಬ ವಸ್ತುವಿದೆ. ಇಲ್ಲಿ ಪ್ರಮುಖ ಅಂಶವೆಂದರೆ ಟೆಂಪ್ಲೇಟ್. ಮತ್ತು ನೀವು ಒಂದು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ನಲ್ಲಿ ಒಂದು ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅನೇಕ ಪಾಡ್ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದು. ಮತ್ತು ಇಲ್ಲಿ ಪ್ರಮುಖ ನುಡಿಗಟ್ಟು "ಒಂದು ಟೆಂಪ್ಲೇಟ್‌ಗಾಗಿ ಹಲವು ಪಾಡ್‌ಗಳು."
ಮತ್ತು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಮಾಡಲು ಒಂದು ದೊಡ್ಡ ಪ್ರಲೋಭನೆ ಇತ್ತು, ಅದನ್ನು ಒಂದು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗೆ ಪ್ಯಾಕ್ ಮಾಡಿದೆ. ಇದು ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅದರಲ್ಲಿ ಯಾವುದೇ ತೊಂದರೆ ಇಲ್ಲ. ಆದರೆ ಒಂದು ಎಚ್ಚರಿಕೆ ಇದೆ. ನಾವು ವೈವಿಧ್ಯಮಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಜೋಡಿಸಲು ಬಯಸಿದರೆ, ಅಂದರೆ, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹಲವಾರು ಆವೃತ್ತಿಗಳಿಂದ, ನಂತರ ಪ್ರಶ್ನೆಗಳು ಉದ್ಭವಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತವೆ. ಹೌದು, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್ ರೋಲಿಂಗ್ ಅಪ್‌ಡೇಟ್ ಮಾಡಬಹುದು ಮತ್ತು ಅಲ್ಲಿ ನೀವು ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹೊರತರಬಹುದು, ನೀವು ಒಂದೇ ಸಮಯದಲ್ಲಿ ಹಲವಾರು ನೋಡ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಿನದನ್ನು ಪ್ರಯತ್ನಿಸಬೇಕಾಗಿಲ್ಲ ಎಂದು ವಿವರಿಸಿ.
ಆದರೆ ನಾವು ಕಾರ್ಯವನ್ನು ಎಕ್ಸ್‌ಟ್ರಾಪೋಲೇಟ್ ಮಾಡಿದರೆ ಮತ್ತು ನಾವು ಸಂಪೂರ್ಣವಾಗಿ ವೈವಿಧ್ಯಮಯ ಕ್ಲಸ್ಟರ್ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ ಮತ್ತು ರೋಲಿಂಗ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಹಳೆಯ ಆವೃತ್ತಿಯಿಂದ ಹೊಸದಕ್ಕೆ ಬದಲಾಯಿಸಲು ನಾವು ಬಯಸುವುದಿಲ್ಲ ಎಂದು ಹೇಳಿದರೆ, ಆದರೆ ನಾವು ಎರಡೂ ನಿಯಮಗಳಲ್ಲಿ ಭಿನ್ನಜಾತಿಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ವಿವಿಧ ಆವೃತ್ತಿಗಳು ಮತ್ತು ವಿಭಿನ್ನ ಸಂಗ್ರಹಣೆಯ ವಿಷಯದಲ್ಲಿ. ಉದಾಹರಣೆಗೆ, ಪ್ರತ್ಯೇಕ ಡಿಸ್ಕ್ಗಳಲ್ಲಿ ಕೆಲವು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಮಾಡಲು, ನಿಧಾನವಾದವುಗಳಲ್ಲಿ, ಸಾಮಾನ್ಯವಾಗಿ, ಸಂಪೂರ್ಣವಾಗಿ ವೈವಿಧ್ಯಮಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ನಾವು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್ ಒಂದು ಟೆಂಪ್ಲೇಟ್‌ನಿಂದ ಪ್ರಮಾಣಿತ ಪರಿಹಾರವನ್ನು ಮಾಡುತ್ತದೆ ಎಂಬ ಕಾರಣದಿಂದಾಗಿ, ಇದನ್ನು ಮಾಡಲು ಯಾವುದೇ ಮಾರ್ಗವಿಲ್ಲ.
ಸ್ವಲ್ಪ ಯೋಚಿಸಿದ ನಂತರ, ನಾವು ಈ ರೀತಿ ಮಾಡೋಣ ಎಂದು ನಿರ್ಧರಿಸಲಾಯಿತು. ನಾವು ಪ್ರತಿಯೊಂದು ಪ್ರತಿಕೃತಿಯನ್ನು ಅದರ ಸ್ವಂತ ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ನಲ್ಲಿ ಹೊಂದಿದ್ದೇವೆ. ಈ ಪರಿಹಾರಕ್ಕೆ ಕೆಲವು ನ್ಯೂನತೆಗಳಿವೆ, ಆದರೆ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಇದು ಆಪರೇಟರ್ನಿಂದ ಸಂಪೂರ್ಣವಾಗಿ ಸುತ್ತುವರಿಯಲ್ಪಟ್ಟಿದೆ. ಮತ್ತು ಸಾಕಷ್ಟು ಅನುಕೂಲಗಳಿವೆ. ನಮಗೆ ಬೇಕಾದ ನಿಖರವಾದ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಾವು ನಿರ್ಮಿಸಬಹುದು, ಉದಾಹರಣೆಗೆ, ಸಂಪೂರ್ಣವಾಗಿ ಭಿನ್ನಜಾತಿ. ಆದ್ದರಿಂದ, ನಾವು ಒಂದು ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಎರಡು ಚೂರುಗಳನ್ನು ಹೊಂದಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ, ನಾವು 2 ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳು ಮತ್ತು 2 ಪಾಡ್ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ ಏಕೆಂದರೆ ನಾವು ಒಂದು ಭಿನ್ನಜಾತಿಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ಸಾಧ್ಯವಾಗುವಂತೆ ಮೇಲೆ ತಿಳಿಸಿದ ಕಾರಣಗಳಿಗಾಗಿ ಈ ವಿಧಾನವನ್ನು ಆರಿಸಿದ್ದೇವೆ.
ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಗಳಿಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಾವು ಬಳಕೆದಾರರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗಿದೆ, ಅಂದರೆ. ನೀವು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಕೆಲವು ಸಂರಚನೆಯನ್ನು ಮಾಡಬೇಕಾಗಿದೆ. ಆಪರೇಟರ್ ಇದಕ್ಕಾಗಿ ಎಲ್ಲಾ ಸಾಧ್ಯತೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ.
ನಮಗೆ ಬೇಕಾದುದನ್ನು ನೇರವಾಗಿ YAML ನಲ್ಲಿ ಬರೆಯಬಹುದು. ಎಲ್ಲಾ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳನ್ನು ಈ YAML ನಿಂದ ನೇರವಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕಾನ್ಫಿಗ್‌ಗಳಿಗೆ ಮ್ಯಾಪ್ ಮಾಡಲಾಗುತ್ತದೆ, ನಂತರ ಅದನ್ನು ಕ್ಲಸ್ಟರ್‌ನಾದ್ಯಂತ ವಿತರಿಸಲಾಗುತ್ತದೆ.
ನೀವು ಇದನ್ನು ಹೀಗೆ ಬರೆಯಬಹುದು. ಇದು ಉದಾಹರಣೆಗೆ. ಪಾಸ್ವರ್ಡ್ ಅನ್ನು ಎನ್ಕ್ರಿಪ್ಟ್ ಮಾಡಬಹುದು. ಸಂಪೂರ್ಣವಾಗಿ ಎಲ್ಲಾ ಕ್ಲಿಕ್ಹೌಸ್ ಕಾನ್ಫಿಗರೇಶನ್ ಆಯ್ಕೆಗಳು ಬೆಂಬಲಿತವಾಗಿದೆ. ಇಲ್ಲಿ ಕೇವಲ ಒಂದು ಉದಾಹರಣೆ.
ಕ್ಲಸ್ಟರ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್ ಆಗಿ ವಿತರಿಸಲಾಗಿದೆ. ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್ ನವೀಕರಣವು ತಕ್ಷಣವೇ ಸಂಭವಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಕ್ಲಸ್ಟರ್ ದೊಡ್ಡದಾಗಿದ್ದರೆ, ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ತಳ್ಳುವ ಪ್ರಕ್ರಿಯೆಯು ಸ್ವಲ್ಪ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಆದರೆ ಇದೆಲ್ಲವೂ ಬಳಸಲು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ.
ಕಾರ್ಯವನ್ನು ಸಂಕೀರ್ಣಗೊಳಿಸೋಣ. ಕ್ಲಸ್ಟರ್ ಅಭಿವೃದ್ಧಿಯಾಗುತ್ತಿದೆ. ನಾವು ಡೇಟಾವನ್ನು ಪುನರಾವರ್ತಿಸಲು ಬಯಸುತ್ತೇವೆ. ಅಂದರೆ, ನಾವು ಈಗಾಗಲೇ ಎರಡು ಚೂರುಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಪ್ರತಿಯೊಂದರ ಪ್ರತಿಕೃತಿ, ಮತ್ತು ಬಳಕೆದಾರರನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ. ನಾವು ಬೆಳೆಯುತ್ತಿದ್ದೇವೆ ಮತ್ತು ಪ್ರತಿರೂಪವನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ.
ನಕಲು ಮಾಡಲು ನಮಗೆ ಏನು ಬೇಕು?
ನಮಗೆ ZooKeeper ಅಗತ್ಯವಿದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ, ಝೂಕೀಪರ್ ಬಳಸಿ ಪ್ರತಿಕೃತಿಯನ್ನು ನಿರ್ಮಿಸಲಾಗಿದೆ. ZooKeeper ಅಗತ್ಯವಿದೆ ಆದ್ದರಿಂದ ಯಾವ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನಲ್ಲಿ ಯಾವ ಡೇಟಾ ಬ್ಲಾಕ್‌ಗಳಿವೆ ಎಂಬುದರ ಕುರಿತು ವಿವಿಧ ಕ್ಲಿಕ್ಹೌಸ್ ಪ್ರತಿಕೃತಿಗಳು ಒಮ್ಮತವನ್ನು ಹೊಂದಿವೆ.
ZooKeeper ಅನ್ನು ಯಾರಾದರೂ ಬಳಸಬಹುದು. ಎಂಟರ್‌ಪ್ರೈಸ್ ಬಾಹ್ಯ ZooKeeper ಅನ್ನು ಹೊಂದಿದ್ದರೆ, ಅದನ್ನು ಬಳಸಬಹುದು. ಇಲ್ಲದಿದ್ದರೆ, ನೀವು ಅದನ್ನು ನಮ್ಮ ರೆಪೊಸಿಟರಿಯಿಂದ ಸ್ಥಾಪಿಸಬಹುದು. ಈ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಸುಲಭಗೊಳಿಸುವ ಅನುಸ್ಥಾಪಕವಿದೆ.
ಮತ್ತು ಇಡೀ ಸಿಸ್ಟಮ್ನ ಪರಸ್ಪರ ರೇಖಾಚಿತ್ರವು ಈ ರೀತಿ ತಿರುಗುತ್ತದೆ. ನಾವು ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ವೇದಿಕೆಯಾಗಿ ಹೊಂದಿದ್ದೇವೆ. ಇದು ಕ್ಲಿಕ್ಹೌಸ್ ಆಪರೇಟರ್ ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುತ್ತದೆ. ನಾನು ಇಲ್ಲಿ ZooKeeper ಅನ್ನು ಚಿತ್ರಿಸಿದೆ. ಮತ್ತು ಆಪರೇಟರ್ ಕ್ಲಿಕ್ಹೌಸ್ ಮತ್ತು ಝೂಕೀಪರ್ ಎರಡರೊಂದಿಗೂ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಅಂದರೆ, ಪರಸ್ಪರ ಕ್ರಿಯೆಯ ಫಲಿತಾಂಶಗಳು.
ಮತ್ತು K8s ನಲ್ಲಿ ಡೇಟಾವನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪುನರಾವರ್ತಿಸಲು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗೆ ಇವೆಲ್ಲವೂ ಅವಶ್ಯಕ.
ಈಗ ಕಾರ್ಯವನ್ನು ಸ್ವತಃ ನೋಡೋಣ, ಪ್ರತಿಕೃತಿಗಾಗಿ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಹೇಗಿರುತ್ತದೆ.
ನಾವು ನಮ್ಮ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗೆ ಎರಡು ವಿಭಾಗಗಳನ್ನು ಸೇರಿಸುತ್ತಿದ್ದೇವೆ. ಮೊದಲನೆಯದು ಝೂಕೀಪರ್ ಅನ್ನು ಎಲ್ಲಿ ಪಡೆಯುವುದು, ಅದು ಕುಬರ್ನೆಟ್ಸ್ ಒಳಗೆ ಅಥವಾ ಬಾಹ್ಯವಾಗಿರಬಹುದು. ಇದು ಕೇವಲ ವಿವರಣೆಯಾಗಿದೆ. ಮತ್ತು ನಾವು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಆದೇಶಿಸುತ್ತೇವೆ. ಆ. ನಮಗೆ ಎರಡು ಪ್ರತಿಕೃತಿಗಳು ಬೇಕು. ಒಟ್ಟಾರೆಯಾಗಿ, ನಾವು ಔಟ್ಪುಟ್ನಲ್ಲಿ 4 ಪಾಡ್ಗಳನ್ನು ಹೊಂದಿರಬೇಕು. ಸಂಗ್ರಹಣೆಯ ಬಗ್ಗೆ ನಮಗೆ ನೆನಪಿದೆ, ಅದು ಸ್ವಲ್ಪ ಸಮಯದ ನಂತರ ಹಿಂತಿರುಗುತ್ತದೆ. ಶೇಖರಣೆಯು ಪ್ರತ್ಯೇಕ ಕಥೆಯಾಗಿದೆ.
ಇದು ಹೀಗಿತ್ತು.
ಇದು ಈ ರೀತಿ ಆಗುತ್ತದೆ. ಪ್ರತಿಕೃತಿಗಳನ್ನು ಸೇರಿಸಲಾಗುತ್ತದೆ. 4 ನೆಯದು ಹೊಂದಿಕೆಯಾಗಲಿಲ್ಲ, ಅವುಗಳಲ್ಲಿ ಹಲವು ಇರಬಹುದೆಂದು ನಾವು ನಂಬುತ್ತೇವೆ. ಮತ್ತು ZooKeeper ಅನ್ನು ಬದಿಗೆ ಸೇರಿಸಲಾಗಿದೆ. ಯೋಜನೆಗಳು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾಗುತ್ತಿವೆ.
ಮತ್ತು ಮುಂದಿನ ಕಾರ್ಯವನ್ನು ಸೇರಿಸುವ ಸಮಯ. ನಾವು ನಿರಂತರ ಸಂಗ್ರಹಣೆಯನ್ನು ಸೇರಿಸುತ್ತೇವೆ.
ನಿರಂತರ ಶೇಖರಣೆಗಾಗಿ ನಾವು ವಿವಿಧ ಆಯ್ಕೆಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ನಾವು ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್‌ನಲ್ಲಿ ಓಡುತ್ತಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ, ಅಮೆಜಾನ್, ಗೂಗಲ್ ಅನ್ನು ಬಳಸುತ್ತಿದ್ದರೆ, ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಬಳಸಲು ಉತ್ತಮ ಪ್ರಲೋಭನೆ ಇರುತ್ತದೆ. ಇದು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ, ಇದು ಒಳ್ಳೆಯದು.
ಮತ್ತು ಎರಡನೇ ಆಯ್ಕೆ ಇದೆ. ಇದು ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಗಾಗಿ, ನಾವು ಪ್ರತಿ ನೋಡ್‌ನಲ್ಲಿ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ಗಳನ್ನು ಹೊಂದಿರುವಾಗ. ಈ ಆಯ್ಕೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಹೆಚ್ಚು ಕಷ್ಟ, ಆದರೆ ಅದೇ ಸಮಯದಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಉತ್ಪಾದಕವಾಗಿದೆ.
ಕ್ಲೌಡ್ ಸ್ಟೋರೇಜ್ ಬಗ್ಗೆ ನಮ್ಮ ಬಳಿ ಏನಿದೆ ಎಂದು ನೋಡೋಣ.
ಅನುಕೂಲಗಳಿವೆ. ಇದು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ತುಂಬಾ ಸುಲಭ. ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್‌ನಿಂದ ನಾವು ಸರಳವಾಗಿ ಆದೇಶಿಸುತ್ತೇವೆ, ದಯವಿಟ್ಟು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಸಾಮರ್ಥ್ಯದ, ಅಂತಹ ಮತ್ತು ಅಂತಹ ವರ್ಗದ ಸಂಗ್ರಹಣೆಯನ್ನು ನಮಗೆ ನೀಡಿ. ತರಗತಿಗಳನ್ನು ಒದಗಿಸುವವರು ಸ್ವತಂತ್ರವಾಗಿ ನಿಗದಿಪಡಿಸಿದ್ದಾರೆ.
ಮತ್ತು ಒಂದು ನ್ಯೂನತೆಯಿದೆ. ಕೆಲವರಿಗೆ, ಇದು ನಿರ್ಣಾಯಕವಲ್ಲದ ನ್ಯೂನತೆಯಾಗಿದೆ. ಸಹಜವಾಗಿ, ಕೆಲವು ಕಾರ್ಯಕ್ಷಮತೆ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ. ಇದು ಬಳಸಲು ತುಂಬಾ ಅನುಕೂಲಕರವಾಗಿದೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹವಾಗಿದೆ, ಆದರೆ ಕೆಲವು ಸಂಭಾವ್ಯ ಕಾರ್ಯಕ್ಷಮತೆಯ ನ್ಯೂನತೆಗಳಿವೆ.
ಮತ್ತು ಏಕೆಂದರೆ ಕ್ಲಿಕ್ಹೌಸ್ ನಿರ್ದಿಷ್ಟವಾಗಿ ಉತ್ಪಾದಕತೆಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸುತ್ತದೆ, ಅದು ಸಾಧ್ಯವಿರುವ ಎಲ್ಲವನ್ನೂ ಹಿಂಡುತ್ತದೆ ಎಂದು ಒಬ್ಬರು ಹೇಳಬಹುದು, ಅದಕ್ಕಾಗಿಯೇ ಹೆಚ್ಚಿನ ಗ್ರಾಹಕರು ಗರಿಷ್ಠ ಉತ್ಪಾದಕತೆಯನ್ನು ಹಿಂಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಾರೆ.
ಮತ್ತು ಹೆಚ್ಚಿನದನ್ನು ಪಡೆಯಲು, ನಮಗೆ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯ ಅಗತ್ಯವಿದೆ.
ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯನ್ನು ಬಳಸಲು ಕುಬರ್ನೆಟ್ಸ್ ಮೂರು ಅಮೂರ್ತತೆಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ. ಇದು:
- ಖಾಲಿ ಡೈರಿ
- ಹೋಸ್ಟ್‌ಪಾತ್.
- ಸ್ಥಳೀಯ
ಅವು ಹೇಗೆ ಭಿನ್ನವಾಗಿವೆ ಮತ್ತು ಅವು ಹೇಗೆ ಹೋಲುತ್ತವೆ ಎಂಬುದನ್ನು ನೋಡೋಣ.
ಮೊದಲನೆಯದಾಗಿ, ಎಲ್ಲಾ ಮೂರು ವಿಧಾನಗಳಲ್ಲಿ ನಾವು ಶೇಖರಣೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ - ಇವುಗಳು ಒಂದೇ ಭೌತಿಕ k8s ನೋಡ್‌ನಲ್ಲಿರುವ ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ಗಳಾಗಿವೆ. ಆದರೆ ಅವರಿಗೆ ಕೆಲವು ವ್ಯತ್ಯಾಸಗಳಿವೆ.
ಸರಳವಾದ ಒಂದರಿಂದ ಪ್ರಾರಂಭಿಸೋಣ, ಅಂದರೆ ಖಾಲಿDir. ಆಚರಣೆಯಲ್ಲಿ ಇದು ಏನು? ನಮ್ಮ ವಿವರಣೆಯಲ್ಲಿ, ಸ್ಥಳೀಯ ಡಿಸ್ಕ್‌ನಲ್ಲಿರುವ ಫೋಲ್ಡರ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಒದಗಿಸಲು ನಾವು ಕಂಟೈನರೈಸೇಶನ್ ಸಿಸ್ಟಮ್ (ಹೆಚ್ಚಾಗಿ ಡಾಕರ್) ಅನ್ನು ಕೇಳುತ್ತೇವೆ.
ಪ್ರಾಯೋಗಿಕವಾಗಿ, ಡಾಕರ್ ತನ್ನದೇ ಆದ ಹಾದಿಯಲ್ಲಿ ಎಲ್ಲೋ ತಾತ್ಕಾಲಿಕ ಫೋಲ್ಡರ್ ಅನ್ನು ರಚಿಸುತ್ತದೆ ಮತ್ತು ಅದನ್ನು ದೀರ್ಘ ಹ್ಯಾಶ್ ಎಂದು ಕರೆಯುತ್ತದೆ. ಮತ್ತು ಅದನ್ನು ಪ್ರವೇಶಿಸಲು ಇಂಟರ್ಫೇಸ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ.
ಕಾರ್ಯಕ್ಷಮತೆಯ ಪ್ರಕಾರ ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಇದು ಸ್ಥಳೀಯ ಡಿಸ್ಕ್ ವೇಗದಲ್ಲಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ, ಅಂದರೆ. ಇದು ನಿಮ್ಮ ಸ್ಕ್ರೂಗೆ ಪೂರ್ಣ ಪ್ರವೇಶವಾಗಿದೆ.
ಆದರೆ ಈ ಪ್ರಕರಣವು ಅದರ ನ್ಯೂನತೆಯನ್ನು ಹೊಂದಿದೆ. ಈ ವಿಷಯದಲ್ಲಿ ನಿರಂತರವು ಸಾಕಷ್ಟು ಸಂಶಯಾಸ್ಪದವಾಗಿದೆ. ಮೊದಲ ಬಾರಿಗೆ ಡಾಕರ್ ಕಂಟೈನರ್‌ಗಳೊಂದಿಗೆ ಚಲಿಸಿದಾಗ, ಪರ್ಸಿಸ್ಟೆಂಟ್ ಕಳೆದುಹೋಗುತ್ತದೆ. ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಈ ಪಾಡ್ ಅನ್ನು ಮತ್ತೊಂದು ಡಿಸ್ಕ್ಗೆ ಸರಿಸಲು ಬಯಸಿದರೆ, ಡೇಟಾ ಕಳೆದುಹೋಗುತ್ತದೆ.
ಈ ವಿಧಾನವು ಪರೀಕ್ಷೆಗಳಿಗೆ ಒಳ್ಳೆಯದು, ಏಕೆಂದರೆ ಇದು ಈಗಾಗಲೇ ಸಾಮಾನ್ಯ ವೇಗವನ್ನು ತೋರಿಸುತ್ತದೆ, ಆದರೆ ಗಂಭೀರವಾದ ಏನಾದರೂ ಈ ಆಯ್ಕೆಯು ಸೂಕ್ತವಲ್ಲ.
ಆದ್ದರಿಂದ ಎರಡನೇ ವಿಧಾನವಿದೆ. ಇದು ಹೋಸ್ಟ್‌ಪಾತ್ ಆಗಿದೆ. ನೀವು ಹಿಂದಿನ ಸ್ಲೈಡ್ ಮತ್ತು ಇದನ್ನು ನೋಡಿದರೆ, ನೀವು ಒಂದೇ ಒಂದು ವ್ಯತ್ಯಾಸವನ್ನು ನೋಡಬಹುದು. ನಮ್ಮ ಫೋಲ್ಡರ್ ಡಾಕರ್‌ನಿಂದ ನೇರವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ನೋಡ್‌ಗೆ ಸರಿಸಲಾಗಿದೆ. ಇಲ್ಲಿ ಸ್ವಲ್ಪ ಸರಳವಾಗಿದೆ. ನಾವು ನಮ್ಮ ಡೇಟಾವನ್ನು ಸಂಗ್ರಹಿಸಲು ಬಯಸುವ ಸ್ಥಳೀಯ ಫೈಲ್ ಸಿಸ್ಟಮ್‌ನಲ್ಲಿ ನಾವು ನೇರವಾಗಿ ಮಾರ್ಗವನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ.
ಈ ವಿಧಾನವು ಪ್ರಯೋಜನಗಳನ್ನು ಹೊಂದಿದೆ. ಇದು ಈಗಾಗಲೇ ನಿಜವಾದ ನಿರಂತರವಾಗಿದೆ ಮತ್ತು ಅದರಲ್ಲಿ ಕ್ಲಾಸಿಕ್ ಆಗಿದೆ. ನಾವು ಕೆಲವು ವಿಳಾಸದಲ್ಲಿ ಡಿಸ್ಕ್ನಲ್ಲಿ ದಾಖಲಾದ ಡೇಟಾವನ್ನು ಹೊಂದಿದ್ದೇವೆ.
ಅನಾನುಕೂಲಗಳೂ ಇವೆ. ಇದು ನಿರ್ವಹಣೆಯ ಸಂಕೀರ್ಣತೆಯಾಗಿದೆ. ನಮ್ಮ ಕುಬರ್ನೆಟ್‌ಗಳು ಪಾಡ್ ಅನ್ನು ಮತ್ತೊಂದು ಭೌತಿಕ ನೋಡ್‌ಗೆ ಸರಿಸಲು ಬಯಸಬಹುದು. ಮತ್ತು ಇಲ್ಲಿಯೇ DevOps ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ. ಈ ಪಾಡ್ಗಳನ್ನು ನೀವು ಈ ಮಾರ್ಗಗಳಲ್ಲಿ ಏನನ್ನಾದರೂ ಜೋಡಿಸಿರುವ ಆ ನೋಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ಸರಿಸಬಹುದು ಮತ್ತು ಒಂದು ಸಮಯದಲ್ಲಿ ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು ನೋಡ್‌ಗಳಿಲ್ಲ ಎಂದು ಅವರು ಸಂಪೂರ್ಣ ಸಿಸ್ಟಮ್‌ಗೆ ಸರಿಯಾಗಿ ವಿವರಿಸಬೇಕು. ಇದು ಸಾಕಷ್ಟು ಕಷ್ಟ.
ವಿಶೇಷವಾಗಿ ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ಈ ಎಲ್ಲಾ ಸಂಕೀರ್ಣತೆಯನ್ನು ಮರೆಮಾಡಲು ನಾವು ನಮ್ಮ ಆಪರೇಟರ್‌ನಲ್ಲಿ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಮಾಡಿದ್ದೇವೆ. ಮತ್ತು ನೀವು ಸರಳವಾಗಿ ಹೇಳಬಹುದು: "ನಾನು ಪ್ರತಿ ಭೌತಿಕ ನೋಡ್‌ಗೆ ಮತ್ತು ಅಂತಹ ಮಾರ್ಗದಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಒಂದು ನಿದರ್ಶನವನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತೇನೆ."
ಆದರೆ ಈ ಅಗತ್ಯವು ನಮಗೆ ಮಾತ್ರ ಅಗತ್ಯವಿಲ್ಲ, ಆದ್ದರಿಂದ ಕುಬರ್ನೆಟ್ಸ್ನ ಮಹನೀಯರು ಸಹ ಜನರು ಭೌತಿಕ ಡಿಸ್ಕ್ಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಲು ಬಯಸುತ್ತಾರೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಅವರು ಮೂರನೇ ಪದರವನ್ನು ಒದಗಿಸುತ್ತಾರೆ.
ಇದನ್ನು ಸ್ಥಳೀಯ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ಹಿಂದಿನ ಸ್ಲೈಡ್‌ನಿಂದ ಪ್ರಾಯೋಗಿಕವಾಗಿ ಯಾವುದೇ ವ್ಯತ್ಯಾಸವಿಲ್ಲ. ನಾವು ಈ ಪಾಡ್ಗಳನ್ನು ನೋಡ್‌ನಿಂದ ನೋಡ್‌ಗೆ ವರ್ಗಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ಹಸ್ತಚಾಲಿತವಾಗಿ ದೃಢೀಕರಿಸುವ ಅಗತ್ಯವಿತ್ತು, ಏಕೆಂದರೆ ಅವುಗಳನ್ನು ಕೆಲವು ಮಾರ್ಗದಲ್ಲಿ ಸ್ಥಳೀಯ ಭೌತಿಕ ಡಿಸ್ಕ್ಗೆ ಲಗತ್ತಿಸಬೇಕು, ಆದರೆ ಈಗ ಈ ಎಲ್ಲಾ ಜ್ಞಾನವು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿಯೇ ಆವರಿಸಲ್ಪಟ್ಟಿದೆ. ಮತ್ತು ಅದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಲು ಹೆಚ್ಚು ಸುಲಭವಾಗುತ್ತದೆ.
ನಮ್ಮ ಪ್ರಾಯೋಗಿಕ ಸಮಸ್ಯೆಗೆ ಹಿಂತಿರುಗಿ ನೋಡೋಣ. YAML ಟೆಂಪ್ಲೇಟ್‌ಗೆ ಹಿಂತಿರುಗೋಣ. ಇಲ್ಲಿ ನಾವು ನಿಜವಾದ ಸಂಗ್ರಹವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಾವು ಅದಕ್ಕೆ ಹಿಂತಿರುಗಿದ್ದೇವೆ. ನಾವು k8s ನಲ್ಲಿರುವಂತೆ ಕ್ಲಾಸಿಕ್ VolumeClaim ಟೆಂಪ್ಲೇಟ್ ಅನ್ನು ಹೊಂದಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಮಗೆ ಯಾವ ರೀತಿಯ ಸಂಗ್ರಹಣೆ ಬೇಕು ಎಂದು ನಾವು ವಿವರಿಸುತ್ತೇವೆ.
ಇದರ ನಂತರ, k8s ಸಂಗ್ರಹಣೆಯನ್ನು ವಿನಂತಿಸುತ್ತದೆ. ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ನಲ್ಲಿ ನಮಗೆ ಅದನ್ನು ನಿಯೋಜಿಸುತ್ತದೆ. ಮತ್ತು ಕೊನೆಯಲ್ಲಿ ಇದು ClickHouse ವಿಲೇವಾರಿ ಇರುತ್ತದೆ.
ನಾವು ಈ ಯೋಜನೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ. ನಮ್ಮ ಪರ್ಸಿಸ್ಟೆಂಟ್ ಸ್ಟೋರೇಜ್ ಕೆಂಪು ಬಣ್ಣದ್ದಾಗಿತ್ತು, ಇದನ್ನು ಮಾಡಬೇಕಾಗಿದೆ ಎಂದು ಸುಳಿವು ನೀಡುವಂತೆ ತೋರುತ್ತಿದೆ.
ಮತ್ತು ಅದು ಹಸಿರು ಬಣ್ಣಕ್ಕೆ ತಿರುಗುತ್ತದೆ. ಈಗ ಕ್ಲಿಕ್ಹೌಸ್ ಆನ್ k8s ಕ್ಲಸ್ಟರ್ ಸ್ಕೀಮ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಅಂತಿಮಗೊಳಿಸಲಾಗಿದೆ. ನಾವು ಚೂರುಗಳು, ಪ್ರತಿಕೃತಿಗಳು, ZooKeeper ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ನಾವು ನಿಜವಾದ ನಿರಂತರತೆಯನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದನ್ನು ಒಂದು ರೀತಿಯಲ್ಲಿ ಅಥವಾ ಇನ್ನೊಂದರಲ್ಲಿ ಅಳವಡಿಸಲಾಗಿದೆ. ಯೋಜನೆಯು ಈಗಾಗಲೇ ಸಂಪೂರ್ಣವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ.
ನಾವು ಬದುಕುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ. ಮತ್ತು ಅಲೆಕ್ಸಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪ್ರಯತ್ನಿಸುತ್ತಾನೆ ಮತ್ತು ಬಿಡುಗಡೆ ಮಾಡುತ್ತಾನೆ.
ಪ್ರಾಯೋಗಿಕ ಕಾರ್ಯವು ಉದ್ಭವಿಸುತ್ತದೆ - ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಪರೀಕ್ಷಿಸಲು. ಮತ್ತು, ಸ್ವಾಭಾವಿಕವಾಗಿ, ನೀವು ಎಲ್ಲವನ್ನೂ ಹೊರತೆಗೆಯಲು ಬಯಸುವುದಿಲ್ಲ; ನೀವು ಎಲ್ಲೋ ದೂರದ ಮೂಲೆಯಲ್ಲಿ ಒಂದು ಪ್ರತಿಕೃತಿಯಲ್ಲಿ ಹೊಸ ಆವೃತ್ತಿಯನ್ನು ಹಾಕಲು ಬಯಸುತ್ತೀರಿ, ಮತ್ತು ಬಹುಶಃ ಒಂದು ಹೊಸ ಆವೃತ್ತಿಯಲ್ಲ, ಆದರೆ ಒಂದೇ ಬಾರಿಗೆ ಎರಡು, ಏಕೆಂದರೆ ಅವುಗಳು ಆಗಾಗ್ಗೆ ಹೊರಬರುತ್ತವೆ.
ಇದರ ಬಗ್ಗೆ ನಾವು ಏನು ಹೇಳಬಹುದು?
ಇಲ್ಲಿ ನಮಗೆ ಅಂತಹ ಅವಕಾಶವಿದೆ. ಇವು ಪಾಡ್ ಟೆಂಪ್ಲೆಟ್ಗಳಾಗಿವೆ. ವೈವಿಧ್ಯಮಯ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿರ್ಮಿಸಲು ನಮ್ಮ ಆಪರೇಟರ್ ನಿಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ಅನುಮತಿಸುತ್ತದೆ ಎಂದು ನೀವು ಬರೆಯಬಹುದು. ಆ. ಕಾನ್ಫಿಗರ್ ಮಾಡಿ, ಗುಂಪಿನಲ್ಲಿರುವ ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಪ್ರತಿ ವೈಯಕ್ತಿಕ ಪ್ರತಿಕೃತಿಯೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ, ನಾವು ಕ್ಲಿಕ್ಹೌಸ್ ಯಾವ ಆವೃತ್ತಿಯನ್ನು ಬಯಸುತ್ತೇವೆ, ಯಾವ ಆವೃತ್ತಿಯು ನಮಗೆ ಸಂಗ್ರಹಣೆ ಬೇಕು. ನಮಗೆ ಅಗತ್ಯವಿರುವ ಸಂರಚನೆಯೊಂದಿಗೆ ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಬಹುದು.
ಒಳಗೆ ಸ್ವಲ್ಪ ಆಳಕ್ಕೆ ಹೋಗೋಣ. ಇದಕ್ಕೂ ಮೊದಲು, ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ನಿಶ್ಚಿತಗಳಿಗೆ ಸಂಬಂಧಿಸಿದಂತೆ ಕ್ಲಿಕ್ಹೌಸ್-ಆಪರೇಟರ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾವು ಮಾತನಾಡಿದ್ದೇವೆ.
ಈಗ ನಾನು ಯಾವುದೇ ಆಪರೇಟರ್ ಸಾಮಾನ್ಯವಾಗಿ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಕೆಲವು ಪದಗಳನ್ನು ಹೇಳಲು ಬಯಸುತ್ತೇನೆ, ಹಾಗೆಯೇ ಅದು K8 ಗಳೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ.
K8s ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುವುದನ್ನು ಮೊದಲು ನೋಡೋಣ. ನಾವು kubectl ಅನ್ನು ಅನ್ವಯಿಸಿದಾಗ ಏನಾಗುತ್ತದೆ? ನಮ್ಮ ವಸ್ತುಗಳು API ಮೂಲಕ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತವೆ.
ಉದಾಹರಣೆಗೆ, ಮೂಲ ಕುಬರ್ನೆಟ್ ವಸ್ತುಗಳು: ಪಾಡ್, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್, ಸೇವೆ, ಮತ್ತು ಹೀಗೆ ಪಟ್ಟಿಯ ಕೆಳಗೆ.
ಅದೇ ಸಮಯದಲ್ಲಿ, ಇನ್ನೂ ಭೌತಿಕ ಏನೂ ಆಗುವುದಿಲ್ಲ. ಈ ವಸ್ತುಗಳು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಸ್ತುವಾಗಬೇಕು.
ಈ ಉದ್ದೇಶಕ್ಕಾಗಿ, ನಿಯಂತ್ರಕ ಕಾಣಿಸಿಕೊಳ್ಳುತ್ತದೆ. ನಿಯಂತ್ರಕವು ವಿಶೇಷ k8s ಘಟಕವಾಗಿದ್ದು ಅದು ಈ ವಿವರಣೆಗಳನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುತ್ತದೆ. ದೈಹಿಕವಾಗಿ ಹೇಗೆ ಮತ್ತು ಏನು ಮಾಡಬೇಕೆಂದು ಅವನಿಗೆ ತಿಳಿದಿದೆ. ಕಂಟೇನರ್‌ಗಳನ್ನು ಹೇಗೆ ಚಲಾಯಿಸಬೇಕು, ಸರ್ವರ್ ಕೆಲಸ ಮಾಡಲು ಅಲ್ಲಿ ಏನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕೆಂದು ಅವನಿಗೆ ತಿಳಿದಿದೆ.
ಮತ್ತು ಇದು K8 ಗಳಲ್ಲಿ ನಮ್ಮ ವಸ್ತುಗಳನ್ನು ವಸ್ತುವಾಗಿಸುತ್ತದೆ.
ಆದರೆ ನಾವು ಪಾಡ್‌ಗಳು ಮತ್ತು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳೊಂದಿಗೆ ಮಾತ್ರ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಬಯಸುತ್ತೇವೆ, ನಾವು ಕ್ಲಿಕ್ಹೌಸ್ ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಅನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ, ಅಂದರೆ ಕ್ಲಿಕ್ಹೌಸ್ ಪ್ರಕಾರದ ವಸ್ತು, ಅದರೊಂದಿಗೆ ಒಟ್ಟಾರೆಯಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸಲು. ಇಲ್ಲಿಯವರೆಗೆ ಅಂತಹ ಯಾವುದೇ ಸಾಧ್ಯತೆ ಇಲ್ಲ.
ಆದರೆ K8s ಕೆಳಗಿನ ಉತ್ತಮವಾದ ವಿಷಯವನ್ನು ಹೊಂದಿದೆ. ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪಾಡ್‌ಗಳು ಮತ್ತು ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ನಿಂದ ಜೋಡಿಸಲಾದ ಈ ಸಂಕೀರ್ಣ ಘಟಕದಂತಹ ಎಲ್ಲೋ ನಾವು ಹೊಂದಬೇಕೆಂದು ನಾವು ಬಯಸುತ್ತೇವೆ.
ಮತ್ತು ಇದಕ್ಕಾಗಿ ಏನು ಮಾಡಬೇಕು? ಮೊದಲಿಗೆ, ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನವು ಚಿತ್ರದಲ್ಲಿ ಬರುತ್ತದೆ. ಅದು ಏನು? ಇದು K8s ಗಾಗಿ ವಿವರಣೆಯಾಗಿದೆ, ನೀವು ಇನ್ನೊಂದು ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಹೊಂದಿರುವಿರಿ, ನಾವು ಪಾಡ್‌ಗೆ ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲವನ್ನು ಸೇರಿಸಲು ಬಯಸುತ್ತೇವೆ, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್, ಇದು ಒಳಗೆ ಸಂಕೀರ್ಣವಾಗಿರುತ್ತದೆ. ಇದು ಡೇಟಾ ರಚನೆಯ ವಿವರಣೆಯಾಗಿದೆ.
ನಾವು ಅದನ್ನು kubectl apply ಮೂಲಕ ಅಲ್ಲಿಗೆ ಕಳುಹಿಸುತ್ತೇವೆ. ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಸಂತೋಷದಿಂದ ತೆಗೆದುಕೊಂಡರು.
ಮತ್ತು ಈಗ ನಮ್ಮ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ, etcd ನಲ್ಲಿರುವ ವಸ್ತುವು ClickHouseInstallation ಎಂಬ ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲವನ್ನು ರೆಕಾರ್ಡ್ ಮಾಡಲು ಅವಕಾಶವನ್ನು ಹೊಂದಿದೆ.
ಆದರೆ ಸದ್ಯಕ್ಕೆ ಮುಂದೆ ಏನೂ ಆಗುವುದಿಲ್ಲ. ಅಂದರೆ, ನಾವು ಈಗ ಚೂರುಗಳು ಮತ್ತು ಪ್ರತಿಕೃತಿಗಳನ್ನು ವಿವರಿಸುವ YAML ಫೈಲ್ ಅನ್ನು ರಚಿಸಿದರೆ ಮತ್ತು "kubectl ಅನ್ವಯಿಸು" ಎಂದು ಹೇಳಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ಅದನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ, ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಇರಿಸಿ ಮತ್ತು ಹೇಳುತ್ತಾರೆ: "ಅದ್ಭುತ, ಆದರೆ ನನಗೆ ಏನು ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲ. ಅದರೊಂದಿಗೆ. ClickHouseInstallation ಅನ್ನು ಹೇಗೆ ನಿರ್ವಹಿಸುವುದು ಎಂದು ನನಗೆ ಗೊತ್ತಿಲ್ಲ.
ಅಂತೆಯೇ, ಕುಬರ್ನೆಟ್ಸ್ ಹೊಸ ಡೇಟಾ ಪ್ರಕಾರವನ್ನು ಪೂರೈಸಲು ನಮಗೆ ಯಾರಾದರೂ ಸಹಾಯ ಮಾಡಬೇಕಾಗಿದೆ. ಎಡಭಾಗದಲ್ಲಿ ನಾವು ಸ್ಥಳೀಯ ಡೇಟಾ ಪ್ರಕಾರಗಳೊಂದಿಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಸ್ಥಳೀಯ ಕುಬರ್ನೆಟ್ಸ್ ನಿಯಂತ್ರಕವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಮತ್ತು ಬಲಭಾಗದಲ್ಲಿ ನಾವು ಕಸ್ಟಮ್ ಡೇಟಾ ಪ್ರಕಾರಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಕಸ್ಟಮ್ ನಿಯಂತ್ರಕವನ್ನು ಹೊಂದಿರಬೇಕು.
ಮತ್ತು ಇನ್ನೊಂದು ರೀತಿಯಲ್ಲಿ ಇದನ್ನು ಆಪರೇಟರ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನಾನು ಇದನ್ನು ನಿರ್ದಿಷ್ಟವಾಗಿ ಇಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಎಂದು ಸೇರಿಸಿದ್ದೇನೆ, ಏಕೆಂದರೆ ಇದನ್ನು K8s ಹೊರಗೆ ಸಹ ಕಾರ್ಯಗತಗೊಳಿಸಬಹುದು. ಹೆಚ್ಚಾಗಿ, ಸಹಜವಾಗಿ, ಎಲ್ಲಾ ನಿರ್ವಾಹಕರನ್ನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕಾರ್ಯಗತಗೊಳಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಹೊರಗೆ ನಿಲ್ಲುವುದನ್ನು ಏನೂ ತಡೆಯುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಇಲ್ಲಿ ಅದನ್ನು ವಿಶೇಷವಾಗಿ ಹೊರಗೆ ಸ್ಥಳಾಂತರಿಸಲಾಗುತ್ತದೆ.
ಮತ್ತು ಪ್ರತಿಯಾಗಿ, ಆಪರೇಟರ್ ಎಂದೂ ಕರೆಯಲ್ಪಡುವ ಕಸ್ಟಮ್ ನಿಯಂತ್ರಕ, API ಮೂಲಕ ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. API ನೊಂದಿಗೆ ಹೇಗೆ ಸಂವಹನ ನಡೆಸಬೇಕೆಂದು ಇದು ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಮತ್ತು ನಾವು ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲದಿಂದ ಮಾಡಲು ಬಯಸುವ ಸಂಕೀರ್ಣ ಸರ್ಕ್ಯೂಟ್ ಅನ್ನು ಹೇಗೆ ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುವುದು ಎಂದು ಅವರಿಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಆಪರೇಟರ್ ನಿಖರವಾಗಿ ಏನು ಮಾಡುತ್ತಾನೆ.
ಆಪರೇಟರ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ? ಅವನು ಅದನ್ನು ಹೇಗೆ ಮಾಡುತ್ತಾನೆ ಎಂಬುದನ್ನು ನೋಡಲು ಬಲಭಾಗವನ್ನು ನೋಡೋಣ. ಆಪರೇಟರ್ ಈ ಎಲ್ಲವನ್ನು ಹೇಗೆ ಕಾರ್ಯರೂಪಕ್ಕೆ ತರುತ್ತದೆ ಮತ್ತು K8 ಗಳೊಂದಿಗಿನ ಮತ್ತಷ್ಟು ಸಂವಹನವು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಕಂಡುಹಿಡಿಯೋಣ.
ಆಪರೇಟರ್ ಒಂದು ಪ್ರೋಗ್ರಾಂ ಆಗಿದೆ. ಅವಳು ಈವೆಂಟ್-ಆಧಾರಿತಳು. ಕುಬರ್ನೆಟ್ಸ್ API ಬಳಸಿಕೊಂಡು ಈವೆಂಟ್‌ಗಳಿಗೆ ಆಪರೇಟರ್ ಚಂದಾದಾರರಾಗುತ್ತಾರೆ. ಕುಬರ್ನೆಟ್ಸ್ API ಪ್ರವೇಶ ಬಿಂದುಗಳನ್ನು ಹೊಂದಿದೆ, ಅಲ್ಲಿ ನೀವು ಈವೆಂಟ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗಬಹುದು. ಮತ್ತು K8 ಗಳಲ್ಲಿ ಏನಾದರೂ ಬದಲಾದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ಎಲ್ಲರಿಗೂ ಈವೆಂಟ್‌ಗಳನ್ನು ಕಳುಹಿಸುತ್ತಾನೆ, ಅಂದರೆ. ಈ API ಪಾಯಿಂಟ್‌ಗೆ ಚಂದಾದಾರರಾಗಿರುವವರು ಅಧಿಸೂಚನೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ.
ಆಪರೇಟರ್ ಈವೆಂಟ್‌ಗಳಿಗೆ ಚಂದಾದಾರರಾಗುತ್ತಾರೆ ಮತ್ತು ಕೆಲವು ರೀತಿಯ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಮಾಡಬೇಕು. ಉದಯೋನ್ಮುಖ ಘಟನೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುವುದು ಇದರ ಕಾರ್ಯವಾಗಿದೆ.
ಕೆಲವು ನವೀಕರಣಗಳಿಂದ ಈವೆಂಟ್‌ಗಳನ್ನು ರಚಿಸಲಾಗಿದೆ. ClickHouseInstallation ನ ವಿವರಣೆಯೊಂದಿಗೆ ನಮ್ಮ YAML ಫೈಲ್ ಆಗಮಿಸುತ್ತದೆ. ಅವರು kubectl apply ಮೂಲಕ etcd ಗೆ ಹೋದರು. ಅಲ್ಲಿ ಈವೆಂಟ್ ಅನ್ನು ಪ್ರಚೋದಿಸಲಾಯಿತು ಮತ್ತು ಇದರ ಪರಿಣಾಮವಾಗಿ ಈ ಈವೆಂಟ್ ಕ್ಲಿಕ್ಹೌಸ್-ಆಪರೇಟರ್‌ಗೆ ಬಂದಿತು. ಆಪರೇಟರ್ ಈ ವಿವರಣೆಯನ್ನು ಸ್ವೀಕರಿಸಿದ್ದಾರೆ. ಮತ್ತು ಅವನು ಏನನ್ನಾದರೂ ಮಾಡಬೇಕು. ಕ್ಲಿಕ್‌ಹೌಸ್‌ಇನ್‌ಸ್ಟಾಲೇಶನ್ ಆಬ್ಜೆಕ್ಟ್‌ಗೆ ಅಪ್‌ಡೇಟ್ ಬಂದಿದ್ದರೆ, ನೀವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಅಪ್‌ಡೇಟ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನವೀಕರಿಸುವುದು ಆಪರೇಟರ್ನ ಕಾರ್ಯವಾಗಿದೆ.
ಅವನು ಏನು ಮಾಡುತ್ತಿದ್ದಾನೆ? ಮೊದಲಿಗೆ, ಈ ಅಪ್‌ಡೇಟ್‌ನೊಂದಿಗೆ ನಾವು ಏನು ಮಾಡುತ್ತೇವೆ ಎಂಬುದಕ್ಕೆ ನಾವು ಕ್ರಿಯಾ ಯೋಜನೆಯನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ. ನವೀಕರಣಗಳು ತುಂಬಾ ಚಿಕ್ಕದಾಗಿರಬಹುದು, ಅಂದರೆ. YAML ಎಕ್ಸಿಕ್ಯೂಶನ್‌ನಲ್ಲಿ ಚಿಕ್ಕದಾಗಿದೆ, ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬಹಳ ದೊಡ್ಡ ಬದಲಾವಣೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಆದ್ದರಿಂದ, ಆಪರೇಟರ್ ಯೋಜನೆಯನ್ನು ರಚಿಸುತ್ತಾನೆ, ಮತ್ತು ನಂತರ ಅವನು ಅದಕ್ಕೆ ಅಂಟಿಕೊಳ್ಳುತ್ತಾನೆ.
ಈ ಯೋಜನೆಯ ಪ್ರಕಾರ, ಪಾಡ್‌ಗಳು, ಸೇವೆಗಳನ್ನು ಕಾರ್ಯರೂಪಕ್ಕೆ ತರಲು ಅವನು ಈ ರಚನೆಯನ್ನು ಒಳಗೆ ಬೇಯಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತಾನೆ, ಅಂದರೆ. ಅವನ ಮುಖ್ಯ ಕಾರ್ಯವನ್ನು ಮಾಡಿ. ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ನಿರ್ಮಿಸುವುದು.
ಈಗ ಅಂತಹ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವನ್ನು ಸ್ಪರ್ಶಿಸೋಣ. ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಆಪರೇಟರ್ ನಡುವಿನ ಜವಾಬ್ದಾರಿಯ ವಿಭಾಗವಾಗಿದೆ, ಅಂದರೆ. ಕುಬರ್ನೆಟ್ಸ್ ಏನು ಮಾಡುತ್ತಾರೆ, ಆಪರೇಟರ್ ಏನು ಮಾಡುತ್ತಾರೆ ಮತ್ತು ಅವರು ಪರಸ್ಪರ ಹೇಗೆ ಸಂವಹನ ನಡೆಸುತ್ತಾರೆ.
ಸಿಸ್ಟಮ್ ವಿಷಯಗಳಿಗೆ ಕುಬರ್ನೆಟ್ಸ್ ಜವಾಬ್ದಾರನಾಗಿರುತ್ತಾನೆ, ಅಂದರೆ. ಸಿಸ್ಟಮ್-ಸ್ಕೋಪ್ ಎಂದು ಅರ್ಥೈಸಬಹುದಾದ ವಸ್ತುಗಳ ಮೂಲಭೂತ ಸೆಟ್ಗಾಗಿ. ಪಾಡ್ಗಳನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸುವುದು, ಕಂಟೇನರ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಹೇಗೆ, ಸಂಪುಟಗಳನ್ನು ಹೇಗೆ ಆರೋಹಿಸುವುದು, ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ನೊಂದಿಗೆ ಹೇಗೆ ಕೆಲಸ ಮಾಡುವುದು, ಅಂದರೆ ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ತಿಳಿದಿದೆ. ಎಲ್ಲವನ್ನೂ ವ್ಯವಸ್ಥೆ ಎಂದು ಕರೆಯಬಹುದು.
ನಿರ್ವಾಹಕರು ಡೊಮೇನ್‌ಗಳಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಾರೆ. ಪ್ರತಿ ಆಪರೇಟರ್ ತನ್ನದೇ ಆದ ವಿಷಯದ ಪ್ರದೇಶಕ್ಕಾಗಿ ಮಾಡಲ್ಪಟ್ಟಿದೆ. ನಾವು ಅದನ್ನು ಕ್ಲಿಕ್‌ಹೌಸ್‌ಗಾಗಿ ಮಾಡಿದ್ದೇವೆ.
ಮತ್ತು ಆಪರೇಟರ್ ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸುವುದು, ರೇಖಾಚಿತ್ರವನ್ನು ಮಾಡುವುದು, ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಹೊಂದಿಸುವುದು ಮುಂತಾದ ವಿಷಯದ ಪ್ರದೇಶದ ವಿಷಯದಲ್ಲಿ ನಿಖರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತದೆ. ಇದು ವಿಭಜನೆಗೆ ಕಾರಣವಾಗುತ್ತದೆ.
ನಾವು ಆಡ್ ಪ್ರತಿಕೃತಿ ಕ್ರಿಯೆಯನ್ನು ಮಾಡುವಾಗ ಜವಾಬ್ದಾರಿಯ ಈ ವಿಭಜನೆಯು ಹೇಗೆ ಸಂಭವಿಸುತ್ತದೆ ಎಂಬುದರ ಪ್ರಾಯೋಗಿಕ ಉದಾಹರಣೆಯನ್ನು ನೋಡೋಣ.
ಆಪರೇಟರ್ ಕಾರ್ಯವನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ - ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸಲು. ಆಪರೇಟರ್ ಏನು ಮಾಡುತ್ತಾನೆ? ಹೊಸ ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್ ಅನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ ಎಂದು ಆಪರೇಟರ್ ಲೆಕ್ಕಾಚಾರ ಮಾಡುತ್ತದೆ, ಅದರಲ್ಲಿ ಅಂತಹ ಮತ್ತು ಅಂತಹ ಟೆಂಪ್ಲೇಟ್‌ಗಳು, ವಾಲ್ಯೂಮ್ ಕ್ಲೈಮ್ ಅನ್ನು ವಿವರಿಸಬೇಕು.
ಅವನು ಎಲ್ಲವನ್ನೂ ಸಿದ್ಧಪಡಿಸಿದನು ಮತ್ತು ಅದನ್ನು K8 ಗಳಿಗೆ ರವಾನಿಸುತ್ತಾನೆ. ಅವರಿಗೆ ಕಾನ್ಫಿಗ್ಮ್ಯಾಪ್, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್, ವಾಲ್ಯೂಮ್ ಅಗತ್ಯವಿದೆ ಎಂದು ಅವರು ಹೇಳುತ್ತಾರೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದಾರೆ. ಅವನು ಕಾರ್ಯನಿರ್ವಹಿಸುವ ಮೂಲಭೂತ ಘಟಕಗಳನ್ನು ಅವನು ವಸ್ತುಗೊಳಿಸುತ್ತಾನೆ.
ತದನಂತರ ಕ್ಲಿಕ್ಹೌಸ್-ಆಪರೇಟರ್ ಮತ್ತೆ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ. ಅವರು ಈಗಾಗಲೇ ಭೌತಿಕ ಪಾಡ್ ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಅದರಲ್ಲಿ ಅವರು ಈಗಾಗಲೇ ಏನನ್ನಾದರೂ ಮಾಡಬಹುದು. ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್-ಆಪರೇಟರ್ ಮತ್ತೆ ಡೊಮೇನ್ ಪರಿಭಾಷೆಯಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ. ಆ. ನಿರ್ದಿಷ್ಟವಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್, ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸಲು, ನೀವು ಮೊದಲು, ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಡೇಟಾ ಸ್ಕೀಮಾವನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕು. ಮತ್ತು, ಎರಡನೆಯದಾಗಿ, ಈ ಪ್ರತಿಕೃತಿಯನ್ನು ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ಸೇರಿಸಬೇಕು ಇದರಿಂದ ಅದನ್ನು ಸ್ಪಷ್ಟವಾಗಿ ಪತ್ತೆಹಚ್ಚಬಹುದು. ಆಪರೇಟರ್ ಈಗಾಗಲೇ ಇದನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ.
ಮತ್ತು ಅದರ ನಂತರವೇ ಕ್ಲಿಕ್ಹೌಸ್ ಸ್ವತಃ ಕಾರ್ಯರೂಪಕ್ಕೆ ಬರುತ್ತದೆ, ಅಂದರೆ. ಮತ್ತೊಂದು ಉನ್ನತ ಮಟ್ಟದ ಘಟಕ. ಇದು ಈಗಾಗಲೇ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ. ಇದು ತನ್ನದೇ ಆದ ನಿದರ್ಶನವನ್ನು ಹೊಂದಿದೆ, ಕ್ಲಸ್ಟರ್‌ಗೆ ಸೇರಲು ಸಿದ್ಧವಾಗಿರುವ ಮತ್ತೊಂದು ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ಪ್ರತಿಕೃತಿ.
ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸುವಾಗ ಮರಣದಂಡನೆಯ ಸರಪಳಿ ಮತ್ತು ಜವಾಬ್ದಾರಿಯ ವಿಭಜನೆಯು ಸಾಕಷ್ಟು ಉದ್ದವಾಗಿದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ.
ನಾವು ನಮ್ಮ ಪ್ರಾಯೋಗಿಕ ಕಾರ್ಯಗಳನ್ನು ಮುಂದುವರಿಸುತ್ತೇವೆ. ನೀವು ಈಗಾಗಲೇ ಕ್ಲಸ್ಟರ್ ಹೊಂದಿದ್ದರೆ, ನೀವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸಬಹುದು.
ನಾವು ಇದನ್ನು ಮಾಡಿದ್ದೇವೆ ಆದ್ದರಿಂದ ನೀವು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ xml ಗೆ ಅಂಟಿಸಬಹುದು, ಅದನ್ನು ಕ್ಲಿಕ್ಹೌಸ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ.
ನೀವು ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಉತ್ತಮಗೊಳಿಸಬಹುದು. ಹೋಸ್ಟ್‌ಪಾತ್, ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯನ್ನು ವಿವರಿಸುವಾಗ ನಾನು ಮಾತನಾಡಿದ್ದು ಜಸ್ಟ್ ಝೋನ್ಡ್ ಡಿಪ್ಲಾಯ್ಮೆಂಟ್. ವಲಯದ ನಿಯೋಜನೆಯನ್ನು ಸರಿಯಾಗಿ ಮಾಡುವುದು ಹೀಗೆ.
ಮುಂದಿನ ಪ್ರಾಯೋಗಿಕ ಕಾರ್ಯವು ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿದೆ.
ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಬದಲಾದರೆ, ನಾವು ನಿಯತಕಾಲಿಕವಾಗಿ ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಬೇಕಾಗುತ್ತದೆ.
ರೇಖಾಚಿತ್ರವನ್ನು ನೋಡೋಣ. ನಾವು ಈಗಾಗಲೇ ಇಲ್ಲಿ ಹಸಿರು ಬಾಣಗಳನ್ನು ನೋಡಿದ್ದೇವೆ. ಈಗ ಕೆಂಪು ಬಾಣಗಳನ್ನು ನೋಡೋಣ. ಈ ರೀತಿ ನಾವು ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮೇಲ್ವಿಚಾರಣೆ ಮಾಡಲು ಬಯಸುತ್ತೇವೆ. ಕ್ಲಿಕ್ಹೌಸ್ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳು ಪ್ರಮೀತಿಯಸ್‌ಗೆ ಮತ್ತು ನಂತರ ಗ್ರಾಫಾನಾಗೆ ಹೇಗೆ ಬರುತ್ತವೆ.
ಮೇಲ್ವಿಚಾರಣೆಯಲ್ಲಿ ತೊಂದರೆ ಏನು? ಇದನ್ನು ಕೆಲವು ರೀತಿಯ ಸಾಧನೆ ಎಂದು ಏಕೆ ಪ್ರಸ್ತುತಪಡಿಸಲಾಗಿದೆ? ಕಷ್ಟವು ಡೈನಾಮಿಕ್ಸ್ನಲ್ಲಿದೆ. ನಾವು ಒಂದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ ಮತ್ತು ಅದು ಸ್ಥಿರವಾಗಿದ್ದರೆ, ನಾವು ಒಮ್ಮೆ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಹೊಂದಿಸಬಹುದು ಮತ್ತು ಇನ್ನು ಮುಂದೆ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ.
ಆದರೆ ನಾವು ಬಹಳಷ್ಟು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದರೆ ಅಥವಾ ಏನಾದರೂ ನಿರಂತರವಾಗಿ ಬದಲಾಗುತ್ತಿದ್ದರೆ, ಪ್ರಕ್ರಿಯೆಯು ಕ್ರಿಯಾತ್ಮಕವಾಗಿರುತ್ತದೆ. ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ನಿರಂತರವಾಗಿ ಮರುಸಂರಚಿಸುವುದು ಸಂಪನ್ಮೂಲಗಳು ಮತ್ತು ಸಮಯದ ವ್ಯರ್ಥ, ಅಂದರೆ. ಕೇವಲ ಸೋಮಾರಿತನ ಕೂಡ. ಇದನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಬೇಕಾಗಿದೆ. ತೊಂದರೆಯು ಪ್ರಕ್ರಿಯೆಯ ಡೈನಾಮಿಕ್ಸ್ನಲ್ಲಿದೆ. ಮತ್ತು ಆಪರೇಟರ್ ಇದನ್ನು ಚೆನ್ನಾಗಿ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸುತ್ತದೆ.
ನಮ್ಮ ಕ್ಲಸ್ಟರ್ ಹೇಗೆ ಅಭಿವೃದ್ಧಿ ಹೊಂದಿತು? ಆರಂಭದಲ್ಲಿ ಅವನು ಹಾಗೆ ಇದ್ದ.
ಆಗ ಅವನು ಹೀಗಿದ್ದನು.
ಕೊನೆಗೆ ಅವನು ಹೀಗೇ ಆದ.
ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯನ್ನು ಆಪರೇಟರ್ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಮಾಡಲಾಗುತ್ತದೆ. ಪ್ರವೇಶದ ಏಕ ಬಿಂದು.
ಮತ್ತು ನಿರ್ಗಮಿಸುವಾಗ ನಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನ ಜೀವನವು ಹೇಗೆ ಕುದಿಯುತ್ತಿದೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಾವು ಗ್ರಾಫನಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ನೋಡುತ್ತೇವೆ.
ಮೂಲಕ, ಗ್ರಾಫನಾ ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಅನ್ನು ನಮ್ಮ ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಮೂಲ ಕೋಡ್‌ನಲ್ಲಿ ವಿತರಿಸಲಾಗುತ್ತದೆ. ನೀವು ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಬಳಸಬಹುದು. ನಮ್ಮ DevOps ನನಗೆ ಈ ಸ್ಕ್ರೀನ್‌ಶಾಟ್ ನೀಡಿದೆ.
ನಾವು ಮುಂದೆ ಎಲ್ಲಿಗೆ ಹೋಗಲು ಬಯಸುತ್ತೇವೆ? ಇದು:
- ಪರೀಕ್ಷಾ ಯಾಂತ್ರೀಕರಣವನ್ನು ಅಭಿವೃದ್ಧಿಪಡಿಸಿ. ಮುಖ್ಯ ಕಾರ್ಯವೆಂದರೆ ಹೊಸ ಆವೃತ್ತಿಗಳ ಸ್ವಯಂಚಾಲಿತ ಪರೀಕ್ಷೆ.
- ನಾವು ನಿಜವಾಗಿಯೂ ZooKeeper ನೊಂದಿಗೆ ಏಕೀಕರಣವನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಬಯಸುತ್ತೇವೆ. ಮತ್ತು ZooKeeper-ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲು ಯೋಜನೆಗಳಿವೆ. ಆ. ZooKeeper ಗಾಗಿ ಆಪರೇಟರ್ ಅನ್ನು ಬರೆಯಲಾಗಿದೆ ಮತ್ತು ಎರಡು ಆಪರೇಟರ್‌ಗಳು ಹೆಚ್ಚು ಅನುಕೂಲಕರ ಪರಿಹಾರವನ್ನು ನಿರ್ಮಿಸಲು ಸಂಯೋಜಿಸಲು ಪ್ರಾರಂಭಿಸುವುದು ತಾರ್ಕಿಕವಾಗಿದೆ.
- ನಾವು ಹೆಚ್ಚು ಸಂಕೀರ್ಣವಾದ ಪ್ರಮುಖ ಚಿಹ್ನೆಗಳನ್ನು ಮಾಡಲು ಬಯಸುತ್ತೇವೆ.
- ನಾವು ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಆನುವಂಶಿಕತೆಯನ್ನು ಸಮೀಪಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ನಾನು ಹಸಿರು ಬಣ್ಣದಲ್ಲಿ ಹೈಲೈಟ್ ಮಾಡಿದ್ದೇನೆ - ಮುಗಿದಿದೆ, ಅಂದರೆ ಆಪರೇಟರ್ನ ಮುಂದಿನ ಬಿಡುಗಡೆಯೊಂದಿಗೆ ನಾವು ಈಗಾಗಲೇ ಟೆಂಪ್ಲೇಟ್‌ಗಳ ಉತ್ತರಾಧಿಕಾರವನ್ನು ಹೊಂದಿದ್ದೇವೆ. ತುಣುಕುಗಳಿಂದ ಸಂಕೀರ್ಣ ಸಂರಚನೆಗಳನ್ನು ನಿರ್ಮಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ಶಕ್ತಿಶಾಲಿ ಸಾಧನವಾಗಿದೆ.
- ಮತ್ತು ನಾವು ಸಂಕೀರ್ಣ ಕಾರ್ಯಗಳ ಯಾಂತ್ರೀಕರಣವನ್ನು ಬಯಸುತ್ತೇವೆ. ಮುಖ್ಯವಾದದ್ದು ಮರು-ಶರ್ಡಿಂಗ್.
ಕೆಲವು ಮಧ್ಯಂತರ ಫಲಿತಾಂಶಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ.
ಪರಿಣಾಮವಾಗಿ ನಾವು ಏನು ಪಡೆಯುತ್ತೇವೆ? ಮತ್ತು ಅದನ್ನು ಮಾಡುವುದು ಯೋಗ್ಯವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ? ಡೇಟಾಬೇಸ್ ಅನ್ನು ಕುಬರ್ನೆಟ್ಸ್‌ಗೆ ಎಳೆಯಲು ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಆಪರೇಟರ್ ಅನ್ನು ಮತ್ತು ನಿರ್ದಿಷ್ಟವಾಗಿ ಅಲಿಟ್ನಿಟಿ ಆಪರೇಟರ್ ಅನ್ನು ಬಳಸಲು ಪ್ರಯತ್ನಿಸುವುದು ಅಗತ್ಯವೇ?
ಔಟ್ಪುಟ್ನಲ್ಲಿ ನಾವು ಪಡೆಯುತ್ತೇವೆ:
- ಸಂರಚನೆ, ನಿಯೋಜನೆ ಮತ್ತು ನಿರ್ವಹಣೆಯ ಗಮನಾರ್ಹ ಸರಳೀಕರಣ ಮತ್ತು ಯಾಂತ್ರೀಕರಣ.
- ತಕ್ಷಣವೇ ಅಂತರ್ನಿರ್ಮಿತ ಮೇಲ್ವಿಚಾರಣೆ.
- ಮತ್ತು ಸಂಕೀರ್ಣ ಸನ್ನಿವೇಶಗಳಿಗಾಗಿ ಕ್ರೋಡೀಕರಿಸಿದ ಟೆಂಪ್ಲೇಟ್‌ಗಳನ್ನು ಬಳಸಲು ಸಿದ್ಧವಾಗಿದೆ. ಪ್ರತಿಕೃತಿಯನ್ನು ಸೇರಿಸುವಂತಹ ಕ್ರಿಯೆಯನ್ನು ಕೈಯಾರೆ ಮಾಡುವ ಅಗತ್ಯವಿಲ್ಲ. ಆಪರೇಟರ್ ಇದನ್ನು ಮಾಡುತ್ತಾರೆ.
ಕೊನೆಯದಾಗಿ ಒಂದೇ ಒಂದು ಪ್ರಶ್ನೆ ಉಳಿದಿದೆ. ನಾವು ಈಗಾಗಲೇ ಕುಬರ್ನೆಟ್ಸ್, ವರ್ಚುವಲೈಸೇಶನ್‌ನಲ್ಲಿ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ. ಅಂತಹ ಪರಿಹಾರದ ಕಾರ್ಯಕ್ಷಮತೆಯ ಬಗ್ಗೆ ಏನು, ವಿಶೇಷವಾಗಿ ಕ್ಲಿಕ್ಹೌಸ್ ಕಾರ್ಯಕ್ಷಮತೆಗಾಗಿ ಆಪ್ಟಿಮೈಸ್ ಮಾಡಿರುವುದರಿಂದ?
ಉತ್ತರ ಎಲ್ಲವೂ ಚೆನ್ನಾಗಿದೆ! ನಾನು ವಿವರವಾಗಿ ಹೋಗುವುದಿಲ್ಲ; ಇದು ಪ್ರತ್ಯೇಕ ವರದಿಯ ವಿಷಯವಾಗಿದೆ.
ಆದರೆ ಟಿಎಸ್ಬಿಎಸ್ನಂತಹ ಯೋಜನೆ ಇದೆ. ಅದರ ಮುಖ್ಯ ಕಾರ್ಯವೇನು? ಇದು ಡೇಟಾಬೇಸ್ ಕಾರ್ಯಕ್ಷಮತೆ ಪರೀಕ್ಷೆಯಾಗಿದೆ. ಬೆಚ್ಚಗೆ ಬೆಚ್ಚಗೆ, ಮೃದುವಾಗಿ ಮೆತ್ತಗೆ ಹೋಲಿಸುವ ಪ್ರಯತ್ನವಿದು.
ಅವನು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತಾನೆ? ಒಂದು ಡೇಟಾ ಸೆಟ್ ಅನ್ನು ರಚಿಸಲಾಗಿದೆ. ನಂತರ ಈ ಡೇಟಾದ ಸೆಟ್ ಅನ್ನು ಒಂದೇ ರೀತಿಯ ಪರೀಕ್ಷೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ವಿವಿಧ ಡೇಟಾಬೇಸ್‌ಗಳಲ್ಲಿ ರನ್ ಮಾಡಲಾಗುತ್ತದೆ. ಮತ್ತು ಪ್ರತಿ ಡೇಟಾಬೇಸ್ ಹೇಗೆ ತಿಳಿದಿರುವ ರೀತಿಯಲ್ಲಿ ಒಂದು ಸಮಸ್ಯೆಯನ್ನು ಪರಿಹರಿಸುತ್ತದೆ. ತದನಂತರ ನೀವು ಫಲಿತಾಂಶಗಳನ್ನು ಹೋಲಿಸಬಹುದು.
ಇದು ಈಗಾಗಲೇ ಡೇಟಾಬೇಸ್‌ಗಳ ದೊಡ್ಡ ಗುಂಪನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ. ನಾನು ಮೂರು ಮುಖ್ಯವಾದವುಗಳನ್ನು ಗುರುತಿಸಿದ್ದೇನೆ. ಇದು:
- ಟೈಮ್ಸ್ಕೇಲ್DB.
- InfluxDB.
- ಕ್ಲಿಕ್ಹೌಸ್.
ಇದೇ ರೀತಿಯ ಮತ್ತೊಂದು ಪರಿಹಾರದೊಂದಿಗೆ ಹೋಲಿಕೆಯನ್ನು ಸಹ ಮಾಡಲಾಗಿದೆ. ರೆಡ್‌ಶಿಫ್ಟ್‌ನೊಂದಿಗೆ ಹೋಲಿಕೆ. ಅಮೆಜಾನ್‌ನಲ್ಲಿ ಹೋಲಿಕೆ ಮಾಡಲಾಗಿದೆ. ಕ್ಲಿಕ್ಹೌಸ್ ಕೂಡ ಈ ವಿಷಯದಲ್ಲಿ ಎಲ್ಲರಿಗಿಂತ ಮುಂದಿದೆ.
ನಾನು ಹೇಳಿದ ವಿಷಯದಿಂದ ಯಾವ ತೀರ್ಮಾನಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಬಹುದು?
- ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಡಿಬಿ ಸಾಧ್ಯ. ಬಹುಶಃ ಯಾವುದಾದರೂ ಸಾಧ್ಯ, ಆದರೆ ಒಟ್ಟಾರೆಯಾಗಿ ಅದು ಸಾಧ್ಯ ಎಂದು ತೋರುತ್ತಿದೆ. ನಮ್ಮ ಆಪರೇಟರ್ನ ಸಹಾಯದಿಂದ ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಕ್ಲಿಕ್ಹೌಸ್ ಖಂಡಿತವಾಗಿಯೂ ಸಾಧ್ಯ.
- ಆಪರೇಟರ್ ಪ್ರಕ್ರಿಯೆಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ ಮತ್ತು ನಿಜವಾಗಿಯೂ ಜೀವನವನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.
- ಕಾರ್ಯಕ್ಷಮತೆ ಸಾಮಾನ್ಯವಾಗಿದೆ.
- ಮತ್ತು ಇದನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ಬಳಸಬೇಕು ಎಂದು ನಮಗೆ ತೋರುತ್ತದೆ.
ತೆರೆದ ಮೂಲ - ನಮ್ಮೊಂದಿಗೆ ಸೇರಿ!
ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ಆಪರೇಟರ್ ಸಂಪೂರ್ಣವಾಗಿ ತೆರೆದ ಮೂಲ ಉತ್ಪನ್ನವಾಗಿದೆ, ಆದ್ದರಿಂದ ಗರಿಷ್ಠ ಸಂಖ್ಯೆಯ ಜನರು ಅದನ್ನು ಬಳಸಿದರೆ ಅದು ತುಂಬಾ ಒಳ್ಳೆಯದು. ನಮ್ಮ ಜೊತೆಗೂಡು! ನಾವು ನಿಮ್ಮೆಲ್ಲರಿಗೂ ಕಾಯುತ್ತಿದ್ದೇವೆ!
ಎಲ್ಲರಿಗೂ ಧನ್ಯವಾದಗಳು!
ಪ್ರಶ್ನೆಗಳು
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನನ್ನ ಹೆಸರು ಆಂಟನ್. ನಾನು SEMrush ನಿಂದ ಬಂದಿದ್ದೇನೆ. ಲಾಗಿಂಗ್‌ನಲ್ಲಿ ಏನಾಗಿದೆ ಎಂದು ನಾನು ಆಶ್ಚರ್ಯ ಪಡುತ್ತೇನೆ. ನಾವು ಮಾನಿಟರಿಂಗ್ ಬಗ್ಗೆ ಕೇಳುತ್ತೇವೆ, ಆದರೆ ಲಾಗಿಂಗ್ ಬಗ್ಗೆ ಏನೂ ಇಲ್ಲ, ನಾವು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಬಗ್ಗೆ ಮಾತನಾಡಿದರೆ. ಉದಾಹರಣೆಗೆ, ನಾವು ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದ್ದೇವೆ. ಮತ್ತು ನಾವು ಕೇಂದ್ರೀಕೃತ ಲಾಗಿಂಗ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ, ಪ್ರಮಾಣಿತ ವಿಧಾನಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅವುಗಳನ್ನು ಸಾಮಾನ್ಯ ರಾಶಿಯಾಗಿ ಸಂಗ್ರಹಿಸುತ್ತೇವೆ. ತದನಂತರ ಅಲ್ಲಿಂದ ನಮಗೆ ಆಸಕ್ತಿಯಿರುವ ಡೇಟಾವನ್ನು ನಾವು ಪಡೆಯುತ್ತೇವೆ.
ಒಳ್ಳೆಯ ಪ್ರಶ್ನೆ, ಅಂದರೆ ಟೊಡೊ ಪಟ್ಟಿಗೆ ಲಾಗ್ ಇನ್ ಮಾಡುವುದು. ನಮ್ಮ ಆಪರೇಟರ್ ಇದನ್ನು ಇನ್ನೂ ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಿಲ್ಲ. ಇದು ಇನ್ನೂ ಅಭಿವೃದ್ಧಿ ಹೊಂದುತ್ತಿದೆ, ಯೋಜನೆಯು ಇನ್ನೂ ಚಿಕ್ಕದಾಗಿದೆ. ಲಾಗಿಂಗ್ ಅಗತ್ಯವನ್ನು ನಾವು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇವೆ. ಇದು ಕೂಡ ಬಹಳ ಮುಖ್ಯವಾದ ವಿಷಯ. ಮತ್ತು ಇದು ಬಹುಶಃ ಮೇಲ್ವಿಚಾರಣೆಗಿಂತ ಕಡಿಮೆ ಮುಖ್ಯವಲ್ಲ. ಆದರೆ ಅನುಷ್ಠಾನದ ಪಟ್ಟಿಯಲ್ಲಿ ಮೊದಲನೆಯದು ಮೇಲ್ವಿಚಾರಣೆಯಾಗಿತ್ತು. ಲಾಗಿಂಗ್ ಇರುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಾವು ಕ್ಲಸ್ಟರ್ ಜೀವನದ ಎಲ್ಲಾ ಅಂಶಗಳನ್ನು ಸ್ವಯಂಚಾಲಿತಗೊಳಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತೇವೆ. ಆದ್ದರಿಂದ, ಉತ್ತರವು ಈ ಸಮಯದಲ್ಲಿ ಆಪರೇಟರ್, ದುರದೃಷ್ಟವಶಾತ್, ಇದನ್ನು ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ತಿಳಿದಿಲ್ಲ, ಆದರೆ ಇದು ಯೋಜನೆಗಳಲ್ಲಿದೆ, ನಾವು ಅದನ್ನು ಮಾಡುತ್ತೇವೆ. ನೀವು ಸೇರಲು ಬಯಸಿದರೆ, ದಯವಿಟ್ಟು ವಿನಂತಿಯನ್ನು ಎಳೆಯಿರಿ.
ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ನಾನು ನಿರಂತರ ಸಂಪುಟಗಳಿಗೆ ಸಂಬಂಧಿಸಿದ ಪ್ರಮಾಣಿತ ಪ್ರಶ್ನೆಯನ್ನು ಹೊಂದಿದ್ದೇನೆ. ಈ ಆಪರೇಟರ್‌ನೊಂದಿಗೆ ನಾವು ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ರಚಿಸಿದಾಗ, ನಾವು ಯಾವ ನೋಡ್‌ನಲ್ಲಿ ನಿರ್ದಿಷ್ಟ ಡಿಸ್ಕ್ ಅಥವಾ ಫೋಲ್ಡರ್ ಅನ್ನು ಲಗತ್ತಿಸಿದ್ದೇವೆ ಎಂಬುದನ್ನು ಆಪರೇಟರ್ ಹೇಗೆ ನಿರ್ಧರಿಸುತ್ತದೆ? ಡಿಸ್ಕ್ ಹೊಂದಿರುವ ಈ ನೋಡ್‌ಗಳಲ್ಲಿ ದಯವಿಟ್ಟು ನಮ್ಮ ಕ್ಲಿಕ್ಹೌಸ್ ಅನ್ನು ಇರಿಸಿ ಎಂದು ನಾವು ಮೊದಲು ಅವರಿಗೆ ವಿವರಿಸಬೇಕು?
ನಾನು ಅರ್ಥಮಾಡಿಕೊಂಡಂತೆ, ಈ ಪ್ರಶ್ನೆಯು ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯ ಮುಂದುವರಿಕೆಯಾಗಿದೆ, ವಿಶೇಷವಾಗಿ ಅದರ ಹೋಸ್ಟ್‌ಪಾತ್ ಭಾಗವಾಗಿದೆ. ಪಾಡ್ ಅನ್ನು ಅಂತಹ ಮತ್ತು ಅಂತಹ ನೋಡ್‌ನಲ್ಲಿ ಪ್ರಾರಂಭಿಸಬೇಕು ಎಂದು ಇಡೀ ಸಿಸ್ಟಮ್‌ಗೆ ವಿವರಿಸುವಂತಿದೆ, ನಾವು ಭೌತಿಕವಾಗಿ ಸಂಪರ್ಕಗೊಂಡಿರುವ ಡಿಸ್ಕ್ ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅದು ಅಂತಹ ಮತ್ತು ಅಂತಹ ಮಾರ್ಗದಲ್ಲಿ ಜೋಡಿಸಲ್ಪಟ್ಟಿದೆ. ಇದು ನಾನು ತುಂಬಾ ಮೇಲ್ನೋಟಕ್ಕೆ ಸ್ಪರ್ಶಿಸಿದ ಸಂಪೂರ್ಣ ವಿಭಾಗವಾಗಿದೆ ಏಕೆಂದರೆ ಉತ್ತರವು ಸಾಕಷ್ಟು ದೊಡ್ಡದಾಗಿದೆ.
ಸಂಕ್ಷಿಪ್ತವಾಗಿ ಇದು ಈ ರೀತಿ ಕಾಣುತ್ತದೆ. ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಾವು ಈ ಸಂಪುಟಗಳನ್ನು ಒದಗಿಸಬೇಕಾಗಿದೆ. ಈ ಸಮಯದಲ್ಲಿ, ಸ್ಥಳೀಯ ಸಂಗ್ರಹಣೆಯಲ್ಲಿ ಯಾವುದೇ ಡೈನಾಮಿಕ್ ನಿಬಂಧನೆ ಇಲ್ಲ, ಆದ್ದರಿಂದ DevOps ಡಿಸ್ಕ್ಗಳನ್ನು ಸ್ವತಃ ಕತ್ತರಿಸಬೇಕು, ಈ ಸಂಪುಟಗಳು. ಮತ್ತು ನೀವು ಅಂತಹ ಮತ್ತು ಅಂತಹ ವರ್ಗದ ನಿರಂತರ ಸಂಪುಟಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಕುಬರ್ನೆಟ್ಸ್ ಒದಗಿಸುವಿಕೆಯನ್ನು ಅವರು ವಿವರಿಸಬೇಕು, ಅದು ಅಂತಹ ಮತ್ತು ಅಂತಹ ನೋಡ್‌ಗಳಲ್ಲಿದೆ. ಅಂತಹ ಮತ್ತು ಅಂತಹ ಸ್ಥಳೀಯ ಶೇಖರಣಾ ವರ್ಗದ ಅಗತ್ಯವಿರುವ ಪಾಡ್ಗಳನ್ನು ಲೇಬಲ್ಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಂತಹ ಮತ್ತು ಅಂತಹ ನೋಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ನಿರ್ದೇಶಿಸುವ ಅಗತ್ಯವಿದೆ ಎಂದು ನೀವು ಕುಬರ್ನೆಟ್‌ಗಳಿಗೆ ವಿವರಿಸಬೇಕಾಗುತ್ತದೆ. ಈ ಉದ್ದೇಶಗಳಿಗಾಗಿ, ನಿರ್ವಾಹಕರು ಕೆಲವು ರೀತಿಯ ಲೇಬಲ್ ಅನ್ನು ನಿಯೋಜಿಸುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದ್ದಾರೆ ಮತ್ತು ಪ್ರತಿ ಹೋಸ್ಟ್ ನಿದರ್ಶನಕ್ಕೆ ಒಂದನ್ನು ನೀಡುತ್ತಾರೆ. ಮತ್ತು ಸರಳ ಪದಗಳಲ್ಲಿ ಅವಶ್ಯಕತೆಗಳು, ಲೇಬಲ್ಗಳನ್ನು ಪೂರೈಸುವ ನೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ ರನ್ ಮಾಡಲು ಪಾಡ್ಗಳನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಮೂಲಕ ರವಾನಿಸಲಾಗುತ್ತದೆ ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ನಿರ್ವಾಹಕರು ಲೇಬಲ್‌ಗಳು ಮತ್ತು ಪ್ರಾವಿಷನ್ ಡಿಸ್ಕ್ಗಳನ್ನು ಹಸ್ತಚಾಲಿತವಾಗಿ ನಿಯೋಜಿಸುತ್ತಾರೆ. ತದನಂತರ ಅದು ಮಾಪಕವಾಗುತ್ತದೆ.
ಮತ್ತು ಇದು ಮೂರನೇ ಆಯ್ಕೆಯಾಗಿದೆ, ಸ್ಥಳೀಯ, ಇದು ಸ್ವಲ್ಪ ಸುಲಭಗೊಳಿಸಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ನಾನು ಈಗಾಗಲೇ ಒತ್ತಿಹೇಳಿದಂತೆ, ಇದು ಶ್ರುತಿ ಮಾಡುವಲ್ಲಿ ಶ್ರಮದಾಯಕ ಕೆಲಸವಾಗಿದೆ, ಇದು ಅಂತಿಮವಾಗಿ ಗರಿಷ್ಠ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಪಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ.
ಇದಕ್ಕೆ ಸಂಬಂಧಿಸಿದಂತೆ ನನಗೆ ಎರಡನೇ ಪ್ರಶ್ನೆ ಇದೆ. ನಾವು ನೋಡ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತೇವೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂಬುದು ನಮಗೆ ಅಪ್ರಸ್ತುತವಾಗುವ ರೀತಿಯಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ನಮ್ಮ ಚೂರು ನೇತಾಡುವ ನೋಡ್ ಅನ್ನು ನಾವು ಕಳೆದುಕೊಂಡರೆ ಈ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಏನು ಮಾಡಬೇಕು?
ಹೌದು, ಕುಬರ್ನೆಟ್ಸ್ ಆರಂಭದಲ್ಲಿ ನಮ್ಮ ಪಾಡ್‌ಗಳೊಂದಿಗಿನ ನಮ್ಮ ಸಂಬಂಧವು ದನದಂತಿದೆ ಎಂದು ಭಾವಿಸಲಾಗಿತ್ತು, ಆದರೆ ಇಲ್ಲಿ ನಮ್ಮೊಂದಿಗೆ ಪ್ರತಿ ಡಿಸ್ಕ್ ಸಾಕುಪ್ರಾಣಿಯಂತೆ ಆಗುತ್ತದೆ. ಅಂತಹ ಸಮಸ್ಯೆ ಇದೆ, ನಾವು ಅವುಗಳನ್ನು ಎಸೆಯಲು ಸಾಧ್ಯವಿಲ್ಲ. ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ನ ಅಭಿವೃದ್ಧಿಯು ಸಂಪೂರ್ಣವಾಗಿ ತಿರಸ್ಕರಿಸಿದ ಸಂಪನ್ಮೂಲದಂತೆ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ತಾತ್ವಿಕವಾಗಿ ಪರಿಗಣಿಸುವುದು ಅಸಾಧ್ಯ ಎಂಬ ದಿಕ್ಕಿನಲ್ಲಿ ಸಾಗುತ್ತಿದೆ.
ಈಗ ಪ್ರಾಯೋಗಿಕ ಪ್ರಶ್ನೆಗೆ. ಡಿಸ್ಕ್ ಇರುವ ನೋಡ್ ಅನ್ನು ನೀವು ಕಳೆದುಕೊಂಡರೆ ಏನು ಮಾಡಬೇಕು? ಇಲ್ಲಿ ಸಮಸ್ಯೆಯನ್ನು ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಪರಿಹರಿಸಲಾಗುತ್ತಿದೆ. ಕ್ಲಿಕ್‌ಹೌಸ್‌ನ ಸಂದರ್ಭದಲ್ಲಿ, ನಾವು ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ ಕೆಲಸ ಮಾಡುವ ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಅಂದರೆ. ಕ್ಲಿಕ್ಹೌಸ್ ಮಟ್ಟದಲ್ಲಿ.
ಪರಿಣಾಮವಾಗಿ ಇತ್ಯರ್ಥವೇನು? ಡೇಟಾ ಕಳೆದುಹೋಗುವುದಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು DevOps ಕಾರಣವಾಗಿದೆ. ಅವನು ಪ್ರತಿಕೃತಿಯನ್ನು ಸರಿಯಾಗಿ ಹೊಂದಿಸಬೇಕು ಮತ್ತು ಪ್ರತಿಕೃತಿ ಚಾಲನೆಯಲ್ಲಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಬೇಕು. ಕ್ಲಿಕ್ಹೌಸ್ ಮಟ್ಟದಲ್ಲಿನ ಪ್ರತಿಕೃತಿಯು ನಕಲಿ ಡೇಟಾವನ್ನು ಹೊಂದಿರಬೇಕು. ಇದು ಆಪರೇಟರ್ ಪರಿಹರಿಸುವ ಕಾರ್ಯವಲ್ಲ. ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಸ್ವತಃ ಪರಿಹರಿಸುವ ಸಮಸ್ಯೆಯಲ್ಲ. ಇದು ಕ್ಲಿಕ್ಹೌಸ್ ಮಟ್ಟದಲ್ಲಿದೆ.
ನಿಮ್ಮ ಕಬ್ಬಿಣದ ನೋಡ್ ಬಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು? ಮತ್ತು ನೀವು ಎರಡನೆಯದನ್ನು ಸ್ಥಾಪಿಸಬೇಕು, ಅದರ ಮೇಲೆ ಡಿಸ್ಕ್ ಅನ್ನು ಸರಿಯಾಗಿ ಒದಗಿಸಬೇಕು ಮತ್ತು ಲೇಬಲ್ಗಳನ್ನು ಅನ್ವಯಿಸಬೇಕು ಎಂದು ಅದು ತಿರುಗುತ್ತದೆ. ಮತ್ತು ಅದರ ನಂತರ, ಕುಬರ್ನೆಟ್ಸ್ ಅದರ ಮೇಲೆ ನಿದರ್ಶನ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಬಹುದಾದ ಅವಶ್ಯಕತೆಗಳನ್ನು ಇದು ಪೂರೈಸುತ್ತದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಇದನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ. ನಿರ್ದಿಷ್ಟಪಡಿಸಿದ ಸಂಖ್ಯೆಯನ್ನು ಪೂರೈಸಲು ನಿಮ್ಮ ಪಾಡ್‌ಗಳ ಸಂಖ್ಯೆಯು ಸಾಕಾಗುವುದಿಲ್ಲ. ಇದು ನಾನು ತೋರಿಸಿದ ಚಕ್ರದ ಮೂಲಕ ಹೋಗುತ್ತದೆ. ಮತ್ತು ಉನ್ನತ ಮಟ್ಟದಲ್ಲಿ, ನಾವು ಪ್ರತಿಕೃತಿಯನ್ನು ನಮೂದಿಸಿದ್ದೇವೆ ಎಂದು ಕ್ಲಿಕ್ಹೌಸ್ ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ, ಅದು ಇನ್ನೂ ಖಾಲಿಯಾಗಿದೆ ಮತ್ತು ನಾವು ಅದಕ್ಕೆ ಡೇಟಾವನ್ನು ವರ್ಗಾಯಿಸಲು ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿದೆ. ಆ. ಈ ಪ್ರಕ್ರಿಯೆಯು ಇನ್ನೂ ಚೆನ್ನಾಗಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿಲ್ಲ.
ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಎಲ್ಲಾ ರೀತಿಯ ಅಸಹ್ಯ ಸಂಗತಿಗಳು ಸಂಭವಿಸಿದಾಗ, ಆಪರೇಟರ್ ಕ್ರ್ಯಾಶ್ ಆಗುತ್ತದೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಈವೆಂಟ್‌ಗಳು ಆಗಮಿಸುತ್ತವೆ, ನೀವು ಇದನ್ನು ಹೇಗಾದರೂ ನಿಭಾಯಿಸುತ್ತೀರಾ?
ಆಪರೇಟರ್ ಕ್ರ್ಯಾಶ್ ಆಗಿದ್ದರೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಿದರೆ ಏನಾಗುತ್ತದೆ, ಸರಿ?
ಹೌದು. ಮತ್ತು ಆ ಕ್ಷಣದಲ್ಲಿ ಘಟನೆಗಳು ಬಂದವು.
ಈ ಸಂದರ್ಭದಲ್ಲಿ ಏನು ಮಾಡಬೇಕೆಂಬುದನ್ನು ಆಯೋಜಕರು ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ನಡುವೆ ಭಾಗಶಃ ಹಂಚಿಕೊಳ್ಳಲಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಸಂಭವಿಸಿದ ಈವೆಂಟ್ ಅನ್ನು ರಿಪ್ಲೇ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಹೊಂದಿದೆ. ಅವನು ರಿಪ್ಲೇ ಮಾಡುತ್ತಾನೆ. ಮತ್ತು ಈವೆಂಟ್ ಲಾಗ್ ಅನ್ನು ಅವನ ಮೇಲೆ ಮರುಪ್ಲೇ ಮಾಡಿದಾಗ, ಈ ಘಟನೆಗಳು ಅಸಮರ್ಥವಾಗಿವೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಆಪರೇಟರ್ನ ಕಾರ್ಯವಾಗಿದೆ. ಮತ್ತು ಅದೇ ಘಟನೆಯ ಪುನರಾವರ್ತಿತ ಘಟನೆಯು ನಮ್ಮ ವ್ಯವಸ್ಥೆಯನ್ನು ಮುರಿಯುವುದಿಲ್ಲ. ಮತ್ತು ನಮ್ಮ ಆಪರೇಟರ್ ಈ ಕೆಲಸವನ್ನು ನಿಭಾಯಿಸುತ್ತಾನೆ.
ನಮಸ್ಕಾರ! ವರದಿಗಾಗಿ ಧನ್ಯವಾದಗಳು! ಡಿಮಿಟ್ರಿ ಜವ್ಯಾಲೋವ್, ಕಂಪನಿ ಸ್ಮೆಡೋವಾ. ಆಪರೇಟರ್‌ಗೆ ಹ್ಯಾಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಕಾನ್ಫಿಗರ್ ಮಾಡುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸಲು ಯೋಜನೆಗಳಿವೆಯೇ? ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಒಂದನ್ನು ಹೊರತುಪಡಿಸಿ ಬೇರೆ ಕೆಲವು ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳಲ್ಲಿ ನಾನು ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇನೆ, ಇದರಿಂದ ಅದು ಸ್ಮಾರ್ಟ್ ಆಗಿದೆ ಮತ್ತು ಕ್ಲಿಕ್ಹೌಸ್ ನಿಜವಾಗಿಯೂ ಇದೆ ಎಂದು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತದೆ.
ನೀವು ಪ್ರವೇಶದ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತಿದ್ದೀರಾ?
ಹೌದು, ಇನ್‌ಗ್ರೆಸ್ ಅನ್ನು ಹ್ಯಾಪ್ರಾಕ್ಸಿಯೊಂದಿಗೆ ಬದಲಾಯಿಸಿ. ಹ್ಯಾಪ್ರಾಕ್ಸಿಯಲ್ಲಿ ನೀವು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿರುವ ಕ್ಲಸ್ಟರ್‌ನ ಟೋಪೋಲಜಿಯನ್ನು ನಿರ್ದಿಷ್ಟಪಡಿಸಬಹುದು.
ನಾವು ಇನ್ನೂ ಅದರ ಬಗ್ಗೆ ಯೋಚಿಸಿಲ್ಲ. ನಿಮಗೆ ಇದು ಅಗತ್ಯವಿದ್ದರೆ ಮತ್ತು ಅದು ಏಕೆ ಬೇಕು ಎಂದು ವಿವರಿಸಿದರೆ, ಅದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ವಿಶೇಷವಾಗಿ ನೀವು ಭಾಗವಹಿಸಲು ಬಯಸಿದರೆ. ಆಯ್ಕೆಯನ್ನು ಪರಿಗಣಿಸಲು ನಾವು ಸಂತೋಷಪಡುತ್ತೇವೆ. ಚಿಕ್ಕ ಉತ್ತರವೆಂದರೆ ಇಲ್ಲ, ನಾವು ಪ್ರಸ್ತುತ ಅಂತಹ ಕಾರ್ಯವನ್ನು ಹೊಂದಿಲ್ಲ. ಸಲಹೆಗಾಗಿ ಧನ್ಯವಾದಗಳು, ನಾವು ಈ ವಿಷಯವನ್ನು ಪರಿಶೀಲಿಸುತ್ತೇವೆ. ಮತ್ತು ನೀವು ಬಳಕೆಯ ಸಂದರ್ಭವನ್ನು ವಿವರಿಸಿದರೆ ಮತ್ತು ಆಚರಣೆಯಲ್ಲಿ ಅದು ಏಕೆ ಬೇಕು, ಉದಾಹರಣೆಗೆ, GitHub ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳನ್ನು ರಚಿಸಿ, ಆಗ ಅದು ಉತ್ತಮವಾಗಿರುತ್ತದೆ.
ಈಗಾಗಲೇ.
ಫೈನ್. ಯಾವುದೇ ಸಲಹೆಗಳಿಗೆ ನಾವು ಮುಕ್ತರಾಗಿದ್ದೇವೆ. ಮತ್ತು ಹ್ಯಾಪ್ರಾಕ್ಸಿಯನ್ನು ಟೊಡೊ ಪಟ್ಟಿಗೆ ಸೇರಿಸಲಾಗಿದೆ. ಟೊಡೊ ಪಟ್ಟಿ ಬೆಳೆಯುತ್ತಿದೆ, ಇನ್ನೂ ಕುಗ್ಗುತ್ತಿಲ್ಲ. ಆದರೆ ಇದು ಒಳ್ಳೆಯದು, ಇದರರ್ಥ ಉತ್ಪನ್ನವು ಬೇಡಿಕೆಯಲ್ಲಿದೆ.
ಮೂಲ: www.habr.com