Private GKE-noder avgjør ikke hvilken API kubectl bruker

Nodene er private, VPN-en når dem, og likevel kan ikke kubectl snakke med klyngen. De to faktaene har ingenting med hverandre å gjøre. Adressen kubectl bruker, kommer fra serverens URL som ble lagret i kubeconfig da legitimasjonen ble hentet, og ingen rute du legger til endrer den. Samtidig er ikke nodene det kubectl i det hele tatt prøver å nå.

Fem kontroller, med utgangspunkt i den eneste verdien som betyr noe.

Kontroll 1: les serverens URL i kubeconfig

Skriv ut endepunktet uten å dumpe legitimasjonen: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Den ene strengen forteller deg om klienten peker på en IP-adresse, et DNS-navn eller en ekstern adresse du ikke hadde til hensikt. Alt annet i denne undersøkelsen følger av den.

Hvis URL-en ikke er endepunktet du trodde du hadde konfigurert, er resten av diagnosen en avledning.

Kontroll 2: match URL-en mot endepunkttypen

Dagens GKE støtter både IP-basert og DNS-basert tilgang til kontrollplanet, og legitimasjonen du henter velger én av dem. gcloud container clusters get-credentials NAME --location REGION --internal-ip skriver det interne IP-endepunktet, mens --dns-endpoint velger DNS-basert tilgang. Ingen av flaggene etablerer en nettverksrute, noe som overrasker folk som forventer at hentingen skal rette opp tilkoblingen. Gjenta hentingen med vilje og les URL-en på nytt etterpå.

Å endre flagg uten å lese URL-en på nytt er måten en laptop ender opp med legitimasjonen til to klynger og én forvirrende feil.

En oppføring i det autoriserte nettverket avgjør hvem som kan nå et eksternt endepunkt og gjelder ikke for det interne. Å utvide den for å teste en privat rute endrer eksponeringen din, ikke diagnosen din.

Kontroll 3: bevis ruten til det endepunktet

Hvis URL-en er en intern IP, verifiser ruten fra nettverket klienten faktisk sitter på, det tillatte kildeområdet og klyngens regionale eller globale tilgangsinnstilling. Kontrollplanets område og nodenes subnett er ikke samme destinasjon, så en fungerende rute til nodene beviser ingenting om endepunktet. For DNS-basert tilgang er ruten Google API-tilkobling med sin dokumenterte Private Google Access-ordning, ikke en rute til arbeidernes subnett. Test endepunktet med en vanlig TCP-tilkobling før du klandrer kubectl.

En timeout er et ruteproblem. En 403 er et policyproblem. De deler ikke en løsning.

Kontroll 4: skill logger og exec fra API-kall

Hvis vanlige API-forespørsler lykkes og kubectl logs eller kubectl exec feiler, er du allerede forbi valget av endepunkt. Disse operasjonene trenger de tilsvarende Kubernetes-tillatelsene og avhenger av kommunikasjon fra kontrollplanet til nodene, og feilen kan være et Forbidden-svar i stedet for en timeout. SSH-tilgang til en node tester en helt annen tjeneste og etablerer dem ikke.

Les feilklassen før du gjenåpner VPN-billetten, fordi de to klassene bor på forskjellige steder.

Kontroll 5: ta vare på tre observasjoner til neste person

Noter den valgte API-URL-en, om én autorisert API-forespørsel virker, og nøyaktig hvilken senere operasjon som feiler, sammen med feilteksten. De tre linjene skiller valget av endepunkt fra nodetilgang, og de hindrer at en helt god VPN-rute blir klandret for en forespørsel den aldri bar.

Den neste ingeniøren vil spørre om tunnelen er ødelagt. Notatet ditt bør allerede svare på det.