kubectl VPN ಮೇಲೆ ಏಕೆ ಕೆಲಸ ಮಾಡುತ್ತದೆ ಆದರೆ AKS ಸ್ಕೇಲಿಂಗ್ ಏಕೆ ನಿಲ್ಲಿಸುತ್ತದೆ

ನೀವು ಕಚೇರಿ VPN ನ ಸಾರ್ವಜನಿಕ ವಿಳಾಸವನ್ನು AKS API ಸರ್ವರ್‌ನ ಅನುಮತಿ ಪಟ್ಟಿಗೆ ಸೇರಿಸುತ್ತೀರಿ, ಮತ್ತು kubectl ಕೆಲಸ ಮಾಡುತ್ತದೆ. ಒಂದು ವಾರದ ನಂತರ node pool‌ನ ಸ್ಕೇಲ್-ಅಪ್ ವಿಫಲವಾಗುತ್ತದೆ, CI ಕಾರ್ಯವು ಕ್ಲಸ್ಟರ್ ತಲುಪಲು ಸಾಧ್ಯವಿಲ್ಲ, ಮತ್ತು ಪೋರ್ಟಲ್ IP ಶ್ರೇಣಿಗಳ ಬಗ್ಗೆ ಏನನ್ನೂ ಹೇಳದ ದೋಷವನ್ನು ತೋರಿಸುತ್ತದೆ. ಯಾರೂ ಅನುಮತಿ ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸಿಲ್ಲ. ನೀವು ಸಕ್ರಿಯಗೊಳಿಸಿದ ನಿಯಂತ್ರಣವು API ಸರ್ವರ್‌ನ ಮುಂದೆ ಇರುವ ಸಾರ್ವಜನಿಕ IP ಫಿಲ್ಟರ್ ಆಗಿದೆ, ಮತ್ತು ಯಾರು ಕರೆ ಮಾಡುತ್ತಿದ್ದಾರೆ ಎಂದು ಅದಕ್ಕೆ ಗೊತ್ತಿಲ್ಲ, ಕರೆ ಯಾವ ವಿಳಾಸದಿಂದ ಬಂತು ಎಷ್ಟೇ ಗೊತ್ತು. VPN ಕ್ಲಸ್ಟರ್‌ಗೆ ಬೇಕಾದ ಹಲವು ವಿಳಾಸಗಳಲ್ಲಿ ಒಂದು, ಮತ್ತು ಮೊದಲು ಒಡೆಯುವುದು ಅದೇ ಆಗಿರುವುದು ಅಪರೂಪ.

ಅನುಮತಿ ಪಟ್ಟಿ ವಿಳಾಸಕ್ಕೆ ಹೊಂದುತ್ತದೆ, ವ್ಯಕ್ತಿಗೆ ಅಲ್ಲ

--api-server-authorized-ip-ranges ಇದು CIDR ಬ್ಲಾಕ್‌ಗಳನ್ನು ಸ್ವೀಕರಿಸುತ್ತದೆ, ಬಳಕೆದಾರರು ಅಥವಾ ಗುಂಪುಗಳನ್ನಲ್ಲ. ಡೆವಲಪರ್‌ನ ವಿನಂತಿ VPN ಸರ್ವರ್ ಬಿಟ್ಟು Azure ಕಡೆಗೆ ಹೋದಾಗ, API ಸರ್ವರ್‌ನಲ್ಲಿನ ಮೂಲ ವಿಳಾಸ VPN ಸರ್ವರ್‌ನ ಸಾರ್ವಜನಿಕ ಹೊರಹರಿವು. ಆದ್ದರಿಂದ ಆ VPN ನಲ್ಲಿನ ಪ್ರತಿಯೊಬ್ಬರೂ ಒಂದೇ ನಮೂದನ್ನು ಹಂಚಿಕೊಳ್ಳುತ್ತಾರೆ, ಮತ್ತು VPN ನ ಹೊರಗಿನ ಯಾರನ್ನೂ ದೃಢೀಕರಣ ನಡೆಯುವ ಮೊದಲೇ ನಿರಾಕರಿಸಲಾಗುತ್ತದೆ.

ಇದರ ಅರ್ಥ ನಮೂದು ನೀವು ಉದ್ದೇಶಿಸಿದ್ದಕ್ಕಿಂತ ಹೆಚ್ಚು ಜನರನ್ನು ಒಳಗೆ ಬಿಡುತ್ತದೆ. VPN ಪ್ರವೇಶವಿರುವ ಗುತ್ತಿಗೆದಾರ, ಅದೇ ಕನ್ಸೆಂಟ್ರೇಟರ್‌ನಲ್ಲಿರುವ ವೈಯಕ್ತಿಕ ಲ್ಯಾಪ್‌ಟಾಪ್, ಮತ್ತು ಹ್ಯಾಕ್ ಆದ ಖಾತೆ ಎಲ್ಲರೂ ಒಂದೇ ವಿಳಾಸದಿಂದ ಬರುತ್ತಾರೆ. ಕ್ಲಸ್ಟರ್ ಅಧಿಕಾರ ಬದಲಾಗಿಲ್ಲ, ಆದ್ದರಿಂದ ಪಾತ್ರ-ಆಧಾರಿತ ಪ್ರವೇಶ ನಿಯಂತ್ರಣವೇ ಕರೆ ಮಾಡುವವರು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ, ಆದರೆ ಅನುಮತಿ ಪಟ್ಟಿ ಗುರುತಿನ ನಿಯಂತ್ರಣವಲ್ಲ ಮತ್ತು ಅದನ್ನು ಹಾಗೆ ವಿವರಿಸಬಾರದು.

ಮೊದಲು ಒಡೆಯುವುದು ಸಾಮಾನ್ಯವಾಗಿ kubectl ಅಲ್ಲ

ಅನುಮತಿ ಪಟ್ಟಿ API ಸರ್ವರ್‌ನ ಸಾರ್ವಜನಿಕ ಎಂಡ್‌ಪಾಯಿಂಟ್‌ಗೆ ಅನ್ವಯಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ ನಿಮ್ಮ ಪಟ್ಟಿ ಮಾಡಿದ ವಿಳಾಸಗಳ ಹೊರಗಿನ ಎಲ್ಲವೂ ತಕ್ಷಣ ಕೆಲಸ ಮಾಡುವುದನ್ನು ನಿಲ್ಲಿಸುತ್ತದೆ. ಸ್ಪಷ್ಟ ಬಲಿಪಶುಗಳು VPN ಮಾರ್ಗವಿಲ್ಲದ ಎರಡನೇ ಕಚೇರಿ, ಹೋಸ್ಟ್ ಮಾಡಿದ ಪೈಪ್‌ಲೈನ್‌ನಲ್ಲಿ CI ರನ್ನರ್, ಮತ್ತು ಸಂಪರ್ಕಿಸಲು ಮರೆತ ಲ್ಯಾಪ್‌ಟಾಪ್. ಇವನ್ನು ಗುರುತಿಸುವುದು ಸುಲಭ ಏಕೆಂದರೆ ಒಬ್ಬ ಮನುಷ್ಯ ಕಾಯುತ್ತಿದ್ದಾನೆ.

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

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

ಇಡೀ ಪಟ್ಟಿಯನ್ನು ಒಂದೇ ಆಜ್ಞೆಯಲ್ಲಿ ನಿರ್ಮಿಸಿ

ಅಪ್‌ಡೇಟ್ ಪ್ಯಾರಾಮೀಟರ್ ನಮೂದನ್ನು ಸೇರಿಸುವ ಬದಲು ಇಡೀ ಪಟ್ಟಿಯನ್ನು ಬದಲಿಸುತ್ತದೆ, ಆದ್ದರಿಂದ VPN ವಿಳಾಸವನ್ನು ಮಾತ್ರ ಹೊತ್ತ ಆಜ್ಞೆ ಅಲ್ಲಿದ್ದ ಎಲ್ಲವನ್ನೂ ಸದ್ದಿಲ್ಲದೆ ಬಿಟ್ಟುಬಿಡುತ್ತದೆ. ಮೊದಲು ಪ್ರಸ್ತುತ ಮೌಲ್ಯವನ್ನು ಓದಿ, ಅದನ್ನು ಇಟ್ಟುಕೊಳ್ಳಿ, ಮತ್ತು ಒಕ್ಕೂಟವನ್ನು ಕಳುಹಿಸಿ:

az aks show -g rg-app -n aks-prod \
  --query apiServerAccessProfile.authorizedIpRanges -o tsv

az aks update -g rg-app -n aks-prod \
  --api-server-authorized-ip-ranges 203.0.113.10/32,198.51.100.0/24

ಇದನ್ನು ಅವಲಂಬಿಸುವ ಮೊದಲು VPN ಸರ್ವರ್‌ಗೆ ಕಾಯ್ದಿರಿಸಿದ ಸಾರ್ವಜನಿಕ IP ಬಳಸಿ. ಕ್ರಿಯಾತ್ಮಕ ವಿಳಾಸ ಮರುಸಂಪರ್ಕದಲ್ಲಿ ಬದಲಾಗುತ್ತದೆ, ಮತ್ತು ಪ್ರತಿ ಬದಲಾವಣೆಯೂ ಇನ್ನೂ ಅನುಮತಿಸಲಾದ ನೆಟ್‌ವರ್ಕ್‌ನಿಂದ ಯಾರಾದರೂ ಪಟ್ಟಿಯನ್ನು ನವೀಕರಿಸುವವರೆಗೆ ತಂಡವನ್ನು ಕ್ಲಸ್ಟರ್‌ನಿಂದ ಸದ್ದಿಲ್ಲದೆ ಹೊರಗೆ ಕೂಡಿಸುತ್ತದೆ. ಪುನರಾವರ್ತನೆಗಾಗಿ ಎರಡು VPN ಹೊರಹರಿವು ಬಿಂದುಗಳಿದ್ದರೆ ಎರಡನ್ನೂ ಪಟ್ಟಿ ಮಾಡಿ, ಏಕೆಂದರೆ ಫಿಲ್ಟರ್‌ಗೆ ಆದ್ಯತೆಯ ಮಾರ್ಗದ ಕಲ್ಪನೆ ಇಲ್ಲ.

ಮೊದಲ ಅನುಮತಿಸಲಾದ ಪ್ರಯತ್ನವೇ ಪರೀಕ್ಷೆಯಾಗುವಂತೆ ಬದಲಾವಣೆಯನ್ನು ಕ್ರಮಗೊಳಿಸಿ. ಹೊಸ ಪಟ್ಟಿಯನ್ನು ಘೋಷಿಸಿ, ಅನ್ವಯಿಸಿ, ಮತ್ತು ತಕ್ಷಣ VPN ನಿಂದ ಸಂಪರ್ಕಿಸಿ; ವಿರುದ್ಧ ಕ್ರಮದಲ್ಲಿ ಮಾಡಿದರೆ CIDR ಬ್ಲಾಕ್‌ನಲ್ಲಿನ ಟೈಪೊ ಸರಿಪಡಿಸಲು ಯಾರೂ API ಸರ್ವರ್ ತಲುಪಲಾಗದ ಕಿಟಕಿ ಉಳಿಯುತ್ತದೆ.

ಅನುಮತಿ ಪಟ್ಟಿ ಎಂದಿಗೂ ಏನನ್ನು ಆವರಿಸಿಲ್ಲ

ಅದು API ಸರ್ವರ್ ಅನ್ನು ಖಾಸಗಿಯಾಗಿಸುವುದಿಲ್ಲ. ಖಾಸಗಿ ಕ್ಲಸ್ಟರ್ ಖಾಸಗಿ ಎಂಡ್‌ಪಾಯಿಂಟ್ ಮತ್ತು ಖಾಸಗಿ DNS ಬಳಸುತ್ತದೆ, ಮತ್ತು ಅಧಿಕೃತ-ಶ್ರೇಣಿ ಪಟ್ಟಿ ಅದನ್ನು ಬದಲಿಸುವ ನಿಯಂತ್ರಣವಲ್ಲ. ಒಳಗೆ ಬಿಟ್ಟ ಕರೆ ಮಾಡುವವರು ಏನು ಮಾಡಬಹುದು ಎಂಬುದನ್ನೂ ಅದು ಬದಲಿಸುವುದಿಲ್ಲ, ಆದ್ದರಿಂದ ಸೋರಿಕೆಯಾದ ಅಡ್ಮಿನ್ kubeconfig ಯಾವುದೇ ಅನುಮತಿಸಲಾದ ವಿಳಾಸದಿಂದ ಇನ್ನೂ ಕೆಲಸ ಮಾಡುತ್ತದೆ. ರುಜುವಾತನ್ನು ಭದ್ರತಾ ಗಡಿ ಎಂದು ಮತ್ತು ಪಟ್ಟಿಯನ್ನು ನೆಟ್‌ವರ್ಕ್ ಅನುಕೂಲ ಎಂದು ಪರಿಗಣಿಸಿ.

ಅದಕ್ಕೂ ವರ್ಕ್‌ಲೋಡ್‌ಗಳಿಗೂ ಯಾವುದೇ ಸಂಬಂಧವಿಲ್ಲ. ಪಟ್ಟಿ ಸಕ್ರಿಯವಾಗಿದ್ದರೂ Pods ಮತ್ತು Services ಕೆಲಸ ಮಾಡುತ್ತಲೇ ಇರುತ್ತವೆ, ಮತ್ತು VPN ಮೂಲಕ ಅಪ್ಲಿಕೇಶನ್ ತಲುಪುವುದು ಪ್ರತ್ಯೇಕ ಸಮಸ್ಯೆ: ಕೇವಲ ಕ್ಲಸ್ಟರ್ IP ಹೊಂದಿರುವ Service ಗೆ ಲ್ಯಾಪ್‌ಟಾಪ್ ಅದನ್ನು ತೆರೆಯುವ ಮೊದಲು ಇನ್ನೂ ಆಂತರಿಕ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್, ingress ಅಥವಾ port-forward ಬೇಕು. ಈ ಎರಡು ವಿನ್ಯಾಸಗಳನ್ನು ಬೆರೆಸಿದರೆ ಡೆವಲಪರ್‌ಗಳನ್ನು ನಿರ್ಬಂಧಿಸುವುದಾಗಿ ಹೇಳಿಕೊಂಡು ಅಪ್ಲಿಕೇಶನ್‌ಗಳ ಬಗ್ಗೆ ವಾಸ್ತವವಾಗಿ ಏನನ್ನೂ ನಿರ್ಬಂಧಿಸದ ಬದಲಾವಣೆ ಟಿಕೆಟ್ ಸೃಷ್ಟಿಯಾಗುತ್ತದೆ.

ಎರಡೂ ಕಡೆಯಿಂದ ಪರಿಶೀಲಿಸಿ, ನಂತರ ಒಂದು ನಿಜವಾದ ಕಾರ್ಯಾಚರಣೆ ನಡೆಸಿ

VPN ನಲ್ಲಿ ಹೊಸ ಕ್ಲೈಂಟ್ ಮತ್ತು ಅದರ ಹೊರಗಿನ ಕ್ಲೈಂಟ್‌ನೊಂದಿಗೆ ಪರೀಕ್ಷಿಸಿ. ಹೊರಗಿನ ಪ್ರಯತ್ನವನ್ನು ಹೆಸರು ವಿಭೇದನದಲ್ಲಿ ಅಲ್ಲ, API ಸರ್ವರ್‌ನಲ್ಲಿ ನಿರಾಕರಿಸಬೇಕು; ಹೆಸರು ಪರಿಹರಿಸದಿದ್ದರೆ, ನೀವು DNS ಪರೀಕ್ಷಿಸುತ್ತಿದ್ದೀರಿ ಮತ್ತು ಫಿಲ್ಟರ್ ಬಗ್ಗೆ ಏನೂ ಕಲಿಯಲಿಲ್ಲ. ನಂತರ ಸಂವಾದಾತ್ಮಕ kubectl ಕರೆ ಅಲ್ಲದ ಕಾರ್ಯಾಚರಣೆಯನ್ನು ನಡೆಸಿ, ಉದಾಹರಣೆಗೆ node pool ಸ್ಕೇಲ್ ಅಥವಾ ಅಪ್‌ಗ್ರೇಡ್ ಪರಿಶೀಲನೆ, ಮತ್ತು ಆಗುತ್ತದೆ ಎಂದು ಭಾವಿಸುವ ಬದಲು ಪೂರ್ಣಗೊಂಡಿದೆ ಎಂದು ದೃಢೀಕರಿಸಿ.

ಬದಲಾವಣೆಯ ಪಕ್ಕದಲ್ಲಿ ಹಿಂದಿನ ಪಟ್ಟಿ ಮೌಲ್ಯವನ್ನು ದಾಖಲಿಸಿ, ಮತ್ತು ಟೈಪ್ ಮಾಡಿದ ಆಜ್ಞೆಯನ್ನು ನಂಬುವ ಬದಲು ಅಪ್‌ಡೇಟ್ ನಂತರ ಪರಿಣಾಮಕಾರಿ ಮೌಲ್ಯವನ್ನು ಮತ್ತೆ ಓದಿ. AKS ಅಧಿಕೃತ IP ಶ್ರೇಣಿ ದಾಖಲೆ ಬೆಂಬಲಿತ ಪ್ಯಾರಾಮೀಟರ್‌ಗಳನ್ನು ಮತ್ತು ಅದೇ ಪಟ್ಟಿಗೆ ಸೇರಿದ ಪ್ಲಾಟ್‌ಫಾರ್ಮ್ ಅಗತ್ಯಗಳನ್ನು ಪಟ್ಟಿ ಮಾಡುತ್ತದೆ, ಮತ್ತು ಬಹುಪಾಲು ಟಿಕೆಟ್ ವಿವರಣೆಗಳು ಬಿಟ್ಟುಬಿಡುವ ಭಾಗ ಅದೇ.