Private GKE-nodar avgjer ikkje kva API kubectl brukar

Nodane er private, VPN-en når dei, og likevel kan ikkje kubectl snakke med klynga. Dei to fakta har ingenting med kvarandre å gjere. Adressa kubectl brukar, kjem frå server-URL-en som vart lagra i kubeconfig då innloggingsdetaljane vart henta, og inga rute du legg til endrar det. Samstundes er ikkje nodane det kubectl i det heile prøver å nå.

Fem kontrollar, med utgangspunkt i den einaste verdien som tel.

Kontroll 1: les server-URL-en i kubeconfig

Skriv ut endepunktet utan å dumpe innloggingsdetaljane: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Den eine strengen fortel deg om klienten peikar på ei IP-adresse, eit DNS-namn eller ei ekstern adresse du ikkje hadde til hensikt. Alt anna i denne undersøkinga følgjer av den.

Viss URL-en ikkje er endepunktet du trudde du hadde konfigurert, er resten av diagnosen ei avleiing.

Kontroll 2: match URL-en mot endepunkttypen

Dagens GKE støttar både IP-basert og DNS-basert tilgang til kontrollplanet, og innloggingsdetaljane du hentar vel éin av dei. gcloud container clusters get-credentials NAME --location REGION --internal-ip skriv det interne IP-endepunktet, medan --dns-endpoint vel DNS-basert tilgang. Ingen av flagga legg til rette for ein nettverksveg, noko som overraskar folk som ventar at hentinga skal rette opp tilkoplinga. Gjenta hentinga med vilje og les URL-en på nytt etterpå.

Å endre flagg utan å lese URL-en på nytt er måten ein laptop endar opp med innloggingsdetaljane til to klynger og éin forvirrande feil.

Ein oppføring i det autoriserte nettverket avgjer kven som kan nå eit eksternt endepunkt og gjeld ikkje for det interne. Å utvide det for å teste ein privat veg endrar eksponeringa di, ikkje diagnosen din.

Kontroll 3: prov veg-en til det endepunktet

Viss URL-en er ein intern IP, verifiser ruta frå nettverket klienten faktisk sit på, det tillatne kjeldeområdet og den regionale eller globale tilgangsinnstillinga til klynga. Området til kontrollplanet og subnettet til nodane er ikkje same mål, så ei fungerande rute til nodane provar ingenting om endepunktet. For DNS-basert tilgang er vegen Google API-tilkopling med den dokumenterte Private Google Access-ordninga, ikkje ei rute til subnettet til arbeidarane. Test endepunktet med ei vanleg TCP-tilkopling før du klandrar kubectl.

Ein timeout er eit ruteproblem. Ein 403 er eit policyproblem. Dei deler ikkje ei løysing.

Kontroll 4: skil loggar og exec frå API-kall

Viss vanlege API-førespurnader lukkast og kubectl logs eller kubectl exec feilar, er du alt forbi valet av endepunkt. Desse operasjonane treng dei tilsvarande Kubernetes-løyva og er avhengige av kommunikasjon frå kontrollplanet til nodane, og feilen kan vere eit Forbidden-svar i staden for ein timeout. SSH-tilgang til ein node testar ei heilt anna teneste og etablerer dei ikkje.

Les feilklassen før du opnar VPN-billetten på nytt, fordi dei to klassane bur på ulike stader.

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

Noter den valde API-URL-en, om éin autorisert API-førespurnad verkar, og nøyaktig kva seinare operasjon som feilar, saman med feilteksten. Dei tre linjene skil valet av endepunkt frå nodetilgang, og dei hindrar at ei heilt god VPN-rute blir klandra for ein førespurnad ho aldri bar.

Den neste ingeniøren vil spørje om tunnelen er øydelagd. Notatet ditt bør alt svare på det.