VPC CNI ಜೊತೆಗೆ Pod VPC ಯಿಂದ ವಿಳಾಸವನ್ನು ಹೊಂದಬಹುದು, ಮತ್ತು ಸರಿಯಾದ ರೂಟ್ ಇರುವ VPN ಬಳಕೆದಾರರು ಅದನ್ನು ನೇರವಾಗಿ ತಲುಪಬಹುದು. ಇದು ನೇರ Pod ಪ್ರವೇಶವನ್ನು ಸರಳವಾದ ಆಯ್ಕೆಯಂತೆ ಕಾಣಿಸುತ್ತದೆ, ಮತ್ತು Pod ಬದಲಾಯಿಸುವವರೆಗೆ ಅದು ಹಾಗೆಯೇ. ಬಳಕೆದಾರರು ನೆನಪಿಟ್ಟುಕೊಳ್ಳುವ ವಿಳಾಸ ಅಪ್ಲಿಕೇಶನ್ಗೆ ಸೇರಿರಬೇಕು, ಪ್ರತಿರೂಪಕ್ಕಲ್ಲ. ಮೂರು ಪ್ರವೇಶಗಳ ಹೋಲಿಕೆ ಕೊನೆಗೆ ವಿಳಾಸ ಯಾವ ವಸ್ತುವಿನದು ಮತ್ತು ಕೆಲಸದ ಹೊರೆ ಸರಿದಾಗ ಏನು ಕೆಲಸ ಮಾಡುತ್ತಿರಬೇಕು ಎಂಬುದಕ್ಕೆ ಬರುತ್ತದೆ.

ಮೊದಲು ಜೀವನಚಕ್ರದ ಪ್ರಕಾರ ಆಯ್ಕೆಮಾಡಿ, ನಂತರ ಪ್ರವೇಶವನ್ನು ತಲುಪಬಹುದಾದಂತೆ ಮಾಡಲು ನೆಟ್ವರ್ಕ್ ಏನು ಮಾಡಬೇಕು ಎಂಬುದರ ಪ್ರಕಾರ.

ಮೂರು ಪ್ರವೇಶಗಳು, ಮೂರು ಜೀವನಚಕ್ರಗಳು

Pod IP ಯ ಮಾಲೀಕತ್ವ Pod ಗೆ ಇದೆ: ಅದರೊಂದಿಗೆ ಹಂಚಿಕೆಯಾಗುತ್ತದೆ ಮತ್ತು ಅದು ಮುಗಿದಾಗ ಬಿಡುಗಡೆಯಾಗುತ್ತದೆ. ClusterIP ಯ ಮಾಲೀಕತ್ವ Service ಗೆ ಇದೆ ಮತ್ತು ಅದು ವರ್ಚುವಲ್, ಕ್ಲಸ್ಟರ್ನ ಸೇವಾ ರೂಟಿಂಗ್ ಇರುವಲ್ಲಿಯೇ ಅದಕ್ಕೆ ಅರ್ಥವಿದೆ. ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ನ ಮಾಲೀಕತ್ವ ಕ್ಲೌಡ್ ಸಂಪನ್ಮೂಲಕ್ಕೆ ಇದೆ, ಅದನ್ನು ಕ್ಲಸ್ಟರ್ನ ನಿಯಂತ್ರಕ ಬ್ಯಾಕೆಂಡ್ಗಳೊಂದಿಗೆ ಪ್ರೋಗ್ರಾಂ ಮಾಡುತ್ತದೆ. ಈ ಮಾಲೀಕತ್ವ ಮಾದರಿಗಳು ನೀವು ಪಡೆಯುವ ವೈಫಲ್ಯವನ್ನು ಮುಂಚಿತವಾಗಿ ಹೇಳುತ್ತವೆ: ಹಳೆಯ ವಿಳಾಸ, ತಲುಪಲಾಗದ ಹೆಸರು, ಅಥವಾ ಹಳೆಯ ಬ್ಯಾಕೆಂಡ್ ಗುಂಪು.

ಆಯ್ಕೆ ಮಾಡುವ ಮೊದಲು ಹೋಲಿಕೆಯನ್ನು ಬರೆಯಿರಿ. ಮಾಲೀಕ ಮತ್ತು ವೈಫಲ್ಯವನ್ನು ಹೆಸರಿಸಿದ ನಂತರ ಆಯ್ಕೆ ಸಾಮಾನ್ಯವಾಗಿ ತಾನೇ ಆಗುತ್ತದೆ.

EntryOwnerFailure when the workload moves
Pod IPThe PodAddress changes and saved links break
ClusterIPThe ServiceVirtual address with no meaning outside cluster routing
Internal balancerCloud resource plus controllerBackends update, but the DNS view is yours to maintain

ನೇರ Pod ಪ್ರವೇಶ: ಉಪಯುಕ್ತ, ತಾತ್ಕಾಲಿಕ

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

ಇದು ಅಗಲವಾದ ನಿಯಮಗಳನ್ನೂ ಆಹ್ವಾನಿಸುತ್ತದೆ. ಒಬ್ಬ ನಿರ್ವಾಹಕರಿಗೆ ಒಂದು Pod ತಲುಪುವ ಅನುಮತಿ ನೋಡ್ ಉಪಜಾಲದ ಪ್ರತಿ ವಿಳಾಸಕ್ಕೂ ಅನುಮತಿಯಲ್ಲ, ಮತ್ತು ಸಾಮಾನ್ಯವಾಗಿ ಎರಡನೆಯದನ್ನೇ ಬರೆಯಲಾಗುತ್ತದೆ.

ClusterIP: ವಿನ್ಯಾಸದಿಂದ ಕ್ಲಸ್ಟರ್ಗೆ ಸೀಮಿತ

ClusterIP ಕೆಲಸ ಮಾಡುತ್ತದೆ ಏಕೆಂದರೆ ಕ್ಲಸ್ಟರ್ನ ಡೇಟಾಪ್ಲೇನ್ ಅದಕ್ಕೆ ಕ್ಲಸ್ಟರ್ ಒಳಗೆ ರೂಟಿಂಗ್ ಪ್ರೋಗ್ರಾಂ ಮಾಡುತ್ತದೆ. VPN ನಲ್ಲಿರುವ ಲ್ಯಾಪ್ಟಾಪ್ನಿಂದ ವಿಳಾಸಕ್ಕೆ ಏನೂ ಅರ್ಥವಿಲ್ಲ, ಯಾವುದೋ ಅದನ್ನು ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಬಹಿರಂಗಪಡಿಸದಿದ್ದರೆ. svc.cluster.local ನಲ್ಲಿ ಕೊನೆಗೊಳ್ಳುವ ಹೆಸರು ಕ್ಲಸ್ಟರ್ DNS ನದು, ಆದ್ದರಿಂದ ಅದನ್ನು ಬೇರೆ ರಿಜಾಲ್ವರ್ ಇರುವ ಕ್ಲೈಂಟ್ಗೆ ನಕಲಿಸುವುದು ರೂಟಿಂಗ್ ದೋಷದ ಬದಲು ಅಸ್ತಿತ್ವದಲ್ಲಿಲ್ಲದ ಹೆಸರನ್ನು ನೀಡುತ್ತದೆ.

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

ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್: ಪ್ರಕಟಿತ ಮಾರ್ಗ

ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್ ನಿಮಗೆ ಸ್ಥಿರವಾದ ಖಾಸಗಿ ವಿಳಾಸ ಮತ್ತು ನಿಮ್ಮ ವಲಯವು ಸೂಚಿಸಬಹುದಾದ ಹೆಸರನ್ನು ನೀಡುತ್ತದೆ, ಆದರೆ ನಿಯಂತ್ರಕವು ಬ್ಯಾಕೆಂಡ್ ಗುಂಪನ್ನು ನವೀಕೃತವಾಗಿ ಇಡುತ್ತದೆ, EKS ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮಾರ್ಗದರ್ಶಿ ವಿವರಿಸುವಂತೆ. ಸಾಮಾನ್ಯ Pod ಬದಲಾವಣೆಯನ್ನು ಯಾರೂ ದಾಖಲೆ ಸಂಪಾದಿಸದೆ ದಾಟುವ ಪ್ರವೇಶ ಅದೇ. ಅದರ ವೆಚ್ಚ ಕ್ಲೌಡ್ ಸಂಪನ್ಮೂಲ, ನಿಯಂತ್ರಕ ಸಂರಚನೆ ಮತ್ತು VPN ನಿಂದ ಒಂದು ರೂಟ್, ಮತ್ತು ಜನರು ಕಡಿಮೆ ಅಂದಾಜು ಮಾಡುವುದು ಈ ಭಾಗಗಳನ್ನೇ.

ಕ್ಲಸ್ಟರ್ ನಿಜವಾಗಿ ಚಲಾಯಿಸುವ ನಿಯಂತ್ರಕ ಮಾದರಿಯನ್ನು ಬಳಸಿ. ಒಂದು ಸಂಯೋಜನೆಗೆ ಬರೆದ ಟಿಪ್ಪಣಿಗಳು ಇನ್ನೊಂದಕ್ಕೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ.

ಮೂಲ ವಿಳಾಸ ಯಾರು

ಭದ್ರತಾ ಗುಂಪುಗಳು ತಮ್ಮ ಗಡಿಗೆ ಬರುವ ಮೂಲವನ್ನು ನೋಡುತ್ತವೆ, ಅದು VPN ಮತ್ತು ಲೋಡ್-ಬ್ಯಾಲೆನ್ಸಿಂಗ್ ಮಾರ್ಗವನ್ನು ಅವಲಂಬಿಸಿ ಸಂಪರ್ಕಿತ ಕ್ಲೈಂಟ್ ಅಥವಾ ಅನುವಾದಿತ ವಿಳಾಸವಾಗಿರಬಹುದು. EC2 ಆಧಾರಿತ ನೋಡ್ಗಳಲ್ಲಿ ಸಾಮಾನ್ಯ VPC CNI Pod ಗಳು ಡೀಫಾಲ್ಟ್ ಆಗಿ ನೋಡ್ನ ENI ಗುಂಪುಗಳನ್ನು ಬಳುವಳಿಯಾಗಿ ಪಡೆಯುತ್ತವೆ, ಆದರೆ ಬೆಂಬಲಿತ ಸಂರಚನೆಗಳು Pod-ನಿರ್ದಿಷ್ಟ ಗುಂಪುಗಳನ್ನು ಜೋಡಿಸಬಹುದು. ಊಹಿಸಿದ ಲ್ಯಾಪ್ಟಾಪ್ ವಿಳಾಸಕ್ಕಲ್ಲ, ದಾಖಲಿತ ಮಾರ್ಗಕ್ಕೆ ನಿಯಮಗಳನ್ನು ಬರೆಯಿರಿ.

ಅಪ್ಲಿಕೇಶನ್ನ ಸ್ವಂತ ಶ್ರೋತ ಮತ್ತು ದೃಢೀಕರಣವನ್ನು ಪ್ರತ್ಯೇಕ ನಿಯಂತ್ರಣಗಳಾಗಿ ಇರಿಸಿ. ಹರಿವನ್ನು ಅನುಮತಿಸುವ ನೆಟ್ವರ್ಕ್ ನಿಯಮ ಅಧಿಕಾರದ ನಿರ್ಣಯವಲ್ಲ ಮತ್ತು ಹಾಗೆ ಪರಿಗಣಿಸಬಾರದು.

ಬಳಕೆದಾರರಿಗೆ ಏನು ನೀಡಬೇಕು

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

Pod ಗೆ ನೇರ ಪ್ರವೇಶವನ್ನು ತನ್ನದೇ ವ್ಯಾಪ್ತಿಯ ದಾಖಲಿತ ಕಾರ್ಯಾಚರಣೆ ವಿನಾಯಿತಿಯಾಗಿ, ಬಳಕೆದಾರ ಸೂಚನೆಗಳಿಂದ ದೂರ ಇರಿಸಿ.

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