Privé-GKE-knooppunten bepalen niet welke API kubectl gebruikt

De knooppunten zijn privé, de VPN bereikt ze, en toch kan kubectl niet met het cluster praten. Die twee feiten hebben niets met elkaar te maken. Het adres dat kubectl gebruikt, komt uit de server-URL die in de kubeconfig is opgeslagen toen de inloggegevens werden opgehaald, en geen route die je toevoegt verandert dat. Ondertussen zijn de knooppunten helemaal niet wat kubectl probeert te bereiken.

Vijf controles, te beginnen met de enige waarde die ertoe doet.

Controle 1: lees de server-URL in de kubeconfig

Print het eindpunt zonder de inloggegevens te dumpen: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Die ene string vertelt je of de client naar een IP-adres, een DNS-naam of een extern adres wijst dat je niet bedoelde. Al het andere in dit onderzoek volgt daaruit.

Als de URL niet het eindpunt is dat je dacht te hebben geconfigureerd, is de rest van de diagnose een afleiding.

Controle 2: koppel de URL aan het type eindpunt

Het huidige GKE ondersteunt zowel IP- als DNS-gebaseerde toegang tot het controlevlak, en de inloggegevens die je ophaalt kiezen er één. gcloud container clusters get-credentials NAME --location REGION --internal-ip schrijft het interne IP-eindpunt, terwijl --dns-endpoint DNS-gebaseerde toegang selecteert. Geen van beide vlaggen voorziet in een netwerkpad, wat mensen verrast die verwachten dat het ophalen de connectiviteit oplost. Herhaal het ophalen bewust en lees daarna de URL opnieuw.

Vlaggen wijzigen zonder de URL opnieuw te lezen is hoe een laptop eindigt met de inloggegevens van twee clusters en één verwarrende fout.

Een vermelding in het geautoriseerde netwerk bepaalt wie een extern eindpunt mag bereiken en geldt niet voor het interne. Het verbreden om een privépad te testen verandert je blootstelling, niet je diagnose.

Controle 3: bewijs het pad naar dat eindpunt

Als de URL een intern IP is, controleer dan de route vanaf het netwerk waar de client werkelijk zit, het toegestane bronbereik en de regionale of globale toegangsinstelling van het cluster. Het bereik van het controlevlak en het subnet van de knooppunten zijn niet dezelfde bestemming, dus een werkende route naar de knooppunten bewijst niets over het eindpunt. Voor DNS-gebaseerde toegang is het pad Google API-connectiviteit met de gedocumenteerde Private Google Access-regeling, niet een route naar het subnet van de workers. Test het eindpunt met een gewone TCP-verbinding voordat je kubectl de schuld geeft.

Een time-out is een padprobleem. Een 403 is een beleidsprobleem. Ze delen geen oplossing.

Controle 4: scheid logs en exec van API-aanroepen

Als gewone API-verzoeken slagen en kubectl logs of kubectl exec mislukt, ben je al voorbij de eindpuntkeuze. Die bewerkingen vereisen de bijbehorende Kubernetes-rechten en zijn afhankelijk van communicatie van het controlevlak naar de knooppunten, en de fout kan een Forbidden-antwoord zijn in plaats van een time-out. SSH-toegang tot een knooppunt test een heel andere dienst en stelt ze niet vast.

Lees de foutklasse voordat je het VPN-ticket heropent, want de twee klassen leven op verschillende plekken.

Controle 5: bewaar drie observaties voor de volgende persoon

Noteer de gekozen API-URL, of één geautoriseerd API-verzoek werkt en precies welke latere bewerking mislukt, samen met de fouttekst. Die drie regels scheiden de eindpuntkeuze van knooppunttoegang, en ze voorkomen dat een volstrekt goede VPN-route de schuld krijgt van een verzoek dat ze nooit heeft gedragen.

De volgende engineer zal vragen of de tunnel kapot is. Je notitie zou dat al moeten beantwoorden.