Pod, ನೋಡ್ ಅಥವಾ ಕ್ಲಸ್ಟರ್: VPN sidecar ನಿಜವಾಗಿ ಏನನ್ನು ಮರುಮಾರ್ಗ ಮಾಡುತ್ತದೆ

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

ಹಂಚಿದ namespace, ಹಂಚಿದ ಪರಿಣಾಮಗಳು

ಒಂದು Pod ನಲ್ಲಿನ ಎರಡು ಕಂಟೇನರ‍್ಗಳು loopback ಮೂಲಕ ಮಾತನಾಡುತ್ತವೆ ಮತ್ತು ಅದೇ ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ನೋಡುತ್ತವೆ, ಮತ್ತು ಆದ್ದರಿಂದಲೇ sidecar ಮಾದರಿ ಕೆಲಸ ಮಾಡುತ್ತದೆ: ಅಪ್ಲಿಕೇಶನ್‌ ಟನೆಲ್ ಇದೆ ಎಂದು ತಿಳಿಯಬೇಕಿಲ್ಲ, ಏಕೆಂದರೆ ಅದು ಪರಿಹರಿಸುವ ರೂಟ್ ಅದು ಬಳಸುವ namespace ನಲ್ಲಿ ಸ್ಥಾಪಿತವಾಗಿದೆ. ಅದೇ ಗುಣಲಕ್ಷಣವು sidecar ನ ತಪ್ಪುಗಳು ಅಪ್ಲಿಕೇಶನ್‌ನ ತಪ್ಪುಗಳು ಎಂದು ಅರ್ಥ. ಹೆಚ್ಚು ಹಿಡಿಯುವ ರೂಟ್, ಅಥವಾ ಟನೆಲ್ ಒಳಗಿನ ರಿಜಾಲ್ವರ್‌ಗೆ ತೋರಿಸುವ DNS ಬದಲಾವಣೆ, ಆ Pod ನ ಪ್ರತಿ ಪ್ರಕ್ರಿಯೆಗೂ ತಕ್ಷಣ ಅನ್ವಯವಾಗುತ್ತದೆ. ಹಂಚಿದ namespace ನಲ್ಲಿ ಕಂಟೇನರ್ ಪ್ರಕಾರ ರೂಟಿಂಗ್ ಇಲ್ಲ, ಆದ್ದರಿಂದ sidecar ಅನ್ನು ಒಂದು ಪ್ರಕ್ರಿಯೆಗೆ ಸೀಮಿತಗೊಳಿಸಲಾಗದು.

ಪರಿಶೀಲನೆಯ ಸಮಯದಲ್ಲಿ ನೆನಪಿಡಬೇಕಾದ ಕಾರ್ಯವಿಧಾನ ಇದು: ಪರಿಣಾಮದ ತ್ರಿಜ್ಯ Pod, ನೋಡ್ ಅಲ್ಲ ಮತ್ತು ಕ್ಲಸ್ಟರ್ ಅಲ್ಲ.

sidecar ತಲುಪದ ಜಾಗ

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

ಕ್ಲಸ್ಟರ್ ಸೇವೆಗಳ ಸಂಚಾರವು ಇನ್ನೊಂದು ಸಾಮಾನ್ಯ ಆಶ್ಚರ್ಯ. Pod ಒಳಗಿನ ಅಗಲವಾದ ಡೀಫಾಲ್ಟ್ ರೂಟ್ API ಸರ್ವರ್ ಅಥವಾ ClusterIP ಸೇವೆಗೆ ಉದ್ದೇಶಿಸಿದ ವಿನಂತಿಗಳನ್ನು ಹಿಡಿಯಬಹುದು, ಮತ್ತು ಅವು ನಂತರ ಟನೆಲ್ ಒಡೆದಂತೆ ಕಾಣುವ ರೀತಿಯಲ್ಲಿ ವಿಫಲವಾಗುತ್ತವೆ.

ರೂಟ್ ಯೋಜನೆ: Pod, ಸೇವೆ, ನೋಡ್ ಮತ್ತು VPN ಶ್ರೇಣಿಗಳು

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

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

ಪ್ರಾರಂಭ ಮತ್ತು ವೈಫಲ್ಯ ಸ್ಪಷ್ಟ ಸ್ಥಿತಿಗಳು

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

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

ಕ್ರಮವನ್ನು ವೈಫಲ್ಯ ಪರೀಕ್ಷೆಯೊಂದಿಗೆ ಜೋಡಿಸಿ. sidecar ಅನ್ನು ಕೊಲ್ಲಿರಿ ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಮೌನವಾಗಿ ಹಿಂದೆ ಸರಿಯುವ ಬದಲು ತನ್ನ ಉದ್ದೇಶಿತ ಎಗ್ರೆಸ್ ಅನ್ನು ಕಳೆದುಕೊಳ್ಳುತ್ತದೆ ಎಂದು ಖಚಿತಪಡಿಸಿ.

ಸಾಮರ್ಥ್ಯಗಳು, ನೀತಿಗಳು ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ ಕಂಟೇನರ್‌ನಿಂದ ಪರೀಕ್ಷೆ

ಇಂಟರ್‌ಫೇಸ್‌ಗಳನ್ನು ರಚಿಸಲು ಮತ್ತು ರೂಟ್‌ಗಳನ್ನು ಬದಲಿಸಲು ಬೇಕಾದ ಸಾಮರ್ಥ್ಯಗಳನ್ನು ನೀಡುವುದು ಸವಲತ್ತಿನ ನಿರ್ಧಾರ, ಮತ್ತು ಪ್ರತ್ಯೇಕಿಸಿದ Pod ಗೆ ಸೂಕ್ತವಾದ ಸವಲತ್ತು ನೋಡ್ ಸ್ಟಾಕ್‌ನಲ್ಲಿ ಸ್ವಯಂಚಾಲಿತವಾಗಿ ಸೂಕ್ತವಲ್ಲ. ಕ್ಲಸ್ಟರ್ ಬೆಂಬಲಿಸುವ ನೆಟ್‌ವರ್ಕ್ ಮತ್ತು ಭದ್ರತಾ ನೀತಿ ಕಾರ್ಯವಿಧಾನಗಳನ್ನು ಬಳಸಿ, ಮತ್ತು ಪ್ರತಿ CNI ಅಥವಾ ನೀತಿ ಅನುಷ್ಠಾನವು VPN ಇಂಟರ್‌ಫೇಸ್ ಅನ್ನು ಒಂದೇ ರೀತಿ ಪರಿಗಣಿಸುತ್ತದೆ ಎಂದು ಭಾವಿಸಬೇಡಿ; ವ್ಯತ್ಯಾಸಗಳು ನಿಮಗೆ ಮುಖ್ಯವಾದ ವೈಫಲ್ಯ ಪ್ರಕರಣಗಳಲ್ಲಿಯೇ ಕಾಣುತ್ತವೆ.

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

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