ನೀವು vpn-gateway ಎಂಬ Pod ಅನ್ನು ನಿಯೋಜಿಸುತ್ತೀರಿ, ಪರೀಕ್ಷಾ ಕ್ಲೈಂಟ್ ಅನ್ನು ಅದರ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತೀರಿ ಮತ್ತು ಪ್ಯಾಕೆಟ್ಗಳು ಕಣ್ಮರೆಯಾಗುವುದನ್ನು ನೋಡುತ್ತೀರಿ. ಮ್ಯಾನಿಫೆಸ್ಟ್ನಲ್ಲಿ ಏನೂ ತಪ್ಪಿಲ್ಲ ಮತ್ತು kubelet ಗೆ ಯಾವುದೇ ದೂರಿಲ್ಲ. ಕಾರಣ ರಚನಾತ್ಮಕ, ಸಂರಚನಾತ್ಮಕವಲ್ಲ: Kubernetes ಪ್ರತಿ Pod ಗೆ ತನ್ನದೇ ನೆಟ್ವರ್ಕ್ ನೇಮ್ಸ್ಪೇಸ್ ನೀಡುತ್ತದೆ, ಆದ್ದರಿಂದ ಹೆಸರು, ಲೇಬಲ್ ಅಥವಾ ಹಂಚಿದ API ನೇಮ್ಸ್ಪೇಸ್ ಪ್ಯಾಕೆಟ್ಗಳು ಎಲ್ಲಿಗೆ ಹೋಗುತ್ತವೆ ಎಂಬುದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಆದ್ದರಿಂದ VPN ಸಂಚಾರ ಕ್ಲಸ್ಟರ್ನಿಂದ ಹೇಗೆ ಹೊರಬರುತ್ತದೆ ಎಂಬ ನಿರ್ಧಾರ ಮಾಲೀಕತ್ವದ ಪ್ರಶ್ನೆಯಿಂದ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ, ಕಂಟೇನರ್ ಇಮೇಜ್ಗಳಿಂದ ಅಲ್ಲ.

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

Pod ನ ಗಡಿ ನೇಮ್ಸ್ಪೇಸ್, ಜಂಪ್ ಹೋಸ್ಟ್ ಅಲ್ಲ

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

ಆದ್ದರಿಂದಲೇ ಗೇಟ್ವೇ-Pod ಮಾದರಿ ಮೇಲಿನಿಂದ ಏನಾದರೂ ನಿಜವಾಗಿ ಅದಕ್ಕೆ ಪ್ಯಾಕೆಟ್ಗಳನ್ನು ಕಳುಹಿಸಿದಾಗ ಮಾತ್ರ ಕೆಲಸ ಮಾಡುತ್ತದೆ: Service, ನೋಡ್ನಲ್ಲಿ ಸ್ಥಿರ ರೂಟ್, ಅಥವಾ CNI ಯಲ್ಲಿ ಸ್ಟೀರಿಂಗ್ ನೀತಿ. ಬರೀ ವಿಳಾಸ ಏನನ್ನೂ ಸೆಳೆಯುವುದಿಲ್ಲ.

ಪ್ರತಿ Pod ಗೆ ಸುರಂಗ ಏನು ಕೊಡುತ್ತದೆ ಮತ್ತು ಎಷ್ಟು ವೆಚ್ಚವಾಗುತ್ತದೆ

ವರ್ಕ್ಲೋಡ್ನ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ ಚಲಿಸುವ ಸುರಂಗ ಆ ವರ್ಕ್ಲೋಡ್ಗೆ ತನ್ನದೇ ಕ್ಲೈಂಟ್ ಗುರುತನ್ನು ನೀಡುತ್ತದೆ, ಅದನ್ನು ಅನೇಕ ದೂರಸ್ಥ ಪ್ರವೇಶ ಸೇವೆಗಳು ಸೆಷನ್ ಅನ್ನು ಅಧಿಕೃತಗೊಳಿಸುವ ಅಥವಾ ಲೆಕ್ಕಹಾಕುವ ಮೊದಲು ಬಯಸುತ್ತವೆ. ಹಾನಿಯ ತ್ರಿಜ್ಯವೂ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯುತ್ತದೆ: ಮುರಿದ ಸುರಂಗ ಎಲ್ಲವೂ ಬಳಸುವ ಹಂಚಿದ ಮಾರ್ಗದ ಬದಲು ಒಂದು Deployment ಅನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಅದು ಹೇಗೆ ಚಲಿಸುತ್ತದೆ ಎಂಬುದು ಅನುಷ್ಠಾನವನ್ನು ಅವಲಂಬಿಸಿದೆ, ಮತ್ತು ಇಲ್ಲಿಯೇ ಜನರು ತಪ್ಪಾಗಿ ಊಹಿಸುತ್ತಾರೆ.

ಕೇವಲ ಕರ್ನಲ್ ಸ್ಥಿತಿ ಬೇಕಾದ ಸೆಟಪ್ init ಕಂಟೇನರ್ನಲ್ಲಿ ಮುಗಿದು ಹೊರಬರಬಹುದು. Pod ನ ಇಡೀ ಜೀವಿತಾವಧಿಯಲ್ಲಿ ಜೀವಂತವಾಗಿರಬೇಕಾದ ಬಳಕೆದಾರ ಸ್ಥಳದ ಡೀಮನ್ಗೆ Kubernetes 1.29 ರಲ್ಲಿ ಸ್ಥಳೀಯ ಸೈಡ್ಕಾರ್ ಆಗಿ ಪರಿಚಯಿಸಲಾದ ಮರುಪ್ರಾರಂಭಿಸಬಹುದಾದ init ಕಂಟೇನರ್ ರೂಪ ಬೇಕು, ಮತ್ತು ಈ ವ್ಯತ್ಯಾಸ ಅಭಿರುಚಿಯಿಂದಲ್ಲ, ಸುರಂಗದ ಅನುಷ್ಠಾನದಿಂದ ಬರುತ್ತದೆ. ಈ ಮಾದರಿಯ ವೆಚ್ಚ ನಕಲು: ಪ್ರತಿ ಪ್ರತಿಕೃತಿ ದೃಢೀಕರಿಸುತ್ತದೆ, ತನ್ನದೇ ಸುರಂಗ ವಿಳಾಸವನ್ನು ಪಡೆಯುತ್ತದೆ ಮತ್ತು ದೂರಸ್ಥ ಸೆಷನ್ ಸ್ಲಾಟ್ ಬಳಸುತ್ತದೆ, ಆದ್ದರಿಂದ ಸ್ವಯಂ-ಸ್ಕೇಲಿಂಗ್ ಘಟನೆ ಕೊಂಡಿಯ ಇನ್ನೊಂದು ಬದಿಯಲ್ಲಿ ಸಾಮರ್ಥ್ಯದ ಘಟನೆಯಾಗುತ್ತದೆ. ಒಂದೇ ರುಜುವಾತನ್ನು ಎಲ್ಲಾ ಪ್ರತಿಕೃತಿಗಳಿಗೆ ನಕಲಿಸುವುದು ಆ ವೆಚ್ಚವನ್ನು ತೆಗೆದುಹಾಕುವುದಿಲ್ಲ, ಅದು ಆಡಿಟ್ ಜಾಡನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಸಾಮರ್ಥ್ಯಗಳೂ ಅದೇ ಪರಿಶೀಲನೆಗೆ ಅರ್ಹ, ಏಕೆಂದರೆ ತನ್ನ ನೇಮ್ಸ್ಪೇಸ್ನಲ್ಲಿ NET_ADMIN ಬಯಸುವ ಸುರಂಗಕ್ಕೆ privileged: true ಉದಾಹರಣೆಯ ಇಡೀ ಹೋಸ್ಟ್ನ ಅಧಿಕಾರವನ್ನು ಆನುವಂಶಿಕವಾಗಿ ಪಡೆಯಲು ಯಾವ ಕಾರಣವೂ ಇಲ್ಲ.

CNI ಎಗ್ರೆಸ್ ಅನ್ನು ಹೊಂದಿರುವಾಗ

CNI ಅದನ್ನು ಬೆಂಬಲಿಸಿದರೆ, ಎಗ್ರೆಸ್ ಗೇಟ್ವೇ ವರ್ಕ್ಲೋಡ್ ಮತ್ತು ಗಮ್ಯಸ್ಥಾನ ಶ್ರೇಣಿಯ ಮೂಲಕ ಸಂಚಾರವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ, ನಂತರ ಒಂದೇ ಊಹಿಸಬಹುದಾದ ಮೂಲ ವಿಳಾಸದ ಅಡಿಯಲ್ಲಿ ಆಯ್ದ ನೋಡ್ಗಳ ಮೂಲಕ ಕಳುಹಿಸುತ್ತದೆ. Cilium ನ ಆವೃತ್ತಿ ಸಾಮಾನ್ಯ ಉಲ್ಲೇಖವಾಗಿದೆ, ಮತ್ತು ಅದರ ದಾಖಲೆಗಳು ಈ ವೈಶಿಷ್ಟ್ಯಕ್ಕೆ ನಿರ್ದಿಷ್ಟ Cilium ಸಂರಚನೆ ಮತ್ತು ಸರಿಯಾದ ಇಂಟರ್ಫೇಸ್ ಹಾಗೂ ವಿಳಾಸಗಳನ್ನು ಹೊಂದಿರುವ ಗೇಟ್ವೇ ನೋಡ್ಗಳು ಬೇಕು ಎಂದು ಸ್ಪಷ್ಟವಾಗಿ ಹೇಳುತ್ತವೆ. ಇದು Pod ರಚಿಸಿದ ನಂತರದ ಆರಂಭಿಕ ಅವಧಿಯನ್ನೂ ಉಲ್ಲೇಖಿಸುತ್ತದೆ, ಆಗ ಸ್ಟೀರಿಂಗ್ ಇನ್ನೂ ಜಾರಿಯಾಗಿಲ್ಲ, ಇದು ಪಾದಟಿಪ್ಪಣಿ ಅಲ್ಲ, ವಿನ್ಯಾಸದ ಇನ್ಪುಟ್.

ಆ ವಿಳಂಬವನ್ನು ನಿಮ್ಮದೇ ಭರವಸೆಯ ವಿರುದ್ಧ ಓದಿ. ಬೇರೆ ಮಾರ್ಗದಿಂದ ಯಾವುದೇ ಸಂಚಾರ ಹೊರಹೋಗಬಾರದು ಎಂಬುದು ನಿಯಮವಾದರೆ, ಅಂತರದ ಸಮಯದಲ್ಲಿ ಕಳುಹಿಸುವ ಹೊಸ Pod ಅದನ್ನು ಈಗಾಗಲೇ ಮುರಿದಿದೆ, ಆದ್ದರಿಂದ ಪ್ರಾರಂಭಿಕ ಕ್ರಮಕ್ಕೆ ತನ್ನದೇ ಉತ್ತರ ಬೇಕು: ನೀತಿ ಜಾರಿಯಾಗುವವರೆಗೆ ಅಪ್ಲಿಕೇಶನ್ ಅನ್ನು ಹಿಡಿದಿಡಿ, ಅಥವಾ ಕಿಟಕಿಯನ್ನು ಒಪ್ಪಿಕೊಂಡು ದಾಖಲಿಸಿ.

ಪ್ರತಿಪಾದನೆಯನ್ನು ಸಂಕುಚಿತವಾಗಿಡಿ. ಎಗ್ರೆಸ್ ಗೇಟ್ವೇ ಮಾರ್ಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ ಅನುವಾದಿಸುತ್ತದೆ. ಅದು VPN ಅನ್ನು ಕೊನೆಗೊಳಿಸುವುದಿಲ್ಲ, ಮತ್ತು ಅದರ ಹಿಂದೆ ಬೆಂಬಲಿತ ಸಂಪರ್ಕವಿಲ್ಲದೆ ಕ್ಲಸ್ಟರ್ ಅನ್ನು ನಿಮ್ಮ ದೂರಸ್ಥ ನೆಟ್ವರ್ಕ್ನ ಕ್ಲೈಂಟ್ ಆಗಿ ಮಾಡುವುದಿಲ್ಲ.

QuestionPer-Pod tunnelCNI egress gateway
Who holds the client identityEach workloadThe gateway, shared
What scaling changesEnrollment and sessions per replicaThroughput and capacity per node
What the remote side seesDistinct addressesOne translated source
Failure scopeOne DeploymentEvery workload behind the gateway

ಅನುವಾದವು ದೂರದ ಬದಿ ಏನನ್ನು ನೋಡುತ್ತದೆ ಎಂಬುದನ್ನು ಮೌನವಾಗಿ ಬದಲಿಸುತ್ತದೆ

ಗೇಟ್ವೇ ಮೂಲವನ್ನು ಮರುಬರೆದ ನಂತರ ಪ್ರತಿ Pod ನ ವಿಳಾಸಗಳು ಹೋಗುತ್ತವೆ, ಆದ್ದರಿಂದ ಗುರುತಿನ ಆಧಾರಿತ ಅನುಮತಿ ಪಟ್ಟಿ ಒಂದೇ ಹಂಚಿದ ವಿಳಾಸದ ಆಧಾರಿತ ಪಟ್ಟಿಯಾಗುತ್ತದೆ. ಇದು ದೋಷವಲ್ಲ, ವಿನಿಮಯ: ನಿರ್ವಹಿಸಲು ಕಡಿಮೆ ನಿಯಮಗಳು, ಏನಾದರೂ ತಪ್ಪಾಗಿ ವರ್ತಿಸಿದಾಗ ಒರಟಾದ ಆರೋಪಣೆ.

ಅಪ್ಲಿಕೇಶನ್ ಮಟ್ಟದ ದೃಢೀಕರಣ ಮತ್ತು ವಿನಂತಿ ಲಾಗಿಂಗ್ ನೆಟ್ವರ್ಕ್ ಇನ್ನು ಹೇಳದ್ದನ್ನು ಹೊರಬೇಕು. ಗೇಟ್ವೇ ಸಾಮರ್ಥ್ಯ ಮತ್ತು ಬದಲಿಯನ್ನು ಹಂಚಿದ ಮೂಲಸೌಕರ್ಯವಾಗಿ ಪರಿಗಣಿಸಿ, ಏಕೆಂದರೆ ಒಂದೇ ನೋಡ್ ಮರುಬೂಟ್ ಈಗ ಅದರ ಹಿಂದಿನ ಪ್ರತಿ ವರ್ಕ್ಲೋಡ್ ಅನ್ನು ಅಡ್ಡಿಪಡಿಸುತ್ತದೆ, ಮತ್ತು ಹಿಂತಿರುಗುವ ಮಾರ್ಗವನ್ನು ಬೇಗನೆ ಪರಿಶೀಲಿಸಿ: ದೂರದ ತುದಿ ಅನುವಾದಿತ ವಿಳಾಸವನ್ನು ತಲುಪುವ ಬಗೆ ತಿಳಿದಿರಬೇಕು, ಸಾಮಾನ್ಯವಾಗಿ ಮನುಷ್ಯನಿಗೆ, ಮ್ಯಾನಿಫೆಸ್ಟ್ಗೆ ಅಲ್ಲ, ಸೇರಬೇಕಾದ ರೂಟ್ ಅಥವಾ NAT ಮೂಲಕ. ವಿಳಾಸ ಯೋಜನೆಯೂ ಇಲ್ಲಿಗೆ ಸೇರುತ್ತದೆ, ಏಕೆಂದರೆ ಅತಿಕ್ರಮಿಸುವ ಕ್ಲಸ್ಟರ್ ಮತ್ತು ದೂರಸ್ಥ ಶ್ರೇಣಿಗಳು ಎರಡೂ ಮಾದರಿಗಳನ್ನು ಮುರಿಯುತ್ತವೆ ಮತ್ತು IPv6 ಅಳವಡಿಸಿಕೊಳ್ಳುವುದು ವಿರೋಧಾತ್ಮಕ ಯೋಜನೆಗೆ ಸಮರ್ಥನೆಯಲ್ಲ.

ಮಾಲೀಕತ್ವದಿಂದ ನಿರ್ಧರಿಸಿ, ನಂತರ ಭರವಸೆ ನೀಡಿದ ವೈಫಲ್ಯವನ್ನು ಪರೀಕ್ಷಿಸಿ

ದೂರಸ್ಥ ಸೇವೆ ಪ್ರತ್ಯೇಕ ವರ್ಕ್ಲೋಡ್ಗಳನ್ನು ದೃಢೀಕರಿಸಿದಾಗ, ಕೆಲವೇ Deployment ಗೆ ಕೊಂಡಿ ಬೇಕಾದಾಗ, ಮತ್ತು ವೈಫಲ್ಯ ಸ್ಥಳೀಯವಾಗಿ ಉಳಿಯಬೇಕಾದಾಗ ಪ್ರತಿ Pod ಗೆ ಸುರಂಗವನ್ನು ಆಯ್ಕೆ ಮಾಡಿ. ನೆಟ್ವರ್ಕ್ ತಂಡ ಈಗಾಗಲೇ ಮಾರ್ಗವನ್ನು ಹೊಂದಿದ್ದಾಗ, ಅನೇಕ ವರ್ಕ್ಲೋಡ್ಗಳು ಒಂದೇ ಗಮ್ಯಸ್ಥಾನವನ್ನು ಹಂಚಿಕೊಂಡಾಗ, ಮತ್ತು ಸ್ಥಿರ ಮೂಲ ವಿಳಾಸವೇ ಇಡೀ ಅಭ್ಯಾಸದ ಉದ್ದೇಶವಾದಾಗ ಗೇಟ್ವೇ ಆಯ್ಕೆ ಮಾಡಿ.

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

ಸಂಬಂಧಿತ ಲೇಖನಗಳು