ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೇಗೆ ಸಂಪರ್ಕಿಸುವುದು

ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ವಿಕ್ ಸ್ಟಾರ್ಟ್ ಸರಣಿಗೆ ಸುಸ್ವಾಗತ. ಇದು ನಾವು ಆನ್‌ಲೈನ್‌ನಲ್ಲಿ ಮತ್ತು ನಮ್ಮ ತರಬೇತಿಗಳಲ್ಲಿ ಸ್ವೀಕರಿಸುವ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ಪ್ರಶ್ನೆಗಳೊಂದಿಗೆ ನಿಯಮಿತ ಅಂಕಣವಾಗಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ತಜ್ಞರು ಉತ್ತರಿಸುತ್ತಾರೆ.

ಇಂದಿನ ತಜ್ಞ ಡೇನಿಯಲ್ ಪೋಲೆಂಚಿಕ್ (ಡೇನಿಯಲ್ ಪೋಲೆನ್ಸಿಕ್) ಡೇನಿಯಲ್ ಬೋಧಕ ಮತ್ತು ಸಾಫ್ಟ್‌ವೇರ್ ಡೆವಲಪರ್ ಆಗಿ ಕೆಲಸ ಮಾಡುತ್ತಾರೆ Learn8s.

ಮುಂದಿನ ಪೋಸ್ಟ್‌ನಲ್ಲಿ ನಿಮ್ಮ ಪ್ರಶ್ನೆಗೆ ಉತ್ತರವನ್ನು ನೀವು ಬಯಸಿದರೆ, ಇಮೇಲ್ ಮೂಲಕ ನಮ್ಮನ್ನು ಸಂಪರ್ಕಿಸಿ ಅಥವಾ Twitter: @learnk8s.

ಹಿಂದಿನ ಪೋಸ್ಟ್‌ಗಳನ್ನು ಕಳೆದುಕೊಂಡಿದ್ದೀರಾ? ಅವುಗಳನ್ನು ಇಲ್ಲಿ ಹುಡುಕಿ.

ವಿವಿಧ ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಹೇಗೆ?

ಸಂಕ್ಷಿಪ್ತವಾಗಿ: Kubefed v2 ಶೀಘ್ರದಲ್ಲೇ ಬರಲಿದೆ, ಮತ್ತು ನಾನು ಓದುವುದನ್ನು ಸಹ ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ ಸಾಗಣೆದಾರ и ಬಹು-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಯೋಜನೆ.

ಆಗಾಗ್ಗೆ, ಮೂಲಸೌಕರ್ಯವನ್ನು ವಿವಿಧ ಪ್ರದೇಶಗಳಲ್ಲಿ, ವಿಶೇಷವಾಗಿ ನಿಯಂತ್ರಿತ ಪರಿಸರದಲ್ಲಿ ಪುನರಾವರ್ತಿಸಲಾಗುತ್ತದೆ ಮತ್ತು ವಿತರಿಸಲಾಗುತ್ತದೆ.

ಒಂದು ಪ್ರದೇಶವು ಲಭ್ಯವಿಲ್ಲದಿದ್ದರೆ, ಅಡಚಣೆಗಳನ್ನು ತಪ್ಪಿಸಲು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ಮರುನಿರ್ದೇಶಿಸಲಾಗುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ, ನೀವು ಒಂದೇ ರೀತಿಯ ತಂತ್ರವನ್ನು ಬಳಸಬಹುದು ಮತ್ತು ವಿವಿಧ ಪ್ರದೇಶಗಳಲ್ಲಿ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ವಿತರಿಸಬಹುದು.

ನೀವು ಪ್ರತಿ ತಂಡ, ಪ್ರದೇಶ, ಪರಿಸರ ಅಥವಾ ಈ ಅಂಶಗಳ ಸಂಯೋಜನೆಗೆ ಒಂದು ಅಥವಾ ಹೆಚ್ಚಿನ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಬಹುದು.

ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ವಿವಿಧ ಮೋಡಗಳಲ್ಲಿ ಮತ್ತು ಆವರಣದಲ್ಲಿ ಹೋಸ್ಟ್ ಮಾಡಬಹುದು.

ಆದರೆ ಅಂತಹ ಭೌಗೋಳಿಕ ಹರಡುವಿಕೆಗಾಗಿ ನೀವು ಮೂಲಸೌಕರ್ಯವನ್ನು ಹೇಗೆ ಯೋಜಿಸುತ್ತೀರಿ?
ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಹಲವಾರು ಕ್ಲೌಡ್ ಪರಿಸರಗಳಿಗಾಗಿ ನೀವು ಒಂದು ದೊಡ್ಡ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುವ ಅಗತ್ಯವಿದೆಯೇ?
ಅಥವಾ ಅನೇಕ ಸಣ್ಣ ಸಮೂಹಗಳನ್ನು ಹೊಂದಿದ್ದೀರಾ ಮತ್ತು ಅವುಗಳನ್ನು ನಿಯಂತ್ರಿಸಲು ಮತ್ತು ಸಿಂಕ್ರೊನೈಸ್ ಮಾಡಲು ಒಂದು ಮಾರ್ಗವನ್ನು ಕಂಡುಕೊಳ್ಳುವುದೇ?

ಒಂದು ನಾಯಕತ್ವ ಕ್ಲಸ್ಟರ್

ಒಂದೇ ನೆಟ್‌ವರ್ಕ್‌ನಲ್ಲಿ ಒಂದು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ರಚಿಸುವುದು ಅಷ್ಟು ಸುಲಭವಲ್ಲ.

ನೀವು ಅಪಘಾತವನ್ನು ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ, ಕ್ಲಸ್ಟರ್ ವಿಭಾಗಗಳ ನಡುವಿನ ಸಂಪರ್ಕವು ಕಳೆದುಹೋಗಿದೆ.

ನೀವು ಒಂದು ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಹೊಂದಿದ್ದರೆ, ಅರ್ಧದಷ್ಟು ಸಂಪನ್ಮೂಲಗಳು ಹೊಸ ಆಜ್ಞೆಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಏಕೆಂದರೆ ಅವರು ಮಾಸ್ಟರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ನೀವು ಹಳೆಯ ರೂಟಿಂಗ್ ಕೋಷ್ಟಕಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ (kube-proxy ಹೊಸದನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ) ಮತ್ತು ಹೆಚ್ಚುವರಿ ಪಾಡ್‌ಗಳಿಲ್ಲ (ಕುಬೆಲೆಟ್ ನವೀಕರಣಗಳನ್ನು ವಿನಂತಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ).

ವಿಷಯಗಳನ್ನು ಇನ್ನಷ್ಟು ಹದಗೆಡಿಸಲು, ಕುಬರ್ನೆಟ್ಸ್ ನೋಡ್ ಅನ್ನು ನೋಡದಿದ್ದರೆ, ಅದು ಅನಾಥವಾಗಿದೆ ಎಂದು ಗುರುತಿಸುತ್ತದೆ ಮತ್ತು ಕಾಣೆಯಾದ ಪಾಡ್‌ಗಳನ್ನು ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ನೋಡ್‌ಗಳಿಗೆ ವಿತರಿಸುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಎರಡು ಪಟ್ಟು ಹೆಚ್ಚು ಪಾಡ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೀರಿ.

ನೀವು ಪ್ರತಿ ಪ್ರದೇಶಕ್ಕೂ ಒಂದು ಮಾಸ್ಟರ್ ಸರ್ವರ್ ಅನ್ನು ಮಾಡಿದರೆ, etcd ಡೇಟಾಬೇಸ್‌ನಲ್ಲಿ ಒಮ್ಮತದ ಅಲ್ಗಾರಿದಮ್‌ನಲ್ಲಿ ಸಮಸ್ಯೆಗಳಿರುತ್ತವೆ. (ಅಂದಾಜು ಸಂ. — ವಾಸ್ತವವಾಗಿ, etcd ಡೇಟಾಬೇಸ್ ಮಾಸ್ಟರ್ ಸರ್ವರ್‌ಗಳಲ್ಲಿ ಇರಬೇಕಾಗಿಲ್ಲ. ಅದೇ ಪ್ರದೇಶದಲ್ಲಿ ಸರ್ವರ್‌ಗಳ ಪ್ರತ್ಯೇಕ ಗುಂಪಿನಲ್ಲಿ ಇದನ್ನು ಚಲಾಯಿಸಬಹುದು. ನಿಜ, ಅದೇ ಸಮಯದಲ್ಲಿ ಕ್ಲಸ್ಟರ್ನ ವೈಫಲ್ಯದ ಹಂತವನ್ನು ಪಡೆಯುವುದು. ಆದರೆ ಬೇಗನೆ.)

ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸುತ್ತದೆ ರಾಫ್ಟ್ ಅಲ್ಗಾರಿದಮ್ಡಿಸ್ಕ್ಗೆ ಬರೆಯುವ ಮೊದಲು ಮೌಲ್ಯವನ್ನು ಮಾತುಕತೆ ಮಾಡಲು.
ಅಂದರೆ, ರಾಜ್ಯವನ್ನು ಇತ್ಯಾದಿಗಳಿಗೆ ಬರೆಯುವ ಮೊದಲು ಹೆಚ್ಚಿನ ನಿದರ್ಶನಗಳು ಒಮ್ಮತವನ್ನು ತಲುಪಬೇಕು.

ಬೇರೆ ಬೇರೆ ಪ್ರದೇಶಗಳಲ್ಲಿ ಮೂರು etcd ನಿದರ್ಶನಗಳಂತೆ ಇತ್ಯಾದಿ ಇತ್ಯಾದಿ ನಿದರ್ಶನಗಳ ನಡುವಿನ ಸುಪ್ತತೆಯು ನಾಟಕೀಯವಾಗಿ ಹೆಚ್ಚಾದರೆ, ಮೌಲ್ಯವನ್ನು ಮಾತುಕತೆ ಮಾಡಲು ಮತ್ತು ಅದನ್ನು ಡಿಸ್ಕ್‌ಗೆ ಬರೆಯಲು ಬಹಳ ಸಮಯ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.
ಇದು ಕುಬರ್ನೆಟ್ಸ್ ನಿಯಂತ್ರಕಗಳಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ.

ನಿಯಂತ್ರಕ ವ್ಯವಸ್ಥಾಪಕರಿಗೆ ಬದಲಾವಣೆಯ ಬಗ್ಗೆ ತಿಳಿಯಲು ಮತ್ತು ಡೇಟಾಬೇಸ್‌ಗೆ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ಬರೆಯಲು ಹೆಚ್ಚಿನ ಸಮಯ ಬೇಕಾಗುತ್ತದೆ.

ಮತ್ತು ಒಂದು ನಿಯಂತ್ರಕ ಇಲ್ಲದಿರುವುದರಿಂದ, ಆದರೆ ಹಲವಾರು, ಸರಣಿ ಕ್ರಿಯೆಯ ಫಲಿತಾಂಶಗಳು ಮತ್ತು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಬಹಳ ನಿಧಾನವಾಗಿ ಕೆಲಸ ಮಾಡಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

etcd ಎಷ್ಟು ಲೇಟೆನ್ಸಿ ಸೆನ್ಸಿಟಿವ್ ಆಗಿದೆ ಸಾಮಾನ್ಯ ಹಾರ್ಡ್ ಡ್ರೈವ್‌ಗಳ ಬದಲಿಗೆ SSD ಗಳನ್ನು ಬಳಸಲು ಅಧಿಕೃತ ದಸ್ತಾವೇಜನ್ನು ಶಿಫಾರಸು ಮಾಡುತ್ತದೆ.

ಒಂದೇ ಕ್ಲಸ್ಟರ್‌ಗಾಗಿ ದೊಡ್ಡ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಪ್ರಸ್ತುತ ಯಾವುದೇ ಉತ್ತಮ ಉದಾಹರಣೆಗಳಿಲ್ಲ.

ಮೂಲಭೂತವಾಗಿ, ಡೆವಲಪರ್ ಸಮುದಾಯ ಮತ್ತು SIG-ಕ್ಲಸ್ಟರ್ ಗುಂಪು ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡುವ ರೀತಿಯಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೇಗೆ ಆರ್ಕೆಸ್ಟ್ರೇಟ್ ಮಾಡಬೇಕೆಂದು ಲೆಕ್ಕಾಚಾರ ಮಾಡಲು ಪ್ರಯತ್ನಿಸುತ್ತಿದೆ.

ಆಯ್ಕೆ 1: ಕುಬೆಫೆಡ್‌ನೊಂದಿಗೆ ಕ್ಲಸ್ಟರ್ ಫೆಡರೇಶನ್

SIG-ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಅಧಿಕೃತ ಪ್ರತಿಕ್ರಿಯೆ - kubefed2, ಮೂಲ ಕ್ಯೂಬ್ ಫೆಡರೇಶನ್ ಕ್ಲೈಂಟ್ ಮತ್ತು ಆಪರೇಟರ್‌ನ ಹೊಸ ಆವೃತ್ತಿ.

ಮೊದಲ ಬಾರಿಗೆ, ನಾವು ಕ್ಯೂಬ್ ಫೆಡರೇಶನ್ ಟೂಲ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲಸ್ಟರ್‌ಗಳ ಸಂಗ್ರಹವನ್ನು ಒಂದೇ ವಸ್ತುವಾಗಿ ನಿರ್ವಹಿಸಲು ಪ್ರಯತ್ನಿಸಿದ್ದೇವೆ.

ಪ್ರಾರಂಭವು ಉತ್ತಮವಾಗಿತ್ತು, ಆದರೆ ಕೊನೆಯಲ್ಲಿ ಕುಬೆ ಫೆಡರೇಶನ್ ಎಂದಿಗೂ ಜನಪ್ರಿಯವಾಗಲಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಎಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬೆಂಬಲಿಸಲಿಲ್ಲ.

ಇದು ಫೆಡರೇಟೆಡ್ ವಿತರಣೆಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಆದರೆ ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳನ್ನು ಅಲ್ಲ, ಉದಾಹರಣೆಗೆ.
ಅಲ್ಲದೆ, ಫೆಡರೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಟಿಪ್ಪಣಿಗಳ ರೂಪದಲ್ಲಿ ರವಾನಿಸಲಾಗಿದೆ ಮತ್ತು ಅದು ಹೊಂದಿಕೊಳ್ಳುವುದಿಲ್ಲ.

ಕೇವಲ ಟಿಪ್ಪಣಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಒಕ್ಕೂಟದಲ್ಲಿ ಪ್ರತಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ಪ್ರತಿಕೃತಿ ವಿಭಜನೆಯನ್ನು ನೀವು ಹೇಗೆ ವಿವರಿಸಬಹುದು ಎಂದು ಊಹಿಸಿ.

ಇದು ಸಂಪೂರ್ಣ ಅವ್ಯವಸ್ಥೆಯಾಗಿತ್ತು.

SIG-cluster kubefed v1 ನಂತರ ಬಹಳಷ್ಟು ಕೆಲಸ ಮಾಡಿದೆ ಮತ್ತು ಸಮಸ್ಯೆಯನ್ನು ಬೇರೆ ಕೋನದಿಂದ ಸಮೀಪಿಸಲು ನಿರ್ಧರಿಸಿದೆ.

ಟಿಪ್ಪಣಿಗಳ ಬದಲಿಗೆ, ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಸ್ಥಾಪಿಸಲಾದ ನಿಯಂತ್ರಕವನ್ನು ಬಿಡುಗಡೆ ಮಾಡಲು ಅವರು ನಿರ್ಧರಿಸಿದರು. ಇದನ್ನು ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನಗಳನ್ನು (CRDs) ಬಳಸಿಕೊಂಡು ಕಸ್ಟಮೈಸ್ ಮಾಡಬಹುದು.

ಒಕ್ಕೂಟದ ಭಾಗವಾಗಿರುವ ಪ್ರತಿಯೊಂದು ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ, ನೀವು ಮೂರು ವಿಭಾಗಗಳೊಂದಿಗೆ ಕಸ್ಟಮ್ CRD ವ್ಯಾಖ್ಯಾನವನ್ನು ಹೊಂದಿರುವಿರಿ:

• ಸಂಪನ್ಮೂಲದ ಪ್ರಮಾಣಿತ ವ್ಯಾಖ್ಯಾನ, ಉದಾಹರಣೆಗೆ ನಿಯೋಜನೆ;
• ವಿಭಾಗ placement, ಫೆಡರೇಶನ್‌ನಲ್ಲಿ ಸಂಪನ್ಮೂಲವನ್ನು ಹೇಗೆ ವಿತರಿಸಲಾಗುವುದು ಎಂಬುದನ್ನು ನೀವು ಎಲ್ಲಿ ವ್ಯಾಖ್ಯಾನಿಸುತ್ತೀರಿ;
• ವಿಭಾಗ override, ನಿರ್ದಿಷ್ಟ ಸಂಪನ್ಮೂಲಕ್ಕಾಗಿ ನೀವು ನಿಯೋಜನೆಯಿಂದ ತೂಕ ಮತ್ತು ನಿಯತಾಂಕಗಳನ್ನು ಅತಿಕ್ರಮಿಸಬಹುದು.

ಪ್ಲೇಸ್‌ಮೆಂಟ್ ಮತ್ತು ಓವರ್‌ರೈಡ್ ವಿಭಾಗಗಳೊಂದಿಗೆ ಸಂಯೋಜಿತ ವಿತರಣೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ.

apiVersion: types.federation.k8s.io/v1alpha1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
            - image: nginx
              name: nginx
  placement:
    clusterNames:
      - cluster2
      - cluster1
  overrides:
    - clusterName: cluster2
      clusterOverrides:
        - path: spec.replicas
          value: 5

ನೀವು ನೋಡುವಂತೆ, ಪೂರೈಕೆಯನ್ನು ಎರಡು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ವಿತರಿಸಲಾಗುತ್ತದೆ: cluster1 и cluster2.

ಮೊದಲ ಕ್ಲಸ್ಟರ್ ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಪೂರೈಸುತ್ತದೆ, ಮತ್ತು ಎರಡನೆಯದು 5 ಕ್ಕೆ ಹೊಂದಿಸಲಾಗಿದೆ.

ಪ್ರತಿಕೃತಿಗಳ ಸಂಖ್ಯೆಯ ಮೇಲೆ ನಿಮಗೆ ಹೆಚ್ಚಿನ ನಿಯಂತ್ರಣ ಅಗತ್ಯವಿದ್ದರೆ, kubefed2 ಪ್ರತಿಕೃತಿಗಳನ್ನು ತೂಕ ಮಾಡಬಹುದಾದ ಹೊಸ ReplicaSchedulingPreference ಆಬ್ಜೆಕ್ಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ:

apiVersion: scheduling.federation.k8s.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-ns
spec:
  targetKind: FederatedDeployment
  totalReplicas: 9
  clusters:
    A:
      weight: 1
    B:
      weight: 2

CRD ರಚನೆ ಮತ್ತು API ಇನ್ನೂ ಸಿದ್ಧವಾಗಿಲ್ಲ, ಮತ್ತು ಅಧಿಕೃತ ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಯಲ್ಲಿ ಸಕ್ರಿಯ ಕೆಲಸ ನಡೆಯುತ್ತಿದೆ.

Kubefed2 ಮೇಲೆ ಕಣ್ಣಿಡಿ, ಆದರೆ ಇದು ಉತ್ಪಾದನೆಗೆ ಇನ್ನೂ ಸೂಕ್ತವಲ್ಲ ಎಂದು ನೆನಪಿಡಿ.

kubefed2 ಕುರಿತು ಇನ್ನಷ್ಟು ತಿಳಿಯಿರಿ kubefed2 ಬಗ್ಗೆ ಅಧಿಕೃತ ಲೇಖನ ಕುಬರ್ನೆಟ್ಸ್ ಮತ್ತು ಇನ್ ಬಗ್ಗೆ ಬ್ಲಾಗ್‌ನಲ್ಲಿ ಕುಬೆಫೆಡ್ ಯೋಜನೆಯ ಅಧಿಕೃತ ಭಂಡಾರ.

ಆಯ್ಕೆ 2: Booking.com ಶೈಲಿಯಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಸಂಯೋಜಿಸುವುದು

Booking.com ನ ಡೆವಲಪರ್‌ಗಳು kubefed v2 ನಲ್ಲಿ ಕೆಲಸ ಮಾಡಲಿಲ್ಲ, ಆದರೆ ಅವರು ಶಿಪ್ಪರ್‌ನೊಂದಿಗೆ ಬಂದರು - ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ, ಹಲವಾರು ಪ್ರದೇಶಗಳಲ್ಲಿ ಮತ್ತು ಹಲವಾರು ಮೋಡಗಳಲ್ಲಿ ವಿತರಣೆಗಾಗಿ ಆಪರೇಟರ್.

ಸಾಗಣೆದಾರ kubefed2 ಗೆ ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಹೋಲುತ್ತದೆ.

ಎರಡೂ ಪರಿಕರಗಳು ನಿಮ್ಮ ಬಹು-ಕ್ಲಸ್ಟರ್ ನಿಯೋಜನೆ ತಂತ್ರವನ್ನು ಕಸ್ಟಮೈಸ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ (ಯಾವ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಬಳಸಲಾಗುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿವೆ).

ಆದರೆ ವಿತರಣೆಯ ಸಮಯದಲ್ಲಿ ದೋಷಗಳ ಅಪಾಯವನ್ನು ಕಡಿಮೆ ಮಾಡುವುದು ಸಾಗಣೆದಾರರ ಗುರಿಯಾಗಿದೆ.

ಶಿಪ್ಪರ್‌ನಲ್ಲಿ, ಹಿಂದಿನ ಮತ್ತು ಪ್ರಸ್ತುತ ನಿಯೋಜನೆ ಮತ್ತು ಒಳಬರುವ ದಟ್ಟಣೆಯ ಪರಿಮಾಣದ ನಡುವಿನ ಪ್ರತಿಕೃತಿಗಳ ವಿಭಜನೆಯನ್ನು ವಿವರಿಸುವ ಹಂತಗಳ ಸರಣಿಯನ್ನು ನೀವು ವ್ಯಾಖ್ಯಾನಿಸಬಹುದು.

ನೀವು ಕ್ಲಸ್ಟರ್‌ಗೆ ಸಂಪನ್ಮೂಲವನ್ನು ತಳ್ಳಿದಾಗ, ಸಾಗಣೆದಾರ ನಿಯಂತ್ರಕವು ಸೇರ್ಪಡೆಗೊಂಡ ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್‌ಗಳಾದ್ಯಂತ ಬದಲಾವಣೆಯನ್ನು ಹೆಚ್ಚಿಸುತ್ತದೆ.

ಅಲ್ಲದೆ, ಸಾಗಣೆದಾರ ಬಹಳ ಸೀಮಿತವಾಗಿದೆ.

ಉದಾಹರಣೆಗೆ, ಇದು ಹೆಲ್ಮ್ ಚಾರ್ಟ್‌ಗಳನ್ನು ಇನ್‌ಪುಟ್ ಆಗಿ ಸ್ವೀಕರಿಸುತ್ತದೆ ಮತ್ತು ವೆನಿಲ್ಲಾ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬೆಂಬಲಿಸುವುದಿಲ್ಲ.
ಸಾಮಾನ್ಯ ಪರಿಭಾಷೆಯಲ್ಲಿ, ಶಿಪ್ಪರ್ ಈ ರೀತಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಪ್ರಮಾಣಿತ ವಿತರಣೆಯ ಬದಲಿಗೆ, ನೀವು ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಅನ್ನು ಒಳಗೊಂಡಿರುವ ಅಪ್ಲಿಕೇಶನ್ ಸಂಪನ್ಮೂಲವನ್ನು ರಚಿಸಬೇಕಾಗಿದೆ:

apiVersion: shipper.booking.com/v1alpha1
kind: Application
metadata:
  name: super-server
spec:
  revisionHistoryLimit: 3
  template:
    chart:
      name: nginx
      repoUrl: https://storage.googleapis.com/shipper-demo
      version: 0.0.1
    clusterRequirements:
      regions:
        - name: local
    strategy:
      steps:
        - capacity:
            contender: 1
            incumbent: 100
          name: staging
          traffic:
            contender: 0
            incumbent: 100
        - capacity:
            contender: 100
            incumbent: 0
          name: full on
          traffic:
            contender: 100
            incumbent: 0
    values:
      replicaCount: 3

ಬಹು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ನಿರ್ವಹಿಸಲು ಶಿಪ್ಪರ್ ಉತ್ತಮ ಆಯ್ಕೆಯಾಗಿದೆ, ಆದರೆ ಹೆಲ್ಮ್‌ನೊಂದಿಗೆ ಅದರ ನಿಕಟ ಸಂಬಂಧವು ಮಾತ್ರ ದಾರಿಯಲ್ಲಿ ಸಿಗುತ್ತದೆ.

ನಾವೆಲ್ಲರೂ ಹೆಲ್ಮ್‌ನಿಂದ ಬದಲಾಯಿಸಿದರೆ ಏನು ಕಸ್ಟಮೈಸ್ ಮಾಡಿ ಅಥವಾ ಕಪಿಟನ್?

ರಲ್ಲಿ ಶಿಪ್ಪರ್ ಮತ್ತು ಅದರ ತತ್ವಶಾಸ್ತ್ರದ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಿ ಈ ಅಧಿಕೃತ ಪತ್ರಿಕಾ ಪ್ರಕಟಣೆ.

ನೀವು ಕೋಡ್ ಅನ್ನು ಅಗೆಯಲು ಬಯಸಿದರೆ, ಅಧಿಕೃತ ಪ್ರಾಜೆಕ್ಟ್ ರೆಪೊಸಿಟರಿಗೆ ಹೋಗಿ.

ಆಯ್ಕೆ 3: "ಮ್ಯಾಜಿಕ್" ಕ್ಲಸ್ಟರ್ ವಿಲೀನಗೊಳಿಸುವಿಕೆ

Kubefed v2 ಮತ್ತು ಶಿಪ್ಪರ್ ಕ್ಲಸ್ಟರ್ ಫೆಡರೇಶನ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ, ಕಸ್ಟಮ್ ಸಂಪನ್ಮೂಲ ವ್ಯಾಖ್ಯಾನದ ಮೂಲಕ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ಹೊಸ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಒದಗಿಸುತ್ತವೆ.

ಆದರೆ ನೀವು ವಿಲೀನಗೊಳ್ಳಲು ಎಲ್ಲಾ ವಿತರಣೆಗಳು, ಸ್ಟೇಟ್‌ಫುಲ್‌ಸೆಟ್‌ಗಳು, ಡೇಮನ್‌ಸೆಟ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ಪುನಃ ಬರೆಯಲು ಬಯಸದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು?

YAML ಅನ್ನು ಬದಲಾಯಿಸದೆ ಫೆಡರೇಶನ್‌ನಲ್ಲಿ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ಸೇರಿಸುವುದು?

ಬಹು-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಒಂದು ಅಡ್ಮಿರಾಲಿಟಿ ಯೋಜನೆಯಾಗಿದೆ, ಇದು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಕೆಲಸದ ಹೊರೆಗಳನ್ನು ನಿಗದಿಪಡಿಸುವುದರೊಂದಿಗೆ ವ್ಯವಹರಿಸುತ್ತದೆ.

ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಮತ್ತು ಕಸ್ಟಮ್ ವ್ಯಾಖ್ಯಾನಗಳಲ್ಲಿ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಸುತ್ತುವ ಹೊಸ ಮಾರ್ಗದೊಂದಿಗೆ ಬರುವ ಬದಲು, ಮಲ್ಟಿ-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಅನ್ನು ಪ್ರಮಾಣಿತ ಕುಬರ್ನೆಟ್ಸ್ ಜೀವನಚಕ್ರದಲ್ಲಿ ಎಂಬೆಡ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಪಾಡ್‌ಗಳನ್ನು ರಚಿಸುವ ಎಲ್ಲಾ ಕರೆಗಳನ್ನು ಪ್ರತಿಬಂಧಿಸುತ್ತದೆ.

ಪ್ರತಿ ರಚಿಸಲಾದ ಪಾಡ್ ಅನ್ನು ತಕ್ಷಣವೇ ನಕಲಿನೊಂದಿಗೆ ಬದಲಾಯಿಸಲಾಗುತ್ತದೆ.

ಬಹು-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಬಳಕೆಗಳು ಪ್ರವೇಶ ಮಾರ್ಪಾಡುಗಾಗಿ ವೆಬ್‌ಹೂಕ್ಸ್ಕರೆಯನ್ನು ಪ್ರತಿಬಂಧಿಸಲು ಮತ್ತು ಐಡಲ್ ಡಮ್ಮಿ ಪಾಡ್ ಅನ್ನು ರಚಿಸಲು.

ಮೂಲ ಪಾಡ್ ಮತ್ತೊಂದು ಯೋಜನಾ ಚಕ್ರದ ಮೂಲಕ ಹೋಗುತ್ತದೆ, ಅಲ್ಲಿ ಸಂಪೂರ್ಣ ಒಕ್ಕೂಟವನ್ನು ಮತದಾನ ಮಾಡಿದ ನಂತರ, ಉದ್ಯೋಗ ನಿರ್ಧಾರವನ್ನು ತೆಗೆದುಕೊಳ್ಳಲಾಗುತ್ತದೆ.

ಅಂತಿಮವಾಗಿ, ಪಾಡ್ ಅನ್ನು ಗುರಿ ಕ್ಲಸ್ಟರ್‌ಗೆ ತಲುಪಿಸಲಾಗುತ್ತದೆ.

ಪರಿಣಾಮವಾಗಿ, ನೀವು ಹೆಚ್ಚುವರಿ ಪಾಡ್ ಅನ್ನು ಹೊಂದಿದ್ದೀರಿ ಅದು ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ, ಕೇವಲ ಜಾಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ.

ಅನುಕೂಲವೆಂದರೆ ನೀವು ಸರಬರಾಜುಗಳನ್ನು ಸಂಯೋಜಿಸಲು ಹೊಸ ಸಂಪನ್ಮೂಲಗಳನ್ನು ಬರೆಯಬೇಕಾಗಿಲ್ಲ.

ಪಾಡ್ ಅನ್ನು ರಚಿಸುವ ಪ್ರತಿಯೊಂದು ಸಂಪನ್ಮೂಲವು ಸ್ವಯಂಚಾಲಿತವಾಗಿ ವಿಲೀನಗೊಳ್ಳಲು ಸಿದ್ಧವಾಗಿದೆ.

ಇದು ಆಸಕ್ತಿದಾಯಕವಾಗಿದೆ, ಏಕೆಂದರೆ ಇದ್ದಕ್ಕಿದ್ದಂತೆ ನೀವು ಹಲವಾರು ಪ್ರದೇಶಗಳಲ್ಲಿ ಸರಬರಾಜುಗಳನ್ನು ವಿತರಿಸಿದ್ದೀರಿ ಮತ್ತು ನೀವು ಗಮನಿಸಲಿಲ್ಲ. ಆದಾಗ್ಯೂ, ಇದು ಸಾಕಷ್ಟು ಅಪಾಯಕಾರಿಯಾಗಿದೆ, ಏಕೆಂದರೆ ಇಲ್ಲಿ ಎಲ್ಲವೂ ಮ್ಯಾಜಿಕ್ ಮೇಲೆ ನಿಂತಿದೆ.

ಆದರೆ ಸಾಗಣೆದಾರರು ಹೆಚ್ಚಾಗಿ ವಿತರಣೆಗಳ ಪ್ರಭಾವವನ್ನು ತಗ್ಗಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವಾಗ, ಬಹು-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಹೆಚ್ಚು ಸಾಮಾನ್ಯ ಕಾರ್ಯಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ ಮತ್ತು ಬಹುಶಃ ಬ್ಯಾಚ್ ಉದ್ಯೋಗಗಳಿಗೆ ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.

ಇದು ಸುಧಾರಿತ ಕ್ರಮೇಣ ವಿತರಣಾ ಕಾರ್ಯವಿಧಾನವನ್ನು ಹೊಂದಿಲ್ಲ.

ಬಹು-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಕುರಿತು ಹೆಚ್ಚಿನದನ್ನು ಇಲ್ಲಿ ಕಾಣಬಹುದು ಅಧಿಕೃತ ರೆಪೊಸಿಟರಿ ಪುಟ.

ನೀವು ಕ್ರಿಯೆಯಲ್ಲಿ ಮಲ್ಟಿ-ಕ್ಲಸ್ಟರ್-ಶೆಡ್ಯೂಲರ್ ಬಗ್ಗೆ ಓದಲು ಬಯಸಿದರೆ, ಅಡ್ಮಿರಾಲ್ಟಿ ಹೊಂದಿದೆ ಆರ್ಗೋ ಜೊತೆಗಿನ ಆಸಕ್ತಿದಾಯಕ ಬಳಕೆಯ ಪ್ರಕರಣ - ಕೆಲಸದ ಹರಿವುಗಳು, ಘಟನೆಗಳು, CI ಮತ್ತು CD ಕುಬರ್ನೆಟ್ಸ್.

ಇತರ ಉಪಕರಣಗಳು ಮತ್ತು ಪರಿಹಾರಗಳು

ಬಹು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವುದು ಮತ್ತು ನಿರ್ವಹಿಸುವುದು ಒಂದು ಸಂಕೀರ್ಣ ಕಾರ್ಯವಾಗಿದೆ ಮತ್ತು ಸಾರ್ವತ್ರಿಕ ಪರಿಹಾರವಿಲ್ಲ.

ನೀವು ಈ ವಿಷಯವನ್ನು ಮತ್ತಷ್ಟು ಅನ್ವೇಷಿಸಲು ಬಯಸಿದರೆ, ಇಲ್ಲಿ ಕೆಲವು ಸಂಪನ್ಮೂಲಗಳಿವೆ:

• ರಾಂಚರ್ ಅವರಿಂದ ಜಲಾಂತರ್ಗಾಮಿ ವಿವಿಧ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳ ಓವರ್‌ಲೇ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸುವ ಸಾಧನವಾಗಿದೆ.
• ಚಿಲ್ಲರೆ ಸರಪಳಿ ಟಾರ್ಗೆಟ್ ಬಳಕೆಗಳು ಯುನಿಮ್ಯಾಟ್ರಿಕ್ಸ್ ಅನೇಕ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ನಿಯೋಜನೆಯನ್ನು ಸಂಘಟಿಸಲು ಸ್ಪಿನ್ನಕರ್‌ನೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟಿದೆ.
• IPV6 ಮತ್ತು ಬಳಸಲು ಪ್ರಯತ್ನಿಸಿ ಹಲವಾರು ಪ್ರದೇಶಗಳಲ್ಲಿ ಒಂದೇ ನೆಟ್ವರ್ಕ್.
• ನೀವು ಸೇವಾ ಜಾಲರಿಯನ್ನು ಬಳಸಬಹುದು, ಉದಾಹರಣೆಗೆ ಬಹು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಸಂಪರ್ಕಿಸಲು ಇಸ್ಟಿಯೊ.
• Cilium, ಕಂಟೈನರ್ ನೆಟ್ವರ್ಕ್ ಇಂಟರ್ಫೇಸ್ ಪ್ಲಗಿನ್, ನೀಡುತ್ತದೆ ಕ್ಲಸ್ಟರ್ ಮೆಶ್ ಕಾರ್ಯ, ಇದು ಹಲವಾರು ಕ್ಲಸ್ಟರ್ಗಳನ್ನು ಸಂಯೋಜಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ

ಇವತ್ತಿಗೂ ಅಷ್ಟೆ

ಕೊನೆಯವರೆಗೂ ಓದಿದ್ದಕ್ಕಾಗಿ ಧನ್ಯವಾದಗಳು!

ಬಹು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೆಚ್ಚು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ಸಂಪರ್ಕಿಸುವುದು ಹೇಗೆ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನಮಗೆ ಹೇಳು.

ನಾವು ನಿಮ್ಮ ವಿಧಾನವನ್ನು ಲಿಂಕ್‌ಗಳಿಗೆ ಸೇರಿಸುತ್ತೇವೆ.

ಕ್ರಿಸ್ ನೆಸ್ಬಿಟ್-ಸ್ಮಿತ್ ಅವರಿಗೆ ವಿಶೇಷ ಧನ್ಯವಾದಗಳು (ಕ್ರಿಸ್ ನೆಸ್ಬಿಟ್-ಸ್ಮಿತ್) ಮತ್ತು ವಿನ್ಸೆಂಟ್ ಡಿ ಸ್ಮೆ (ವಿನ್ಸೆಂಟ್ ಡಿ ಸ್ಮೆಟ್) (ವಿಶ್ವಾಸಾರ್ಹ ಇಂಜಿನಿಯರ್ swatmobile.io) ಲೇಖನವನ್ನು ಓದಲು ಮತ್ತು ಫೆಡರೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ಉಪಯುಕ್ತ ಮಾಹಿತಿಯನ್ನು ಹಂಚಿಕೊಳ್ಳಲು.

ಮೂಲ: www.habr.com