ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ರಂಧ್ರಗಳನ್ನು ಸರಿಪಡಿಸುವುದು. DevOpsConf ನಿಂದ ವರದಿ ಮತ್ತು ಪ್ರತಿಲೇಖನ

ಸೌತ್‌ಬ್ರಿಡ್ಜ್ ಪರಿಹಾರಗಳ ವಾಸ್ತುಶಿಲ್ಪಿ ಮತ್ತು ಸ್ಲರ್ಮ್ ಶಿಕ್ಷಕರಾದ ಪಾವೆಲ್ ಸೆಲಿವನೊವ್ ಅವರು DevOpsConf 2019 ರಲ್ಲಿ ಪ್ರಸ್ತುತಿಯನ್ನು ನೀಡಿದರು. ಈ ಚರ್ಚೆಯು ಕುಬರ್ನೆಟ್ಸ್ "ಸ್ಲರ್ಮ್ ಮೆಗಾ" ಕುರಿತು ಆಳವಾದ ಕೋರ್ಸ್‌ನ ವಿಷಯಗಳ ಒಂದು ಭಾಗವಾಗಿದೆ.

ಸ್ಲರ್ಮ್ ಬೇಸಿಕ್: ಆನ್ ಇಂಟ್ರಡಕ್ಷನ್ ಟು ಕುಬರ್ನೆಟ್ಸ್ ನವೆಂಬರ್ 18-20 ರಂದು ಮಾಸ್ಕೋದಲ್ಲಿ ನಡೆಯುತ್ತದೆ.
ಸ್ಲರ್ಮ್ ಮೆಗಾ: ಕುಬರ್ನೆಟ್ಸ್ನ ಹುಡ್ ಅಡಿಯಲ್ಲಿ ನೋಡುತ್ತಿರುವುದು - ಮಾಸ್ಕೋ, ನವೆಂಬರ್ 22-24.
ಸ್ಲರ್ಮ್ ಆನ್‌ಲೈನ್: ಎರಡೂ ಕುಬರ್ನೆಟ್ ಕೋರ್ಸ್‌ಗಳು ಯಾವಾಗಲೂ ಲಭ್ಯವಿದೆ.

ಕಟ್ ಕೆಳಗೆ ವರದಿಯ ಪ್ರತಿಲೇಖನವಿದೆ.

ಶುಭ ಮಧ್ಯಾಹ್ನ, ಸಹೋದ್ಯೋಗಿಗಳು ಮತ್ತು ಅವರೊಂದಿಗೆ ಸಹಾನುಭೂತಿ ಹೊಂದಿರುವವರು. ಇಂದು ನಾನು ಸುರಕ್ಷತೆಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.

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

ಸುಮಾರು ಆರು ತಿಂಗಳ ಹಿಂದೆ ನಾನು ಒಂದು ಸಾರ್ವಜನಿಕ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೋಡಿದೆ. ಸಾರ್ವಜನಿಕ ಎಂದರೆ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳ n ನೇ ಸಂಖ್ಯೆಯಿದೆ; ಈ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಲ್ಲಿ ಬಳಕೆದಾರರು ತಮ್ಮ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಪ್ರತ್ಯೇಕವಾಗಿರುತ್ತಾರೆ. ಈ ಎಲ್ಲಾ ಬಳಕೆದಾರರು ವಿವಿಧ ಕಂಪನಿಗಳಿಗೆ ಸೇರಿದವರು. ಅಲ್ಲದೆ, ಈ ಕ್ಲಸ್ಟರ್ ಅನ್ನು CDN ಆಗಿ ಬಳಸಬೇಕೆಂದು ಊಹಿಸಲಾಗಿದೆ. ಅಂದರೆ, ಅವರು ನಿಮಗೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೀಡುತ್ತಾರೆ, ಅವರು ನಿಮಗೆ ಅಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ನೀಡುತ್ತಾರೆ, ನೀವು ನಿಮ್ಮ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಹೋಗಿ, ನಿಮ್ಮ ಮುಂಭಾಗಗಳನ್ನು ನಿಯೋಜಿಸಿ.

ನನ್ನ ಹಿಂದಿನ ಕಂಪನಿಯು ಅಂತಹ ಸೇವೆಯನ್ನು ಮಾರಾಟ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ. ಮತ್ತು ಈ ಪರಿಹಾರವು ಸೂಕ್ತವಾಗಿದೆಯೇ ಅಥವಾ ಇಲ್ಲವೇ ಎಂದು ನೋಡಲು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಇರಿಯಲು ನನ್ನನ್ನು ಕೇಳಲಾಯಿತು.

ನಾನು ಈ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬಂದಿದ್ದೇನೆ. ನನಗೆ ಸೀಮಿತ ಹಕ್ಕುಗಳು, ಸೀಮಿತ ನೇಮ್‌ಸ್ಪೇಸ್ ನೀಡಲಾಗಿದೆ. ಸುರಕ್ಷತೆ ಏನು ಎಂದು ಅಲ್ಲಿನ ಹುಡುಗರಿಗೆ ಅರ್ಥವಾಯಿತು. ಅವರು ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿ ಪಾತ್ರ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣ (RBAC) ಕುರಿತು ಓದಿದರು - ಮತ್ತು ಅವರು ಅದನ್ನು ತಿರುಚಿದರು ಆದ್ದರಿಂದ ನಾನು ನಿಯೋಜನೆಗಳಿಂದ ಪ್ರತ್ಯೇಕವಾಗಿ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಾಗಲಿಲ್ಲ. ನಿಯೋಜನೆ ಇಲ್ಲದೆ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸುವ ಮೂಲಕ ನಾನು ಪರಿಹರಿಸಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ಸಮಸ್ಯೆ ನನಗೆ ನೆನಪಿಲ್ಲ, ಆದರೆ ನಾನು ನಿಜವಾಗಿಯೂ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಲು ಬಯಸುತ್ತೇನೆ. ಅದೃಷ್ಟಕ್ಕಾಗಿ, ನಾನು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿದ್ದೇನೆ, ನಾನು ಏನು ಮಾಡಬಹುದು, ನಾನು ಏನು ಮಾಡಬಾರದು ಮತ್ತು ಅವರು ಅಲ್ಲಿ ಏನು ಸ್ಕ್ರೂ ಮಾಡಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನೋಡಲು ನಾನು ನಿರ್ಧರಿಸಿದೆ. ಅದೇ ಸಮಯದಲ್ಲಿ, ಅವರು RBAC ನಲ್ಲಿ ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಿದ್ದಾರೆ ಎಂಬುದನ್ನು ನಾನು ನಿಮಗೆ ಹೇಳುತ್ತೇನೆ.

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

ನಾನು ಇದನ್ನು ಹೇಗೆ ಮಾಡಿದ್ದೇನೆ ಮತ್ತು ಇದರಿಂದ ನಿಮ್ಮನ್ನು ಹೇಗೆ ರಕ್ಷಿಸಿಕೊಳ್ಳುವುದು ಎಂದು ನಾನು ಉದಾಹರಣೆಗಳೊಂದಿಗೆ ಹೇಳುತ್ತೇನೆ.

ಆದರೆ ಮೊದಲು, ನಾನು ನನ್ನನ್ನು ಪರಿಚಯಿಸುತ್ತೇನೆ. ನನ್ನ ಹೆಸರು ಪಾವೆಲ್ ಸೆಲಿವನೋವ್. ನಾನು ಸೌತ್‌ಬ್ರಿಡ್ಜ್‌ನಲ್ಲಿ ವಾಸ್ತುಶಿಲ್ಪಿ. ನಾನು Kubernetes, DevOps ಮತ್ತು ಎಲ್ಲಾ ರೀತಿಯ ಅಲಂಕಾರಿಕ ವಿಷಯಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೇನೆ. ಸೌತ್‌ಬ್ರಿಡ್ಜ್ ಎಂಜಿನಿಯರ್‌ಗಳು ಮತ್ತು ನಾನು ಇದನ್ನೆಲ್ಲ ನಿರ್ಮಿಸುತ್ತಿದ್ದೇವೆ ಮತ್ತು ನಾನು ಸಲಹೆ ನೀಡುತ್ತಿದ್ದೇನೆ.

ನಮ್ಮ ಮುಖ್ಯ ಚಟುವಟಿಕೆಗಳ ಜೊತೆಗೆ, ನಾವು ಇತ್ತೀಚೆಗೆ ಸ್ಲರ್ಮ್ಸ್ ಎಂಬ ಯೋಜನೆಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ. ಕುಬರ್ನೆಟ್ಸ್‌ನೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುವ ನಮ್ಮ ಸಾಮರ್ಥ್ಯವನ್ನು ಸ್ವಲ್ಪಮಟ್ಟಿಗೆ ಜನಸಾಮಾನ್ಯರಿಗೆ ತರಲು ನಾವು ಪ್ರಯತ್ನಿಸುತ್ತಿದ್ದೇವೆ, ಇತರ ಜನರಿಗೆ K8 ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಲು ಕಲಿಸಲು.

ನಾನು ಇಂದು ಏನು ಮಾತನಾಡುತ್ತೇನೆ? ವರದಿಯ ವಿಷಯವು ಸ್ಪಷ್ಟವಾಗಿದೆ - ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನ ಭದ್ರತೆಯ ಬಗ್ಗೆ. ಆದರೆ ಈ ವಿಷಯವು ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ - ಮತ್ತು ಆದ್ದರಿಂದ ನಾನು ಖಂಡಿತವಾಗಿಯೂ ಏನು ಮಾತನಾಡುವುದಿಲ್ಲ ಎಂಬುದನ್ನು ತಕ್ಷಣವೇ ಸ್ಪಷ್ಟಪಡಿಸಲು ಬಯಸುತ್ತೇನೆ. ಇಂಟರ್ನೆಟ್ನಲ್ಲಿ ಈಗಾಗಲೇ ನೂರು ಬಾರಿ ಬಳಸಲಾದ ಹ್ಯಾಕ್ನೀಡ್ ಪದಗಳ ಬಗ್ಗೆ ನಾನು ಮಾತನಾಡುವುದಿಲ್ಲ. ಎಲ್ಲಾ ರೀತಿಯ RBAC ಮತ್ತು ಪ್ರಮಾಣಪತ್ರಗಳು.

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಭದ್ರತೆಯ ಬಗ್ಗೆ ನನಗೆ ಮತ್ತು ನನ್ನ ಸಹೋದ್ಯೋಗಿಗಳಿಗೆ ಏನು ನೋವುಂಟುಮಾಡುತ್ತದೆ ಎಂಬುದರ ಕುರಿತು ನಾನು ಮಾತನಾಡುತ್ತೇನೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳನ್ನು ಒದಗಿಸುವ ಪೂರೈಕೆದಾರರಲ್ಲಿ ಮತ್ತು ನಮ್ಮ ಬಳಿಗೆ ಬರುವ ಕ್ಲೈಂಟ್‌ಗಳಲ್ಲಿ ನಾವು ಈ ಸಮಸ್ಯೆಗಳನ್ನು ನೋಡುತ್ತೇವೆ. ಮತ್ತು ಇತರ ಸಲಹಾ ನಿರ್ವಾಹಕ ಕಂಪನಿಗಳಿಂದ ನಮ್ಮ ಬಳಿಗೆ ಬರುವ ಗ್ರಾಹಕರಿಂದಲೂ ಸಹ. ಅಂದರೆ, ದುರಂತದ ಪ್ರಮಾಣವು ನಿಜವಾಗಿಯೂ ತುಂಬಾ ದೊಡ್ಡದಾಗಿದೆ.

ನಾನು ಇಂದು ಮಾತನಾಡಲು ಅಕ್ಷರಶಃ ಮೂರು ಅಂಶಗಳಿವೆ:

  1. ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳು ಮತ್ತು ಪಾಡ್ ಹಕ್ಕುಗಳು. ಬಳಕೆದಾರರ ಹಕ್ಕುಗಳು ಮತ್ತು ಪಾಡ್ ಹಕ್ಕುಗಳು ಒಂದೇ ವಿಷಯವಲ್ಲ.
  2. ಕ್ಲಸ್ಟರ್ ಬಗ್ಗೆ ಮಾಹಿತಿ ಸಂಗ್ರಹಿಸುವುದು. ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ವಿಶೇಷ ಹಕ್ಕುಗಳಿಲ್ಲದೆಯೇ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ನಿಮಗೆ ಅಗತ್ಯವಿರುವ ಎಲ್ಲಾ ಮಾಹಿತಿಯನ್ನು ನೀವು ಸಂಗ್ರಹಿಸಬಹುದು ಎಂದು ನಾನು ತೋರಿಸುತ್ತೇನೆ.
  3. ಕ್ಲಸ್ಟರ್ ಮೇಲೆ DoS ದಾಳಿ. ನಾವು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ ನಾವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹಾಕಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ. ನಾನು ಕ್ಲಸ್ಟರ್ ನಿಯಂತ್ರಣ ಅಂಶಗಳ ಮೇಲೆ DoS ದಾಳಿಯ ಬಗ್ಗೆ ಮಾತನಾಡುತ್ತೇನೆ.

ನಾನು ಪ್ರಸ್ತಾಪಿಸುವ ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ವಿಷಯವೆಂದರೆ ನಾನು ಇದನ್ನೆಲ್ಲ ಪರೀಕ್ಷಿಸಿದ್ದೇನೆ, ಅದರ ಮೇಲೆ ಎಲ್ಲವೂ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂದು ನಾನು ಖಂಡಿತವಾಗಿ ಹೇಳಬಲ್ಲೆ.

ನಾವು Kubespray ಬಳಸಿಕೊಂಡು Kubernetes ಕ್ಲಸ್ಟರ್ ಸ್ಥಾಪನೆಯನ್ನು ಆಧಾರವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುತ್ತೇವೆ. ಯಾರಿಗಾದರೂ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ, ಇದು ವಾಸ್ತವವಾಗಿ ಅನ್ಸಿಬಲ್‌ನ ಪಾತ್ರಗಳ ಗುಂಪಾಗಿದೆ. ನಾವು ಅದನ್ನು ನಮ್ಮ ಕೆಲಸದಲ್ಲಿ ನಿರಂತರವಾಗಿ ಬಳಸುತ್ತೇವೆ. ಒಳ್ಳೆಯ ವಿಷಯವೆಂದರೆ ನೀವು ಅದನ್ನು ಎಲ್ಲಿ ಬೇಕಾದರೂ ಸುತ್ತಿಕೊಳ್ಳಬಹುದು - ನೀವು ಅದನ್ನು ಕಬ್ಬಿಣದ ತುಂಡುಗಳ ಮೇಲೆ ಅಥವಾ ಎಲ್ಲೋ ಮೋಡದೊಳಗೆ ಸುತ್ತಿಕೊಳ್ಳಬಹುದು. ಒಂದು ಅನುಸ್ಥಾಪನ ವಿಧಾನವು ಎಲ್ಲದಕ್ಕೂ ತಾತ್ವಿಕವಾಗಿ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

ಈ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನಾನು ಕುಬರ್ನೆಟ್ಸ್ v1.14.5 ಅನ್ನು ಹೊಂದಿದ್ದೇನೆ. ನಾವು ಪರಿಗಣಿಸುವ ಸಂಪೂರ್ಣ ಕ್ಯೂಬ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಾಗಿ ವಿಂಗಡಿಸಲಾಗಿದೆ, ಪ್ರತಿ ನೇಮ್‌ಸ್ಪೇಸ್ ಪ್ರತ್ಯೇಕ ತಂಡಕ್ಕೆ ಸೇರಿದೆ ಮತ್ತು ಈ ತಂಡದ ಸದಸ್ಯರು ಪ್ರತಿ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿರುತ್ತಾರೆ. ಅವರು ಬೇರೆ ಬೇರೆ ನಾಮಸ್ಥಳಗಳಿಗೆ ಹೋಗಲಾರರು, ತಮ್ಮ ಸ್ವಂತಕ್ಕೆ ಮಾತ್ರ. ಆದರೆ ಸಂಪೂರ್ಣ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹಕ್ಕುಗಳನ್ನು ಹೊಂದಿರುವ ನಿರ್ದಿಷ್ಟ ನಿರ್ವಾಹಕ ಖಾತೆಯಿದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ರಂಧ್ರಗಳನ್ನು ಸರಿಪಡಿಸುವುದು. DevOpsConf ನಿಂದ ವರದಿ ಮತ್ತು ಪ್ರತಿಲೇಖನ

ಕ್ಲಸ್ಟರ್‌ಗೆ ನಿರ್ವಾಹಕ ಹಕ್ಕುಗಳನ್ನು ಪಡೆಯುವುದು ನಾವು ಮಾಡುವ ಮೊದಲ ಕೆಲಸ ಎಂದು ನಾನು ಭರವಸೆ ನೀಡಿದ್ದೇನೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮುರಿಯಲು ನಮಗೆ ವಿಶೇಷವಾಗಿ ಸಿದ್ಧಪಡಿಸಿದ ಪಾಡ್ ಅಗತ್ಯವಿದೆ. ನಾವು ಮಾಡಬೇಕಾಗಿರುವುದು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಅನ್ವಯಿಸುವುದು.

kubectl apply -f pod.yaml

ಈ ಪಾಡ್ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನ ಮಾಸ್ಟರ್‌ಗಳಲ್ಲಿ ಒಬ್ಬರಿಗೆ ತಲುಪುತ್ತದೆ. ಮತ್ತು ಇದರ ನಂತರ ಕ್ಲಸ್ಟರ್ ನಮಗೆ admin.conf ಎಂಬ ಫೈಲ್ ಅನ್ನು ಸಂತೋಷದಿಂದ ಹಿಂತಿರುಗಿಸುತ್ತದೆ. ಕ್ಯೂಬ್‌ನಲ್ಲಿ, ಈ ಫೈಲ್ ಎಲ್ಲಾ ನಿರ್ವಾಹಕ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತದೆ ಮತ್ತು ಅದೇ ಸಮಯದಲ್ಲಿ ಕ್ಲಸ್ಟರ್ API ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡುತ್ತದೆ. 98% ರಷ್ಟು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗಳಿಗೆ ನಿರ್ವಾಹಕ ಪ್ರವೇಶವನ್ನು ಪಡೆಯುವುದು ಎಷ್ಟು ಸುಲಭ ಎಂದು ನಾನು ಭಾವಿಸುತ್ತೇನೆ.

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

ಮತ್ತು ಈಗ ವಿಶೇಷವಾಗಿ ತಯಾರಿಸಿದ ಪಾಡ್ ಬಗ್ಗೆ. ನಾವು ಯಾವುದೇ ಚಿತ್ರದ ಮೇಲೆ ಓಡುತ್ತೇವೆ. ಡೆಬಿಯನ್:ಜೆಸ್ಸಿಯನ್ನು ಉದಾಹರಣೆಯಾಗಿ ತೆಗೆದುಕೊಳ್ಳೋಣ.

ನಾವು ಈ ವಿಷಯವನ್ನು ಹೊಂದಿದ್ದೇವೆ:

tolerations:
-   effect: NoSchedule 
    operator: Exists 
nodeSelector: 
    node-role.kubernetes.io/master: "" 

ಸಹಿಷ್ಣುತೆ ಎಂದರೇನು? ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಮಾಸ್ಟರ್ಸ್ ಅನ್ನು ಸಾಮಾನ್ಯವಾಗಿ ಟೇಂಟ್ ಎಂದು ಕರೆಯುತ್ತಾರೆ. ಮತ್ತು ಈ "ಸೋಂಕಿನ" ಮೂಲತತ್ವವೆಂದರೆ ಅದು ಪಾಡ್ಗಳನ್ನು ಮಾಸ್ಟರ್ ನೋಡ್ಗಳಿಗೆ ನಿಯೋಜಿಸಲಾಗುವುದಿಲ್ಲ ಎಂದು ಹೇಳುತ್ತದೆ. ಆದರೆ ಯಾವುದೇ ಪಾಡ್‌ನಲ್ಲಿ ಅದು "ಸೋಂಕನ್ನು" ಸಹಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಸೂಚಿಸಲು ಯಾರೂ ತಲೆಕೆಡಿಸಿಕೊಳ್ಳುವುದಿಲ್ಲ. ಸಹಿಷ್ಣುತೆ ವಿಭಾಗವು ಕೆಲವು ನೋಡ್‌ನಲ್ಲಿ NoSchedule ಹೊಂದಿದ್ದರೆ, ನಮ್ಮ ನೋಡ್ ಅಂತಹ ಸೋಂಕನ್ನು ಸಹಿಸಿಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಹೇಳುತ್ತದೆ - ಮತ್ತು ಯಾವುದೇ ಸಮಸ್ಯೆಗಳಿಲ್ಲ.

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

ಈ ಎರಡು ವಿಭಾಗಗಳೊಂದಿಗೆ ಅವರು ಖಂಡಿತವಾಗಿ ಮಾಸ್ಟರ್ಗೆ ಬರುತ್ತಾರೆ. ಮತ್ತು ಅವನಿಗೆ ಅಲ್ಲಿ ವಾಸಿಸಲು ಅವಕಾಶ ನೀಡಲಾಗುವುದು.

ಆದರೆ ಯಜಮಾನನ ಬಳಿಗೆ ಬರುವುದು ನಮಗೆ ಸಾಕಾಗುವುದಿಲ್ಲ. ಇದು ನಮಗೆ ಏನನ್ನೂ ನೀಡುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ ಮುಂದೆ ನಾವು ಈ ಎರಡು ವಿಷಯಗಳನ್ನು ಹೊಂದಿದ್ದೇವೆ:

hostNetwork: true 
hostPID: true 

ನಾವು ಪ್ರಾರಂಭಿಸುವ ನಮ್ಮ ಪಾಡ್ ಕರ್ನಲ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ, ನೆಟ್‌ವರ್ಕ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ಮತ್ತು PID ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿ ವಾಸಿಸುತ್ತದೆ ಎಂದು ನಾವು ನಿರ್ದಿಷ್ಟಪಡಿಸುತ್ತೇವೆ. ಮಾಸ್ಟರ್‌ನಲ್ಲಿ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸಿದ ನಂತರ, ಈ ನೋಡ್‌ನ ಎಲ್ಲಾ ನೈಜ, ಲೈವ್ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ, ಎಲ್ಲಾ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಆಲಿಸಿ ಮತ್ತು ಎಲ್ಲಾ ಪ್ರಕ್ರಿಯೆಗಳ PID ಅನ್ನು ನೋಡಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ನಂತರ ಇದು ಸಣ್ಣ ವಿಷಯಗಳ ವಿಷಯವಾಗಿದೆ. ಇತ್ಯಾದಿಗಳನ್ನು ತೆಗೆದುಕೊಂಡು ನಿಮಗೆ ಬೇಕಾದುದನ್ನು ಓದಿ.

ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ಈ ಕುಬರ್ನೆಟ್ಸ್ ವೈಶಿಷ್ಟ್ಯ, ಇದು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ಇರುತ್ತದೆ.

volumeMounts:
- mountPath: /host 
  name: host 
volumes:
- hostPath: 
    path: / 
    type: Directory 
  name: host 

ಮತ್ತು ಅದರ ಸಾರವೆಂದರೆ ನಾವು ಈ ಕ್ಲಸ್ಟರ್‌ಗೆ ಹಕ್ಕುಗಳಿಲ್ಲದೆಯೇ ನಾವು ಪ್ರಾರಂಭಿಸುವ ಪಾಡ್‌ನಲ್ಲಿ ಹೇಳಬಹುದು, ನಾವು ಟೈಪ್ ಹೋಸ್ಟ್‌ಪಾತ್‌ನ ಪರಿಮಾಣವನ್ನು ರಚಿಸಲು ಬಯಸುತ್ತೇವೆ. ಇದರರ್ಥ ನಾವು ಪ್ರಾರಂಭಿಸುವ ಹೋಸ್ಟ್‌ನಿಂದ ಮಾರ್ಗವನ್ನು ತೆಗೆದುಕೊಳ್ಳುವುದು - ಮತ್ತು ಅದನ್ನು ಪರಿಮಾಣವಾಗಿ ತೆಗೆದುಕೊಳ್ಳುವುದು. ತದನಂತರ ನಾವು ಅದನ್ನು ಹೆಸರು ಎಂದು ಕರೆಯುತ್ತೇವೆ: ಹೋಸ್ಟ್. ನಾವು ಪಾಡ್ ಒಳಗೆ ಈ ಸಂಪೂರ್ಣ ಹೋಸ್ಟ್‌ಪಾತ್ ಅನ್ನು ಆರೋಹಿಸುತ್ತೇವೆ. ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, / ಹೋಸ್ಟ್ ಡೈರೆಕ್ಟರಿಗೆ.

ನಾನು ಅದನ್ನು ಮತ್ತೆ ಪುನರಾವರ್ತಿಸುತ್ತೇನೆ. ನಾವು ಪಾಡ್‌ಗೆ ಮಾಸ್ಟರ್‌ಗೆ ಬರಲು ಹೇಳಿದ್ದೇವೆ, ಅಲ್ಲಿ ಹೋಸ್ಟ್‌ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಹೋಸ್ಟ್‌ಪಿಐಡಿ ಪಡೆಯಿರಿ - ಮತ್ತು ಈ ಪಾಡ್‌ನೊಳಗೆ ಮಾಸ್ಟರ್‌ನ ಸಂಪೂರ್ಣ ಮೂಲವನ್ನು ಮೌಂಟ್ ಮಾಡಿ.

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

ನಂತರ ಸಂಪೂರ್ಣ ಕಾರ್ಯವು ಉಪ ಡೈರೆಕ್ಟರಿ / ಹೋಸ್ಟ್ / ಇತ್ಯಾದಿ / ಕುಬರ್ನೆಟ್ಸ್ / ಪಿಕೆಐಗೆ ಹೋಗುವುದು, ನಾನು ತಪ್ಪಾಗಿ ಭಾವಿಸದಿದ್ದರೆ, ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ಮಾಸ್ಟರ್ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳಿ ಮತ್ತು ಅದರ ಪ್ರಕಾರ, ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರಾಗಿ.

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

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

ನನ್ನ ನೆಚ್ಚಿನ ರೂಟ್ ಬಳಕೆದಾರ. ಮತ್ತು ಕುಬರ್ನೆಟ್ಸ್ ಈ ರನ್ ಆಸ್ ನಾನ್-ರೂಟ್ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿದೆ. ಇದು ಹ್ಯಾಕರ್‌ನಿಂದ ಒಂದು ರೀತಿಯ ರಕ್ಷಣೆಯಾಗಿದೆ. "ಮೊಲ್ಡೇವಿಯನ್ ವೈರಸ್" ಎಂದರೇನು ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆಯೇ? ನೀವು ಇದ್ದಕ್ಕಿದ್ದಂತೆ ಹ್ಯಾಕರ್ ಆಗಿದ್ದರೆ ಮತ್ತು ನನ್ನ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಬಂದರೆ, ನಾವು, ಬಡ ನಿರ್ವಾಹಕರು, ಕೇಳುತ್ತೇವೆ: “ದಯವಿಟ್ಟು ನಿಮ್ಮ ಪಾಡ್‌ಗಳಲ್ಲಿ ನೀವು ನನ್ನ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹ್ಯಾಕ್ ಮಾಡುತ್ತೀರಿ ಎಂಬುದನ್ನು ಸೂಚಿಸಿ, ರೂಟ್ ಅಲ್ಲದ ರೀತಿಯಲ್ಲಿ ರನ್ ಮಾಡಿ. ಇಲ್ಲದಿದ್ದರೆ, ನಿಮ್ಮ ಪಾಡ್‌ನಲ್ಲಿ ನೀವು ಪ್ರಕ್ರಿಯೆಯನ್ನು ರೂಟ್ ಅಡಿಯಲ್ಲಿ ನಡೆಸುತ್ತೀರಿ ಮತ್ತು ನನ್ನನ್ನು ಹ್ಯಾಕ್ ಮಾಡುವುದು ನಿಮಗೆ ತುಂಬಾ ಸುಲಭವಾಗುತ್ತದೆ. ದಯವಿಟ್ಟು ನಿಮ್ಮಿಂದ ನಿಮ್ಮನ್ನು ರಕ್ಷಿಸಿಕೊಳ್ಳಿ."

ಹೋಸ್ಟ್ ಪಾಥ್ ಪರಿಮಾಣವು ನನ್ನ ಅಭಿಪ್ರಾಯದಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಬಯಸಿದ ಫಲಿತಾಂಶವನ್ನು ಪಡೆಯುವ ವೇಗವಾದ ಮಾರ್ಗವಾಗಿದೆ.

ಆದರೆ ಇದೆಲ್ಲವನ್ನೂ ಏನು ಮಾಡಬೇಕು?

ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಎದುರಿಸುವ ಯಾವುದೇ ಸಾಮಾನ್ಯ ನಿರ್ವಾಹಕರಿಗೆ ಬರಬೇಕಾದ ಆಲೋಚನೆ: “ಹೌದು, ನಾನು ನಿಮಗೆ ಹೇಳಿದ್ದೇನೆ, ಕುಬರ್ನೆಟ್ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ. ಅದರಲ್ಲಿ ರಂಧ್ರಗಳಿವೆ. ಮತ್ತು ಇಡೀ ಕ್ಯೂಬ್ ಬುಲ್ಶಿಟ್ ಆಗಿದೆ. ವಾಸ್ತವವಾಗಿ, ದಾಖಲಾತಿಯಂತಹ ವಿಷಯವಿದೆ, ಮತ್ತು ನೀವು ಅಲ್ಲಿ ನೋಡಿದರೆ, ಒಂದು ವಿಭಾಗವಿದೆ ಪಾಡ್ ಭದ್ರತಾ ನೀತಿ.

ಇದು ಯಾಮ್ಲ್ ವಸ್ತುವಾಗಿದೆ - ನಾವು ಇದನ್ನು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ರಚಿಸಬಹುದು - ಇದು ನಿರ್ದಿಷ್ಟವಾಗಿ ಪಾಡ್‌ಗಳ ವಿವರಣೆಯಲ್ಲಿ ಭದ್ರತಾ ಅಂಶಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಅಂದರೆ, ವಾಸ್ತವವಾಗಿ, ಇದು ಯಾವುದೇ ಹೋಸ್ಟ್‌ನೆಟ್‌ವರ್ಕ್, ಹೋಸ್ಟ್‌ಪಿಐಡಿ, ಪ್ರಾರಂಭದಲ್ಲಿ ಪಾಡ್‌ಗಳಲ್ಲಿ ಇರುವ ಕೆಲವು ವಾಲ್ಯೂಮ್ ಪ್ರಕಾರಗಳನ್ನು ಬಳಸುವ ಹಕ್ಕುಗಳನ್ನು ನಿಯಂತ್ರಿಸುತ್ತದೆ. ಪಾಡ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿಯ ಸಹಾಯದಿಂದ ಇದನ್ನೆಲ್ಲ ವಿವರಿಸಬಹುದು.

ಪಾಡ್ ಸೆಕ್ಯುರಿಟಿ ಪಾಲಿಸಿಯ ಅತ್ಯಂತ ಆಸಕ್ತಿದಾಯಕ ವಿಷಯವೆಂದರೆ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ, ಎಲ್ಲಾ ಪಿಎಸ್‌ಪಿ ಸ್ಥಾಪಕಗಳನ್ನು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ವಿವರಿಸಲಾಗಿಲ್ಲ, ಅವುಗಳನ್ನು ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಲಾಗುತ್ತದೆ. ಪ್ರವೇಶ ಪ್ಲಗಿನ್ ಬಳಸಿಕೊಂಡು ಪಾಡ್ ಭದ್ರತಾ ನೀತಿಯನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಲಾಗಿದೆ.

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

ಮತ್ತು ಎಲ್ಲವೂ ನಮ್ಮೊಂದಿಗೆ ಉತ್ತಮವಾಗಿದೆ ಎಂದು ತೋರುತ್ತದೆ. ಮತ್ತು ನಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಎರಡು ನಿಮಿಷಗಳಲ್ಲಿ ಹ್ಯಾಕ್ ಮಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ.

ಸಮಸ್ಯೆ ಇದೆ. ಹೆಚ್ಚಾಗಿ, ನೀವು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಹೊಂದಿದ್ದರೆ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಮಾನಿಟರಿಂಗ್ ಅನ್ನು ಸ್ಥಾಪಿಸಲಾಗಿದೆ. ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್ ಮಾನಿಟರಿಂಗ್ ಹೊಂದಿದ್ದರೆ, ಅದನ್ನು ಪ್ರೊಮೆಥಿಯಸ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ ಎಂದು ಊಹಿಸಲು ನಾನು ಇಲ್ಲಿಯವರೆಗೆ ಹೋಗುತ್ತೇನೆ.

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

ಬಹುಶಃ ಎಲ್ಲರೂ ಹಬ್ರೆಯಲ್ಲಿ ಒಂದೇ ರೀತಿಯ ಲೇಖನಗಳನ್ನು ಓದುತ್ತಾರೆ ಮತ್ತು ಮೇಲ್ವಿಚಾರಣೆಯು ಮಾನಿಟರಿಂಗ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ನಲ್ಲಿದೆ. ಹೆಲ್ಮ್ ಚಾರ್ಟ್ ಅನ್ನು ಎಲ್ಲರಿಗೂ ಸರಿಸುಮಾರು ಒಂದೇ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ. ನೀವು ಚುಕ್ಕಾಣಿ ಸ್ಥಿರ/ಪ್ರಮೀತಿಯಸ್ ಅನ್ನು ಸ್ಥಾಪಿಸಿದರೆ, ನೀವು ಸರಿಸುಮಾರು ಅದೇ ಹೆಸರುಗಳೊಂದಿಗೆ ಕೊನೆಗೊಳ್ಳುತ್ತೀರಿ ಎಂದು ನಾನು ಊಹಿಸುತ್ತೇನೆ. ಮತ್ತು ಹೆಚ್ಚಾಗಿ ನಾನು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ DNS ಹೆಸರನ್ನು ಊಹಿಸಬೇಕಾಗಿಲ್ಲ. ಏಕೆಂದರೆ ಇದು ಪ್ರಮಾಣಿತವಾಗಿದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ನಲ್ಲಿ ರಂಧ್ರಗಳನ್ನು ಸರಿಪಡಿಸುವುದು. DevOpsConf ನಿಂದ ವರದಿ ಮತ್ತು ಪ್ರತಿಲೇಖನ

ಮುಂದೆ ನಾವು ನಿರ್ದಿಷ್ಟ dev ns ಅನ್ನು ಹೊಂದಿದ್ದೇವೆ, ಇದರಲ್ಲಿ ನೀವು ನಿರ್ದಿಷ್ಟ ಪಾಡ್ ಅನ್ನು ಚಲಾಯಿಸಬಹುದು. ತದನಂತರ ಈ ಪಾಡ್‌ನಿಂದ ಈ ರೀತಿ ಮಾಡಲು ತುಂಬಾ ಸುಲಭ:

$ curl http://prometheus-kube-state-metrics.monitoring 

prometheus-kube-state-metrics ಕುಬರ್ನೆಟ್ಸ್ API ನಿಂದಲೇ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಸಂಗ್ರಹಿಸುವ Prometheus ರಫ್ತುದಾರರಲ್ಲಿ ಒಂದಾಗಿದೆ. ಅಲ್ಲಿ ಸಾಕಷ್ಟು ಡೇಟಾ ಇದೆ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಏನು ಚಾಲನೆಯಲ್ಲಿದೆ, ಅದು ಏನು, ಅದರಲ್ಲಿ ನಿಮಗೆ ಯಾವ ಸಮಸ್ಯೆಗಳಿವೆ.

ಸರಳ ಉದಾಹರಣೆಯಾಗಿ:

kube_pod_container_info{namespace=“kube-system”,pod=”kube-apiserver-k8s- 1″,container=”kube-apiserver”,image=

"gcr.io/google-containers/kube-apiserver:v1.14.5"

,image_id=»docker-pullable://gcr.io/google-containers/kube- apiserver@sha256:e29561119a52adad9edc72bfe0e7fcab308501313b09bf99df4a96 38ee634989″,container_id=»docker://7cbe7b1fea33f811fdd8f7e0e079191110268f2 853397d7daf08e72c22d3cf8b»} 1

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

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

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

PSP ಯಂತೆಯೇ, ಈ ಎಲ್ಲಾ ಅಲಂಕಾರಿಕ ತಂತ್ರಜ್ಞಾನಗಳು - ಕುಬರ್ನೆಟ್ಸ್, ಪ್ರಮೀಥಿಯಸ್ - ಅವು ಕೇವಲ ಕೆಲಸ ಮಾಡುವುದಿಲ್ಲ ಮತ್ತು ರಂಧ್ರಗಳಿಂದ ತುಂಬಿರುವುದು ಸಮಸ್ಯೆ ಎಂದು ಭಾಸವಾಗುತ್ತದೆ. ನಿಜವಾಗಿಯೂ ಅಲ್ಲ.

ಅಂತಹ ಒಂದು ವಿಷಯವಿದೆ - ನೆಟ್‌ವರ್ಕ್ ನೀತಿ.

ನೀವು ಸಾಮಾನ್ಯ ನಿರ್ವಾಹಕರಾಗಿದ್ದರೆ, ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯ ಬಗ್ಗೆ ಇದು ಮತ್ತೊಂದು ಯಮಲ್ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿರಬಹುದು, ಅದರಲ್ಲಿ ಈಗಾಗಲೇ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬಹಳಷ್ಟು ಇವೆ. ಮತ್ತು ಕೆಲವು ನೆಟ್‌ವರ್ಕ್ ನೀತಿಗಳು ಖಂಡಿತವಾಗಿಯೂ ಅಗತ್ಯವಿಲ್ಲ. ಮತ್ತು ನೆಟ್‌ವರ್ಕ್ ನೀತಿ ಏನೆಂದು ನೀವು ಓದಿದರೂ, ಅದು ಕುಬರ್ನೆಟ್ಸ್‌ನ ಯಮ್ಲ್ ಫೈರ್‌ವಾಲ್, ಇದು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳ ನಡುವೆ, ಪಾಡ್‌ಗಳ ನಡುವೆ ಪ್ರವೇಶ ಹಕ್ಕುಗಳನ್ನು ಮಿತಿಗೊಳಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ನಂತರ ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಯಾಮ್ಲ್ ಫಾರ್ಮ್ಯಾಟ್‌ನಲ್ಲಿರುವ ಫೈರ್‌ವಾಲ್ ಮುಂದಿನ ಅಮೂರ್ತತೆಗಳನ್ನು ಆಧರಿಸಿದೆ ಎಂದು ನೀವು ಖಚಿತವಾಗಿ ನಿರ್ಧರಿಸಿದ್ದೀರಿ. ... ಇಲ್ಲ, ಇಲ್ಲ. ಇದು ಖಂಡಿತವಾಗಿಯೂ ಅಗತ್ಯವಿಲ್ಲ.

ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು ನೀವು ತುಂಬಾ ಸುಲಭ ಮತ್ತು ಸರಳವಾದ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು ಎಂದು ನಿಮ್ಮ ಭದ್ರತಾ ತಜ್ಞರಿಗೆ ನೀವು ಹೇಳದಿದ್ದರೂ ಸಹ, ಮತ್ತು ಅದರಲ್ಲಿ ತುಂಬಾ ಹರಳಿನ ಫೈರ್‌ವಾಲ್ ಅನ್ನು ನಿರ್ಮಿಸಬಹುದು. ಅವರಿಗೆ ಇದು ಇನ್ನೂ ತಿಳಿದಿಲ್ಲದಿದ್ದರೆ ಮತ್ತು ನಿಮಗೆ ತೊಂದರೆಯಾಗದಿದ್ದರೆ: “ಸರಿ, ನನಗೆ ಕೊಡು, ನನಗೆ ಕೊಡು...” ನಂತರ ಯಾವುದೇ ಸಂದರ್ಭದಲ್ಲಿ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಎಳೆಯಬಹುದಾದ ಕೆಲವು ಸೇವಾ ಸ್ಥಳಗಳಿಗೆ ಪ್ರವೇಶವನ್ನು ನಿರ್ಬಂಧಿಸಲು ನಿಮಗೆ ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯ ಅಗತ್ಯವಿದೆ. ಯಾವುದೇ ಅನುಮತಿಯಿಲ್ಲದೆ.

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

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

ಏನು ಮಾಡುವುದು?

ನಿಮ್ಮ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೀವು ಹೊಂದಿರುವ ನೆಟ್‌ವರ್ಕ್ ಪರಿಹಾರವನ್ನು ಮರುಹಂಚಿಕೆ ಮಾಡಲು ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು, ಅದನ್ನು ಹೆಚ್ಚು ಕ್ರಿಯಾತ್ಮಕವಾಗಿ ಬದಲಾಯಿಸಲು ಪ್ರಯತ್ನಿಸಿ. ಅದೇ ಕ್ಯಾಲಿಕೊಗೆ, ಉದಾಹರಣೆಗೆ. ಆದರೆ ಕುಬರ್ನೆಟ್ಸ್ ವರ್ಕಿಂಗ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಪರಿಹಾರವನ್ನು ಬದಲಾಯಿಸುವ ಕಾರ್ಯವು ಕ್ಷುಲ್ಲಕವಲ್ಲ ಎಂದು ನಾನು ಈಗಿನಿಂದಲೇ ಹೇಳಲು ಬಯಸುತ್ತೇನೆ. ನಾನು ಅದನ್ನು ಎರಡು ಬಾರಿ ಪರಿಹರಿಸಿದೆ (ಎರಡೂ ಬಾರಿ, ಆದಾಗ್ಯೂ, ಸೈದ್ಧಾಂತಿಕವಾಗಿ), ಆದರೆ ನಾವು ಅದನ್ನು ಸ್ಲರ್ಮ್ಸ್‌ನಲ್ಲಿ ಹೇಗೆ ಮಾಡಬೇಕೆಂದು ತೋರಿಸಿದ್ದೇವೆ. ನಮ್ಮ ವಿದ್ಯಾರ್ಥಿಗಳಿಗೆ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೆಟ್‌ವರ್ಕ್ ಪರಿಹಾರವನ್ನು ಹೇಗೆ ಬದಲಾಯಿಸುವುದು ಎಂದು ನಾವು ತೋರಿಸಿದ್ದೇವೆ. ತಾತ್ವಿಕವಾಗಿ, ಉತ್ಪಾದನಾ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಯಾವುದೇ ಅಲಭ್ಯತೆ ಇಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ನೀವು ಪ್ರಯತ್ನಿಸಬಹುದು. ಆದರೆ ನೀವು ಬಹುಶಃ ಯಶಸ್ವಿಯಾಗುವುದಿಲ್ಲ.

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

ನೀವು ಹೊಸ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೆಚ್ಚಿಸಿದಾಗ, ಅದೇ ಸಮಯದಲ್ಲಿ ಫ್ಲಾನೆಲ್ ಬದಲಿಗೆ ಕ್ಯಾಲಿಕೊವನ್ನು ಸೇರಿಸಿ.

ನಿಮ್ಮ ಪ್ರಮಾಣಪತ್ರಗಳನ್ನು ನೂರು ವರ್ಷಗಳವರೆಗೆ ನೀಡಿದರೆ ಮತ್ತು ನೀವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಮರುಹೊಂದಿಸಲು ಹೋಗದಿದ್ದರೆ ಏನು ಮಾಡಬೇಕು? Kube-RBAC-Proxy ನಂತಹ ವಿಷಯವಿದೆ. ಇದು ಅತ್ಯಂತ ತಂಪಾದ ಬೆಳವಣಿಗೆಯಾಗಿದೆ, ಇದು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಯಾವುದೇ ಪಾಡ್‌ಗೆ ಸೈಡ್‌ಕಾರ್ ಕಂಟೇನರ್‌ನಂತೆ ಎಂಬೆಡ್ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ಇದು ವಾಸ್ತವವಾಗಿ ಕುಬರ್ನೆಟ್ಸ್‌ನ RBAC ಮೂಲಕ ಈ ಪಾಡ್‌ಗೆ ಅಧಿಕಾರವನ್ನು ಸೇರಿಸುತ್ತದೆ.

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

ಇನ್ನೂ ಒಂದು ಸಣ್ಣ ಸಮಸ್ಯೆ ಇದೆ. ಪ್ರಮೀತಿಯಸ್ ಮಾತ್ರ ತನ್ನ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಯಾರಿಗಾದರೂ ಹಸ್ತಾಂತರಿಸುವುದಿಲ್ಲ. ನಮ್ಮ ಎಲ್ಲಾ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಘಟಕಗಳು ತಮ್ಮದೇ ಆದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಹಿಂದಿರುಗಿಸಲು ಸಾಧ್ಯವಾಗುತ್ತದೆ.

ಆದರೆ ನಾನು ಈಗಾಗಲೇ ಹೇಳಿದಂತೆ, ನೀವು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಪ್ರವೇಶಿಸಲು ಮತ್ತು ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ, ನೀವು ಕನಿಷ್ಟ ಸ್ವಲ್ಪ ಹಾನಿ ಮಾಡಬಹುದು.

ಹಾಗಾಗಿ ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಹೇಗೆ ಹಾಳುಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಾನು ತ್ವರಿತವಾಗಿ ಎರಡು ಮಾರ್ಗಗಳನ್ನು ತೋರಿಸುತ್ತೇನೆ.

ನಾನು ಇದನ್ನು ಹೇಳಿದಾಗ ನೀವು ನಗುತ್ತೀರಿ, ಇವು ಎರಡು ನಿಜ ಜೀವನದ ಪ್ರಕರಣಗಳು.

ವಿಧಾನ ಒಂದು. ಸಂಪನ್ಮೂಲ ಸವಕಳಿ.

ಮತ್ತೊಂದು ವಿಶೇಷ ಪಾಡ್ ಅನ್ನು ಪ್ರಾರಂಭಿಸೋಣ. ಇದು ಈ ರೀತಿಯ ವಿಭಾಗವನ್ನು ಹೊಂದಿರುತ್ತದೆ.

resources: 
    requests: 
        cpu: 4 
        memory: 4Gi 

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

ನಾನು ಅಂತಹ ಪಾಡ್ ಅನ್ನು ಚಲಾಯಿಸಿದರೆ, ನಾನು ಆಜ್ಞೆಯನ್ನು ಚಲಾಯಿಸುತ್ತೇನೆ:

$ kubectl scale special-pod --replicas=...

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

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

ಅಂತಹ ಒಂದು ವಿಷಯದ ಸಹಾಯದಿಂದ, ತಂಡಗಳ ನಿರ್ದಿಷ್ಟ ಉತ್ಪನ್ನ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳಲ್ಲಿ ಬಳಕೆದಾರರನ್ನು ಅವರ ಪಾಡ್‌ಗಳಲ್ಲಿ ಎಲ್ಲಾ ರೀತಿಯ ಅಸಹ್ಯ ವಿಷಯಗಳನ್ನು ಸೂಚಿಸುವ ಸಾಮರ್ಥ್ಯದಲ್ಲಿ ನಾವು ಮಿತಿಗೊಳಿಸಬಹುದು. ಆದರೆ ದುರದೃಷ್ಟವಶಾತ್, ಒಂದಕ್ಕಿಂತ ಹೆಚ್ಚು CPU ಗಾಗಿ ವಿನಂತಿಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಲು ಸಾಧ್ಯವಿಲ್ಲ ಎಂದು ನೀವು ಬಳಕೆದಾರರಿಗೆ ಹೇಳಿದರೂ ಸಹ, ಅಂತಹ ಅದ್ಭುತ ಪ್ರಮಾಣದ ಆದೇಶವಿದೆ, ಅಥವಾ ಅವರು ಡ್ಯಾಶ್‌ಬೋರ್ಡ್ ಮೂಲಕ ಸ್ಕೇಲ್ ಮಾಡಬಹುದು.

ಮತ್ತು ಇಲ್ಲಿ ವಿಧಾನ ಸಂಖ್ಯೆ ಎರಡು ಬರುತ್ತದೆ. ನಾವು 11 ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸುತ್ತೇವೆ. ಅದು ಹನ್ನೊಂದು ಬಿಲಿಯನ್. ಇದು ನಾನು ಅಂತಹ ಸಂಖ್ಯೆಯನ್ನು ತಂದಿದ್ದರಿಂದ ಅಲ್ಲ, ಆದರೆ ನಾನೇ ಅದನ್ನು ನೋಡಿದ್ದರಿಂದ.

ನಿಜವಾದ ಕಥೆ. ಸಂಜೆ ತಡವಾಗಿ ನಾನು ಆಫೀಸಿನಿಂದ ಹೊರಡಲಿದ್ದೆ. ಡೆವಲಪರ್‌ಗಳ ಗುಂಪು ಮೂಲೆಯಲ್ಲಿ ಕುಳಿತು, ತಮ್ಮ ಲ್ಯಾಪ್‌ಟಾಪ್‌ಗಳೊಂದಿಗೆ ಉದ್ರಿಕ್ತವಾಗಿ ಏನನ್ನಾದರೂ ಮಾಡುತ್ತಿರುವುದನ್ನು ನಾನು ನೋಡುತ್ತೇನೆ. ನಾನು ಹುಡುಗರ ಬಳಿಗೆ ಹೋಗಿ ಕೇಳುತ್ತೇನೆ: "ನಿಮಗೆ ಏನಾಯಿತು?"

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

ನಿಜ, ಈ ಕಥೆಯು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ನಡೆಯಲಿಲ್ಲ; ಆ ಸಮಯದಲ್ಲಿ ಅದು ಅಲೆಮಾರಿಯಾಗಿತ್ತು. ನೊಮಾಡ್ ಅನ್ನು ಅಳೆಯುವ ನಿರಂತರ ಪ್ರಯತ್ನಗಳಿಂದ ತಡೆಯುವ ನಮ್ಮ ಪ್ರಯತ್ನಗಳ ಒಂದು ಗಂಟೆಯ ನಂತರ, ನೋಮಾಡ್ ಅವರು ಸ್ಕೇಲಿಂಗ್ ಅನ್ನು ನಿಲ್ಲಿಸುವುದಿಲ್ಲ ಮತ್ತು ಬೇರೆ ಏನನ್ನೂ ಮಾಡುವುದಿಲ್ಲ ಎಂದು ಉತ್ತರಿಸಿದರು. "ನಾನು ದಣಿದಿದ್ದೇನೆ, ನಾನು ಹೊರಡುತ್ತಿದ್ದೇನೆ." ಮತ್ತು ಅವನು ಸುತ್ತಿಕೊಂಡನು.

ಸ್ವಾಭಾವಿಕವಾಗಿ, ನಾನು ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಅದೇ ರೀತಿ ಮಾಡಲು ಪ್ರಯತ್ನಿಸಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಹನ್ನೊಂದು ಬಿಲಿಯನ್ ಪಾಡ್‌ಗಳೊಂದಿಗೆ ಸಂತೋಷವಾಗಿರಲಿಲ್ಲ, ಅವರು ಹೇಳಿದರು: "ನನಗೆ ಸಾಧ್ಯವಿಲ್ಲ. ಆಂತರಿಕ ಮೌತ್ ಗಾರ್ಡ್‌ಗಳನ್ನು ಮೀರಿದೆ." ಆದರೆ 1 ಪಾಡ್‌ಗಳು ಸಾಧ್ಯವಾಯಿತು.

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

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

ಆದರೆ ನಾನು ಇನ್ನೂ ಮುಂದೆ ಹೋಗಲು ನಿರ್ಧರಿಸಿದೆ. ನಿಮಗೆ ತಿಳಿದಿರುವಂತೆ, ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಸೇವೆ ಎಂಬ ವಿಷಯವಿದೆ. ಸರಿ, ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ, ಸೇವೆಯು ಐಪಿ ಕೋಷ್ಟಕಗಳನ್ನು ಬಳಸಿಕೊಂಡು ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ.

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

for i in {1..1111111}; do
    kubectl expose deployment test --port 80  
        --overrides="{"apiVersion": "v1", 
           "metadata": {"name": "nginx$i"}}"; 
done 

ಕ್ಲಸ್ಟರ್‌ನ ಎಲ್ಲಾ ನೋಡ್‌ಗಳಲ್ಲಿ, ಹೆಚ್ಚು ಹೆಚ್ಚು ಹೊಸ iptables ನಿಯಮಗಳನ್ನು ಸರಿಸುಮಾರು ಏಕಕಾಲದಲ್ಲಿ ರಚಿಸಲಾಗುತ್ತದೆ. ಇದಲ್ಲದೆ, ಪ್ರತಿ ಸೇವೆಗೆ ಒಂದು ಬಿಲಿಯನ್ iptables ನಿಯಮಗಳನ್ನು ರಚಿಸಲಾಗುತ್ತದೆ.

ನಾನು ಈ ಸಂಪೂರ್ಣ ವಿಷಯವನ್ನು ಹತ್ತು ಹಲವು ಸಾವಿರಗಳಲ್ಲಿ ಪರಿಶೀಲಿಸಿದೆ. ಮತ್ತು ಸಮಸ್ಯೆಯೆಂದರೆ ಈಗಾಗಲೇ ಈ ಮಿತಿಯಲ್ಲಿ ನೋಡ್‌ಗೆ ssh ಮಾಡಲು ಸಾಕಷ್ಟು ಸಮಸ್ಯಾತ್ಮಕವಾಗಿದೆ. ಏಕೆಂದರೆ ಪ್ಯಾಕೆಟ್‌ಗಳು, ಹಲವಾರು ಸರಪಳಿಗಳ ಮೂಲಕ ಹೋಗುವುದರಿಂದ, ಉತ್ತಮವಾಗಿಲ್ಲ ಎಂದು ಭಾವಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತದೆ.

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

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

ಸಂಪನ್ಮೂಲ ಕೋಟಾ + ಮಿತಿ ಶ್ರೇಣಿ + RBAC
• ನೇಮ್‌ಸ್ಪೇಸ್ ರಚಿಸಿ
• ಒಳಗೆ ಮಿತಿಯನ್ನು ರಚಿಸಿ
• ಸಂಪನ್ಮೂಲ ಕೋಟಾ ಒಳಗೆ ರಚಿಸಿ
• CI ಗಾಗಿ ಸೇವಾ ಖಾತೆಯನ್ನು ರಚಿಸಿ
• CI ಮತ್ತು ಬಳಕೆದಾರರಿಗಾಗಿ ರೋಲ್‌ಬೈಂಡಿಂಗ್ ಅನ್ನು ರಚಿಸಿ
• ಐಚ್ಛಿಕವಾಗಿ ಅಗತ್ಯ ಸೇವೆ ಪಾಡ್‌ಗಳನ್ನು ಪ್ರಾರಂಭಿಸಿ

ಆದ್ದರಿಂದ, ನನ್ನ ಬೆಳವಣಿಗೆಗಳನ್ನು ಹಂಚಿಕೊಳ್ಳಲು ನಾನು ಈ ಅವಕಾಶವನ್ನು ಬಳಸಲು ಬಯಸುತ್ತೇನೆ. SDK ಆಪರೇಟರ್ ಎಂದು ಕರೆಯಲ್ಪಡುವ ಒಂದು ವಿಷಯವಿದೆ. ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ಗೆ ಆಪರೇಟರ್‌ಗಳನ್ನು ಬರೆಯಲು ಇದು ಒಂದು ಮಾರ್ಗವಾಗಿದೆ. ನೀವು ಅನ್ಸಿಬಲ್ ಬಳಸಿ ಹೇಳಿಕೆಗಳನ್ನು ಬರೆಯಬಹುದು.

ಮೊದಲಿಗೆ ಇದನ್ನು ಅನ್ಸಿಬಲ್‌ನಲ್ಲಿ ಬರೆಯಲಾಗಿದೆ, ಮತ್ತು ನಂತರ SDK ಆಪರೇಟರ್ ಇರುವುದನ್ನು ನಾನು ನೋಡಿದೆ ಮತ್ತು ಆನ್ಸಿಬಲ್ ಪಾತ್ರವನ್ನು ಆಪರೇಟರ್ ಆಗಿ ಪುನಃ ಬರೆದಿದ್ದೇನೆ. ಈ ಹೇಳಿಕೆಯು ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಕಮಾಂಡ್ ಎಂಬ ವಸ್ತುವನ್ನು ರಚಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ. ಆಜ್ಞೆಯ ಒಳಗೆ, ಈ ಆಜ್ಞೆಯ ಪರಿಸರವನ್ನು yaml ನಲ್ಲಿ ವಿವರಿಸಲು ಇದು ನಿಮ್ಮನ್ನು ಅನುಮತಿಸುತ್ತದೆ. ಮತ್ತು ತಂಡದ ಪರಿಸರದಲ್ಲಿ, ನಾವು ಹಲವಾರು ಸಂಪನ್ಮೂಲಗಳನ್ನು ನಿಯೋಜಿಸುತ್ತಿದ್ದೇವೆ ಎಂದು ವಿವರಿಸಲು ಇದು ನಮಗೆ ಅನುಮತಿಸುತ್ತದೆ.

ಸ್ವಲ್ಪ ಈ ಸಂಪೂರ್ಣ ಸಂಕೀರ್ಣ ಪ್ರಕ್ರಿಯೆಯನ್ನು ಸುಲಭಗೊಳಿಸುತ್ತದೆ.

ಮತ್ತು ಕೊನೆಯಲ್ಲಿ. ಇದನ್ನೆಲ್ಲ ಏನು ಮಾಡಬೇಕು?
ಪ್ರಥಮ. ಪಾಡ್ ಭದ್ರತಾ ನೀತಿ ಉತ್ತಮವಾಗಿದೆ. ಮತ್ತು ಯಾವುದೇ ಕುಬರ್ನೆಟ್ ಸ್ಥಾಪಕರು ಇಂದಿಗೂ ಅವುಗಳನ್ನು ಬಳಸುವುದಿಲ್ಲ ಎಂಬ ವಾಸ್ತವದ ಹೊರತಾಗಿಯೂ, ನೀವು ಅವುಗಳನ್ನು ನಿಮ್ಮ ಕ್ಲಸ್ಟರ್‌ಗಳಲ್ಲಿ ಇನ್ನೂ ಬಳಸಬೇಕಾಗುತ್ತದೆ.

ನೆಟ್‌ವರ್ಕ್ ನೀತಿಯು ಮತ್ತೊಂದು ಅನಗತ್ಯ ವೈಶಿಷ್ಟ್ಯವಲ್ಲ. ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಇದು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದೆ.

LimitRange/ResourceQuota - ಇದು ಬಳಸಲು ಸಮಯ. ನಾವು ಇದನ್ನು ಬಹಳ ಹಿಂದೆಯೇ ಬಳಸಲು ಪ್ರಾರಂಭಿಸಿದ್ದೇವೆ ಮತ್ತು ಎಲ್ಲರೂ ಇದನ್ನು ಬಳಸುತ್ತಿದ್ದಾರೆ ಎಂದು ನನಗೆ ಖಚಿತವಾಗಿತ್ತು. ಇದು ಅಪರೂಪ ಎಂದು ಬದಲಾಯಿತು.

ವರದಿಯ ಸಮಯದಲ್ಲಿ ನಾನು ಪ್ರಸ್ತಾಪಿಸಿದ್ದಕ್ಕೆ ಹೆಚ್ಚುವರಿಯಾಗಿ, ಕ್ಲಸ್ಟರ್ ಮೇಲೆ ದಾಳಿ ಮಾಡಲು ನಿಮಗೆ ಅನುಮತಿಸುವ ದಾಖಲೆಗಳಿಲ್ಲದ ವೈಶಿಷ್ಟ್ಯಗಳಿವೆ. ಇತ್ತೀಚೆಗೆ ಬಿಡುಗಡೆಯಾಗಿದೆ ಕುಬರ್ನೆಟ್ಸ್ ದುರ್ಬಲತೆಗಳ ವ್ಯಾಪಕ ವಿಶ್ಲೇಷಣೆ.

ಕೆಲವು ವಿಷಯಗಳು ತುಂಬಾ ದುಃಖ ಮತ್ತು ನೋವುಂಟುಮಾಡುತ್ತವೆ. ಉದಾಹರಣೆಗೆ, ಕೆಲವು ಷರತ್ತುಗಳ ಅಡಿಯಲ್ಲಿ, ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿರುವ ಕ್ಯೂಬ್ಲೆಟ್‌ಗಳು ವಾರ್‌ಲಾಕ್‌ಗಳ ಡೈರೆಕ್ಟರಿಯ ವಿಷಯಗಳನ್ನು ಅನಧಿಕೃತ ಬಳಕೆದಾರರಿಗೆ ನೀಡಬಹುದು.

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

ಎಲ್ಲರಿಗೂ ಧನ್ಯವಾದಗಳು.

ಮೂಲ: www.habr.com

ಕಾಮೆಂಟ್ ಅನ್ನು ಸೇರಿಸಿ