Οι ιδιωτικοί κόμβοι GKE δεν καθορίζουν ποιο API χρησιμοποιεί το kubectl

Οι κόμβοι είναι ιδιωτικοί, το VPN τους φτάνει και το kubectl εξακολουθεί να μην μπορεί να επικοινωνήσει με το σύμπλεγμα. Αυτά τα δύο γεγονότα δεν σχετίζονται. Η διεύθυνση που χρησιμοποιεί το kubectl προέρχεται από τη διεύθυνση URL του διακομιστή που αποθηκεύτηκε στο kubeconfig όταν ελήφθησαν τα διαπιστευτήρια, και καμία διαδρομή που προσθέτετε δεν την αλλάζει. Στο μεταξύ, οι κόμβοι δεν είναι καθόλου αυτό που το kubectl προσπαθεί να προσεγγίσει.

Πέντε έλεγχοι, ξεκινώντας από τη μόνη τιμή που έχει σημασία.

Έλεγχος 1: διαβάστε τη διεύθυνση URL του διακομιστή στο kubeconfig

Εκτυπώστε το τελικό σημείο χωρίς να εκθέσετε τα διαπιστευτήρια: 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, η διαδρομή είναι η συνδεσιμότητα με το Google API με την τεκμηριωμένη ρύθμιση Private Google Access, όχι διαδρομή προς το υποδίκτυο των εργαζόμενων κόμβων. Δοκιμάστε το τελικό σημείο με απλή σύνδεση TCP πριν κατηγορήσετε το kubectl.

Ένα timeout είναι πρόβλημα διαδρομής. Ένα 403 είναι πρόβλημα πολιτικής. Δεν μοιράζονται διόρθωση.

Έλεγχος 4: διαχωρίστε τα αρχεία καταγραφής και το exec από τις κλήσεις API

Αν τα συνηθισμένα αιτήματα API πετυχαίνουν και το kubectl logs ή το kubectl exec αποτυγχάνει, έχετε ήδη περάσει την επιλογή τελικού σημείου. Αυτές οι ενέργειες απαιτούν τα αντίστοιχα δικαιώματα Kubernetes και εξαρτώνται από την επικοινωνία του επιπέδου ελέγχου με τους κόμβους, και η αποτυχία μπορεί να είναι απάντηση Forbidden αντί για timeout. Η πρόσβαση SSH σε κόμβο δοκιμάζει μια εντελώς διαφορετική υπηρεσία και δεν τα καθιερώνει.

Διαβάστε την κλάση σφάλματος πριν ανοίξετε ξανά το δελτίο VPN, γιατί οι δύο κλάσεις ζουν σε διαφορετικά μέρη.

Έλεγχος 5: κρατήστε τρεις παρατηρήσεις για τον επόμενο άνθρωπο

Καταγράψτε τη διεύθυνση URL του API που επιλέχθηκε, αν λειτουργεί ένα εξουσιοδοτημένο αίτημα API και ποια ακριβώς επόμενη ενέργεια αποτυγχάνει, μαζί με το κείμενο του σφάλματος. Αυτές οι τρεις γραμμές διαχωρίζουν την επιλογή τελικού σημείου από την πρόσβαση στους κόμβους και εμποδίζουν μια απολύτως καλή διαδρομή VPN να κατηγορηθεί για αίτημα που ποτέ δεν μετέφερε.

Ο επόμενος μηχανικός θα ρωτήσει αν η σήραγγα είναι χαλασμένη. Το σημείωμά σας θα πρέπει να το έχει ήδη απαντήσει.