ಕುಬರ್ನೆಟ್ಸ್ ಕಂಟೈನರ್‌ಗಳಿಗೆ ಉತ್ತಮ ಅಭ್ಯಾಸಗಳು: ಆರೋಗ್ಯ ತಪಾಸಣೆ

ಟಿಎಲ್; ಡಿಆರ್

• ಕಂಟೈನರ್‌ಗಳು ಮತ್ತು ಮೈಕ್ರೋ ಸರ್ವೀಸ್‌ಗಳ ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆಯನ್ನು ಸಾಧಿಸಲು, ಲಾಗ್‌ಗಳು ಮತ್ತು ಪ್ರಾಥಮಿಕ ಮೆಟ್ರಿಕ್‌ಗಳು ಸಾಕಾಗುವುದಿಲ್ಲ.
• ವೇಗವಾಗಿ ಚೇತರಿಸಿಕೊಳ್ಳಲು ಮತ್ತು ಹೆಚ್ಚಿದ ಸ್ಥಿತಿಸ್ಥಾಪಕತ್ವಕ್ಕಾಗಿ, ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಹೈ ಅಬ್ಸರ್ವೆಬಿಲಿಟಿ ಪ್ರಿನ್ಸಿಪಲ್ (HOP) ಅನ್ನು ಅನ್ವಯಿಸಬೇಕು.
• ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದಲ್ಲಿ, NOP ಗೆ ಅಗತ್ಯವಿದೆ: ಸರಿಯಾದ ಲಾಗಿಂಗ್, ನಿಕಟ ಮೇಲ್ವಿಚಾರಣೆ, ವಿವೇಕ ತಪಾಸಣೆ ಮತ್ತು ಕಾರ್ಯಕ್ಷಮತೆ/ಪರಿವರ್ತನೆ ಪತ್ತೆಹಚ್ಚುವಿಕೆ.
• NOR ನ ಅಂಶವಾಗಿ ಚೆಕ್‌ಗಳನ್ನು ಬಳಸಿ ಸಿದ್ಧತೆ ತನಿಖೆ и ಜೀವಂತಿಕೆ ಪ್ರೋಬ್ ಕುಬರ್ನೆಟ್ಸ್.

ಆರೋಗ್ಯ ತಪಾಸಣೆ ಟೆಂಪ್ಲೇಟ್ ಎಂದರೇನು?

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

ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆಯ ತತ್ವ (HOP)

ಹೆಚ್ಚಿನ ವೀಕ್ಷಣೆಯ ತತ್ವವು ಒಂದಾಗಿದೆ ಕಂಟೈನರೈಸ್ಡ್ ಅಪ್ಲಿಕೇಶನ್‌ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸಲು ತತ್ವಗಳು. ಮೈಕ್ರೊ ಸರ್ವೀಸ್ ಆರ್ಕಿಟೆಕ್ಚರ್‌ನಲ್ಲಿ, ಸೇವೆಗಳು ತಮ್ಮ ವಿನಂತಿಯನ್ನು ಹೇಗೆ ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಲಾಗುತ್ತದೆ ಎಂಬುದರ ಬಗ್ಗೆ ಕಾಳಜಿ ವಹಿಸುವುದಿಲ್ಲ (ಮತ್ತು ಸರಿಯಾಗಿ), ಆದರೆ ಸ್ವೀಕರಿಸುವ ಸೇವೆಗಳಿಂದ ಅವರು ಹೇಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತಾರೆ ಎಂಬುದು ಮುಖ್ಯವಾಗುತ್ತದೆ. ಉದಾಹರಣೆಗೆ, ಬಳಕೆದಾರರನ್ನು ದೃಢೀಕರಿಸಲು, ಒಂದು ಕಂಟೇನರ್ ಇನ್ನೊಂದಕ್ಕೆ HTTP ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುತ್ತದೆ, ನಿರ್ದಿಷ್ಟ ಸ್ವರೂಪದಲ್ಲಿ ಪ್ರತಿಕ್ರಿಯೆಯನ್ನು ನಿರೀಕ್ಷಿಸುತ್ತದೆ - ಅಷ್ಟೆ. PythonJS ಸಹ ವಿನಂತಿಯನ್ನು ಪ್ರಕ್ರಿಯೆಗೊಳಿಸಬಹುದು ಮತ್ತು ಪೈಥಾನ್ ಫ್ಲಾಸ್ಕ್ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು. ಕಂಟೇನರ್‌ಗಳು ಒಂದಕ್ಕೊಂದು ಗುಪ್ತ ವಿಷಯಗಳನ್ನು ಹೊಂದಿರುವ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಗಳಂತೆ. ಆದಾಗ್ಯೂ, NOP ತತ್ವವು ಪ್ರತಿ ಸೇವೆಯು ಎಷ್ಟು ಆರೋಗ್ಯಕರವಾಗಿದೆ ಎಂಬುದನ್ನು ಸೂಚಿಸುವ ಬಹು API ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಬಹಿರಂಗಪಡಿಸುವ ಅಗತ್ಯವಿದೆ, ಹಾಗೆಯೇ ಅದರ ಸಿದ್ಧತೆ ಮತ್ತು ದೋಷ ಸಹಿಷ್ಣುತೆಯ ಸ್ಥಿತಿಯನ್ನು ಸೂಚಿಸುತ್ತದೆ. ರೂಟಿಂಗ್ ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್‌ಗಾಗಿ ಮುಂದಿನ ಹಂತಗಳ ಮೂಲಕ ಯೋಚಿಸಲು Kubernetes ಈ ಸೂಚಕಗಳನ್ನು ವಿನಂತಿಸುತ್ತದೆ.

ಉತ್ತಮವಾಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾದ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್ ಸ್ಟ್ಯಾಂಡರ್ಡ್ I/O ಸ್ಟ್ರೀಮ್‌ಗಳಾದ STDERR ಮತ್ತು STDOUT ಅನ್ನು ಬಳಸಿಕೊಂಡು ಅದರ ಮುಖ್ಯ ಈವೆಂಟ್‌ಗಳನ್ನು ಲಾಗ್ ಮಾಡುತ್ತದೆ. ಮುಂದೆ ಒಂದು ಸಹಾಯಕ ಸೇವೆ ಬರುತ್ತದೆ, ಉದಾಹರಣೆಗೆ filebeat, logstash ಅಥವಾ fluentd, ಕೇಂದ್ರೀಕೃತ ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗೆ ಲಾಗ್‌ಗಳನ್ನು ತಲುಪಿಸುತ್ತದೆ (ಉದಾಹರಣೆಗೆ Prometheus) ಮತ್ತು ಲಾಗ್ ಸಂಗ್ರಹಣಾ ವ್ಯವಸ್ಥೆ (ELK ಸಾಫ್ಟ್‌ವೇರ್ ಸೂಟ್). ಕೆಳಗಿನ ರೇಖಾಚಿತ್ರವು ಆರೋಗ್ಯ ಪರೀಕ್ಷಾ ಮಾದರಿ ಮತ್ತು ಹೆಚ್ಚಿನ ವೀಕ್ಷಣಾ ತತ್ವದ ಪ್ರಕಾರ ಕ್ಲೌಡ್ ಅಪ್ಲಿಕೇಶನ್ ಹೇಗೆ ಕಾರ್ಯನಿರ್ವಹಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ನಲ್ಲಿ ಆರೋಗ್ಯ ತಪಾಸಣೆ ಮಾದರಿಯನ್ನು ಹೇಗೆ ಅನ್ವಯಿಸುವುದು?

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

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

ಲೈವ್ನೆಸ್ಪ್ರೋಬ್

ಸಮಯದಲ್ಲಿ ಜೀವಂತಿಕೆ ಪ್ರೋಬ್ kubelet 3 ರೀತಿಯ ತಪಾಸಣೆಗಳನ್ನು ನಿರ್ವಹಿಸುತ್ತದೆ: ಪಾಡ್ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ ವಿನಂತಿಗಳನ್ನು ಸ್ವೀಕರಿಸಲು ಮತ್ತು ಸಮರ್ಪಕವಾಗಿ ಪ್ರತಿಕ್ರಿಯಿಸಲು ಸಿದ್ಧವಾಗಿದೆಯೇ ಎಂಬುದನ್ನು ಸಹ ನಿರ್ಧರಿಸುತ್ತದೆ:

• ಪಾಡ್‌ಗೆ HTTP ವಿನಂತಿಯನ್ನು ಹೊಂದಿಸಿ. ಪ್ರತಿಕ್ರಿಯೆಯು 200 ರಿಂದ 399 ರವರೆಗಿನ ವ್ಯಾಪ್ತಿಯಲ್ಲಿ HTTP ಪ್ರತಿಕ್ರಿಯೆ ಕೋಡ್ ಅನ್ನು ಹೊಂದಿರಬೇಕು. ಹೀಗಾಗಿ, ಪ್ರಕ್ರಿಯೆಯು ಚಾಲನೆಯಲ್ಲಿದ್ದರೂ ಸಹ, 5xx ಮತ್ತು 4xx ಸಂಕೇತಗಳು ಪಾಡ್ ಸಮಸ್ಯೆಗಳನ್ನು ಹೊಂದಿದೆ ಎಂದು ಸಂಕೇತಿಸುತ್ತದೆ.
• HTTP ಅಲ್ಲದ ಸೇವೆಗಳೊಂದಿಗೆ ಪಾಡ್‌ಗಳನ್ನು ಪರೀಕ್ಷಿಸಲು (ಉದಾಹರಣೆಗೆ, ಪೋಸ್ಟ್‌ಫಿಕ್ಸ್ ಮೇಲ್ ಸರ್ವರ್), ನೀವು TCP ಸಂಪರ್ಕವನ್ನು ಸ್ಥಾಪಿಸುವ ಅಗತ್ಯವಿದೆ.
• ಪಾಡ್ (ಆಂತರಿಕವಾಗಿ) ಗಾಗಿ ಅನಿಯಂತ್ರಿತ ಆಜ್ಞೆಯನ್ನು ಕಾರ್ಯಗತಗೊಳಿಸಿ. ಕಮಾಂಡ್ ಕಂಪ್ಲೀಶನ್ ಕೋಡ್ 0 ಆಗಿದ್ದರೆ ಚೆಕ್ ಅನ್ನು ಯಶಸ್ವಿಯಾಗಿ ಪರಿಗಣಿಸಲಾಗುತ್ತದೆ.

ಇದು ಹೇಗೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಎಂಬುದಕ್ಕೆ ಒಂದು ಉದಾಹರಣೆ. ಮುಂದಿನ ಪಾಡ್ ವ್ಯಾಖ್ಯಾನವು HTTP ವಿನಂತಿಗಳ ಮೇಲೆ 500 ದೋಷವನ್ನು ಎಸೆಯುವ NodeJS ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಒಳಗೊಂಡಿದೆ. ಅಂತಹ ದೋಷವನ್ನು ಸ್ವೀಕರಿಸುವಾಗ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸಲಾಗಿದೆ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು, ನಾವು livenessProbe ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಬಳಸುತ್ತೇವೆ:

apiVersion: v1
kind: Pod
metadata:
 name: node500
spec:
 containers:
   - image: magalix/node500
     name: node500
     ports:
       - containerPort: 3000
         protocol: TCP
     livenessProbe:
       httpGet:
         path: /
         port: 3000
       initialDelaySeconds: 5

ಇದು ಯಾವುದೇ ಪಾಡ್ ವ್ಯಾಖ್ಯಾನಕ್ಕಿಂತ ಭಿನ್ನವಾಗಿಲ್ಲ, ಆದರೆ ನಾವು ವಸ್ತುವನ್ನು ಸೇರಿಸುತ್ತಿದ್ದೇವೆ .spec.containers.livenessProbe. ಪ್ಯಾರಾಮೀಟರ್ httpGet HTTP GET ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮಾರ್ಗವನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ (ನಮ್ಮ ಉದಾಹರಣೆಯಲ್ಲಿ ಇದು /, ಆದರೆ ಯುದ್ಧದ ಸನ್ನಿವೇಶಗಳಲ್ಲಿ ಏನಾದರೂ ಇರಬಹುದು /api/v1/status) ಮತ್ತೊಂದು ಲೈವ್‌ನೆಸ್ಪ್ರೋಬ್ ಪ್ಯಾರಾಮೀಟರ್ ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ initialDelaySeconds, ಇದು ನಿಗದಿತ ಸಂಖ್ಯೆಯ ಸೆಕೆಂಡುಗಳವರೆಗೆ ಕಾಯಲು ಪರಿಶೀಲನೆ ಕಾರ್ಯಾಚರಣೆಗೆ ಸೂಚನೆ ನೀಡುತ್ತದೆ. ಕಂಟೇನರ್ ಪ್ರಾರಂಭಿಸಲು ಸಮಯ ಬೇಕಾಗಿರುವುದರಿಂದ ವಿಳಂಬದ ಅಗತ್ಯವಿದೆ ಮತ್ತು ಮರುಪ್ರಾರಂಭಿಸಿದಾಗ ಅದು ಸ್ವಲ್ಪ ಸಮಯದವರೆಗೆ ಲಭ್ಯವಿರುವುದಿಲ್ಲ.

ಈ ಸೆಟ್ಟಿಂಗ್ ಅನ್ನು ಕ್ಲಸ್ಟರ್‌ಗೆ ಅನ್ವಯಿಸಲು, ಬಳಸಿ:

kubectl apply -f pod.yaml

ಕೆಲವು ಸೆಕೆಂಡುಗಳ ನಂತರ, ನೀವು ಈ ಕೆಳಗಿನ ಆಜ್ಞೆಯನ್ನು ಬಳಸಿಕೊಂಡು ಪಾಡ್‌ನ ವಿಷಯಗಳನ್ನು ಪರಿಶೀಲಿಸಬಹುದು:

kubectl describe pods node500

ಔಟ್ಪುಟ್ನ ಕೊನೆಯಲ್ಲಿ, ಹುಡುಕಿ ಅದು ಏನು.

ನೀವು ನೋಡುವಂತೆ, livenessProbe HTTP GET ವಿನಂತಿಯನ್ನು ಪ್ರಾರಂಭಿಸಿದೆ, ಕಂಟೇನರ್ ದೋಷ 500 ಅನ್ನು ರಚಿಸಿದೆ (ಇದನ್ನು ಮಾಡಲು ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಲಾಗಿದೆ), ಮತ್ತು kubelet ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸಿದೆ.

NideJS ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹೇಗೆ ಪ್ರೋಗ್ರಾಮ್ ಮಾಡಲಾಗಿದೆ ಎಂದು ನೀವು ಆಶ್ಚರ್ಯ ಪಡುತ್ತಿದ್ದರೆ, ಇಲ್ಲಿ app.js ಮತ್ತು Dockerfile ಅನ್ನು ಬಳಸಲಾಗಿದೆ:

app.js

var http = require('http');

var server = http.createServer(function(req, res) {
    res.writeHead(500, { "Content-type": "text/plain" });
    res.end("We have run into an errorn");
});

server.listen(3000, function() {
    console.log('Server is running at 3000')
})

ಡಾಕರ್‌ಫೈಲ್

FROM node
COPY app.js /
EXPOSE 3000
ENTRYPOINT [ "node","/app.js" ]

ಇದನ್ನು ಗಮನಿಸುವುದು ಮುಖ್ಯ: livenessProbe ಕಂಟೇನರ್ ವಿಫಲವಾದರೆ ಮಾತ್ರ ಅದನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ. ಮರುಪ್ರಾರಂಭವು ಕಂಟೇನರ್ ಅನ್ನು ಚಾಲನೆ ಮಾಡುವುದನ್ನು ತಡೆಯುವ ದೋಷವನ್ನು ಸರಿಪಡಿಸದಿದ್ದರೆ, ಸಮಸ್ಯೆಯನ್ನು ಸರಿಪಡಿಸಲು ಕ್ಯುಬೆಲೆಟ್ ಕ್ರಮ ತೆಗೆದುಕೊಳ್ಳಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ.

ಸಿದ್ಧತೆ ತನಿಖೆ

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

ರೆಡಿನೆಸ್ಪ್ರೋಬ್ ವ್ಯಾಖ್ಯಾನವನ್ನು ಬರೆಯೋಣ ಅದು GET ವಿನಂತಿಯ ಪ್ರತಿಕ್ರಿಯೆಯ ಸಮಯವನ್ನು ಎರಡು ಸೆಕೆಂಡುಗಳಿಗಿಂತ ಹೆಚ್ಚಿಲ್ಲದಂತೆ ಹೊಂದಿಸುತ್ತದೆ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ 5 ಸೆಕೆಂಡುಗಳ ನಂತರ GET ವಿನಂತಿಗೆ ಪ್ರತಿಕ್ರಿಯಿಸುತ್ತದೆ. Pod.yaml ಫೈಲ್ ಈ ರೀತಿ ಇರಬೇಕು:

apiVersion: v1
kind: Pod
metadata:
 name: nodedelayed
spec:
 containers:
   - image: afakharany/node_delayed
     name: nodedelayed
     ports:
       - containerPort: 3000
         protocol: TCP
     readinessProbe:
       httpGet:
         path: /
         port: 3000
       timeoutSeconds: 2

ನಾವು kubectl ನೊಂದಿಗೆ ಪಾಡ್ ಅನ್ನು ನಿಯೋಜಿಸೋಣ:

kubectl apply -f pod.yaml

ಒಂದೆರಡು ಸೆಕೆಂಡುಗಳ ಕಾಲ ಕಾಯೋಣ ಮತ್ತು ನಂತರ ಸನ್ನದ್ಧತೆ ಪ್ರೋಬ್ ಹೇಗೆ ಕೆಲಸ ಮಾಡಿದೆ ಎಂದು ನೋಡೋಣ:

kubectl describe pods nodedelayed

ಔಟ್ಪುಟ್ನ ಕೊನೆಯಲ್ಲಿ ಕೆಲವು ಘಟನೆಗಳು ಹೋಲುತ್ತವೆ ಎಂದು ನೀವು ನೋಡಬಹುದು ಇದು ಒಂದು.

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

ಈಗ ಪಾಡ್ ಆಫ್‌ಲೋಡ್ ಆಗಿರುವುದರಿಂದ, kubectl ಮಾರ್ಗಗಳು ಅದಕ್ಕೆ ಮತ್ತೆ ವಿನಂತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ಗಮನಿಸಿ: GET ವಿನಂತಿಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಗಳು ಇನ್ನು ಮುಂದೆ ವಿಳಂಬವಾಗುವುದಿಲ್ಲ.

ಹೋಲಿಕೆಗಾಗಿ, ಕೆಳಗೆ ಮಾರ್ಪಡಿಸಿದ app.js ಫೈಲ್ ಆಗಿದೆ:

var http = require('http');

var server = http.createServer(function(req, res) {
   const sleep = (milliseconds) => {
       return new Promise(resolve => setTimeout(resolve, milliseconds))
   }
   sleep(5000).then(() => {
       res.writeHead(200, { "Content-type": "text/plain" });
       res.end("Hellon");
   })
});

server.listen(3000, function() {
   console.log('Server is running at 3000')
})

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

ಇಂದು, ತಿದ್ದುಪಡಿಗಳನ್ನು ಬಹುತೇಕ ನೈಜ ಸಮಯದಲ್ಲಿ ಮಾಡಬೇಕಾಗಿದೆ, ಆದ್ದರಿಂದ ಅಪ್ಲಿಕೇಶನ್‌ಗಳು ಇನ್ನು ಮುಂದೆ ಕಪ್ಪು ಪೆಟ್ಟಿಗೆಗಳಾಗಿರಬೇಕಾಗಿಲ್ಲ. ಇಲ್ಲ, ಮೇಲ್ವಿಚಾರಣಾ ವ್ಯವಸ್ಥೆಗಳು ಪ್ರಕ್ರಿಯೆಗಳ ಸ್ಥಿತಿಯ ಬಗ್ಗೆ ಮೌಲ್ಯಯುತವಾದ ಡೇಟಾವನ್ನು ಪ್ರಶ್ನಿಸಲು ಮತ್ತು ಸಂಗ್ರಹಿಸಲು ಅನುಮತಿಸುವ ಅಂತಿಮ ಬಿಂದುಗಳನ್ನು ಅವರು ತೋರಿಸಬೇಕು ಇದರಿಂದ ಅವರು ಅಗತ್ಯವಿದ್ದರೆ ತಕ್ಷಣವೇ ಪ್ರತಿಕ್ರಿಯಿಸಬಹುದು. ಇದನ್ನು ಪರ್ಫಾರ್ಮೆನ್ಸ್ ಟೆಸ್ಟ್ ಡಿಸೈನ್ ಪ್ಯಾಟರ್ನ್ ಎಂದು ಕರೆಯಲಾಗುತ್ತದೆ, ಇದು ಹೈ ಅಬ್ಸರ್ವೆಬಿಲಿಟಿ ಪ್ರಿನ್ಸಿಪಲ್ (HOP) ಅನ್ನು ಅನುಸರಿಸುತ್ತದೆ.

ಕುಬರ್ನೆಟ್ಸ್ ಪೂರ್ವನಿಯೋಜಿತವಾಗಿ 2 ವಿಧದ ಆರೋಗ್ಯ ತಪಾಸಣೆಗಳನ್ನು ನೀಡುತ್ತದೆ: ರೆಡಿನೆಸ್ಪ್ರೋಬ್ ಮತ್ತು ಲೈವ್ನೆಸ್ಪ್ರೋಬ್. ಎರಡೂ ಒಂದೇ ರೀತಿಯ ಚೆಕ್‌ಗಳನ್ನು ಬಳಸುತ್ತವೆ (HTTP GET ವಿನಂತಿಗಳು, TCP ಸಂವಹನಗಳು ಮತ್ತು ಕಮಾಂಡ್ ಎಕ್ಸಿಕ್ಯೂಶನ್). ಪಾಡ್ಗಳಲ್ಲಿನ ಸಮಸ್ಯೆಗಳಿಗೆ ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿ ಅವರು ಯಾವ ನಿರ್ಧಾರಗಳನ್ನು ತೆಗೆದುಕೊಳ್ಳುತ್ತಾರೆ ಎಂಬುದರಲ್ಲಿ ಅವರು ಭಿನ್ನವಾಗಿರುತ್ತವೆ. livenessProbe ದೋಷವು ಮತ್ತೆ ಸಂಭವಿಸುವುದಿಲ್ಲ ಎಂಬ ಭರವಸೆಯಲ್ಲಿ ಕಂಟೇನರ್ ಅನ್ನು ಮರುಪ್ರಾರಂಭಿಸುತ್ತದೆ ಮತ್ತು ರೆಡಿನೆಸ್ಪ್ರೋಬ್ ಸಮಸ್ಯೆಯ ಕಾರಣವನ್ನು ಪರಿಹರಿಸುವವರೆಗೆ ಒಳಬರುವ ಟ್ರಾಫಿಕ್‌ನಿಂದ ಪಾಡ್ ಅನ್ನು ಪ್ರತ್ಯೇಕಿಸುತ್ತದೆ.

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

ಮೂಲ: www.habr.com