minikube erreicht eine private API nicht? Prüfe zuerst den Treiber

Host, Node und Pod haben jeweils eigene Routen und Resolver. Benenne den Treiber, teste denselben Endpunkt von allen drei Stellen und behebe dann den Kontext, der versagt hat.

Eine private API antwortet von deinem Laptop, und ein Pod in minikube erreicht sie nicht. Bevor du auf dem Host etwas änderst, benenne den Treiber hinter dem aktiven Profil, denn diese eine Tatsache entscheidet, aus welchem Netzwerk die Anfrage tatsächlich hinausgeht. Teste dann denselben Endpunkt vom Host, vom Node und vom Pod aus. Nur einer dieser drei ist das, was versagt hat, und eine falsche Vermutung kostet einen Nachmittag.

Schritt 0: Treiber und Ursprung benennen

Frage minikube, welches Profil aktiv ist und wie es läuft. Ein Container-Treiber legt den Node in einen Container auf deiner Maschine, ein VM-Treiber legt ihn in eine virtuelle Maschine, und ein Remote-Treiber legt ihn ganz woanders ab.

minikube profile list
minikube status
kubectl config current-context

Notiere daraus, wo die Anfrage ihren Ursprung hat. Die Antwort bestimmt, welcher Resolver und welche Routen zählen, und das ist nicht immer der des Hosts. Zwei Profile auf demselben Laptop können sich bei derselben URL völlig unterschiedlich verhalten.

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

Schritt 1: denselben Endpunkt dreimal testen

Nutze einen harmlosen Endpunkt und halte Hostname, Port und Adressfamilie in allen drei Tests gleich. Änderst du eines davon zwischen den Läufen, sind die Ergebnisse nicht vergleichbar.

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

Ein erfolgreicher Image-Pull durch den Node beweist nichts über die Namensauflösung für einen privaten Host. Eine erfolgreiche öffentliche Anfrage beweist noch weniger. Halte die Ergebnisse getrennt nach Kontext, denn ein Muster über drei Zeilen ist eine Diagnose, und ein einzelner Fehlschlag ist ein Hinweis.

Wenn auch die Host-Zeile scheitert, höre auf. Du hast ein Host-Netzwerkproblem, und der Cluster ist eine Ablenkung.

Schritt 2: den Weg des Hosts zum Cluster erhalten

Es gibt eine zweite Richtung, die Leute vergessen: Der Host muss weiterhin die eigene API und die Dienste des Clusters erreichen. Ein VPN-Client kann Routen installieren, die mit den Präfixen konkurrieren, die minikube für sein Node-Netz, seinen Service-Bereich und seinen Pod-Bereich verwendet.

Wenn das passiert, ist das Symptom verwirrend, denn der Tunnel funktioniert und kubectl reagiert nicht mehr oder ein NodePort lehnt Verbindungen ab. Es sieht wie ein Cluster-Fehler aus und ist ein Laptop-Routing-Fehler.

Prüfe die Routingtabelle des Hosts gegen die Bereiche von minikube, bevor du den Tunnel für irgendetwas anderes verantwortlich machst. Die Überschneidung zeigt sich meist als spezifischere Route, die auf die Tunnel-Schnittstelle für ein Präfix zeigt, das der Cluster für sich beansprucht.

Schritt 3: Überschneidung ohne Abschalten des VPN auflösen

Das VPN- und Proxy-Handbuch von minikube selbst behandelt diese Konflikte und sieht seine Beispielbereiche als etwas an, das man prüft, nicht als allgemeingültige Liste. Lies es zusammen mit dem Profil, das du tatsächlich hast.

Wo eine echte Überschneidung besteht, ist die unterstützte Antwort ein nicht überlappender Bereich oder eine bewusste lokale Zugriffsrichtlinie, die von der Person genehmigt wurde, der das VPN gehört. Den Service-Bereich zu ändern ist nicht dasselbe wie den Pod-Bereich zu ändern, und beides ist nicht dasselbe wie das Node-Netz zu ändern.

Den Firmen-Tunnel abzuschalten, damit ein lokaler Cluster funktioniert, ist kein Workaround; es ist eine Richtlinienentscheidung, die jemand anderes treffen muss. Trage sie an diese Person heran, statt es still zu tun, nachdem alle anderen nach Hause gegangen sind. Wenn du es bereits getan hast, stelle es zurück, bevor du fragst.

Schritt 4: Proxy, DNS und vier Fehlerformen trennen

Wenn ein Proxy erforderlich ist, finde heraus, welcher Kontext ihn braucht. Eine Browsereinstellung auf dem Host konfiguriert keinen Prozess im Node, und ein Pod braucht die Umgebungsvariablen oder eine Proxy-Konfiguration auf Clusterebene.

Klassifiziere dann den Fehler, statt ihn zu beschreiben. Ein Name, der sich nicht auflösen lässt, ist DNS. Ein Name, der sich auflösen lässt und eine Verbindung ablehnt, ist Routing oder ein Listener. Eine Verbindung, die zustande kommt und an der Identität scheitert, ist TLS. Eine erfolgreiche Verbindung mit einem Fehler-Body ist die Anwendung.

Jeder dieser vier gehört zu einer anderen Lösung, und nur einer von ihnen betrifft das VPN. Notiere, welchen du in jedem Kontext beobachtet hast, und die nächste Person erbt Belege statt einer Geschichte.

Ähnliche Artikel