Private GKE-Knoten entscheiden nicht, welche API kubectl verwendet

Die Knoten sind privat, das VPN erreicht sie, und kubectl kann trotzdem nicht mit dem Cluster sprechen. Diese beiden Tatsachen hängen nicht zusammen. Die Adresse, die kubectl verwendet, stammt aus der Server-URL, die beim Abrufen der Anmeldedaten in der kubeconfig gespeichert wurde, und keine hinzugefügte Route ändert sie. Die Knoten sind dabei gar nicht das, was kubectl überhaupt zu erreichen versucht.

Fünf Prüfungen, beginnend mit dem einzigen Wert, der zählt.

Prüfung 1: Lesen Sie die Server-URL in der kubeconfig

Geben Sie den Endpunkt aus, ohne die Anmeldedaten auszugeben: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Diese eine Zeichenkette sagt Ihnen, ob der Client auf eine IP-Adresse, einen DNS-Namen oder eine externe Adresse zeigt, die Sie nicht beabsichtigt hatten. Alles Weitere in dieser Untersuchung folgt daraus.

Wenn die URL nicht der Endpunkt ist, den Sie konfiguriert zu haben glaubten, ist der Rest der Diagnose eine Ablenkung.

Prüfung 2: Ordnen Sie die URL dem Endpunkttyp zu

Das aktuelle GKE unterstützt sowohl IP-basierten als auch DNS-basierten Zugriff auf die Steuerungsebene, und die abgerufenen Anmeldedaten wählen eines davon. gcloud container clusters get-credentials NAME --location REGION --internal-ip schreibt den internen IP-Endpunkt, während --dns-endpoint den DNS-basierten Zugriff wählt. Keines der Flags stellt einen Netzwerkpfad bereit, was Leute überrascht, die erwarten, dass der Abruf die Konnektivität repariert. Wiederholen Sie den Abruf bewusst und lesen Sie die URL danach erneut.

Flags zu ändern, ohne die URL erneut zu lesen, führt dazu, dass ein Laptop zwei Cluster-Anmeldedaten und einen verwirrenden Fehler hält.

Ein Eintrag im autorisierten Netzwerk bestimmt, wer einen externen Endpunkt erreichen darf, und gilt nicht für den internen. Ihn zu erweitern, um einen privaten Pfad zu testen, ändert Ihre Exposition statt Ihrer Diagnose.

Prüfung 3: Beweisen Sie den Pfad zu diesem Endpunkt

Wenn die URL eine interne IP ist, prüfen Sie die Route aus dem Netz, in dem der Client tatsächlich sitzt, den erlaubten Quellbereich und die regionale oder globale Zugriffseinstellung des Clusters. Der Bereich der Steuerungsebene und das Knoten-Subnetz sind nicht dasselbe Ziel, daher beweist eine funktionierende Route zu den Knoten nichts über den Endpunkt. Für DNS-basierten Zugriff ist der Pfad die Google-API-Konnektivität mit ihrer dokumentierten Private Google Access-Regelung, nicht eine Route zum Worker-Subnetz. Testen Sie den Endpunkt mit einer einfachen TCP-Verbindung, bevor Sie kubectl beschuldigen.

Ein Timeout ist ein Pfadproblem. Ein 403 ist ein Richtlinienproblem. Sie teilen keine Lösung.

Prüfung 4: Trennen Sie Logs und exec von API-Aufrufen

Wenn normale API-Anfragen erfolgreich sind und kubectl logs oder kubectl exec fehlschlägt, haben Sie die Endpunktauswahl bereits hinter sich. Diese Vorgänge benötigen die entsprechenden Kubernetes-Berechtigungen und hängen von der Kommunikation zwischen Steuerungsebene und Knoten ab, und der Fehler kann eine Forbidden-Antwort statt eines Timeouts sein. SSH-Zugriff auf einen Knoten testet einen völlig anderen Dienst und begründet sie nicht.

Lesen Sie die Fehlerklasse, bevor Sie das VPN-Ticket wieder öffnen, denn die beiden Klassen leben an verschiedenen Orten.

Prüfung 5: Halten Sie drei Beobachtungen für die nächste Person fest

Notieren Sie die ausgewählte API-URL, ob eine autorisierte API-Anfrage funktioniert und genau welcher spätere Vorgang fehlschlägt, samt Fehlertext. Diese drei Zeilen trennen die Endpunktauswahl vom Knotenzugriff und verhindern, dass eine völlig gute VPN-Route für eine Anfrage verantwortlich gemacht wird, die sie nie befördert hat.

Der nächste Ingenieur wird fragen, ob der Tunnel defekt ist. Ihre Notiz sollte das bereits beantworten.