VPN ಸೈಡ್‌ಕಾರ್‌ಗೆ ಪ್ರಾರಂಭ ನಿಯಮ ಮತ್ತು ವಿಫಲತೆ ನಿಯಮ ಬೇಕು

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

ಕ್ರಮವು ಮೊದಲ ವಿನಂತಿಯನ್ನು ಮಾತ್ರ ತಡೆಯುತ್ತದೆ

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

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

ಗೇಟ್ ಏನನ್ನು ಗಮನಿಸುತ್ತದೆ ಎಂದು ಹೇಳಿ: ಪ್ರಕ್ರಿಯೆ ಇದೆ, ಇಂಟರ್‌ಫೇಸ್ ಇದೆ, handshake ಪೂರ್ಣಗೊಂಡಿದೆ. ಅವುಗಳಲ್ಲಿ ಪ್ರತಿಯೊಂದೂ “ಈ pod ಗೆ ಬೇಕಾದ ಗಮ್ಯಸ್ಥಾನಗಳಿಗೆ ಡೇಟಾ ಮಾರ್ಗ ಕೆಲಸ ಮಾಡುತ್ತದೆ” ಎಂಬುದಕ್ಕಿಂತ ದುರ್ಬಲ ಹೇಳಿಕೆ.

ಡೇಟಾ ಮಾರ್ಗವನ್ನು ಊಹಿಸುವ ಬದಲು ಜಾರಿಗೊಳಿಸಿ

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

ಒಂದು pod ನಲ್ಲಿನ ಕಂಟೇನರ್‌ಗಳು ಆ ನೇಮ್‌ಸ್ಪೇಸ್ ಅನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತವೆ, ಆದ್ದರಿಂದ ಜಾರಿಗೊಳಿಸುವ ಸ್ಥಳ ನೇಮ್‌ಸ್ಪೇಸ್ ಸ್ವತಃ. ನೀವು ಏನೇ ಬರೆದರೂ, ಅದು ಟನೆಲ್‌ನ ಸ್ವಂತ ಹೊರ ಸಂಪರ್ಕವನ್ನು ಲಭ್ಯವಾಗಿ ಬಿಡಬೇಕು, ಏಕೆಂದರೆ ಆ್ಯಪ್ ಅನ್ನು ರಕ್ಷಿಸಲು ಅದನ್ನು ನಿರ್ಬಂಧಿಸುವುದು ಆ್ಯಪ್‌ಗೆ ಬೇಕಾದ ಮಾರ್ಗವನ್ನು ಕಡಿತಗೊಳಿಸುತ್ತದೆ.

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

ನೀವು ಉಲ್ಲೇಖಿಸದ ಟ್ರಾಫಿಕ್ ಅನ್ನು ಪರೀಕ್ಷಿಸಿ

ನಿಯಂತ್ರಿತ ಟನೆಲ್ ವಿಫಲತೆಯ ಸಮಯದಲ್ಲಿ ಹೊಸ ವಿನಂತಿ ತೆಗೆದುಕೊಂಡು ಅದು ಹೊರಗೆ ಹೋಗುತ್ತದೆಯೇ ನೋಡಿ. ನಂತರ ನಿರ್ಗಮನ-ವಿಳಾಸ ಪರೀಕ್ಷೆ ಎಂದಿಗೂ ಮುಟ್ಟದ ಮಾರ್ಗಗಳಿಗೆ ಪರಿಶೀಲನೆಯನ್ನು ಪುನರಾವರ್ತಿಸಿ: ಕ್ಲಸ್ಟರ್ ಒಳಗಿನ DNS ರೆಸಲ್ಯೂಶನ್, IPv6 ಗಮ್ಯಸ್ಥಾನಗಳು, ಮತ್ತು ಸಾರ್ವಜನಿಕ ಇಂಟರ್ನೆಟ್ ಬದಲು ಕ್ಲಸ್ಟರ್-ಒಳ ವಿಳಾಸಗಳ ಮೂಲಕ ತಲುಪುವ ಸೇವೆಗಳು. ಟನೆಲ್ ಸತ್ತ ನಂತರವೂ ಸದ್ದಿಲ್ಲದೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗಗಳು ಇವು.

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

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

ನಿಯೋಜನೆ ದಾಖಲೆಯನ್ನು ಬರೆಯಿರಿ

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

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

ಕೊನೆಯದಾಗಿ, ಆ್ಯಪ್ ಚಾಲನೆಯಲ್ಲಿರುವಾಗ ಚೇತರಿಕೆ ಮಾರ್ಗವನ್ನು ಒಮ್ಮೆ ಪರೀಕ್ಷಿಸಿ. ನಿರ್ಗಮನವನ್ನು ಮರುಸ್ಥಾಪಿಸಲು pod ಅನ್ನು ಮತ್ತೆ ರಚಿಸುವ ಅಗತ್ಯವಿರುವ ವಿನ್ಯಾಸವು ಒಂದು ನಿರ್ಧಾರ, ಮತ್ತು ಅದು ನೀವು ತೆಗೆದುಕೊಂಡ ನಿರ್ಧಾರವಾಗಿರಬೇಕು, ನೀವು ಕಂಡುಕೊಂಡದ್ದಲ್ಲ.