GKE ಪಾಡ್‌ಗಳು VPN ಮೂಲಕ ಆನ್-ಪ್ರೆಮ್ ಹೋಸ್ಟ್‌ಗಳನ್ನು ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲದ ಕಾರಣ

ನೋಡ್‌ನಿಂದ ಪಿಂಗ್ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಮತ್ತು ಪಾಡ್‌ನಿಂದ ವಿಫಲವಾಗುತ್ತದೆ, ಮತ್ತು ಆನ್-ಪ್ರೆಮ್‌ಗೆ ಏನೂ ತಲುಪುವುದಿಲ್ಲ. ಸುರಂಗ ಮತ್ತು ಮಾರ್ಗ ಸರಿಯಾಗಿದೆ; ತಂತಿಯ ಮೇಲಿನ ಮೂಲ ವಿಳಾಸ ಸರಿಯಾಗಿಲ್ಲ. ಈ ಎರಡು ಸಂದರ್ಭಗಳ ನಡುವಿನ ವ್ಯತ್ಯಾಸವೆಂದರೆ ಕ್ಲಸ್ಟರ್ ಬಿಟ್ಟು ಹೊರಡುವಾಗ ಪ್ಯಾಕೆಟ್ ತಾನು ಏನೆಂದು ಹೇಳಿಕೊಳ್ಳುತ್ತದೆ ಎಂಬುದು, ಮತ್ತು GKE ಗೆ ಅದರ ಬಗ್ಗೆ ಅಭಿಪ್ರಾಯವಿದೆ. ಯಾಂತ್ರಿಕೆ masquerade ವಿನಾಯಿತಿ ಪಟ್ಟಿ, ಮತ್ತು ಅದನ್ನು ಓದಲು ಒಂದು ಆಜ್ಞೆ ಸಾಕು.

ಏನನ್ನೂ ಬದಲಿಸುವ ಮೊದಲು ಜಾರಿಯಲ್ಲಿರುವ ಪಟ್ಟಿಯನ್ನು ಓದಿ

GKE ಪ್ರತಿ ಗಮ್ಯಸ್ಥಾನ ಶ್ರೇಣಿಗೂ ಪಾಡ್ ಸಂಚಾರವು ಹೊರಹೋಗುವಾಗ ನೋಡ್ ವಿಳಾಸಕ್ಕೆ ಮರುಬರೆಯಬೇಕೇ ಎಂದು ನಿರ್ಧರಿಸುವ ಏಜೆಂಟ್ ಅನ್ನು ಒದಗಿಸುತ್ತದೆ. ಅದರ ಪೂರೈಸಿದ ಸಂರಚನೆ ಮೂರು RFC1918 ಬ್ಲಾಕ್‌ಗಳನ್ನು, 10.0.0.0/8, 172.16.0.0/12 ಮತ್ತು 192.168.0.0/16, ವಿನಾಯಿತಿ ಪಡೆದ ಗಮ್ಯಸ್ಥಾನಗಳೆಂದು ಹೆಸರಿಸುತ್ತದೆ. ಆದ್ದರಿಂದ ಪಾಡ್‌ನಿಂದ ಸ್ಥಳೀಯ 10.x ಹೋಸ್ಟ್‌ಗೆ ಕಳುಹಿಸುವ ಯಾವುದೇ ವಿಷಯವು ಪಾಡ್‌ನದೇ ವಿಳಾಸವನ್ನು ಇನ್ನೂ ಹೊಂದಿಕೊಂಡಂತೆಯೇ ನೋಡ್ ಬಿಡುತ್ತದೆ. ನೋಡ್‌ನ ಸ್ವಂತ ಸಂಚಾರ ಮರುಬರೆಯುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ಪಿಂಗ್ ಕೆಲಸ ಮಾಡುವುದಕ್ಕೆ ಅದೇ ಕಾರಣ.

ಉದ್ದೇಶಿತ ಸಂರಚನೆ ಮತ್ತು ಸ್ಥಾಪಿತ ನಿಯಮಗಳನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಅವು ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗದಿರಬಹುದು. kubectl -n kube-system get configmap ip-masq-agent -o yaml ಏಜೆಂಟ್‌ಗೆ ಏನು ಹೇಳಲಾಯಿತು ಎಂಬುದನ್ನು ತೋರಿಸುತ್ತದೆ, ಮತ್ತು kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ಅದನ್ನು ಅನ್ವಯಿಸಲು ಏನಾದರೂ ಚಾಲನೆಯಲ್ಲಿದೆಯೇ ಎಂದು ತೋರಿಸುತ್ತದೆ. ನೋಡ್‌ನಲ್ಲಿ iptables-save | grep -i masq ಕರ್ನಲ್‌ನಲ್ಲಿ ನಿಜವಾಗಿ ಇರುವ ನಿಯಮಗಳನ್ನು ತೋರಿಸುತ್ತದೆ. ConfigMap ಒಂದು ಹೇಳಿದಾಗ ನಿಯಮಗಳು ಇನ್ನೊಂದು ಹೇಳಿದರೆ, ಸಂಶಯಾಸ್ಪದ ವ್ಯಕ್ತಿ ಜಾಲವಲ್ಲ, ಏಜೆಂಟ್.

ಸೆರೆಹಿಡಿಯುವಿಕೆಯಿಂದ ಮೂಲ ವಿಳಾಸವನ್ನು ದೃಢೀಕರಿಸಿ

ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸುವ ಮೊದಲು ಸೆರೆಹಿಡಿಯಿರಿ. ಒಂದೇ ಗಮ್ಯಸ್ಥಾನದ ಮೇಲಿನ ಫಿಲ್ಟರ್ ಔಟ್‌ಪುಟ್ ಅನ್ನು ಓದಲು ಸಾಧ್ಯವಾಗಿಸುತ್ತದೆ: tcpdump -ni any host 10.20.30.40.

ಅದನ್ನು ಆಚೆಗಿನ ಬದಿ ವರದಿ ಮಾಡುವುದರೊಂದಿಗೆ ಹೋಲಿಸಿ. ಆನ್-ಪ್ರೆಮ್‌ನಲ್ಲಿ ಪಾಡ್ ವಿಳಾಸವನ್ನು ತೋರಿಸಿ ಉತ್ತರವಿಲ್ಲದ ಸೆರೆಹಿಡಿಯುವಿಕೆ ವೃತ್ತವನ್ನು ಮುಚ್ಚುತ್ತದೆ: ವಿನಾಯಿತಿ ಪಟ್ಟಿಯು ಯಾವುದೇ ಸುರಂಗ ದೋಷವಿಲ್ಲದೆ ಅಸಮಮಿತಿಯನ್ನು ವಿವರಿಸುತ್ತದೆ. ಒಂದೇ ಮೂಲ ವಿಳಾಸದ ಎರಡು ಅವಲೋಕನಗಳು CNI ಬಗ್ಗೆ ಊಹಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಲು ಸಾಕು.

ವಿನಾಯಿತಿಯನ್ನು ಪಾಡ್ CIDR ಗೆ ಸೀಮಿತಗೊಳಿಸಿ

ಬೆಂಬಲಿತ ದುರಸ್ತಿ ವಿನಾಯಿತಿಯನ್ನು ತೆಗೆದುಹಾಕುವ ಬದಲು ಸೀಮಿತಗೊಳಿಸುತ್ತದೆ: ಪಾಡ್ CIDR ಅನ್ನು ವಿನಾಯಿತಿಯಾಗಿ ಇರಿಸಿ ಮತ್ತು 10.x ಜಾಗದ ಉಳಿದ ಭಾಗವನ್ನು ಬಿಡಿ. ಆ ಪಟ್ಟಿ ಏಜೆಂಟ್‌ನ ConfigMap ನಲ್ಲಿ nonMasqueradeCIDRs ಅಡಿಯಲ್ಲಿ ಇರುತ್ತದೆ, ಮತ್ತು ಅದನ್ನು ಬದಲಿಸುವುದು ಸಂಪಾದನೆ, ನಂತರ ರೋಲ್‌ಔಟ್. ಅಗಲವಾದ ನಮೂದನ್ನು ಕ್ಲಸ್ಟರ್‌ನ ನಿಜವಾದ ಪಾಡ್ ಶ್ರೇಣಿಯಿಂದ ಬದಲಾಯಿಸಿ, ಕ್ಲಸ್ಟರ್ ಒಳಗಿನ ಸಂಚಾರಕ್ಕೆ ಇನ್ನೂ ಬೇಕಿದ್ದರೆ ಇತರ ಖಾಸಗಿ ಬ್ಲಾಕ್‌ಗಳನ್ನು ಇರಿಸಿ, ಮತ್ತು ಕಾರಣವಿಲ್ಲದಿದ್ದರೆ resyncInterval ಅನ್ನು ಹಾಗೆಯೇ ಬಿಡಿ. ಅನ್ವಯಿಸಿ, ಏಜೆಂಟ್ ಪಾಡ್‌ಗಳು ಮರುಪ್ರಾರಂಭವಾದದ್ದನ್ನು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಕರ್ನಲ್ ನಿಯಮಗಳು ಬದಲಾದದ್ದನ್ನು ದೃಢೀಕರಿಸಿ.

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

ಹಲವು ನೋಡ್ ಪೂಲ್‌ಗಳಿರುವ ಕ್ಲಸ್ಟರ್‌ನಲ್ಲಿ, ಪ್ರಭಾವಿತ ಪಾಡ್‌ಗಳು ನಿಜವಾಗಿ ಚಲಿಸುವ ನೋಡ್‌ಗಳಲ್ಲಿ ಏಜೆಂಟ್ ನಿಗದಿಯಾಗಿದೆಯೇ ಎಂದು ಪರಿಶೀಲಿಸಿ. DaemonSet ಇಲ್ಲದ ಪೂಲ್ ತನ್ನ ಹಳೆಯ ನಿಯಮಗಳನ್ನು ಉಳಿಸಿಕೊಳ್ಳುತ್ತದೆ, ಮತ್ತು ConfigMap ನಲ್ಲಿ ಅದನ್ನು ಯಾವುದೂ ತೋರಿಸುವುದಿಲ್ಲ.

ಪರ್ಯಾಯ ಮತ್ತು ಅದರ ವೆಚ್ಚ

ಇನ್ನೊಂದು ಆಯ್ಕೆ ಪಾಡ್ ವಿಳಾಸಗಳನ್ನು ಅಸ್ಪೃಶ್ಯವಾಗಿ ಇರಿಸಿ ಮಾರ್ಗಕ್ಕೆ ಅವುಗಳನ್ನು ಕಲಿಸುತ್ತದೆ. ಪಾಡ್ CIDR Cloud VPN ಸಂಚಾರ ಆಯ್ಕೆಗಾರರಿಗೆ ಹೋಗುತ್ತದೆ, ಮತ್ತು ಆನ್-ಪ್ರೆಮ್ ಬದಿಗೆ ಉತ್ತರಗಳು ಎಲ್ಲಿಗೆ ಹೋಗಬೇಕೆಂದು ತಿಳಿಯಲು ಅದಕ್ಕೆ ಮರಳು ಮಾರ್ಗ ಬೇಕು. ಇದು ಕೆಲವು ಭದ್ರತಾ ಮಾದರಿಗಳು ಬಯಸುವ ಪಾಡ್ ಗುರುತನ್ನು ಸಂರಕ್ಷಿಸುತ್ತದೆ, ಮತ್ತು ಆಚೆಗಿನ ಬದಿ ಒಪ್ಪಿಕೊಳ್ಳಬೇಕಾದ ಮಾರ್ಗನಿರ್ದೇಶನ ಮತ್ತು ಫೈರ್‍‌ವಾಲ್ ವ್ಯಾಪ್ತಿ ಎರಡನ್ನೂ ವಿಸ್ತರಿಸುತ್ತದೆ.

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

ಪರಿಶೀಲಿಸಿ ಮತ್ತು ಹಿಂತಿರುಗಿಸಿ

ಅದೇ ಸೆರೆಹಿಡಿಯುವಿಕೆಯನ್ನು ಮತ್ತೆ ನಡೆಸಿ. ನಿಮ್ಮ ಸಂಪಾದನೆಯ ನಂತರವೂ ನೋಡ್ ಮಟ್ಟದ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಪಾಡ್ ವಿಳಾಸವನ್ನು ಮುದ್ರಿಸಿದರೆ, ConfigMap ಏನೇ ಹೇಳಲಿ ನಿಯಮಗಳು ಎಂದೂ ಬದಲಾಗಿಲ್ಲ ಎಂದರ್ಥ. ತಂತಿಯೇ ಸತ್ಯ; ಉಳಿದೆಲ್ಲವೂ ಅನುಮಾನ.

ನಂತರ ವಿರುದ್ಧ ದಿಕ್ಕನ್ನು ಪರಿಶೀಲಿಸಿ, ಏಕೆಂದರೆ ಈ ಬದಲಾವಣೆಗಳ ಅರ್ಧದಷ್ಟು ಮಾತ್ರ ಹೊರಮುಖವಾಗಿ ಪರಿಶೀಲಿಸಲ್ಪಡುತ್ತದೆ. ಉತ್ತರವು ವಿನಂತಿ ಕಳುಹಿಸಿದ ನೋಡ್ ಅಥವಾ ಪಾಡ್ ಅನ್ನು ತಲುಪುತ್ತದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸಿ, ಮತ್ತು ಅಪ್ಲಿಕೇಶನ್ SYN ಮಾತ್ರ ಸ್ವೀಕರಿಸದೆ ಪೂರ್ಣಗೊಂಡಿದೆಯೇ ಎಂದು ದೃಢೀಕರಿಸಿ. ಉತ್ತರವಿಲ್ಲದ ವಿನಂತಿಯನ್ನು ತೋರಿಸುವ ಸೆರೆಹಿಡಿಯುವಿಕೆ ಆಚೆಗಿನ ಬದಿಯ ಮಾರ್ಗನಿರ್ದೇಶನ ಸಮಸ್ಯೆ, ಈ ಬದಿಯ masquerade ಸಮಸ್ಯೆಯಲ್ಲ.

ಹಿಂತಿರುಗಿಸುವುದು ಹಿಂದಿನ ConfigMap, ಅದೇ ರೀತಿಯಲ್ಲಿ ಅನ್ವಯಿಸಿ, ಏಜೆಂಟ್ ಮರುಪ್ರಾರಂಭವಾದ ಮತ್ತು ನಿಯಮಗಳು ಬದಲಾದ ಅದೇ ದೃಢೀಕರಣದೊಂದಿಗೆ. ಬದಲಾವಣೆ ದಾಖಲೆಯಲ್ಲಿ ಒಂದು ತಿಳಿದ ವಿನಂತಿಯ ಮೊದಲು ಮತ್ತು ನಂತರದ ಮೂಲ ವಿಳಾಸವನ್ನು ಇರಿಸಿ, ಏಕೆಂದರೆ ಆ ಒಂದೇ ಸಾಲು ಬದಲಾವಣೆ ನೀವು ಹೇಳಿದ್ದನ್ನು ಮಾಡಿತು ಎಂದು ಸಾಬೀತುಪಡಿಸುತ್ತದೆ. GKE IP masquerade ಏಜೆಂಟ್ ಮಾರ್ಗದರ್ಶಿ ಡೀಫಾಲ್ಟ್‌ಗಳು ಮತ್ತು ConfigMap ಕ್ಷೇತ್ರಗಳನ್ನು ದಾಖಲಿಸುತ್ತದೆ. ರೋಲ್‌ಔಟ್ ನಂತರ ಮೂಲ ವಿಳಾಸ ಬದಲಾಗದಿದ್ದರೆ, ಆ ನೋಡ್‌ನಲ್ಲಿ ಏಜೆಂಟ್ ಚಲಿಸುತ್ತಿಲ್ಲ ಮತ್ತು ಎಷ್ಟೇ YAML ಸಂಪಾದನೆ ಅದನ್ನು ಸರಿಪಡಿಸುವುದಿಲ್ಲ.