ಕುಬರ್ನೆಟ್ಸ್‌ನಲ್ಲಿನ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳು ಅಪಾಯಕಾರಿಯಾಗಬಹುದು

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

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

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

ತಪ್ಪಾಗಿ ಕಾನ್ಫಿಗರ್ ಮಾಡಲಾಗಿದೆ livenessProbe ಹೆಚ್ಚಿನ ಹೊರೆಯ ಸಂದರ್ಭಗಳನ್ನು ಉಲ್ಬಣಗೊಳಿಸಬಹುದು (ಸ್ನೋಬಾಲ್ ಸ್ಥಗಿತಗೊಳಿಸುವಿಕೆ + ಸಂಭಾವ್ಯ ದೀರ್ಘ ಧಾರಕ/ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭದ ಸಮಯ) ಮತ್ತು ಅವಲಂಬನೆ ಹನಿಗಳಂತಹ ಇತರ ಋಣಾತ್ಮಕ ಪರಿಣಾಮಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು (ಸಹ ನೋಡಿ ನನ್ನ ಇತ್ತೀಚಿನ ಲೇಖನ K3s+ACME ಸಂಯೋಜನೆಯಲ್ಲಿ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯನ್ನು ಮಿತಿಗೊಳಿಸುವ ಬಗ್ಗೆ). ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಅನ್ನು ಆರೋಗ್ಯ ತಪಾಸಣೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಿದಾಗ ಅದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ, ಇದು ಬಾಹ್ಯ ಡೇಟಾಬೇಸ್ ಆಗಿದೆ: ಒಂದು DB ವೈಫಲ್ಯವು ನಿಮ್ಮ ಎಲ್ಲಾ ಕಂಟೈನರ್‌ಗಳನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ!

ಸಾಮಾನ್ಯ ಸಂದೇಶ "ಲೈವ್ನೆಸ್ ಪ್ರೋಬ್ಗಳನ್ನು ಬಳಸಬೇಡಿ" ಈ ಸಂದರ್ಭದಲ್ಲಿ ಇದು ಹೆಚ್ಚು ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸನ್ನದ್ಧತೆ ಮತ್ತು ಜೀವಂತಿಕೆ ಪರಿಶೀಲನೆಗಳು ಏನೆಂದು ನೋಡೋಣ.

ಗಮನಿಸಿ: ಕೆಳಗಿನ ಹೆಚ್ಚಿನ ಪರೀಕ್ಷೆಗಳನ್ನು ಮೂಲತಃ ಝಲ್ಯಾಂಡೊದ ಆಂತರಿಕ ಡೆವಲಪರ್ ದಾಖಲಾತಿಯಲ್ಲಿ ಸೇರಿಸಲಾಗಿದೆ.

ಸನ್ನದ್ಧತೆ ಮತ್ತು ಜೀವಂತಿಕೆ ತಪಾಸಣೆ

ಕುಬರ್ನೆಟ್ಸ್ ಎಂಬ ಎರಡು ಪ್ರಮುಖ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಒದಗಿಸುತ್ತದೆ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳು ಮತ್ತು ರೆಡಿನೆಸ್ ಪ್ರೋಬ್‌ಗಳು. ಅವರು ನಿಯತಕಾಲಿಕವಾಗಿ ಕೆಲವು ಕ್ರಿಯೆಗಳನ್ನು ಮಾಡುತ್ತಾರೆ-ಉದಾಹರಣೆಗೆ HTTP ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವುದು, TCP ಸಂಪರ್ಕವನ್ನು ತೆರೆಯುವುದು ಅಥವಾ ಕಂಟೇನರ್‌ನಲ್ಲಿ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸುವುದು-ಅಪ್ಲಿಕೇಶನ್ ನಿರೀಕ್ಷಿಸಿದಂತೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತಿದೆ ಎಂದು ಖಚಿತಪಡಿಸುತ್ತದೆ.

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

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

ನೀವು ಲೈವ್‌ನೆಸ್/ಸಿದ್ಧತೆ ಪರಿಶೀಲನೆಯಲ್ಲಿ ವಿಫಲವಾದ ಅಪ್ಲಿಕೇಶನ್ ಅಪ್‌ಡೇಟ್ ಅನ್ನು ನಿಯೋಜಿಸಲು ಪ್ರಯತ್ನಿಸಿದರೆ, ಕುಬರ್ನೆಟ್ಸ್ ಸ್ಥಿತಿಗಾಗಿ ಕಾಯುತ್ತಿರುವಾಗ ಅದರ ರೋಲ್‌ಔಟ್ ಸ್ಥಗಿತಗೊಳ್ಳುತ್ತದೆ Ready ಎಲ್ಲಾ ಬೀಜಕೋಶಗಳಿಂದ.

ಉದಾಹರಣೆಗೆ

ಮಾರ್ಗವನ್ನು ಪರಿಶೀಲಿಸುವ ಸಿದ್ಧತೆಯ ತನಿಖೆಯ ಉದಾಹರಣೆ ಇಲ್ಲಿದೆ /health ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ HTTP ಮೂಲಕ (ಮಧ್ಯಂತರ: 10 ಸೆಕೆಂಡುಗಳು, ಸಮಯ ಮೀರಿದೆ: 1 ಸೆಕೆಂಡ್, ಯಶಸ್ಸಿನ ಮಿತಿ: 1, ವೈಫಲ್ಯದ ಮಿತಿ: 3):

# часть общего описания deployment'а/стека
podTemplate:
  spec:
    containers:
    - name: my-container
      # ...
      readinessProbe:
        httpGet:
          path: /health
          port: 8080

ಶಿಫಾರಸುಗಳನ್ನು

1. HTTP ಎಂಡ್‌ಪಾಯಿಂಟ್ (REST, ಇತ್ಯಾದಿ) ಹೊಂದಿರುವ ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳಿಗಾಗಿ ಯಾವಾಗಲೂ ಸನ್ನದ್ಧತೆಯ ತನಿಖೆಯನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಿ, ಇದು ಅಪ್ಲಿಕೇಶನ್ (ಪಾಡ್) ಸಂಚಾರವನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸುತ್ತದೆ.
2. ಸಿದ್ಧತೆ ತನಿಖೆಯನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ನಿಜವಾದ ವೆಬ್ ಸರ್ವರ್ ಪೋರ್ಟ್‌ನ ಲಭ್ಯತೆಯನ್ನು ಒಳಗೊಳ್ಳುತ್ತದೆ:
   • "ನಿರ್ವಹಣೆ" ಅಥವಾ "ನಿರ್ವಹಣೆ" (ಉದಾಹರಣೆಗೆ, 9090) ಎಂದು ಕರೆಯಲ್ಪಡುವ ಆಡಳಿತಾತ್ಮಕ ಉದ್ದೇಶಗಳಿಗಾಗಿ ಪೋರ್ಟ್‌ಗಳನ್ನು ಬಳಸುವುದು readinessProbe, ಪ್ರಾಥಮಿಕ HTTP ಪೋರ್ಟ್ (8080 ನಂತಹ) ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಸಿದ್ಧವಾಗಿದ್ದರೆ ಮಾತ್ರ ಅಂತ್ಯಬಿಂದುವು ಸರಿ ಎಂದು ಹಿಂತಿರುಗಿಸುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ*;

     *ಜಲ್ಯಾಂಡೊದಲ್ಲಿ ಇದು ಸಂಭವಿಸದ ಕನಿಷ್ಠ ಒಂದು ಪ್ರಕರಣದ ಬಗ್ಗೆ ನನಗೆ ತಿಳಿದಿದೆ, ಅಂದರೆ. readinessProbe ನಾನು "ನಿರ್ವಹಣೆ" ಪೋರ್ಟ್ ಅನ್ನು ಪರಿಶೀಲಿಸಿದೆ, ಆದರೆ ಸಂಗ್ರಹವನ್ನು ಲೋಡ್ ಮಾಡುವ ಸಮಸ್ಯೆಗಳಿಂದಾಗಿ ಸರ್ವರ್ ಸ್ವತಃ ಕಾರ್ಯನಿರ್ವಹಿಸಲು ಪ್ರಾರಂಭಿಸಲಿಲ್ಲ.

   • ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್‌ಗೆ ಸನ್ನದ್ಧತೆಯ ತನಿಖೆಯನ್ನು ಲಗತ್ತಿಸುವುದು ಮುಖ್ಯ ಪೋರ್ಟ್‌ನಲ್ಲಿನ ಓವರ್‌ಲೋಡ್ ಆರೋಗ್ಯ ತಪಾಸಣೆಯಲ್ಲಿ ಪ್ರತಿಫಲಿಸುವುದಿಲ್ಲ ಎಂಬ ಅಂಶಕ್ಕೆ ಕಾರಣವಾಗಬಹುದು (ಅಂದರೆ, ಸರ್ವರ್‌ನಲ್ಲಿ ಥ್ರೆಡ್ ಪೂಲ್ ತುಂಬಿದೆ, ಆದರೆ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಇನ್ನೂ ಎಲ್ಲವೂ ಸರಿಯಾಗಿದೆ ಎಂದು ತೋರಿಸುತ್ತದೆ )
3. ಎಂಬುದನ್ನು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ ರೆಡಿನೆಸ್ ಪ್ರೋಬ್ ಡೇಟಾಬೇಸ್ ಇನಿಶಿಯಲೈಸೇಶನ್/ಮೈಗ್ರೇಶನ್ ಅನ್ನು ಶಕ್ತಗೊಳಿಸುತ್ತದೆ;
   • ಇದನ್ನು ಸಾಧಿಸಲು ಸುಲಭವಾದ ಮಾರ್ಗವೆಂದರೆ ಪ್ರಾರಂಭಿಕತೆಯು ಪೂರ್ಣಗೊಂಡ ನಂತರವೇ HTTP ಸರ್ವರ್ ಅನ್ನು ಸಂಪರ್ಕಿಸುವುದು (ಉದಾಹರಣೆಗೆ, ಡೇಟಾಬೇಸ್ ಅನ್ನು ಸ್ಥಳಾಂತರಿಸುವುದು ಫ್ಲೈವೇ ಮತ್ತು ಇತ್ಯಾದಿ.); ಅಂದರೆ, ಆರೋಗ್ಯ ತಪಾಸಣೆ ಸ್ಥಿತಿಯನ್ನು ಬದಲಾಯಿಸುವ ಬದಲು, ಡೇಟಾಬೇಸ್ ವಲಸೆ ಪೂರ್ಣಗೊಳ್ಳುವವರೆಗೆ ವೆಬ್ ಸರ್ವರ್ ಅನ್ನು ಸರಳವಾಗಿ ಪ್ರಾರಂಭಿಸಬೇಡಿ*.

     * ನೀವು ಪಾಡ್‌ನ ಹೊರಗಿನ init ಕಂಟೈನರ್‌ಗಳಿಂದ ಡೇಟಾಬೇಸ್ ವಲಸೆಗಳನ್ನು ಸಹ ಚಲಾಯಿಸಬಹುದು. ನಾನು ಇನ್ನೂ ಸ್ವಯಂ-ಒಳಗೊಂಡಿರುವ ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಅಭಿಮಾನಿಯಾಗಿದ್ದೇನೆ, ಅಂದರೆ, ಬಾಹ್ಯ ಸಮನ್ವಯವಿಲ್ಲದೆ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅಪೇಕ್ಷಿತ ಸ್ಥಿತಿಗೆ ಹೇಗೆ ತರುವುದು ಎಂದು ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್ ತಿಳಿದಿರುತ್ತದೆ.

4. ಬಳಸಿ httpGet ವಿಶಿಷ್ಟವಾದ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಅಂತಿಮ ಬಿಂದುಗಳ ಮೂಲಕ ಸಿದ್ಧತೆ ತಪಾಸಣೆಗಾಗಿ (ಉದಾಹರಣೆಗೆ, /health).
5. ಡೀಫಾಲ್ಟ್ ಚೆಕ್ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳಿ (interval: 10s, timeout: 1s, successThreshold: 1, failureThreshold: 3):
   • ಡೀಫಾಲ್ಟ್ ಆಯ್ಕೆಗಳು ಎಂದರೆ ಪಾಡ್ ಆಗುತ್ತದೆ ಸಿದ್ಧವಾಗಿಲ್ಲ ಸುಮಾರು 30 ಸೆಕೆಂಡುಗಳ ನಂತರ (3 ವಿಫಲವಾದ ವಿವೇಕ ತಪಾಸಣೆ).
6. ನಿಯಮಿತ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಆರೋಗ್ಯ ಮತ್ತು ಮೆಟ್ರಿಕ್ಸ್ ನಿರ್ವಹಣೆಯನ್ನು ಪ್ರತ್ಯೇಕಿಸಲು ತಂತ್ರಜ್ಞಾನದ ಸ್ಟಾಕ್ (ಉದಾ. ಜಾವಾ/ಸ್ಪ್ರಿಂಗ್) ಅನುಮತಿಸಿದರೆ "ನಿರ್ವಹಣೆ" ಅಥವಾ "ನಿರ್ವಹಣೆ" ಗಾಗಿ ಪ್ರತ್ಯೇಕ ಪೋರ್ಟ್ ಬಳಸಿ:
   • ಆದರೆ ಪಾಯಿಂಟ್ 2 ಬಗ್ಗೆ ಮರೆಯಬೇಡಿ.
7. ಅಗತ್ಯವಿದ್ದರೆ, ಸಂಗ್ರಹವನ್ನು ಬೆಚ್ಚಗಾಗಲು/ಲೋಡ್ ಮಾಡಲು ಮತ್ತು ಕಂಟೇನರ್ ಬೆಚ್ಚಗಾಗುವವರೆಗೆ 503 ಸ್ಥಿತಿ ಕೋಡ್ ಅನ್ನು ಹಿಂತಿರುಗಿಸಲು ಸಿದ್ಧತೆ ತನಿಖೆಯನ್ನು ಬಳಸಬಹುದು:
   • ನೀವು ಹೊಸ ಚೆಕ್ ಅನ್ನು ಓದಬೇಕೆಂದು ನಾನು ಶಿಫಾರಸು ಮಾಡುತ್ತೇವೆ startupProbe, ಆವೃತ್ತಿ 1.16 ರಲ್ಲಿ ಕಾಣಿಸಿಕೊಂಡಿದೆ (ನಾವು ಅದರ ಬಗ್ಗೆ ರಷ್ಯನ್ ಭಾಷೆಯಲ್ಲಿ ಬರೆದಿದ್ದೇವೆ ಇಲ್ಲಿ - ಅಂದಾಜು ಅನುವಾದ.).

ಕೇವಟ್ಸ್

1. ಬಾಹ್ಯ ಅವಲಂಬನೆಗಳನ್ನು ಅವಲಂಬಿಸಬೇಡಿ (ಉದಾಹರಣೆಗೆ ಡೇಟಾ ಗೋದಾಮುಗಳು) ಸನ್ನದ್ಧತೆ/ಜೀವಂತ ಪರೀಕ್ಷೆಗಳನ್ನು ನಡೆಸುವಾಗ - ಇದು ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು:
   • ಉದಾಹರಣೆಯಾಗಿ, ಒಂದು ಪೋಸ್ಟ್‌ಗ್ರೆಸ್ ಡೇಟಾಬೇಸ್ ಅನ್ನು ಅವಲಂಬಿಸಿ 10 ಪಾಡ್‌ಗಳೊಂದಿಗೆ ಸ್ಟೇಟ್‌ಫುಲ್ REST ಸೇವೆಯನ್ನು ತೆಗೆದುಕೊಳ್ಳೋಣ: ಚೆಕ್ ಡಿಬಿಗೆ ಕೆಲಸದ ಸಂಪರ್ಕವನ್ನು ಅವಲಂಬಿಸಿದ್ದಾಗ, ನೆಟ್‌ವರ್ಕ್/ಡಿಬಿ ಬದಿಯಲ್ಲಿ ವಿಳಂಬವಾದರೆ ಎಲ್ಲಾ 10 ಪಾಡ್‌ಗಳು ವಿಫಲವಾಗಬಹುದು - ಸಾಮಾನ್ಯವಾಗಿ ಇದು ಎಲ್ಲವು ಸಾಧ್ಯವಿದ್ದಕ್ಕಿಂತ ಕೆಟ್ಟದಾಗಿ ಕೊನೆಗೊಳ್ಳುತ್ತದೆ;
   • ಸ್ಪ್ರಿಂಗ್ ಡೇಟಾ ಡೀಫಾಲ್ಟ್ ಆಗಿ ಡೇಟಾಬೇಸ್ ಸಂಪರ್ಕವನ್ನು ಪರಿಶೀಲಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ*;

     * ಇದು ಸ್ಪ್ರಿಂಗ್ ಡೇಟಾ ರೆಡಿಸ್‌ನ ಡೀಫಾಲ್ಟ್ ನಡವಳಿಕೆಯಾಗಿದೆ (ಕನಿಷ್ಠ ನಾನು ಪರಿಶೀಲಿಸಿದ್ದು ಕೊನೆಯ ಬಾರಿ), ಇದು "ದುರಂತ" ವೈಫಲ್ಯಕ್ಕೆ ಕಾರಣವಾಯಿತು: ರೆಡಿಸ್ ಅಲ್ಪಾವಧಿಗೆ ಲಭ್ಯವಿಲ್ಲದಿದ್ದಾಗ, ಎಲ್ಲಾ ಪಾಡ್‌ಗಳು "ಕ್ರ್ಯಾಶ್" ಆಗಿವೆ.

   • ಈ ಅರ್ಥದಲ್ಲಿ "ಬಾಹ್ಯ" ಅದೇ ಅಪ್ಲಿಕೇಶನ್‌ನ ಇತರ ಪಾಡ್‌ಗಳನ್ನು ಸಹ ಅರ್ಥೈಸಬಲ್ಲದು, ಅಂದರೆ, ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ಕ್ರ್ಯಾಶ್‌ಗಳನ್ನು ತಡೆಗಟ್ಟಲು ಚೆಕ್ ಅದೇ ಕ್ಲಸ್ಟರ್‌ನ ಇತರ ಪಾಡ್‌ಗಳ ಸ್ಥಿತಿಯನ್ನು ಅವಲಂಬಿಸಿರಬಾರದು:
     • ವಿತರಿಸಿದ ಸ್ಥಿತಿಯೊಂದಿಗೆ ಅಪ್ಲಿಕೇಶನ್‌ಗಳಿಗೆ ಫಲಿತಾಂಶಗಳು ಬದಲಾಗಬಹುದು (ಉದಾಹರಣೆಗೆ, ಪಾಡ್‌ಗಳಲ್ಲಿ ಇನ್-ಮೆಮೊರಿ ಕ್ಯಾಶಿಂಗ್).
2. ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಅನ್ನು ಬಳಸಬೇಡಿ ಪಾಡ್‌ಗಳಿಗಾಗಿ (ವಿನಾಯಿತಿಗಳು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದಾಗ ಮತ್ತು ಅವುಗಳ ಬಳಕೆಯ ನಿಶ್ಚಿತಗಳು ಮತ್ತು ಪರಿಣಾಮಗಳ ಬಗ್ಗೆ ನಿಮಗೆ ಸಂಪೂರ್ಣವಾಗಿ ತಿಳಿದಿರುತ್ತದೆ):
   • ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಹ್ಯಾಂಗ್ ಕಂಟೈನರ್‌ಗಳನ್ನು ಮರುಪಡೆಯಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ, ಆದರೆ ನಿಮ್ಮ ಅಪ್ಲಿಕೇಶನ್‌ನ ಮೇಲೆ ನೀವು ಸಂಪೂರ್ಣ ನಿಯಂತ್ರಣವನ್ನು ಹೊಂದಿರುವುದರಿಂದ, ಹ್ಯಾಂಗ್ ಪ್ರಕ್ರಿಯೆಗಳು ಮತ್ತು ಡೆಡ್‌ಲಾಕ್‌ಗಳಂತಹ ವಿಷಯಗಳು ಆದರ್ಶಪ್ರಾಯವಾಗಿ ಸಂಭವಿಸಬಾರದು: ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಕ್ರ್ಯಾಶ್ ಮಾಡುವುದು ಮತ್ತು ಹಿಂದಿನ ಸ್ಥಿರ ಸ್ಥಿತಿಗೆ ತರುವುದು ಉತ್ತಮ ಪರ್ಯಾಯವಾಗಿದೆ;
   • ವಿಫಲವಾದ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲು ಕಾರಣವಾಗುತ್ತದೆ, ಆ ಮೂಲಕ ಬೂಟ್-ಸಂಬಂಧಿತ ದೋಷಗಳ ಪರಿಣಾಮಗಳನ್ನು ಉಲ್ಬಣಗೊಳಿಸುತ್ತದೆ: ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುವುದು ಅಲಭ್ಯತೆಯನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ (ಕನಿಷ್ಠ ಅಪ್ಲಿಕೇಶನ್ ಪ್ರಾರಂಭದ ಅವಧಿಯವರೆಗೆ, 30+ ಸೆಕೆಂಡುಗಳು) ಹೊಸ ದೋಷಗಳನ್ನು ಉಂಟುಮಾಡುತ್ತದೆ, ಇತರ ಧಾರಕಗಳ ಮೇಲೆ ಹೊರೆ ಹೆಚ್ಚಿಸುವುದು ಮತ್ತು ಅವರ ವೈಫಲ್ಯದ ಸಾಧ್ಯತೆಯನ್ನು ಹೆಚ್ಚಿಸುವುದು ಇತ್ಯಾದಿ;
   • ಬಾಹ್ಯ ಅವಲಂಬನೆಯೊಂದಿಗೆ ಸಂಯೋಜಿಸಲ್ಪಟ್ಟ ಲೈವ್‌ನೆಸ್ ಚೆಕ್‌ಗಳು ಅತ್ಯಂತ ಕೆಟ್ಟ ಸಂಭವನೀಯ ಸಂಯೋಜನೆಯಾಗಿದೆ, ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯಗಳನ್ನು ಬೆದರಿಸುತ್ತದೆ: ಡೇಟಾಬೇಸ್ ಬದಿಯಲ್ಲಿ ಸ್ವಲ್ಪ ವಿಳಂಬವು ನಿಮ್ಮ ಎಲ್ಲಾ ಕಂಟೇನರ್‌ಗಳ ಮರುಪ್ರಾರಂಭಕ್ಕೆ ಕಾರಣವಾಗುತ್ತದೆ!
3. ಜೀವಂತಿಕೆ ಮತ್ತು ಸಿದ್ಧತೆ ಪರಿಶೀಲನೆಗಳ ನಿಯತಾಂಕಗಳು ವಿಭಿನ್ನವಾಗಿರಬೇಕು:
   • ನೀವು ಅದೇ ಆರೋಗ್ಯ ತಪಾಸಣೆಯೊಂದಿಗೆ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ಅನ್ನು ಬಳಸಬಹುದು, ಆದರೆ ಹೆಚ್ಚಿನ ಪ್ರತಿಕ್ರಿಯೆ ಮಿತಿ (failureThreshold), ಉದಾಹರಣೆಗೆ, ಸ್ಥಿತಿಯನ್ನು ನಿಯೋಜಿಸಿ ಸಿದ್ಧವಾಗಿಲ್ಲ 3 ಪ್ರಯತ್ನಗಳ ನಂತರ ಮತ್ತು 10 ಪ್ರಯತ್ನಗಳ ನಂತರ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್ ವಿಫಲವಾಗಿದೆ ಎಂದು ಪರಿಗಣಿಸಿ;
4. ಎಕ್ಸಿಕ್ ಚೆಕ್‌ಗಳನ್ನು ಬಳಸಬೇಡಿ, ಅವರು ಜೊಂಬಿ ಪ್ರಕ್ರಿಯೆಗಳ ಗೋಚರಿಸುವಿಕೆಗೆ ಕಾರಣವಾಗುವ ತಿಳಿದಿರುವ ಸಮಸ್ಯೆಗಳೊಂದಿಗೆ ಸಂಬಂಧ ಹೊಂದಿರುವುದರಿಂದ:
   • ವಿವರಗಳು: ನೋಡಿ ಡೇಟಾಡಾಗ್ ತಜ್ಞರಿಂದ ಪ್ರಸ್ತುತಿ.

ಸಾರಾಂಶ

• ಟ್ರಾಫಿಕ್ ಅನ್ನು ಸ್ವೀಕರಿಸಲು ಪಾಡ್ ಯಾವಾಗ ಸಿದ್ಧವಾಗಿದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸಲು ಸಿದ್ಧತೆ ಶೋಧಕಗಳನ್ನು ಬಳಸಿ.
• ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳು ನಿಜವಾಗಿಯೂ ಅಗತ್ಯವಿದ್ದಾಗ ಮಾತ್ರ ಬಳಸಿ.
• ರೆಡಿನೆಸ್/ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳ ಅಸಮರ್ಪಕ ಬಳಕೆಯು ಕಡಿಮೆ ಲಭ್ಯತೆ ಮತ್ತು ಕ್ಯಾಸ್ಕೇಡಿಂಗ್ ವೈಫಲ್ಯಗಳಿಗೆ ಕಾರಣವಾಗಬಹುದು.

ವಿಷಯದ ಕುರಿತು ಹೆಚ್ಚುವರಿ ವಸ್ತುಗಳು

• ಕುಬರ್ನೆಟ್ಸ್ ಡಾಕ್ಸ್: ಲೈವ್‌ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಪ್ರೋಬ್ಸ್ ಅನ್ನು ಕಾನ್ಫಿಗರ್ ಮಾಡಿ;
• ಕುಬರ್ನೆಟ್ಸ್ ಲೈವ್ನೆಸ್ ಮತ್ತು ರೆಡಿನೆಸ್ ಪ್ರೋಬ್ಸ್ ಮರುಪರಿಶೀಲಿಸಲಾಗಿದೆ: ಇತರ ಪಾದದಲ್ಲಿ ನಿಮ್ಮನ್ನು ಶೂಟ್ ಮಾಡುವುದನ್ನು ತಪ್ಪಿಸುವುದು ಹೇಗೆ;
• NRE ಲ್ಯಾಬ್ಸ್ ಔಟೇಜ್ ಪೋಸ್ಟ್ ಮಾರ್ಟಮ್ (ಅವರು ಲೈವ್‌ನೆಸ್‌ಪ್ರೋಬ್ ಬಗ್ಗೆಯೂ ಮಾತನಾಡುತ್ತಾರೆ).

1-2019-09 ರಿಂದ ಸಂಖ್ಯೆ 29 ಅನ್ನು ನವೀಕರಿಸಿ

ಡೇಟಾಬೇಸ್ ವಲಸೆಗಾಗಿ init ಕಂಟೈನರ್‌ಗಳ ಬಗ್ಗೆ: ಅಡಿಟಿಪ್ಪಣಿ ಸೇರಿಸಲಾಗಿದೆ.

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

ಬ್ರಿಯಾನ್ ಅದನ್ನು ಸಂಪೂರ್ಣವಾಗಿ ಹಾಕಿದರು: “ನಿಮಗೆ ನಿಖರವಾಗಿ ಏನು ಗೊತ್ತಾದಾಗ ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬಿಂಗ್ ಬಳಸಿ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಕೊಲ್ಲುವುದು ಉತ್ತಮ ಕೆಲಸ"(ಮತ್ತೆ, ಒಯ್ಯಬೇಡಿ).

2-2019-09 ರಿಂದ ಸಂಖ್ಯೆ 29 ಅನ್ನು ನವೀಕರಿಸಿ

ಬಳಕೆಗೆ ಮೊದಲು ದಸ್ತಾವೇಜನ್ನು ಓದುವ ಬಗ್ಗೆ: ನಾನು ಅನುಗುಣವಾದ ವಿನಂತಿಯನ್ನು ರಚಿಸಿದ್ದೇನೆ (ವೈಶಿಷ್ಟ್ಯ ವಿನಂತಿ) ಲೈವ್‌ನೆಸ್ ಪ್ರೋಬ್‌ಗಳ ಬಗ್ಗೆ ದಸ್ತಾವೇಜನ್ನು ಸೇರಿಸಲು.

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

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

• «ಕುಬರ್ನೆಟ್ಸ್: ಪಾಡ್ ಲೈಫ್";
• «Google ಪ್ರಕಾರ ಕಂಟೈನರ್‌ಗಳನ್ನು ಬಳಸುವ 7 ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು";
• «ಕಂಟೈನರ್-ಆಧಾರಿತ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು 7 ತತ್ವಗಳು».

ಮೂಲ: www.habr.com