Privata GKE-noder avgör inte vilken API kubectl använder

Noderna är privata, VPN:en når dem, och ändå kan kubectl inte tala med klustret. De två fakta har inget med varandra att göra. Adressen som kubectl använder kommer från serverns URL som sparades i kubeconfig när autentiseringsuppgifterna hämtades, och ingen rutt du lägger till ändrar den. Under tiden är noderna inte alls det som kubectl försöker nå.

Fem kontroller, med början i det enda värde som spelar roll.

Kontroll 1: läs serverns URL i kubeconfig

Skriv ut slutpunkten utan att dumpa autentiseringsuppgifterna: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Den enda strängen berättar om klienten pekar på en IP-adress, ett DNS-namn eller en extern adress som du inte avsåg. Allt annat i den här undersökningen följer av den.

Om URL:en inte är den slutpunkt du trodde att du hade konfigurerat, är resten av diagnosen en avledning.

Kontroll 2: matcha URL:en mot slutpunktstypen

Dagens GKE stöder både IP-baserad och DNS-baserad åtkomst till kontrollplanet, och autentiseringsuppgifterna du hämtar väljer en av dem. gcloud container clusters get-credentials NAME --location REGION --internal-ip skriver den interna IP-slutpunkten, medan --dns-endpoint väljer DNS-baserad åtkomst. Ingen av flaggorna skapar en nätverksväg, vilket förvånar dem som förväntar sig att hämtningen ska rätta till anslutningen. Upprepa hämtningen medvetet och läs sedan URL:en igen efteråt.

Att ändra flaggor utan att läsa URL:en igen är hur en laptop hamnar med autentiseringsuppgifter för två kluster och ett förvirrande fel.

En post i det auktoriserade nätverket avgör vem som får nå en extern slutpunkt och gäller inte för den interna. Att vidga den för att testa en privat väg ändrar din exponering, inte din diagnos.

Kontroll 3: bevisa vägen till den slutpunkten

Om URL:en är en intern IP, verifiera rutten från nätverket klienten faktiskt sitter på, det tillåtna källområdet och klustrets regionala eller globala åtkomstinställning. Kontrollplanets område och nodernas subnät är inte samma destination, så en fungerande rutt till noderna bevisar ingenting om slutpunkten. För DNS-baserad åtkomst är vägen Google API-anslutning med sin dokumenterade Private Google Access-ordning, inte en rutt till arbetarnas subnät. Testa slutpunkten med en vanlig TCP-anslutning innan du skyller på kubectl.

En timeout är ett ruttproblem. En 403 är ett policyproblem. De delar ingen lösning.

Kontroll 4: skilj loggar och exec från API-anrop

Om vanliga API-förfrågningar lyckas och kubectl logs eller kubectl exec misslyckas, har du redan passerat valet av slutpunkt. De operationerna kräver motsvarande Kubernetes-behörigheter och beror på kommunikation från kontrollplanet till noderna, och felet kan vara ett Forbidden-svar i stället för en timeout. SSH-åtkomst till en nod testar en helt annan tjänst och etablerar dem inte.

Läs felklassen innan du öppnar VPN-biljetten igen, eftersom de två klasserna bor på olika ställen.

Kontroll 5: spara tre observationer för nästa person

Notera den valda API-URL:en, om en auktoriserad API-förfrågan fungerar och exakt vilken senare operation som misslyckas, tillsammans med feltexten. De tre raderna skiljer valet av slutpunkt från nodåtkomst, och de hindrar en fullt god VPN-rutt från att skyllas för en förfrågan den aldrig bar.

Nästa ingenjör kommer att fråga om tunneln är trasig. Din anteckning borde redan svara på det.