ಕುಬರ್ನೆಟ್ಸ್ ಬಳಸುವಾಗ 🥇10 ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು

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

ಕುಬರ್ನೆಟ್ಸ್ ಅನ್ನು ಬಳಸುವ ವರ್ಷಗಳಲ್ಲಿ, ನಾವು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಕ್ಲಸ್ಟರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡಿದ್ದೇವೆ (ನಿರ್ವಹಿಸಿದ ಮತ್ತು ನಿರ್ವಹಿಸದ ಎರಡೂ - GCP, AWS ಮತ್ತು Azure ನಲ್ಲಿ). ಕಾಲಾನಂತರದಲ್ಲಿ, ಕೆಲವು ತಪ್ಪುಗಳು ನಿರಂತರವಾಗಿ ಪುನರಾವರ್ತನೆಯಾಗುವುದನ್ನು ನಾವು ಗಮನಿಸಲಾರಂಭಿಸಿದ್ದೇವೆ. ಆದಾಗ್ಯೂ, ಇದರಲ್ಲಿ ಯಾವುದೇ ಅವಮಾನವಿಲ್ಲ: ಅವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನದನ್ನು ನಾವೇ ಮಾಡಿದ್ದೇವೆ!

ಲೇಖನವು ಸಾಮಾನ್ಯ ದೋಷಗಳನ್ನು ಒಳಗೊಂಡಿದೆ ಮತ್ತು ಅವುಗಳನ್ನು ಹೇಗೆ ಸರಿಪಡಿಸುವುದು ಎಂಬುದನ್ನು ಸಹ ಉಲ್ಲೇಖಿಸುತ್ತದೆ.

1. ಸಂಪನ್ಮೂಲಗಳು: ವಿನಂತಿಗಳು ಮತ್ತು ಮಿತಿಗಳು

ಈ ಐಟಂ ಖಂಡಿತವಾಗಿಯೂ ಹತ್ತಿರದ ಗಮನ ಮತ್ತು ಪಟ್ಟಿಯಲ್ಲಿ ಮೊದಲ ಸ್ಥಾನಕ್ಕೆ ಅರ್ಹವಾಗಿದೆ.

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

ಅತ್ಯುತ್ತಮ ಪ್ರಯತ್ನ (ಅತ್ಯಂತ ಕೇವಲ ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ):

resources: {}

ಅತ್ಯಂತ ಕಡಿಮೆ CPU ವಿನಂತಿ (ಅತ್ಯಂತ ಕೇವಲ ಶಿಫಾರಸು ಮಾಡಲಾಗಿದೆ):

   resources:
      Requests:
        cpu: "1m"

ಮತ್ತೊಂದೆಡೆ, CPU ಮಿತಿಯ ಉಪಸ್ಥಿತಿಯು ನೋಡ್ ಪ್ರೊಸೆಸರ್ ಸಂಪೂರ್ಣವಾಗಿ ಲೋಡ್ ಆಗದಿದ್ದರೂ ಸಹ, ಪಾಡ್‌ಗಳಿಂದ ಗಡಿಯಾರದ ಚಕ್ರಗಳನ್ನು ಅಸಮಂಜಸವಾಗಿ ಬಿಟ್ಟುಬಿಡಲು ಕಾರಣವಾಗಬಹುದು. ಮತ್ತೆ, ಇದು ಹೆಚ್ಚಿದ ವಿಳಂಬಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು. ಪ್ಯಾರಾಮೀಟರ್ ಸುತ್ತ ವಿವಾದವು ಮುಂದುವರಿಯುತ್ತದೆ CPU CFS ಕೋಟಾ Linux ಕರ್ನಲ್ ಮತ್ತು CPU ನಲ್ಲಿ ಸೆಟ್ ಮಿತಿಗಳನ್ನು ಅವಲಂಬಿಸಿ ಥ್ರೊಟ್ಲಿಂಗ್, ಹಾಗೆಯೇ CFS ಕೋಟಾವನ್ನು ನಿಷ್ಕ್ರಿಯಗೊಳಿಸುವುದು... ಅಯ್ಯೋ, CPU ಮಿತಿಗಳು ಅವರು ಪರಿಹರಿಸುವುದಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಸಮಸ್ಯೆಗಳನ್ನು ಉಂಟುಮಾಡಬಹುದು. ಇದರ ಬಗ್ಗೆ ಹೆಚ್ಚಿನ ಮಾಹಿತಿಯನ್ನು ಕೆಳಗಿನ ಲಿಂಕ್‌ನಲ್ಲಿ ಕಾಣಬಹುದು.

ಅತಿಯಾದ ಆಯ್ಕೆ (ಅತಿಯಾಗಿ ಬದ್ಧತೆ) ಮೆಮೊರಿ ಸಮಸ್ಯೆಗಳು ದೊಡ್ಡ ಸಮಸ್ಯೆಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು. CPU ಮಿತಿಯನ್ನು ತಲುಪುವುದು ಗಡಿಯಾರದ ಚಕ್ರಗಳನ್ನು ಬಿಟ್ಟುಬಿಡುತ್ತದೆ, ಆದರೆ ಮೆಮೊರಿ ಮಿತಿಯನ್ನು ತಲುಪುವುದು ಪಾಡ್ ಅನ್ನು ಕೊಲ್ಲುತ್ತದೆ. ನೀವು ಎಂದಾದರೂ ಗಮನಿಸಿದ್ದೀರಾ OOMkill? ಹೌದು, ನಾವು ನಿಖರವಾಗಿ ಏನು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ.

ಇದು ಸಂಭವಿಸುವ ಸಾಧ್ಯತೆಯನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನೀವು ಬಯಸುವಿರಾ? ಮೆಮೊರಿ ವಿನಂತಿಯನ್ನು ಮಿತಿಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ (ಕೆಳಗಿನ ಉದಾಹರಣೆಯಲ್ಲಿರುವಂತೆ) ಮೆಮೊರಿಯನ್ನು ಅತಿಯಾಗಿ ನಿಯೋಜಿಸಬೇಡಿ ಮತ್ತು ಖಾತರಿಪಡಿಸಿದ QoS (ಸೇವೆಯ ಗುಣಮಟ್ಟ) ಅನ್ನು ಬಳಸಬೇಡಿ. ಇದರ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ಓದಿ ಹೆನ್ನಿಂಗ್ ಜೇಕಬ್ಸ್ ಪ್ರಸ್ತುತಿಗಳು (ಝಲ್ಯಾಂಡೊದಲ್ಲಿ ಲೀಡ್ ಇಂಜಿನಿಯರ್).

ಸಿಡಿಯಬಲ್ಲ (OOMkilled ಪಡೆಯುವ ಹೆಚ್ಚಿನ ಅವಕಾಶ):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

ಭರವಸೆ:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

ಸಂಪನ್ಮೂಲಗಳನ್ನು ಹೊಂದಿಸುವಾಗ ಏನು ಸಹಾಯ ಮಾಡುತ್ತದೆ?

ಸಹಾಯದಿಂದ ಮೆಟ್ರಿಕ್ಸ್-ಸರ್ವರ್ ನೀವು ಪ್ರಸ್ತುತ CPU ಸಂಪನ್ಮೂಲ ಬಳಕೆ ಮತ್ತು ಪಾಡ್‌ಗಳಿಂದ ಮೆಮೊರಿ ಬಳಕೆಯನ್ನು ನೋಡಬಹುದು (ಮತ್ತು ಅವುಗಳೊಳಗಿನ ಕಂಟೈನರ್‌ಗಳು). ಹೆಚ್ಚಾಗಿ, ನೀವು ಈಗಾಗಲೇ ಅದನ್ನು ಬಳಸುತ್ತಿರುವಿರಿ. ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಗಳನ್ನು ಚಲಾಯಿಸಿ:

kubectl top pods
kubectl top pods --containers
kubectl top nodes

ಆದಾಗ್ಯೂ, ಅವರು ಪ್ರಸ್ತುತ ಬಳಕೆಯನ್ನು ಮಾತ್ರ ತೋರಿಸುತ್ತಾರೆ. ಇದು ನಿಮಗೆ ಪರಿಮಾಣದ ಕ್ರಮದ ಸ್ಥೂಲ ಕಲ್ಪನೆಯನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ಅಂತಿಮವಾಗಿ ನಿಮಗೆ ಅಗತ್ಯವಿರುತ್ತದೆ ಕಾಲಾನಂತರದಲ್ಲಿ ಮೆಟ್ರಿಕ್‌ಗಳಲ್ಲಿನ ಬದಲಾವಣೆಗಳ ಇತಿಹಾಸ (ಇಂತಹ ಪ್ರಶ್ನೆಗಳಿಗೆ ಉತ್ತರಿಸಲು: "ಪೀಕ್ CPU ಲೋಡ್ ಏನು?", "ನಿನ್ನೆ ಬೆಳಿಗ್ಗೆ ಲೋಡ್ ಏನು?", ಇತ್ಯಾದಿ.). ಇದಕ್ಕಾಗಿ ನೀವು ಬಳಸಬಹುದು ಪ್ರಮೀತಿಯಸ್, ಡೇಟಾಡಾಗ್ ಮತ್ತು ಇತರ ಉಪಕರಣಗಳು. ಅವರು ಸರಳವಾಗಿ ಮೆಟ್ರಿಕ್ಸ್-ಸರ್ವರ್‌ನಿಂದ ಮೆಟ್ರಿಕ್‌ಗಳನ್ನು ಪಡೆಯುತ್ತಾರೆ ಮತ್ತು ಅವುಗಳನ್ನು ಸಂಗ್ರಹಿಸುತ್ತಾರೆ ಮತ್ತು ಬಳಕೆದಾರರು ಅವುಗಳನ್ನು ಪ್ರಶ್ನಿಸಬಹುದು ಮತ್ತು ಅದಕ್ಕೆ ಅನುಗುಣವಾಗಿ ಅವುಗಳನ್ನು ರೂಪಿಸಬಹುದು.

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

ಕಂಪ್ಯೂಟಿಂಗ್ ಶಕ್ತಿಯನ್ನು ಸಮರ್ಥವಾಗಿ ಬಳಸುವುದು ಸುಲಭದ ಕೆಲಸವಲ್ಲ. ಇದು ಎಲ್ಲಾ ಸಮಯದಲ್ಲೂ ಟೆಟ್ರಿಸ್ ಆಡುವಂತಿದೆ. ಕಡಿಮೆ ಸರಾಸರಿ ಬಳಕೆಯೊಂದಿಗೆ ಕಂಪ್ಯೂಟ್ ಪವರ್‌ಗಾಗಿ ನೀವು ಹೆಚ್ಚು ಪಾವತಿಸುತ್ತಿದ್ದರೆ (~10% ಎಂದು ಹೇಳಿ), AWS ಫಾರ್ಗೇಟ್ ಅಥವಾ ವರ್ಚುವಲ್ ಕುಬೆಲೆಟ್ ಆಧಾರಿತ ಉತ್ಪನ್ನಗಳನ್ನು ನೋಡಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಅವುಗಳನ್ನು ಸರ್ವರ್‌ಲೆಸ್/ಪೇ-ಪರ್-ಯೂಸೇಜ್ ಬಿಲ್ಲಿಂಗ್ ಮಾದರಿಯಲ್ಲಿ ನಿರ್ಮಿಸಲಾಗಿದೆ, ಇದು ಅಂತಹ ಪರಿಸ್ಥಿತಿಗಳಲ್ಲಿ ಅಗ್ಗವಾಗಬಹುದು.

2. ಲೈವ್ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಪ್ರೋಬ್ಸ್

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

ಆದರೆ ಮಾರಣಾಂತಿಕ ದೋಷದ ಸಂದರ್ಭದಲ್ಲಿ ನೀವು ಸೇವೆ ಮರುಪ್ರಾರಂಭವನ್ನು ಹೇಗೆ ಪ್ರಾರಂಭಿಸಬಹುದು? ಮತ್ತು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಪಾಡ್ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಹೇಗೆ ತಿಳಿಯುತ್ತದೆ? ಅಥವಾ ಇದು ಹೆಚ್ಚಿನ ದಟ್ಟಣೆಯನ್ನು ನಿಭಾಯಿಸಬಹುದೇ?

ಈ ಪರೀಕ್ಷೆಗಳು ಸಾಮಾನ್ಯವಾಗಿ ಪರಸ್ಪರ ಗೊಂದಲಕ್ಕೊಳಗಾಗುತ್ತವೆ:

ಜೀವಂತತೆ - "ಬದುಕುಳಿಯುವಿಕೆ" ಚೆಕ್, ಅದು ವಿಫಲವಾದರೆ ಪಾಡ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ;
ಸಿದ್ಧತೆ - ಸಿದ್ಧತೆ ಪರಿಶೀಲನೆ, ಅದು ವಿಫಲವಾದಲ್ಲಿ, ಅದು ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯಿಂದ ಪಾಡ್ ಅನ್ನು ಸಂಪರ್ಕ ಕಡಿತಗೊಳಿಸುತ್ತದೆ (ಇದನ್ನು ಬಳಸಿ ಪರಿಶೀಲಿಸಬಹುದು kubectl get endpoints) ಮತ್ತು ಮುಂದಿನ ಪರಿಶೀಲನೆಯು ಯಶಸ್ವಿಯಾಗಿ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ಟ್ರಾಫಿಕ್ ಆಗುವುದಿಲ್ಲ.

ಈ ಎರಡೂ ಪರಿಶೀಲನೆಗಳು ಪಾಡ್‌ನ ಸಂಪೂರ್ಣ ಜೀವನ ಚಕ್ರದಲ್ಲಿ ಪ್ರದರ್ಶಿಸಲಾಗುತ್ತದೆ. ಇದು ಅತೀ ಮುಖ್ಯವಾದುದು.

ರೆಡಿನೆಸ್ ಪ್ರೋಬ್‌ಗಳನ್ನು ಸ್ಟಾರ್ಟ್‌ಅಪ್‌ನಲ್ಲಿ ಮಾತ್ರ ರನ್ ಮಾಡಲಾಗುತ್ತದೆ ಎಂಬುದು ಒಂದು ಸಾಮಾನ್ಯ ತಪ್ಪುಗ್ರಹಿಕೆಯಾಗಿದೆ. ಇದರಿಂದಾಗಿ ಪಾಡ್ ಸಿದ್ಧವಾಗಿದೆ ಎಂದು ಬ್ಯಾಲೆನ್ಸರ್ ತಿಳಿಯಬಹುದು (Ready) ಮತ್ತು ಸಂಚಾರವನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲು ಪ್ರಾರಂಭಿಸಬಹುದು. ಆದಾಗ್ಯೂ, ಇದು ಅವರ ಬಳಕೆಗೆ ಆಯ್ಕೆಗಳಲ್ಲಿ ಒಂದಾಗಿದೆ.

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

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

ಸಾಮಾನ್ಯ ಅವಲಂಬನೆಗಳು ವಿಫಲವಾದಾಗ ಎರಡೂ ರೀತಿಯ ಚೆಕ್‌ಗಳು ವಿಫಲವಾಗಬಾರದು, ಇಲ್ಲದಿದ್ದರೆ ಇದು ಎಲ್ಲಾ ಪಾಡ್‌ಗಳ ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ (ಹಿಮಪಾತದಂತಹ) ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ. ಬೇರೆ ಪದಗಳಲ್ಲಿ, ನಿಮಗೆ ಹಾನಿ ಮಾಡಬೇಡಿ.

3. ಪ್ರತಿ HTTP ಸೇವೆಗೆ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್

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

ನೀವು ಸೇವೆಯನ್ನು ತೆರೆದರೆ type: LoadBalancer, ಅದರ ನಿಯಂತ್ರಕ (ಸೇವಾ ಪೂರೈಕೆದಾರರನ್ನು ಅವಲಂಬಿಸಿ) ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ ಮತ್ತು ಮಾತುಕತೆ ನಡೆಸುತ್ತದೆ (ಅಗತ್ಯವಾಗಿ L7 ನಲ್ಲಿ ಚಾಲನೆಯಲ್ಲಿಲ್ಲ, ಬದಲಿಗೆ L4 ನಲ್ಲಿಯೂ ಸಹ), ಮತ್ತು ಇದು ವೆಚ್ಚದ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು (ಬಾಹ್ಯ ಸ್ಥಿರ IPv4 ವಿಳಾಸ, ಕಂಪ್ಯೂಟಿಂಗ್ ಪವರ್, ಪ್ರತಿ ಸೆಕೆಂಡ್ ಬಿಲ್ಲಿಂಗ್ ) ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ಅಂತಹ ಸಂಪನ್ಮೂಲಗಳನ್ನು ರಚಿಸುವ ಅಗತ್ಯತೆಯಿಂದಾಗಿ.

ಈ ಸಂದರ್ಭದಲ್ಲಿ, ಒಂದು ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬಳಸುವುದು ಹೆಚ್ಚು ತಾರ್ಕಿಕವಾಗಿದೆ, ಸೇವೆಗಳನ್ನು ತೆರೆಯುತ್ತದೆ type: NodePort. ಅಥವಾ ಇನ್ನೂ ಉತ್ತಮ, ಯಾವುದನ್ನಾದರೂ ವಿಸ್ತರಿಸಿ nginx-ಇಂಗ್ರೆಸ್-ನಿಯಂತ್ರಕ (ಅಥವಾ ಟ್ರಾಫಿಕ್), ಯಾರು ಒಬ್ಬರೇ ಆಗಿರುತ್ತಾರೆ ನೋಡ್ ಪೋರ್ಟ್ ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗೆ ಸಂಬಂಧಿಸಿದ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಬಳಸುತ್ತದೆ ಪ್ರವೇಶ-ಕುಬರ್ನೆಟ್ಸ್ ಸಂಪನ್ಮೂಲಗಳು.

ಪರಸ್ಪರ ಸಂವಹನ ನಡೆಸುವ ಇತರ ಅಂತರ್-ಕ್ಲಸ್ಟರ್ (ಸೂಕ್ಷ್ಮ) ಸೇವೆಗಳು ಸೇವೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು "ಸಂವಹನ" ಮಾಡಬಹುದು ClusterIP ಮತ್ತು DNS ಮೂಲಕ ಅಂತರ್ನಿರ್ಮಿತ ಸೇವಾ ಶೋಧನೆ ಕಾರ್ಯವಿಧಾನ. ಅವರ ಸಾರ್ವಜನಿಕ DNS/IP ಅನ್ನು ಬಳಸಬೇಡಿ, ಏಕೆಂದರೆ ಇದು ಸುಪ್ತತೆಯ ಮೇಲೆ ಪರಿಣಾಮ ಬೀರಬಹುದು ಮತ್ತು ಕ್ಲೌಡ್ ಸೇವೆಗಳ ವೆಚ್ಚವನ್ನು ಹೆಚ್ಚಿಸಬಹುದು.

4. ಅದರ ವೈಶಿಷ್ಟ್ಯಗಳನ್ನು ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳದೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಆಟೋಸ್ಕೇಲಿಂಗ್ ಮಾಡುವುದು

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

ನಿರ್ದಿಷ್ಟ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಬೇಕು ಎಂದು ಊಹಿಸಿ, ಆದರೆ ಲಭ್ಯವಿರುವ ಎಲ್ಲಾ CPU ಪವರ್ ಅನ್ನು ವಿನಂತಿಸಲಾಗಿದೆ/ಡಿಸ್ಅಸೆಂಬಲ್ ಮಾಡಲಾಗಿದೆ ಮತ್ತು ಪಾಡ್ ಒಂದು ಸ್ಥಿತಿಯಲ್ಲಿ ಸಿಲುಕಿಕೊಳ್ಳುತ್ತದೆ Pending. ಬಾಹ್ಯ ಆಟೋಸ್ಕೇಲರ್ ಸರಾಸರಿ ಪ್ರಸ್ತುತ CPU ಲೋಡ್ ಅನ್ನು ನೋಡುತ್ತದೆ (ವಿನಂತಿಸಿದ ಒಂದಲ್ಲ) ಮತ್ತು ವಿಸ್ತರಣೆಯನ್ನು ಪ್ರಾರಂಭಿಸುವುದಿಲ್ಲ (ಸ್ಕೇಲ್-ಔಟ್) - ಇನ್ನೊಂದು ನೋಡ್ ಅನ್ನು ಸೇರಿಸುವುದಿಲ್ಲ. ಪರಿಣಾಮವಾಗಿ, ಈ ಪಾಡ್ ಅನ್ನು ನಿಗದಿಪಡಿಸಲಾಗುವುದಿಲ್ಲ.

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

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

5. IAM/RBAC ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನಿರ್ಲಕ್ಷಿಸುವುದು

ನಿರಂತರ ರಹಸ್ಯಗಳೊಂದಿಗೆ IAM ಬಳಕೆದಾರರನ್ನು ಬಳಸುವ ಬಗ್ಗೆ ಎಚ್ಚರದಿಂದಿರಿ ಯಂತ್ರಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್‌ಗಳು. ಪಾತ್ರಗಳು ಮತ್ತು ಸೇವಾ ಖಾತೆಗಳನ್ನು ಬಳಸಿಕೊಂಡು ತಾತ್ಕಾಲಿಕ ಪ್ರವೇಶವನ್ನು ಆಯೋಜಿಸಿ (ಸೇವಾ ಖಾತೆಗಳು).

ಅಪ್ಲಿಕೇಶನ್ ಕಾನ್ಫಿಗರೇಶನ್‌ನಲ್ಲಿ ಪ್ರವೇಶ ಕೀಗಳನ್ನು (ಮತ್ತು ರಹಸ್ಯಗಳು) ಹಾರ್ಡ್‌ಕೋಡ್ ಮಾಡಲಾಗಿದೆ ಎಂಬ ಅಂಶವನ್ನು ನಾವು ಆಗಾಗ್ಗೆ ಎದುರಿಸುತ್ತೇವೆ, ಹಾಗೆಯೇ ಕ್ಲೌಡ್ IAM ಗೆ ಪ್ರವೇಶವನ್ನು ಹೊಂದಿದ್ದರೂ ಸಹ ರಹಸ್ಯಗಳ ತಿರುಗುವಿಕೆಯನ್ನು ನಿರ್ಲಕ್ಷಿಸುತ್ತೇವೆ. ಸೂಕ್ತವಾದಲ್ಲಿ ಬಳಕೆದಾರರ ಬದಲಿಗೆ IAM ಪಾತ್ರಗಳು ಮತ್ತು ಸೇವಾ ಖಾತೆಗಳನ್ನು ಬಳಸಿ.

kube2iam ಅನ್ನು ಮರೆತುಬಿಡಿ ಮತ್ತು ಸೇವಾ ಖಾತೆಗಳಿಗಾಗಿ IAM ಪಾತ್ರಗಳಿಗೆ ನೇರವಾಗಿ ಹೋಗಿ (ಇಲ್ಲಿ ವಿವರಿಸಿದಂತೆ ಅದೇ ಹೆಸರಿನ ಟಿಪ್ಪಣಿ ಸ್ಟಿಪಾನ್ ವ್ರಾನಿ):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

ಒಂದು ಟಿಪ್ಪಣಿ. ಅಷ್ಟು ಕಷ್ಟವಲ್ಲ, ಸರಿ?

ಅಲ್ಲದೆ, ಸೇವಾ ಖಾತೆಗಳು ಮತ್ತು ನಿದರ್ಶನ ಪ್ರೊಫೈಲ್ ಸವಲತ್ತುಗಳನ್ನು ನೀಡಬೇಡಿ admin и cluster-adminಅವರಿಗೆ ಅದು ಅಗತ್ಯವಿಲ್ಲದಿದ್ದರೆ. ಇದನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು ಸ್ವಲ್ಪ ಹೆಚ್ಚು ಕಷ್ಟ, ವಿಶೇಷವಾಗಿ RBAC K8 ಗಳಲ್ಲಿ, ಆದರೆ ಖಂಡಿತವಾಗಿಯೂ ಪ್ರಯತ್ನಕ್ಕೆ ಯೋಗ್ಯವಾಗಿದೆ.

6. ಪಾಡ್‌ಗಳಿಗೆ ಸ್ವಯಂಚಾಲಿತ ವಿರೋಧಿ ಸಂಬಂಧವನ್ನು ಅವಲಂಬಿಸಬೇಡಿ

ನೀವು ನೋಡ್‌ನಲ್ಲಿ ಕೆಲವು ನಿಯೋಜನೆಯ ಮೂರು ಪ್ರತಿಕೃತಿಗಳನ್ನು ಹೊಂದಿರುವಿರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನೋಡ್ ಬೀಳುತ್ತದೆ, ಮತ್ತು ಅದರೊಂದಿಗೆ ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳು. ಅಹಿತಕರ ಪರಿಸ್ಥಿತಿ, ಸರಿ? ಆದರೆ ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳು ಒಂದೇ ನೋಡ್‌ನಲ್ಲಿ ಏಕೆ? ಕುಬರ್ನೆಟ್ಸ್ ಹೆಚ್ಚಿನ ಲಭ್ಯತೆ (HA) ಅನ್ನು ಒದಗಿಸಬೇಕಲ್ಲವೇ?!

ದುರದೃಷ್ಟವಶಾತ್, ಕುಬರ್ನೆಟ್ಸ್ ಶೆಡ್ಯೂಲರ್, ತನ್ನದೇ ಆದ ಉಪಕ್ರಮದಲ್ಲಿ, ಪ್ರತ್ಯೇಕ ಅಸ್ತಿತ್ವದ ನಿಯಮಗಳನ್ನು ಅನುಸರಿಸುವುದಿಲ್ಲ (ವಿರೋಧಿ ಸಂಬಂಧ) ಬೀಜಕೋಶಗಳಿಗೆ. ಅವರು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳಬೇಕು:

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

ಅಷ್ಟೇ. ಈಗ ಪಾಡ್‌ಗಳನ್ನು ವಿವಿಧ ನೋಡ್‌ಗಳಲ್ಲಿ ನಿಗದಿಪಡಿಸಲಾಗುತ್ತದೆ (ಈ ಸ್ಥಿತಿಯನ್ನು ನಿಗದಿತ ಸಮಯದಲ್ಲಿ ಮಾತ್ರ ಪರಿಶೀಲಿಸಲಾಗುತ್ತದೆ, ಆದರೆ ಅವುಗಳ ಕಾರ್ಯಾಚರಣೆಯ ಸಮಯದಲ್ಲಿ ಅಲ್ಲ - ಆದ್ದರಿಂದ requiredDuringSchedulingIgnoredDuringExecution).

ಇಲ್ಲಿ ನಾವು ಮಾತನಾಡುತ್ತಿದ್ದೇವೆ podAntiAffinity ವಿವಿಧ ನೋಡ್‌ಗಳಲ್ಲಿ: topologyKey: "kubernetes.io/hostname", - ಮತ್ತು ವಿವಿಧ ಲಭ್ಯತೆಯ ವಲಯಗಳ ಬಗ್ಗೆ ಅಲ್ಲ. ಪೂರ್ಣ ಪ್ರಮಾಣದ HA ಅನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಲು, ನೀವು ಈ ವಿಷಯವನ್ನು ಆಳವಾಗಿ ಅಗೆಯಬೇಕು.

7. PodDisruptionBdgets ಅನ್ನು ನಿರ್ಲಕ್ಷಿಸಲಾಗುತ್ತಿದೆ

ಕುಬರ್ನೆಟ್ಸ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ನೀವು ಉತ್ಪಾದನಾ ಹೊರೆ ಹೊಂದಿದ್ದೀರಿ ಎಂದು ಕಲ್ಪಿಸಿಕೊಳ್ಳಿ. ನಿಯತಕಾಲಿಕವಾಗಿ, ನೋಡ್‌ಗಳು ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಅನ್ನು ಸ್ವತಃ ನವೀಕರಿಸಬೇಕು (ಅಥವಾ ನಿಷ್ಕ್ರಿಯಗೊಳಿಸಬೇಕು). PodDisruptionBudget (PDB) ಎಂಬುದು ಕ್ಲಸ್ಟರ್ ನಿರ್ವಾಹಕರು ಮತ್ತು ಬಳಕೆದಾರರ ನಡುವಿನ ಸೇವಾ ಖಾತರಿ ಒಪ್ಪಂದದಂತಿದೆ.

ನೋಡ್‌ಗಳ ಕೊರತೆಯಿಂದ ಉಂಟಾಗುವ ಸೇವಾ ಅಡಚಣೆಗಳನ್ನು ತಪ್ಪಿಸಲು PDB ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ:

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

ಈ ಉದಾಹರಣೆಯಲ್ಲಿ, ನೀವು ಕ್ಲಸ್ಟರ್‌ನ ಬಳಕೆದಾರರಾಗಿ, ನಿರ್ವಾಹಕರಿಗೆ ಹೀಗೆ ಹೇಳುತ್ತೀರಿ: "ಹೇ, ನನ್ನ ಬಳಿ ಝೂಕೀಪರ್ ಸೇವೆ ಇದೆ, ಮತ್ತು ನೀವು ಏನು ಮಾಡಿದರೂ ಪರವಾಗಿಲ್ಲ, ಈ ಸೇವೆಯ ಕನಿಷ್ಠ 2 ಪ್ರತಿಕೃತಿಗಳು ಯಾವಾಗಲೂ ಲಭ್ಯವಿರಬೇಕು ಎಂದು ನಾನು ಬಯಸುತ್ತೇನೆ."

ಇದರ ಬಗ್ಗೆ ನೀವು ಇನ್ನಷ್ಟು ಓದಬಹುದು ಇಲ್ಲಿ.

8. ಸಾಮಾನ್ಯ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ ಬಹು ಬಳಕೆದಾರರು ಅಥವಾ ಪರಿಸರಗಳು

ಕುಬರ್ನೆಟ್ಸ್ ನೇಮ್‌ಸ್ಪೇಸ್‌ಗಳು (ಹೆಸರುಗಳು) ಬಲವಾದ ನಿರೋಧನವನ್ನು ಒದಗಿಸಬೇಡಿ.

ಒಂದು ಸಾಮಾನ್ಯ ತಪ್ಪು ಕಲ್ಪನೆಯೆಂದರೆ, ನೀವು ಉತ್ಪನ್ನವಲ್ಲದ ಲೋಡ್ ಅನ್ನು ಒಂದು ನೇಮ್‌ಸ್ಪೇಸ್‌ಗೆ ಮತ್ತು ಪ್ರಾಡ್ ಲೋಡ್ ಅನ್ನು ಇನ್ನೊಂದಕ್ಕೆ ನಿಯೋಜಿಸಿದರೆ, ನಂತರ ಅವರು ಯಾವುದೇ ರೀತಿಯಲ್ಲಿ ಪರಸ್ಪರ ಪ್ರಭಾವ ಬೀರುವುದಿಲ್ಲ... ಆದಾಗ್ಯೂ, ಸಂಪನ್ಮೂಲ ವಿನಂತಿಗಳು/ಮಿತಿಗಳು, ಕೋಟಾಗಳನ್ನು ಹೊಂದಿಸುವುದು ಮತ್ತು ಆದ್ಯತೆಯ ವರ್ಗಗಳನ್ನು ಹೊಂದಿಸುವ ಮೂಲಕ ಒಂದು ನಿರ್ದಿಷ್ಟ ಮಟ್ಟದ ಪ್ರತ್ಯೇಕತೆಯನ್ನು ಸಾಧಿಸಬಹುದು. ಡೇಟಾ ಸಮತಲದಲ್ಲಿ ಕೆಲವು "ಭೌತಿಕ" ಪ್ರತ್ಯೇಕತೆಯು ಸಂಬಂಧಗಳು, ಸಹಿಷ್ಣುತೆಗಳು, ದೋಷಗಳು (ಅಥವಾ ನೋಡ್ಸೆಲೆಕ್ಟರ್ಗಳು) ಮೂಲಕ ಒದಗಿಸಲಾಗಿದೆ, ಆದರೆ ಅಂತಹ ಪ್ರತ್ಯೇಕತೆಯು ಸಾಕಷ್ಟು ಇರುತ್ತದೆ ಕಷ್ಟ ಕಾರ್ಯಗತಗೊಳಿಸಿ.

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

9. ಬಾಹ್ಯ ಸಂಚಾರ ನೀತಿ: ಕ್ಲಸ್ಟರ್

ಕ್ಲಸ್ಟರ್‌ನೊಳಗಿನ ಎಲ್ಲಾ ದಟ್ಟಣೆಯು NodePort ನಂತಹ ಸೇವೆಯ ಮೂಲಕ ಬರುತ್ತದೆ ಎಂದು ನಾವು ಆಗಾಗ್ಗೆ ನೋಡುತ್ತೇವೆ, ಇದಕ್ಕಾಗಿ ಡೀಫಾಲ್ಟ್ ನೀತಿಯನ್ನು ಹೊಂದಿಸಲಾಗಿದೆ externalTrafficPolicy: Cluster... ಇದರರ್ಥ ನೋಡ್ ಪೋರ್ಟ್ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿನ ಪ್ರತಿಯೊಂದು ನೋಡ್‌ನಲ್ಲಿ ತೆರೆದಿರುತ್ತದೆ ಮತ್ತು ನೀವು ಬಯಸಿದ ಸೇವೆಯೊಂದಿಗೆ ಸಂವಹನ ನಡೆಸಲು ಅವುಗಳಲ್ಲಿ ಯಾವುದನ್ನಾದರೂ ಬಳಸಬಹುದು (ಪಾಡ್‌ಗಳ ಸೆಟ್).

ಅದೇ ಸಮಯದಲ್ಲಿ, ಮೇಲೆ ತಿಳಿಸಿದ NodePort ಸೇವೆಗೆ ಸಂಬಂಧಿಸಿದ ನೈಜ ಪಾಡ್‌ಗಳು ಸಾಮಾನ್ಯವಾಗಿ ನಿರ್ದಿಷ್ಟವಾಗಿ ಮಾತ್ರ ಲಭ್ಯವಿರುತ್ತವೆ ಈ ನೋಡ್‌ಗಳ ಉಪವಿಭಾಗ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನಾನು ಅಗತ್ಯವಿರುವ ಪಾಡ್ ಅನ್ನು ಹೊಂದಿರದ ನೋಡ್‌ಗೆ ಸಂಪರ್ಕಿಸಿದರೆ, ಅದು ಟ್ರಾಫಿಕ್ ಅನ್ನು ಮತ್ತೊಂದು ನೋಡ್‌ಗೆ ಫಾರ್ವರ್ಡ್ ಮಾಡುತ್ತದೆ, ಹಾಪ್ ಅನ್ನು ಸೇರಿಸುವುದು ಮತ್ತು ಹೆಚ್ಚುತ್ತಿರುವ ಸುಪ್ತತೆ (ನೋಡ್‌ಗಳು ವಿಭಿನ್ನ ಲಭ್ಯತೆಯ ವಲಯಗಳು/ಡೇಟಾ ಕೇಂದ್ರಗಳಲ್ಲಿ ನೆಲೆಗೊಂಡಿದ್ದರೆ, ಸುಪ್ತತೆಯು ಸಾಕಷ್ಟು ಹೆಚ್ಚಾಗಿರುತ್ತದೆ; ಹೆಚ್ಚುವರಿಯಾಗಿ, ಎಗ್ರೆಸ್ ಟ್ರಾಫಿಕ್ ವೆಚ್ಚಗಳು ಹೆಚ್ಚಾಗುತ್ತದೆ).

ಮತ್ತೊಂದೆಡೆ, ನಿರ್ದಿಷ್ಟ ಕುಬರ್ನೆಟ್ಸ್ ಸೇವೆಯು ನೀತಿಯನ್ನು ಹೊಂದಿದ್ದರೆ externalTrafficPolicy: Local, ನಂತರ ಅಗತ್ಯವಿರುವ ಪಾಡ್‌ಗಳು ನಿಜವಾಗಿ ಚಾಲನೆಯಲ್ಲಿರುವ ಆ ನೋಡ್‌ಗಳಲ್ಲಿ ಮಾತ್ರ NodePort ತೆರೆಯುತ್ತದೆ. ರಾಜ್ಯವನ್ನು ಪರಿಶೀಲಿಸುವ ಬಾಹ್ಯ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ಅನ್ನು ಬಳಸುವಾಗ (ಆರೋಗ್ಯ ತಪಾಸಣೆ) ಅಂತಿಮ ಬಿಂದುಗಳು (ಅದು ಹೇಗೆ ಮಾಡುತ್ತದೆ AWS ELB), ಅವನು ಅಗತ್ಯ ನೋಡ್‌ಗಳಿಗೆ ಮಾತ್ರ ಸಂಚಾರವನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ಇದು ವಿಳಂಬಗಳು, ಕಂಪ್ಯೂಟಿಂಗ್ ಅಗತ್ಯಗಳು, ಎಗ್ರೆಸ್ ಬಿಲ್‌ಗಳ ಮೇಲೆ ಪ್ರಯೋಜನಕಾರಿ ಪರಿಣಾಮವನ್ನು ಬೀರುತ್ತದೆ (ಮತ್ತು ಸಾಮಾನ್ಯ ಜ್ಞಾನವು ಅದನ್ನು ನಿರ್ದೇಶಿಸುತ್ತದೆ).

ನೀವು ಈಗಾಗಲೇ ಅಂತಹದನ್ನು ಬಳಸುತ್ತಿರುವ ಹೆಚ್ಚಿನ ಅವಕಾಶವಿದೆ ಟ್ರಾಫಿಕ್ ಅಥವಾ nginx-ಇಂಗ್ರೆಸ್-ನಿಯಂತ್ರಕ HTTP ಪ್ರವೇಶದ ದಟ್ಟಣೆಯನ್ನು ಮಾರ್ಗ ಮಾಡಲು NodePort ಎಂಡ್‌ಪಾಯಿಂಟ್ (ಅಥವಾ LoadBalancer, ಇದು NodePort ಅನ್ನು ಸಹ ಬಳಸುತ್ತದೆ) ಮತ್ತು ಈ ಆಯ್ಕೆಯನ್ನು ಹೊಂದಿಸುವುದರಿಂದ ಅಂತಹ ವಿನಂತಿಗಳ ಸುಪ್ತತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡಬಹುದು.

В ಈ ಪ್ರಕಟಣೆ ನೀವು ಬಾಹ್ಯ ಸಂಚಾರ ನೀತಿ, ಅದರ ಅನುಕೂಲಗಳು ಮತ್ತು ಅನಾನುಕೂಲಗಳ ಬಗ್ಗೆ ಇನ್ನಷ್ಟು ತಿಳಿದುಕೊಳ್ಳಬಹುದು.

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

ಹಿಂದೆ, ಸರ್ವರ್‌ಗಳನ್ನು ಸರಿಯಾದ ಹೆಸರುಗಳಿಂದ ಕರೆಯುವುದು ವಾಡಿಕೆಯಾಗಿತ್ತು: ಆಂಟನ್, HAL9000 ಮತ್ತು Colossus... ಇಂದು ಅವುಗಳನ್ನು ಯಾದೃಚ್ಛಿಕವಾಗಿ ರಚಿಸಲಾದ ಗುರುತಿಸುವಿಕೆಗಳಿಂದ ಬದಲಾಯಿಸಲಾಗಿದೆ. ಆದಾಗ್ಯೂ, ಅಭ್ಯಾಸವು ಉಳಿಯಿತು, ಮತ್ತು ಈಗ ಸರಿಯಾದ ಹೆಸರುಗಳು ಸಮೂಹಗಳಿಗೆ ಹೋಗುತ್ತವೆ.

ಒಂದು ವಿಶಿಷ್ಟ ಕಥೆ (ನೈಜ ಘಟನೆಗಳ ಆಧಾರದ ಮೇಲೆ): ಇದು ಪರಿಕಲ್ಪನೆಯ ಪುರಾವೆಯೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಯಿತು, ಆದ್ದರಿಂದ ಕ್ಲಸ್ಟರ್ ಹೆಮ್ಮೆಯ ಹೆಸರನ್ನು ಹೊಂದಿತ್ತು ಪರೀಕ್ಷೆ... ವರ್ಷಗಳು ಕಳೆದಿವೆ ಮತ್ತು ಅದನ್ನು ಇನ್ನೂ ಉತ್ಪಾದನೆಯಲ್ಲಿ ಬಳಸಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿಯೊಬ್ಬರೂ ಅದನ್ನು ಸ್ಪರ್ಶಿಸಲು ಹೆದರುತ್ತಾರೆ.

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

ಮತ್ತೊಂದೆಡೆ, ಅದನ್ನು ಕುಶಲತೆಯಿಂದ ನೀವು ಸಾಗಿಸಬಾರದು. ಸಮಯದ ಜೊತೆಯಲ್ಲಿ ನಿಯಂತ್ರಣ ಪದರವು ನಿಧಾನವಾಗಬಹುದು. ಹೆಚ್ಚಾಗಿ, ಇದು ಹೆಚ್ಚಿನ ಸಂಖ್ಯೆಯ ವಸ್ತುಗಳನ್ನು ಅವುಗಳ ತಿರುಗುವಿಕೆ ಇಲ್ಲದೆ ರಚಿಸಲಾಗಿದೆ (ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಹೆಲ್ಮ್ ಬಳಸುವಾಗ ಸಾಮಾನ್ಯ ಪರಿಸ್ಥಿತಿ, ಅದಕ್ಕಾಗಿಯೇ ಕಾನ್ಫಿಗ್‌ಮ್ಯಾಪ್‌ಗಳು / ರಹಸ್ಯಗಳಲ್ಲಿ ಅದರ ಸ್ಥಿತಿಯನ್ನು ನವೀಕರಿಸಲಾಗುವುದಿಲ್ಲ - ಇದರ ಪರಿಣಾಮವಾಗಿ, ಸಾವಿರಾರು ವಸ್ತುಗಳು ಸಂಗ್ರಹಗೊಳ್ಳುತ್ತವೆ ನಿಯಂತ್ರಣ ಪದರ) ಅಥವಾ kube-api ವಸ್ತುಗಳ ನಿರಂತರ ಸಂಪಾದನೆಯೊಂದಿಗೆ (ಸ್ವಯಂಚಾಲಿತ ಸ್ಕೇಲಿಂಗ್‌ಗಾಗಿ, CI/CD ಗಾಗಿ, ಮೇಲ್ವಿಚಾರಣೆಗಾಗಿ, ಈವೆಂಟ್ ಲಾಗ್‌ಗಳು, ನಿಯಂತ್ರಕಗಳು, ಇತ್ಯಾದಿ.).

ಹೆಚ್ಚುವರಿಯಾಗಿ, ನಿರ್ವಹಿಸಲಾದ ಕುಬರ್ನೆಟ್ಸ್ ಪೂರೈಕೆದಾರರೊಂದಿಗೆ SLA/SLO ಒಪ್ಪಂದಗಳನ್ನು ಪರಿಶೀಲಿಸಲು ಮತ್ತು ಖಾತರಿಗಳಿಗೆ ಗಮನ ಕೊಡಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ. ಮಾರಾಟಗಾರನು ಖಾತರಿ ನೀಡಬಹುದು ನಿಯಂತ್ರಣ ಪದರದ ಲಭ್ಯತೆ (ಅಥವಾ ಅದರ ಉಪಘಟಕಗಳು), ಆದರೆ ನೀವು ಅದಕ್ಕೆ ಕಳುಹಿಸುವ ವಿನಂತಿಗಳ p99 ವಿಳಂಬವಲ್ಲ. ಬೇರೆ ರೀತಿಯಲ್ಲಿ ಹೇಳುವುದಾದರೆ, ನೀವು ನಮೂದಿಸಬಹುದು kubectl get nodes, ಮತ್ತು 10 ನಿಮಿಷಗಳ ನಂತರ ಮಾತ್ರ ಉತ್ತರವನ್ನು ಸ್ವೀಕರಿಸಿ, ಮತ್ತು ಇದು ಸೇವಾ ಒಪ್ಪಂದದ ನಿಯಮಗಳ ಉಲ್ಲಂಘನೆಯಾಗುವುದಿಲ್ಲ.

11. ಬೋನಸ್: ಇತ್ತೀಚಿನ ಟ್ಯಾಗ್ ಅನ್ನು ಬಳಸುವುದು

ಆದರೆ ಇದು ಈಗಾಗಲೇ ಕ್ಲಾಸಿಕ್ ಆಗಿದೆ. ಇತ್ತೀಚೆಗೆ ನಾವು ಈ ತಂತ್ರವನ್ನು ಕಡಿಮೆ ಬಾರಿ ನೋಡಿದ್ದೇವೆ, ಏಕೆಂದರೆ ಅನೇಕರು, ಕಹಿ ಅನುಭವದಿಂದ ಕಲಿತ ನಂತರ, ಟ್ಯಾಗ್ ಬಳಸುವುದನ್ನು ನಿಲ್ಲಿಸಿದ್ದಾರೆ. :latest ಮತ್ತು ಆವೃತ್ತಿಗಳನ್ನು ಪಿನ್ ಮಾಡಲು ಪ್ರಾರಂಭಿಸಿದರು. ಹುರ್ರೇ!

ಇಸಿಆರ್ ಚಿತ್ರದ ಟ್ಯಾಗ್‌ಗಳ ಅಸ್ಥಿರತೆಯನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ; ಈ ಗಮನಾರ್ಹ ವೈಶಿಷ್ಟ್ಯದೊಂದಿಗೆ ನೀವೇ ಪರಿಚಿತರಾಗಿರಲು ನಾವು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ.

ಸಾರಾಂಶ

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

ವಿವಿಧ ತಂಡಗಳ ವಿಫಲ ಅನುಭವಗಳೊಂದಿಗೆ ನೀವು ಪರಿಚಯ ಮಾಡಿಕೊಳ್ಳಬಹುದು ಈ ಕಥೆಗಳ ಸಂಗ್ರಹ ಹೆನ್ನಿಂಗ್ ಜೇಕಬ್ಸ್ ಅವರಿಂದ.

ಈ ಲೇಖನದಲ್ಲಿ ನೀಡಲಾದ ದೋಷಗಳ ಪಟ್ಟಿಗೆ ಸೇರಿಸಲು ಬಯಸುವವರು Twitter ನಲ್ಲಿ ನಮ್ಮನ್ನು ಸಂಪರ್ಕಿಸಬಹುದು (@ಮಾರೆಕ್ ಬಾರ್ಟಿಕ್, @MstrsObserver).

ಅನುವಾದಕರಿಂದ PS

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

ಮೂಲ: www.habr.com

ಕುಬರ್ನೆಟ್ಗಳನ್ನು ಬಳಸುವಾಗ 10 ಸಾಮಾನ್ಯ ತಪ್ಪುಗಳು