🥇ಇತ್ಯಾದಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೇರವಾಗಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ನಮ್ಮ ಅನುಭವ (K8s API ಇಲ್ಲದೆ)

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

ಉದಾಹರಣೆಗೆ, ನಿಮ್ಮ ಸ್ಥಳೀಯ ಯಂತ್ರದಿಂದ ಸೇವೆಗೆ ಸಂಪರ್ಕಿಸುವ ಅವಶ್ಯಕತೆಯಿದೆ memcached.staging.svc.cluster.local. ಕ್ಲೈಂಟ್ ಸಂಪರ್ಕಿಸುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ VPN ಅನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ಈ ಸಾಮರ್ಥ್ಯವನ್ನು ಒದಗಿಸುತ್ತೇವೆ. ಇದನ್ನು ಮಾಡಲು, ನಾವು ಪಾಡ್‌ಗಳು, ಸೇವೆಗಳ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಘೋಷಿಸುತ್ತೇವೆ ಮತ್ತು ಕ್ಲೈಂಟ್‌ಗೆ ಕ್ಲಸ್ಟರ್ DNS ಅನ್ನು ತಳ್ಳುತ್ತೇವೆ. ಹೀಗಾಗಿ, ಕ್ಲೈಂಟ್ ಸೇವೆಗೆ ಸಂಪರ್ಕಿಸಲು ಪ್ರಯತ್ನಿಸಿದಾಗ memcached.staging.svc.cluster.local, ವಿನಂತಿಯು ಕ್ಲಸ್ಟರ್ DNS ಗೆ ಹೋಗುತ್ತದೆ ಮತ್ತು ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಕ್ಲಸ್ಟರ್ ಸೇವಾ ನೆಟ್ವರ್ಕ್ ಅಥವಾ ಪಾಡ್ ವಿಳಾಸದಿಂದ ಈ ಸೇವೆಯ ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ.

ಡೀಫಾಲ್ಟ್ ಸೇವಾ ಸಬ್‌ನೆಟ್ ಇರುವಲ್ಲಿ ನಾವು kubeadm ಅನ್ನು ಬಳಸಿಕೊಂಡು K8s ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತೇವೆ 192.168.0.0/16, ಮತ್ತು ಪಾಡ್ಗಳ ನೆಟ್ವರ್ಕ್ ಆಗಿದೆ 10.244.0.0/16. ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವೂ ಉತ್ತಮವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ, ಆದರೆ ಒಂದೆರಡು ಅಂಶಗಳಿವೆ:

ಸಬ್ನೆಟ್ 192.168.*.* ಸಾಮಾನ್ಯವಾಗಿ ಕ್ಲೈಂಟ್ ಆಫೀಸ್ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಮತ್ತು ಡೆವಲಪರ್ ಹೋಮ್ ನೆಟ್ವರ್ಕ್ಗಳಲ್ಲಿ ಹೆಚ್ಚಾಗಿ ಬಳಸಲಾಗುತ್ತದೆ. ತದನಂತರ ನಾವು ಸಂಘರ್ಷಗಳನ್ನು ಪಡೆಯುತ್ತೇವೆ: ಹೋಮ್ ರೂಟರ್‌ಗಳು ಈ ಸಬ್‌ನೆಟ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತವೆ ಮತ್ತು VPN ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಕ್ಲೈಂಟ್‌ಗೆ ಈ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ತಳ್ಳುತ್ತದೆ.
ನಾವು ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ (ಉತ್ಪಾದನೆ, ಹಂತ ಮತ್ತು/ಅಥವಾ ಹಲವಾರು ದೇವ್ ಕ್ಲಸ್ಟರ್‌ಗಳು). ನಂತರ, ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಎಲ್ಲಾ ಪಾಡ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳಿಗೆ ಒಂದೇ ರೀತಿಯ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತದೆ, ಇದು ಹಲವಾರು ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಸೇವೆಗಳೊಂದಿಗೆ ಏಕಕಾಲಿಕ ಕೆಲಸಕ್ಕಾಗಿ ದೊಡ್ಡ ತೊಂದರೆಗಳನ್ನು ಸೃಷ್ಟಿಸುತ್ತದೆ.

ಒಂದೇ ಯೋಜನೆಯೊಳಗೆ ಸೇವೆಗಳು ಮತ್ತು ಪಾಡ್‌ಗಳಿಗಾಗಿ ವಿಭಿನ್ನ ಸಬ್‌ನೆಟ್‌ಗಳನ್ನು ಬಳಸುವ ಅಭ್ಯಾಸವನ್ನು ನಾವು ಬಹಳ ಹಿಂದೆಯೇ ಅಳವಡಿಸಿಕೊಂಡಿದ್ದೇವೆ - ಸಾಮಾನ್ಯವಾಗಿ, ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್‌ಗಳು ವಿಭಿನ್ನ ನೆಟ್‌ವರ್ಕ್‌ಗಳನ್ನು ಹೊಂದಿರುತ್ತವೆ. ಆದಾಗ್ಯೂ, ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕ್ಲಸ್ಟರ್‌ಗಳು ಕಾರ್ಯಾಚರಣೆಯಲ್ಲಿವೆ, ಅವುಗಳು ಮೊದಲಿನಿಂದ ಉರುಳಲು ಇಷ್ಟಪಡುವುದಿಲ್ಲ, ಏಕೆಂದರೆ ಅವುಗಳು ಅನೇಕ ಸೇವೆಗಳು, ಸ್ಟೇಟ್‌ಫುಲ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇತ್ಯಾದಿಗಳನ್ನು ನಡೆಸುತ್ತವೆ.

ತದನಂತರ ನಾವು ನಮ್ಮನ್ನು ಕೇಳಿಕೊಂಡೆವು: ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಸಬ್‌ನೆಟ್ ಅನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುವುದು?

ನಿರ್ಧಾರಗಳ ಹುಡುಕಾಟ

ಮರುಸೃಷ್ಟಿ ಮಾಡುವುದು ಸಾಮಾನ್ಯ ಅಭ್ಯಾಸ ಎಲ್ಲಾ ClusterIP ಪ್ರಕಾರದ ಸೇವೆಗಳು. ಒಂದು ಆಯ್ಕೆಯಾಗಿ, ಸಲಹೆ ನೀಡಬಹುದು ಮತ್ತು ಇದು:

ಕೆಳಗಿನ ಪ್ರಕ್ರಿಯೆಯು ಸಮಸ್ಯೆಯನ್ನು ಹೊಂದಿದೆ: ಎಲ್ಲವನ್ನೂ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ ನಂತರ, ಪಾಡ್‌ಗಳು ಹಳೆಯ IP ಯೊಂದಿಗೆ DNS ನೇಮ್‌ಸರ್ವರ್‌ನಂತೆ /etc/resolv.conf ನಲ್ಲಿ ಬರುತ್ತವೆ.
ನಾನು ಇನ್ನೂ ಪರಿಹಾರವನ್ನು ಕಂಡುಕೊಳ್ಳದ ಕಾರಣ, ನಾನು ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್ ಅನ್ನು kubeadm ಮರುಹೊಂದಿಸುವಿಕೆಯೊಂದಿಗೆ ಮರುಹೊಂದಿಸಬೇಕಾಗಿತ್ತು ಮತ್ತು ಅದನ್ನು ಮತ್ತೆ ಪ್ರಾರಂಭಿಸಬೇಕಾಗಿತ್ತು.

ಆದರೆ ಇದು ಎಲ್ಲರಿಗೂ ಸೂಕ್ತವಲ್ಲ... ನಮ್ಮ ಪ್ರಕರಣಕ್ಕೆ ಹೆಚ್ಚು ವಿವರವಾದ ಪರಿಚಯಗಳು ಇಲ್ಲಿವೆ:

ಫ್ಲಾನೆಲ್ ಅನ್ನು ಬಳಸಲಾಗುತ್ತದೆ;
ಮೋಡಗಳಲ್ಲಿ ಮತ್ತು ಹಾರ್ಡ್‌ವೇರ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಗಳಿವೆ;
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಎಲ್ಲಾ ಸೇವೆಗಳನ್ನು ಮರು ನಿಯೋಜಿಸುವುದನ್ನು ತಪ್ಪಿಸಲು ನಾನು ಬಯಸುತ್ತೇನೆ;
ಕನಿಷ್ಠ ಸಂಖ್ಯೆಯ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಸಾಮಾನ್ಯವಾಗಿ ಎಲ್ಲವನ್ನೂ ಮಾಡುವ ಅವಶ್ಯಕತೆಯಿದೆ;
ಕುಬರ್ನೆಟ್ಸ್ ಆವೃತ್ತಿಯು 1.16.6 ಆಗಿದೆ (ಆದಾಗ್ಯೂ, ಮುಂದಿನ ಹಂತಗಳು ಇತರ ಆವೃತ್ತಿಗಳಿಗೆ ಹೋಲುತ್ತವೆ);
ಸೇವೆಯ ಸಬ್‌ನೆಟ್‌ನೊಂದಿಗೆ kubeadm ಅನ್ನು ಬಳಸಿಕೊಂಡು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಿಯೋಜಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳುವುದು ಮುಖ್ಯ ಕಾರ್ಯವಾಗಿದೆ 192.168.0.0/16, ಅದನ್ನು ಬದಲಾಯಿಸಿ 172.24.0.0/16.

ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಏನು ಮತ್ತು ಹೇಗೆ ಸಂಗ್ರಹಿಸಲಾಗಿದೆ, ಅದರೊಂದಿಗೆ ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನೋಡಲು ನಾವು ಬಹಳ ಹಿಂದಿನಿಂದಲೂ ಆಸಕ್ತಿ ಹೊಂದಿದ್ದೇವೆ ... ಆದ್ದರಿಂದ ನಾವು ಯೋಚಿಸಿದ್ದೇವೆ: "ಹಳೆಯ IP ವಿಳಾಸಗಳನ್ನು (ಸಬ್‌ನೆಟ್) ಹೊಸದರೊಂದಿಗೆ ಬದಲಿಸಿ, ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಏಕೆ ನವೀಕರಿಸಬಾರದು? "

ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಸಿದ್ಧ ಸಾಧನಗಳನ್ನು ಹುಡುಕಿದಾಗ, ಸಮಸ್ಯೆಯನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಪರಿಹರಿಸುವ ಯಾವುದನ್ನೂ ನಾವು ಕಂಡುಹಿಡಿಯಲಿಲ್ಲ. (ಅಂದಹಾಗೆ, ಇತ್ಯಾದಿಗಳಲ್ಲಿ ನೇರವಾಗಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಯಾವುದೇ ಉಪಯುಕ್ತತೆಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ತಿಳಿದಿದ್ದರೆ, ನಾವು ಲಿಂಕ್‌ಗಳನ್ನು ಪ್ರಶಂಸಿಸುತ್ತೇವೆ.) ಆದಾಗ್ಯೂ, ಉತ್ತಮ ಆರಂಭದ ಹಂತವಾಗಿದೆ ಇತ್ಯಾದಿ ಸಹಾಯಕ OpenShift ನಿಂದ (ಅದರ ಲೇಖಕರಿಗೆ ಧನ್ಯವಾದಗಳು!).

ಈ ಸೌಲಭ್ಯವು ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಬಳಸಿಕೊಂಡು etcd ಗೆ ಸಂಪರ್ಕಿಸಬಹುದು ಮತ್ತು ಆಜ್ಞೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಅಲ್ಲಿಂದ ಡೇಟಾವನ್ನು ಓದಬಹುದು ls, get, dump.

ಇತ್ಯಾದಿ ಸಹಾಯಕವನ್ನು ಸೇರಿಸಿ

ಮುಂದಿನ ಆಲೋಚನೆಯು ತಾರ್ಕಿಕವಾಗಿದೆ: "ಇತ್ಯಾದಿಗಳಿಗೆ ಡೇಟಾವನ್ನು ಬರೆಯುವ ಸಾಮರ್ಥ್ಯವನ್ನು ಸೇರಿಸುವ ಮೂಲಕ ಈ ಉಪಯುಕ್ತತೆಯನ್ನು ಸೇರಿಸುವುದರಿಂದ ನಿಮ್ಮನ್ನು ತಡೆಯುವುದು ಯಾವುದು?"

ಇದು ಎರಡು ಹೊಸ ಕಾರ್ಯಗಳೊಂದಿಗೆ etcdhelper ನ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯಾಗಿದೆ changeServiceCIDR и changePodCIDR. ಅವಳ ಮೇಲೆ ನೀವು ಕೋಡ್ ಅನ್ನು ನೋಡಬಹುದು ಇಲ್ಲಿ.

ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳು ಏನು ಮಾಡುತ್ತವೆ? ಅಲ್ಗಾರಿದಮ್ changeServiceCIDR:

ಒಂದು deserializer ರಚಿಸಿ;
CIDR ಅನ್ನು ಬದಲಿಸಲು ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಕಂಪೈಲ್ ಮಾಡಿ;
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕ್ಲಸ್ಟರ್‌ಐಪಿ ಪ್ರಕಾರದೊಂದಿಗೆ ನಾವು ಎಲ್ಲಾ ಸೇವೆಗಳ ಮೂಲಕ ಹೋಗುತ್ತೇವೆ:
- ಇತ್ಯಾದಿ ಮೌಲ್ಯವನ್ನು ಗೋ ವಸ್ತುವಾಗಿ ಡಿಕೋಡ್ ಮಾಡಿ;
- ನಿಯಮಿತ ಅಭಿವ್ಯಕ್ತಿಯನ್ನು ಬಳಸಿಕೊಂಡು ನಾವು ವಿಳಾಸದ ಮೊದಲ ಎರಡು ಬೈಟ್‌ಗಳನ್ನು ಬದಲಾಯಿಸುತ್ತೇವೆ;
- ಹೊಸ ಸಬ್‌ನೆಟ್‌ನಿಂದ ಸೇವೆಗೆ IP ವಿಳಾಸವನ್ನು ನಿಯೋಜಿಸಿ;
- ಧಾರಾವಾಹಿಯನ್ನು ರಚಿಸಿ, Go ವಸ್ತುವನ್ನು ಪ್ರೋಟೋಬಫ್ ಆಗಿ ಪರಿವರ್ತಿಸಿ, ಇತ್ಯಾದಿಗಳಿಗೆ ಹೊಸ ಡೇಟಾವನ್ನು ಬರೆಯಿರಿ.

ಕಾರ್ಯ changePodCIDR ಮೂಲಭೂತವಾಗಿ ಹೋಲುತ್ತದೆ changeServiceCIDR - ಸೇವೆಯ ವಿವರಣೆಯನ್ನು ಸಂಪಾದಿಸುವ ಬದಲು, ನಾವು ಅದನ್ನು ನೋಡ್ ಮತ್ತು ಬದಲಾವಣೆಗಾಗಿ ಮಾಡುತ್ತೇವೆ .spec.PodCIDR ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗೆ.

ಅಭ್ಯಾಸ

ಸೇವೆ CIDR ಅನ್ನು ಬದಲಾಯಿಸಿ

ಕಾರ್ಯವನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವ ಯೋಜನೆಯು ತುಂಬಾ ಸರಳವಾಗಿದೆ, ಆದರೆ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಎಲ್ಲಾ ಪಾಡ್‌ಗಳ ಮರು-ಸೃಷ್ಟಿಯ ಸಮಯದಲ್ಲಿ ಇದು ಅಲಭ್ಯತೆಯನ್ನು ಒಳಗೊಂಡಿರುತ್ತದೆ. ಮುಖ್ಯ ಹಂತಗಳನ್ನು ವಿವರಿಸಿದ ನಂತರ, ಸಿದ್ಧಾಂತದಲ್ಲಿ, ಈ ಅಲಭ್ಯತೆಯನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡಬಹುದು ಎಂಬುದರ ಕುರಿತು ನಾವು ಆಲೋಚನೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತೇವೆ.

ಪೂರ್ವಸಿದ್ಧತಾ ಹಂತಗಳು:

ಅಗತ್ಯ ಸಾಫ್ಟ್‌ವೇರ್ ಅನ್ನು ಸ್ಥಾಪಿಸುವುದು ಮತ್ತು ಪ್ಯಾಚ್ ಮಾಡಿದ ಇತ್ಯಾದಿ ಸಹಾಯಕವನ್ನು ಜೋಡಿಸುವುದು;
ಬ್ಯಾಕಪ್ ಇತ್ಯಾದಿ ಮತ್ತು /etc/kubernetes.

ಸೇವೆ CIDR ಅನ್ನು ಬದಲಾಯಿಸಲು ಸಂಕ್ಷಿಪ್ತ ಕ್ರಿಯಾ ಯೋಜನೆ:

ಅಪಿಸರ್ವರ್ ಮತ್ತು ನಿಯಂತ್ರಕ-ನಿರ್ವಾಹಕ ಮ್ಯಾನಿಫೆಸ್ಟ್ಗಳನ್ನು ಬದಲಾಯಿಸುವುದು;
ಪ್ರಮಾಣಪತ್ರಗಳ ಮರುಹಂಚಿಕೆ;
ಇತ್ಯಾದಿಗಳಲ್ಲಿ ClusterIP ಸೇವೆಗಳನ್ನು ಬದಲಾಯಿಸುವುದು;
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಪಾಡ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ.

ಕೆಳಗಿನವು ವಿವರವಾದ ಕ್ರಿಯೆಗಳ ಸಂಪೂರ್ಣ ಅನುಕ್ರಮವಾಗಿದೆ.

1. ಡೇಟಾ ಡಂಪ್‌ಗಾಗಿ etcd-ಕ್ಲೈಂಟ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ:

apt install etcd-client

2. ಬಿಲ್ಡ್ ಇತ್ಯಾದಿ ಸಹಾಯಕ:

ಗೋಲಾಂಗ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿ:

GOPATH=/root/golang
mkdir -p $GOPATH/local
curl -sSL https://dl.google.com/go/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH/local
echo "export GOPATH="$GOPATH"" >> ~/.bashrc
echo 'export GOROOT="$GOPATH/local/go"' >> ~/.bashrc
echo 'export PATH="$PATH:$GOPATH/local/go/bin"' >> ~/.bashrc

ನಾವು ನಮಗಾಗಿ ಉಳಿಸುತ್ತೇವೆ etcdhelper.go, ಅವಲಂಬನೆಗಳನ್ನು ಡೌನ್‌ಲೋಡ್ ಮಾಡಿ, ಸಂಗ್ರಹಿಸಿ:

wget https://raw.githubusercontent.com/flant/examples/master/2020/04-etcdhelper/etcdhelper.go
go get go.etcd.io/etcd/clientv3 k8s.io/kubectl/pkg/scheme k8s.io/apimachinery/pkg/runtime
go build -o etcdhelper etcdhelper.go

3. ಬ್ಯಾಕಪ್ ಇತ್ಯಾದಿ ಮಾಡಿ:

backup_dir=/root/backup
mkdir ${backup_dir}
cp -rL /etc/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --endpoints https://192.168.199.100:2379 snapshot save ${backup_dir}/etcd.snapshot

4. ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟ್ರೋಲ್ ಪ್ಲೇನ್ ಮ್ಯಾನಿಫೆಸ್ಟ್‌ಗಳಲ್ಲಿ ಸೇವಾ ಸಬ್‌ನೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿ. ಕಡತಗಳಲ್ಲಿ /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml ನಿಯತಾಂಕವನ್ನು ಬದಲಾಯಿಸಿ --service-cluster-ip-range ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗೆ: 172.24.0.0/16 вместо 192.168.0.0/16.

5. apiserver ಗಾಗಿ kubeadm ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೀಡುವ ಸೇವಾ ಸಬ್‌ನೆಟ್ ಅನ್ನು ನಾವು ಬದಲಾಯಿಸುತ್ತಿರುವುದರಿಂದ (ಸೇರಿದಂತೆ), ಅವುಗಳನ್ನು ಮರುಬಿಡುಗಡೆ ಮಾಡಬೇಕಾಗಿದೆ:

ಪ್ರಸ್ತುತ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಯಾವ ಡೊಮೇನ್‌ಗಳು ಮತ್ತು IP ವಿಳಾಸಗಳಿಗಾಗಿ ನೀಡಲಾಗಿದೆ ಎಂದು ನೋಡೋಣ:

openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
X509v3 Subject Alternative Name:
    DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

kubeadm ಗಾಗಿ ಕನಿಷ್ಠ ಸಂರಚನೆಯನ್ನು ಸಿದ್ಧಪಡಿಸೋಣ:

cat kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
networking:
  podSubnet: "10.244.0.0/16"
  serviceSubnet: "172.24.0.0/16"
apiServer:
  certSANs:
  - "192.168.199.100" # IP-адрес мастер узла

ಹಳೆಯ crt ಮತ್ತು ಕೀಲಿಯನ್ನು ಅಳಿಸೋಣ, ಏಕೆಂದರೆ ಇದು ಇಲ್ಲದೆ ಹೊಸ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡಲಾಗುವುದಿಲ್ಲ:
```
rm /etc/kubernetes/pki/apiserver.{key,crt}
```
API ಸರ್ವರ್‌ಗಾಗಿ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡೋಣ:
```
kubeadm init phase certs apiserver --config=kubeadm-config.yaml
```

ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗಾಗಿ ಪ್ರಮಾಣಪತ್ರವನ್ನು ನೀಡಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:

openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
X509v3 Subject Alternative Name:
    DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

API ಸರ್ವರ್ ಪ್ರಮಾಣಪತ್ರವನ್ನು ಮರು-ವಿತರಿಸಿದ ನಂತರ, ಅದರ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿ:
```
docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart
```
ಇದಕ್ಕಾಗಿ ಸಂರಚನೆಯನ್ನು ಮರುಸೃಷ್ಟಿಸೋಣ admin.conf:
```
kubeadm alpha certs renew admin.conf
```
ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಡೇಟಾವನ್ನು ಸಂಪಾದಿಸೋಣ:
```
./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-service-cidr 172.24.0.0/16 
```
ಎಚ್ಚರಿಕೆ ಈ ಕ್ಷಣದಲ್ಲಿ, ಡೊಮೇನ್ ರೆಸಲ್ಯೂಶನ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ, ಏಕೆಂದರೆ ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ಪಾಡ್‌ಗಳಲ್ಲಿ /etc/resolv.conf ಹಳೆಯ CoreDNS ವಿಳಾಸವನ್ನು (kube-dns) ನೋಂದಾಯಿಸಲಾಗಿದೆ ಮತ್ತು kube-proxy iptables ನಿಯಮಗಳನ್ನು ಹಳೆಯ ಸಬ್‌ನೆಟ್‌ನಿಂದ ಹೊಸದಕ್ಕೆ ಬದಲಾಯಿಸುತ್ತದೆ. ಲೇಖನದಲ್ಲಿ ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ಸಂಭವನೀಯ ಆಯ್ಕೆಗಳ ಬಗ್ಗೆ ಬರೆಯಲಾಗಿದೆ.
ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್ ಅನ್ನು ಸರಿಪಡಿಸೋಣ kube-system:
```
kubectl -n kube-system edit cm kubelet-config-1.16
```
- ಇಲ್ಲಿ ಬದಲಾಯಿಸಿ clusterDNS kube-dns ಸೇವೆಯ ಹೊಸ IP ವಿಳಾಸಕ್ಕೆ: kubectl -n kube-system get svc kube-dns.
```
kubectl -n kube-system edit cm kubeadm-config
```
- ನಾವು ಅದನ್ನು ಸರಿಪಡಿಸುತ್ತೇವೆ data.ClusterConfiguration.networking.serviceSubnet ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗೆ.
kube-dns ವಿಳಾಸವು ಬದಲಾಗಿರುವುದರಿಂದ, ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ kubelet ಸಂರಚನೆಯನ್ನು ನವೀಕರಿಸುವುದು ಅವಶ್ಯಕ:
```
kubeadm upgrade node phase kubelet-config && systemctl restart kubelet
```
ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಎಲ್ಲಾ ಪಾಡ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಮಾತ್ರ ಉಳಿದಿದೆ:
```
kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'
```

ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಿ

ಅಲಭ್ಯತೆಯನ್ನು ಹೇಗೆ ಕಡಿಮೆ ಮಾಡುವುದು ಎಂಬುದರ ಕುರಿತು ಆಲೋಚನೆಗಳು:

ನಿಯಂತ್ರಣ ಪ್ಲೇನ್ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಬದಲಾಯಿಸಿದ ನಂತರ, ಹೊಸ kube-dns ಸೇವೆಯನ್ನು ರಚಿಸಿ, ಉದಾಹರಣೆಗೆ, ಹೆಸರಿನೊಂದಿಗೆ kube-dns-tmp ಮತ್ತು ಹೊಸ ವಿಳಾಸ 172.24.0.10.
ಮಾಡಿ if etcdhelper ನಲ್ಲಿ, ಇದು kube-dns ಸೇವೆಯನ್ನು ಮಾರ್ಪಡಿಸುವುದಿಲ್ಲ.
ಎಲ್ಲಾ ಕುಬೆಲೆಟ್‌ಗಳಲ್ಲಿ ವಿಳಾಸವನ್ನು ಬದಲಾಯಿಸಿ ClusterDNS ಹೊಸದಕ್ಕೆ, ಹಳೆಯ ಸೇವೆಯು ಹೊಸದರೊಂದಿಗೆ ಏಕಕಾಲದಲ್ಲಿ ಕಾರ್ಯನಿರ್ವಹಿಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತದೆ.
ನೈಸರ್ಗಿಕ ಕಾರಣಗಳಿಗಾಗಿ ಅಥವಾ ಒಪ್ಪಿದ ಸಮಯದಲ್ಲಿ ಅಪ್ಲಿಕೇಶನ್‌ಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗಳು ಸ್ವತಃ ಉರುಳುವವರೆಗೆ ಕಾಯಿರಿ.
ಸೇವೆಯನ್ನು ಅಳಿಸಿ kube-dns-tmp ಮತ್ತು ಬದಲಾವಣೆ serviceSubnetCIDR kube-dns ಸೇವೆಗಾಗಿ.

ಈ ಯೋಜನೆಯು ಸೇವೆಯನ್ನು ತೆಗೆದುಹಾಕುವ ಅವಧಿಯವರೆಗೆ ~ಒಂದು ನಿಮಿಷಕ್ಕೆ ಅಲಭ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ kube-dns-tmp ಮತ್ತು ಸೇವೆಗಾಗಿ ಸಬ್ನೆಟ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು kube-dns.

ಮಾರ್ಪಾಡು ಪಾಡ್‌ನೆಟ್‌ವರ್ಕ್

ಅದೇ ಸಮಯದಲ್ಲಿ, ಫಲಿತಾಂಶದ ಇತ್ಯಾದಿಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಪಾಡ್‌ನೆಟ್‌ವರ್ಕ್ ಅನ್ನು ಹೇಗೆ ಮಾರ್ಪಡಿಸುವುದು ಎಂದು ನೋಡಲು ನಾವು ನಿರ್ಧರಿಸಿದ್ದೇವೆ. ಕ್ರಿಯೆಗಳ ಅನುಕ್ರಮವು ಈ ಕೆಳಗಿನಂತಿರುತ್ತದೆ:

ರಲ್ಲಿ ಸಂರಚನೆಗಳನ್ನು ಸರಿಪಡಿಸುವುದು kube-system;
ಕ್ಯೂಬ್-ಕಂಟ್ರೋಲರ್-ಮ್ಯಾನೇಜರ್ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಸರಿಪಡಿಸುವುದು;
ಪಾಡ್‌ಸಿಐಡಿಆರ್ ಅನ್ನು ನೇರವಾಗಿ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಬದಲಾಯಿಸಿ;
ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳನ್ನು ರೀಬೂಟ್ ಮಾಡಿ.

ಈಗ ಈ ಕ್ರಿಯೆಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು:

1. ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ಗಳನ್ನು ಮಾರ್ಪಡಿಸಿ kube-system:

kubectl -n kube-system edit cm kubeadm-config

- ಸರಿಪಡಿಸುವುದು data.ClusterConfiguration.networking.podSubnet ಹೊಸ ಸಬ್‌ನೆಟ್‌ಗೆ 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- ಸರಿಪಡಿಸುವುದು data.config.conf.clusterCIDR: 10.55.0.0/16.

2. ನಿಯಂತ್ರಕ-ನಿರ್ವಾಹಕ ಮ್ಯಾನಿಫೆಸ್ಟ್ ಅನ್ನು ಮಾರ್ಪಡಿಸಿ:

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

- ಸರಿಪಡಿಸುವುದು --cluster-cidr=10.55.0.0/16.

3. ಪ್ರಸ್ತುತ ಮೌಲ್ಯಗಳನ್ನು ನೋಡಿ .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳಿಗೆ:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. ನೇರವಾಗಿ ಇತ್ಯಾದಿಗಳಿಗೆ ಬದಲಾವಣೆಗಳನ್ನು ಮಾಡುವ ಮೂಲಕ podCIDR ಅನ್ನು ಬದಲಾಯಿಸಿ:

./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-pod-cidr 10.55.0.0/16

5. ಪಾಡ್‌ಸಿಐಡಿಆರ್ ನಿಜವಾಗಿಯೂ ಬದಲಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸೋಣ:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. ಎಲ್ಲಾ ಕ್ಲಸ್ಟರ್ ನೋಡ್‌ಗಳನ್ನು ಒಂದೊಂದಾಗಿ ರೀಬೂಟ್ ಮಾಡೋಣ.

7. ನೀವು ಕನಿಷ್ಟ ಒಂದು ನೋಡ್ ಅನ್ನು ಬಿಟ್ಟರೆ ಹಳೆಯ ಪಾಡ್‌ಸಿಐಡಿಆರ್, ನಂತರ kube-controller-manager ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಪಾಡ್‌ಗಳನ್ನು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ.

ವಾಸ್ತವವಾಗಿ, ಪಾಡ್‌ಸಿಐಡಿಆರ್ ಅನ್ನು ಬದಲಾಯಿಸುವುದು ಇನ್ನೂ ಸರಳವಾಗಿ ಮಾಡಬಹುದು (ಉದಾಹರಣೆಗೆ, ಆದ್ದರಿಂದ) ಆದರೆ ನಾವು etcd ನೊಂದಿಗೆ ನೇರವಾಗಿ ಹೇಗೆ ಕೆಲಸ ಮಾಡಬೇಕೆಂದು ಕಲಿಯಲು ಬಯಸಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಕುಬರ್ನೆಟ್ಸ್ ಆಬ್ಜೆಕ್ಟ್‌ಗಳನ್ನು ಸಂಪಾದಿಸುವಾಗ ಸಂದರ್ಭಗಳಿವೆ - ಏಕೈಕ ಸಂಭವನೀಯ ರೂಪಾಂತರ. (ಉದಾಹರಣೆಗೆ, ಅಲಭ್ಯತೆಯಿಲ್ಲದೆ ನೀವು ಸೇವಾ ಕ್ಷೇತ್ರವನ್ನು ಬದಲಾಯಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ spec.clusterIP.)

ಫಲಿತಾಂಶ

ಲೇಖನವು ನೇರವಾಗಿ ಇತ್ಯಾದಿಗಳಲ್ಲಿ ಡೇಟಾದೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ಸಾಧ್ಯತೆಯನ್ನು ಚರ್ಚಿಸುತ್ತದೆ, ಅಂದರೆ. ಕುಬರ್ನೆಟ್ಸ್ API ಅನ್ನು ಬೈಪಾಸ್ ಮಾಡಲಾಗುತ್ತಿದೆ. ಕೆಲವೊಮ್ಮೆ ಈ ವಿಧಾನವು ನಿಮಗೆ "ಟ್ರಿಕಿ ಕೆಲಸಗಳನ್ನು" ಮಾಡಲು ಅನುಮತಿಸುತ್ತದೆ. ನೈಜ K8s ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಪಠ್ಯದಲ್ಲಿ ನೀಡಲಾದ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು ನಾವು ಪರೀಕ್ಷಿಸಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ವ್ಯಾಪಕ ಬಳಕೆಗೆ ಅವರ ಸಿದ್ಧತೆಯ ಸ್ಥಿತಿ PoC (ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆ). ಆದ್ದರಿಂದ, ನೀವು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ etcdhelper ಯುಟಿಲಿಟಿಯ ಮಾರ್ಪಡಿಸಿದ ಆವೃತ್ತಿಯನ್ನು ಬಳಸಲು ಬಯಸಿದರೆ, ನಿಮ್ಮ ಸ್ವಂತ ಜವಾಬ್ದಾರಿಯಲ್ಲಿ ಹಾಗೆ ಮಾಡಿ.

ಪಿಎಸ್

ನಮ್ಮ ಬ್ಲಾಗ್‌ನಲ್ಲಿಯೂ ಓದಿ:

ಮೂಲ: www.habr.com

ಇತ್ಯಾದಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಡೇಟಾದೊಂದಿಗೆ ನಮ್ಮ ಅನುಭವ ನೇರವಾಗಿ (K8s API ಇಲ್ಲದೆ)