ಖಾಸಗಿ GKE ನೋಡ್ಗಳು kubectl ಯಾವ API ಬಳಸುತ್ತದೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದಿಲ್ಲ

ನೋಡ್ಗಳು ಖಾಸಗಿಯಾಗಿವೆ, VPN ಅವುಗಳನ್ನು ತಲುಪುತ್ತದೆ, ಆದರೂ kubectl ಕ್ಲಸ್ಟರ್ನೊಂದಿಗೆ ಮಾತನಾಡಲು ಸಾಧ್ಯವಿಲ್ಲ. ಈ ಎರಡು ಸಂಗತಿಗಳಿಗೆ ಪರಸ್ಪರ ಸಂಬಂಧವಿಲ್ಲ. kubectl ಬಳಸುವ ವಿಳಾಸವು ರುಜುವಾತುಗಳನ್ನು ಪಡೆದಾಗ kubeconfig ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಸರ್ವರ್ URL ನಿಂದ ಬರುತ್ತದೆ, ಮತ್ತು ನೀವು ಸೇರಿಸುವ ಯಾವುದೇ ಮಾರ್ಗವೂ ಅದನ್ನು ಬದಲಿಸುವುದಿಲ್ಲ. ಅಷ್ಟರಲ್ಲಿ, ನೋಡ್ಗಳು kubectl ತಲುಪಲು ಪ್ರಯತ್ನಿಸುತ್ತಿರುವ ವಸ್ತುವೇ ಅಲ್ಲ.

ಐದು ಪರಿಶೀಲನೆಗಳು, ಮುಖ್ಯವಾದ ಏಕೈಕ ಮೌಲ್ಯದಿಂದ ಪ್ರಾರಂಭಿಸಿ.

ಪರಿಶೀಲನೆ 1: kubeconfig ನಲ್ಲಿ ಸರ್ವರ್ URL ಓದಿ

ರುಜುವಾತುಗಳನ್ನು ಸುರಿಯದೆ ಎಂಡ್ಪಾಯಿಂಟ್ ಮುದ್ರಿಸಿ: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". ಆ ಒಂದೇ ಸ್ಟ್ರಿಂಗ್ ಕ್ಲೈಂಟ್ IP ವಿಳಾಸ, DNS ಹೆಸರು ಅಥವಾ ನೀವು ಉದ್ದೇಶಿಸದ ಬಾಹ್ಯ ವಿಳಾಸಕ್ಕೆ ತೋರಿಸುತ್ತಿದೆಯೇ ಎಂದು ಹೇಳುತ್ತದೆ. ಈ ತನಿಖೆಯಲ್ಲಿ ಉಳಿದ ಎಲ್ಲವೂ ಅದರಿಂದಲೇ ಬರುತ್ತದೆ.

URL ನೀವು ಸಂರಚಿಸಿದ್ದೀರಿ ಎಂದು ಭಾವಿಸಿದ ಎಂಡ್ಪಾಯಿಂಟ್ ಅಲ್ಲದಿದ್ದರೆ, ಉಳಿದ ರೋಗನಿರ್ಣಯವು ಗಮನ ಸೆಳೆಯುವುದಷ್ಟೇ.

ಪರಿಶೀಲನೆ 2: URL ಅನ್ನು ಎಂಡ್ಪಾಯಿಂಟ್ ಪ್ರಕಾರಕ್ಕೆ ಹೊಂದಿಸಿ

ಪ್ರಸ್ತುತ GKE IP ಆಧಾರಿತ ಮತ್ತು DNS ಆಧಾರಿತ ಎರಡೂ ನಿಯಂತ್ರಣ ಸಮತಲ ಪ್ರವೇಶವನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆ, ಮತ್ತು ನೀವು ಪಡೆಯುವ ರುಜುವಾತುಗಳು ಅವುಗಳಲ್ಲಿ ಒಂದನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತವೆ. gcloud container clusters get-credentials NAME --location REGION --internal-ip ಆಂತರಿಕ IP ಎಂಡ್ಪಾಯಿಂಟ್ ಬರೆಯುತ್ತದೆ, --dns-endpoint DNS ಆಧಾರಿತ ಪ್ರವೇಶವನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತದೆ. ಯಾವುದೇ ಫ್ಲ್ಯಾಗ್ ನೆಟ್ವರ್ಕ್ ಮಾರ್ಗವನ್ನು ಒದಗಿಸುವುದಿಲ್ಲ, ಇದು ರುಜುವಾತುಗಳನ್ನು ಪಡೆದರೆ ಸಂಪರ್ಕ ಸರಿಯಾಗುತ್ತದೆ ಎಂದು ನಿರೀಕ್ಷಿಸುವವರನ್ನು ಬೆಚ್ಚಿಬೀಳಿಸುತ್ತದೆ. ಉದ್ದೇಶಪೂರ್ವಕವಾಗಿ ಮತ್ತೆ ಪಡೆದು ನಂತರ URL ಅನ್ನು ಮತ್ತೆ ಓದಿ.

URL ಅನ್ನು ಮತ್ತೆ ಓದದೆ ಫ್ಲ್ಯಾಗ್ಗಳನ್ನು ಬದಲಿಸುವುದು ಲ್ಯಾಪ್ಟಾಪ್ ಎರಡು ಕ್ಲಸ್ಟರ್ಗಳ ರುಜುವಾತುಗಳೊಂದಿಗೆ ಮತ್ತು ಒಂದು ಗೊಂದಲದ ದೋಷದೊಂದಿಗೆ ಉಳಿಯುವ ದಾರಿ.

ಅಧಿಕೃತ-ನೆಟ್ವರ್ಕ್ ನಮೂದು ಬಾಹ್ಯ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಯಾರು ತಲುಪಬಹುದು ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುತ್ತದೆ ಮತ್ತು ಆಂತರಿಕ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಅನ್ವಯಿಸುವುದಿಲ್ಲ. ಖಾಸಗಿ ಮಾರ್ಗವನ್ನು ಪರೀಕ್ಷಿಸಲು ಅದನ್ನು ವಿಸ್ತರಿಸುವುದು ನಿಮ್ಮ ರೋಗನಿರ್ಣಯವನ್ನಲ್ಲ, ನಿಮ್ಮ ಒಡ್ಡುವಿಕೆಯನ್ನು ಬದಲಿಸುತ್ತದೆ.

ಪರಿಶೀಲನೆ 3: ಆ ಎಂಡ್ಪಾಯಿಂಟ್ಗೆ ಇರುವ ಮಾರ್ಗವನ್ನು ಸಾಬೀತುಪಡಿಸಿ

URL ಆಂತರಿಕ IP ಆಗಿದ್ದರೆ, ಕ್ಲೈಂಟ್ ನಿಜವಾಗಿ ಇರುವ ನೆಟ್ವರ್ಕ್ನಿಂದ ಮಾರ್ಗ, ಅನುಮತಿಸಲಾದ ಮೂಲ ಶ್ರೇಣಿ ಮತ್ತು ಕ್ಲಸ್ಟರ್ನ ಪ್ರಾದೇಶಿಕ ಅಥವಾ ಜಾಗತಿಕ ಪ್ರವೇಶ ಸೆಟ್ಟಿಂಗ್ ಪರಿಶೀಲಿಸಿ. ನಿಯಂತ್ರಣ ಸಮತಲದ ಶ್ರೇಣಿ ಮತ್ತು ನೋಡ್ ಸಬ್ನೆಟ್ ಒಂದೇ ಗಮ್ಯಸ್ಥಾನವಲ್ಲ, ಆದ್ದರಿಂದ ನೋಡ್ಗಳವರೆಗೆ ಕೆಲಸ ಮಾಡುವ ಮಾರ್ಗ ಎಂಡ್ಪಾಯಿಂಟ್ ಬಗ್ಗೆ ಏನನ್ನೂ ಸಾಬೀತುಪಡಿಸುವುದಿಲ್ಲ. DNS ಆಧಾರಿತ ಪ್ರವೇಶಕ್ಕೆ ಮಾರ್ಗವೆಂದರೆ ದಾಖಲಿತ Private Google Access ವ್ಯವಸ್ಥೆಯೊಂದಿಗೆ Google API ಸಂಪರ್ಕ, ಕೆಲಸಗಾರರ ಸಬ್ನೆಟ್ಗೆ ಮಾರ್ಗವಲ್ಲ. kubectl ಅನ್ನು ದೂಷಿಸುವ ಮೊದಲು ಸಾಮಾನ್ಯ TCP ಸಂಪರ್ಕದಿಂದ ಎಂಡ್ಪಾಯಿಂಟ್ ಪರೀಕ್ಷಿಸಿ.

ಟೈಮೌಟ್ ಮಾರ್ಗದ ಸಮಸ್ಯೆ. 403 ನೀತಿಯ ಸಮಸ್ಯೆ. ಅವುಗಳಿಗೆ ಒಂದೇ ಪರಿಹಾರವಿಲ್ಲ.

ಪರಿಶೀಲನೆ 4: ಲಾಗ್ಗಳು ಮತ್ತು exec ಅನ್ನು API ಕರೆಗಳಿಂದ ಬೇರ್ಪಡಿಸಿ

ಸಾಮಾನ್ಯ API ವಿನಂತಿಗಳು ಯಶಸ್ವಿಯಾಗಿ kubectl logs ಅಥವಾ kubectl exec ವಿಫಲವಾದರೆ, ನೀವು ಈಗಾಗಲೇ ಎಂಡ್ಪಾಯಿಂಟ್ ಆಯ್ಕೆಯನ್ನು ದಾಟಿದ್ದೀರಿ. ಆ ಕಾರ್ಯಾಚರಣೆಗಳಿಗೆ ಸಂಬಂಧಿತ Kubernetes ಅನುಮತಿಗಳು ಬೇಕು ಮತ್ತು ಅವು ನಿಯಂತ್ರಣ ಸಮತಲದಿಂದ ನೋಡ್ಗಳಿಗೆ ಸಂವಹನವನ್ನು ಅವಲಂಬಿಸಿವೆ, ಮತ್ತು ವೈಫಲ್ಯವು ಟೈಮೌಟ್ ಬದಲು Forbidden ಪ್ರತಿಕ್ರಿಯೆಯಾಗಿರಬಹುದು. ನೋಡ್ಗೆ SSH ಪ್ರವೇಶ ಸಂಪೂರ್ಣ ಬೇರೆ ಸೇವೆಯನ್ನು ಪರೀಕ್ಷಿಸುತ್ತದೆ ಮತ್ತು ಅವನ್ನು ಸ್ಥಾಪಿಸುವುದಿಲ್ಲ.

VPN ಟಿಕೆಟ್ ಮತ್ತೆ ತೆರೆಯುವ ಮೊದಲು ದೋಷದ ವರ್ಗವನ್ನು ಓದಿ, ಏಕೆಂದರೆ ಎರಡು ವರ್ಗಗಳು ಬೇರೆ ಬೇರೆ ಸ್ಥಳಗಳಲ್ಲಿ ವಾಸಿಸುತ್ತವೆ.

ಪರಿಶೀಲನೆ 5: ಮುಂದಿನ ವ್ಯಕ್ತಿಗಾಗಿ ಮೂರು ಅವಲೋಕನಗಳನ್ನು ಇರಿಸಿ

ಆಯ್ಕೆ ಮಾಡಿದ API URL, ಒಂದು ಅಧಿಕೃತ API ವಿನಂತಿ ಕೆಲಸ ಮಾಡುತ್ತದೆಯೇ, ಮತ್ತು ನಿಖರವಾಗಿ ಯಾವ ನಂತರದ ಕಾರ್ಯಾಚರಣೆ ವಿಫಲವಾಗುತ್ತದೆ ಎಂಬುದನ್ನು ದೋಷ ಪಠ್ಯದೊಂದಿಗೆ ದಾಖಲಿಸಿ. ಆ ಮೂರು ಸಾಲುಗಳು ಎಂಡ್ಪಾಯಿಂಟ್ ಆಯ್ಕೆಯನ್ನು ನೋಡ್ ಪ್ರವೇಶದಿಂದ ಬೇರ್ಪಡಿಸುತ್ತವೆ, ಮತ್ತು ಸಂಪೂರ್ಣ ಒಳ್ಳೆಯ VPN ಮಾರ್ಗವು ಅದು ಎಂದೂ ಸಾಗಿಸದ ವಿನಂತಿಯ ದೋಷಕ್ಕೆ ಗುರಿಯಾಗದಂತೆ ತಡೆಯುತ್ತವೆ.

ಮುಂದಿನ ಇಂಜಿನಿಯರ್ ಸುರಂಗ ಮುರಿದಿದೆಯೇ ಎಂದು ಕೇಳುತ್ತಾರೆ. ನಿಮ್ಮ ಟಿಪ್ಪಣಿ ಈಗಾಗಲೇ ಅದಕ್ಕೆ ಉತ್ತರಿಸಿರಬೇಕು.