Το minikube δεν φτάνει σε ένα ιδιωτικό API; Ελέγξτε πρώτα τον οδηγό

Ο host, ο κόμβος και το Pod έχουν καθένα τις δικές του διαδρομές και τον δικό του resolver. Ονομάστε τον οδηγό, δοκιμάστε το ίδιο endpoint και από τα τρία και μετά διορθώστε το context που απέτυχε.

Ένα ιδιωτικό API απαντά από τον φορητό σας υπολογιστή και ένα Pod στο minikube δεν μπορεί να το φτάσει. Πριν αλλάξετε οτιδήποτε στον host, ονομάστε τον οδηγό πίσω από το ενεργό προφίλ, γιατί αυτό το ένα γεγονός καθορίζει από ποιο δίκτυο φεύγει στην πραγματικότητα το αίτημα. Στη συνέχεια δοκιμάστε το ίδιο endpoint από τον host, από τον κόμβο και από το Pod. Μόνο ένα από αυτά τα τρία είναι αυτό που απέτυχε, και μια λάθος υπόθεση κοστίζει ένα απόγευμα.

Βήμα 0: ονομάστε τον οδηγό και την προέλευση

Ρωτήστε το minikube ποιο προφίλ είναι ενεργό και πώς εκτελείται. Ένας οδηγός container βάζει τον κόμβο σε ένα container στον υπολογιστή σας, ένας οδηγός VM τον βάζει σε μια εικονική μηχανή, και ένας απομακρυσμένος οδηγός τον βάζει κάπου εντελώς αλλού.

minikube profile list
minikube status
kubectl config current-context

Από αυτό, σημειώστε από πού προέρχεται το αίτημα. Η απάντηση καθορίζει ποιος resolver και ποιες διαδρομές έχουν σημασία, και δεν είναι πάντα του host. Δύο προφίλ στον ίδιο φορητό υπολογιστή μπορούν να συμπεριφέρονται εντελώς διαφορετικά για το ίδιο URL.

ContextWhat has to work
Host processHost resolver and host route to the private destination
minikube nodeThe node's own resolver and its outbound path
PodPod DNS through cluster services plus the cluster network path

Βήμα 1: δοκιμάστε το ίδιο endpoint τρεις φορές

Χρησιμοποιήστε ένα ακίνδυνο endpoint και κρατήστε το hostname, τη θύρα και την οικογένεια διευθύνσεων ίδια και στις τρεις δοκιμές. Αν αλλάξετε οποιοδήποτε από αυτά μεταξύ εκτελέσεων, τα αποτελέσματα δεν είναι συγκρίσιμα.

curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
minikube ssh -- curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health
kubectl run probe --rm -it --image=curlimages/curl --restart=Never -- \
  curl -sS -o /dev/null -w '%{http_code}\n' https://api.corp.example/health

Ένα επιτυχημένο pull εικόνας από τον κόμβο δεν αποδεικνύει τίποτα για την επίλυση ονομάτων για έναν ιδιωτικό host. Ένα επιτυχημένο δημόσιο αίτημα αποδεικνύει ακόμη λιγότερα. Κρατήστε τα αποτελέσματα χωριστά ανά context, γιατί ένα μοτίβο σε τρεις γραμμές είναι διάγνωση και μια μεμονωμένη αποτυχία είναι στοιχείο.

Αν αποτύχει και η γραμμή του host, σταματήστε. Έχετε πρόβλημα δικτύου στον host και το cluster είναι περισπασμός.

Βήμα 2: διατηρήστε τη διαδρομή του host προς το cluster

Υπάρχει μια δεύτερη κατεύθυνση που οι άνθρωποι ξεχνούν: ο host πρέπει να συνεχίσει να φτάνει στο δικό του API και στις υπηρεσίες του cluster. Ένας πελάτης VPN μπορεί να εγκαταστήσει διαδρομές που ανταγωνίζονται τα προθέματα που χρησιμοποιεί το minikube για το δίκτυο κόμβων, το εύρος υπηρεσιών και το εύρος pods του.

Όταν συμβεί αυτό, το σύμπτωμα είναι μπερδεμένο, γιατί η σήραγγα λειτουργεί και το kubectl σταματά να αποκρίνεται ή ένα NodePort αρνείται συνδέσεις. Μοιάζει με βλάβη του cluster και είναι βλάβη δρομολόγησης του φορητού υπολογιστή.

Ελέγξτε τον πίνακα δρομολόγησης του host ως προς τα εύρη του minikube πριν κατηγορήσετε τη σήραγγα για οτιδήποτε άλλο. Η επικάλυψη συνήθως φαίνεται ως πιο συγκεκριμένη διαδρομή που δείχνει στη διεπαφή της σήραγγας για ένα πρόθεμα που το cluster θεωρεί δικό του.

Βήμα 3: λύστε την επικάλυψη χωρίς να απενεργοποιήσετε το VPN

Το ίδιο το εγχειρίδιο VPN και proxy του minikube συζητά αυτές τις συγκρούσεις και αντιμετωπίζει τα παραδείγματα ευρών του ως πράγματα προς επιθεώρηση, όχι ως καθολική λίστα. Διαβάστε το μαζί με το προφίλ που έχετε πραγματικά.

Όπου υπάρχει πραγματική επικάλυψη, η υποστηριζόμενη απάντηση είναι ένα εύρος χωρίς επικάλυψη ή μια σκόπιμη πολιτική τοπικής πρόσβασης εγκεκριμένη από τον ιδιοκτήτη του VPN. Η αλλαγή του εύρους υπηρεσιών δεν είναι το ίδιο με την αλλαγή του εύρους pods, και καμία από τις δύο δεν είναι το ίδιο με την αλλαγή του δικτύου κόμβων.

Η απενεργοποίηση της εταιρικής σήραγγας για να λειτουργήσει ένα τοπικό cluster δεν είναι λύση παράκαμψης· είναι απόφαση πολιτικής που πρέπει να πάρει κάποιος άλλος. Πηγαίνετε την σε αυτό το άτομο αντί να το κάνετε ήσυχα αφού όλοι οι άλλοι έχουν πάει σπίτι. Αν το έχετε ήδη κάνει, επαναφέρετέ το πριν ρωτήσετε.

Βήμα 4: διαχωρίστε proxy, DNS και τέσσερις μορφές αποτυχίας

Αν απαιτείται proxy, προσδιορίστε ποιο context τον χρειάζεται. Μια ρύθμιση προγράμματος περιήγησης στον host δεν διαμορφώνει μια διεργασία μέσα στον κόμβο, και ένα Pod χρειάζεται τις μεταβλητές περιβάλλοντος ή μια διαμόρφωση proxy σε επίπεδο cluster.

Στη συνέχεια ταξινομήστε την αποτυχία αντί να την περιγράψετε. Ένα όνομα που δεν επιλύεται είναι DNS. Ένα όνομα που επιλύεται και αρνείται μια σύνδεση είναι δρομολόγηση ή ένας listener. Μια σύνδεση που εγκαθίσταται και αποτυγχάνει στην ταυτότητα είναι TLS. Μια επιτυχημένη σύνδεση με σώμα σφάλματος είναι η εφαρμογή.

Κάθε μία από αυτές τις τέσσερις ανήκει σε διαφορετική διόρθωση, και μόνο μία από αυτές αφορά το VPN. Σημειώστε ποια παρατηρήσατε σε κάθε context, και ο επόμενος άνθρωπος κληρονομεί αποδείξεις αντί για μια ιστορία.

Σχετικά άρθρα