Privatni GKE čvorovi ne odlučuju koji API kubectl koristi

Čvorovi su privatni, VPN do njih dolazi, a kubectl i dalje ne može razgovarati s klasterom. Te dvije činjenice nisu povezane. Adresa koju kubectl koristi dolazi iz URL-a servera sačuvanog u kubeconfigu kada su preuzeti akreditivi, i nijedna ruta koju dodate to ne mijenja. U međuvremenu, čvorovi nisu ono čemu kubectl uopšte pokušava doći.

Pet provjera, počevši od jedine vrijednosti koja je bitna.

Provjera 1: pročitajte URL servera u kubeconfigu

Ispišite krajnju tačku bez ispisivanja akreditiva: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Taj jedan niz vam kaže da li klijent pokazuje na IP adresu, DNS ime ili vanjsku adresu koju niste namjeravali. Sve ostalo u ovoj istrazi proizlazi iz toga.

Ako URL nije krajnja tačka koju ste mislili da ste konfigurisali, ostatak dijagnostike je odvraćanje pažnje.

Provjera 2: uskladite URL s tipom krajnje tačke

Trenutni GKE podržava i IP i DNS pristup kontrolnoj ravni, a akreditivi koje preuzmete biraju jedan. gcloud container clusters get-credentials NAME --location REGION --internal-ip upisuje krajnju tačku interne IP adrese, dok --dns-endpoint bira DNS pristup. Nijedan flag ne uspostavlja mrežnu putanju, što iznenađuje ljude koji očekuju da će preuzimanje popraviti povezanost. Namjerno ponovite preuzimanje i zatim ponovo pročitajte URL.

Mijenjanje flagova bez ponovnog čitanja URL-a način je na koji laptop završi s akreditivima dva klastera i jednom zbunjujućom greškom.

Unos u dozvoljenoj mreži određuje ko može doći do vanjske krajnje tačke i ne primjenjuje se na internu. Proširivanje radi testiranja privatne putanje mijenja vašu izloženost, a ne vašu dijagnozu.

Provjera 3: dokažite putanju do te krajnje tačke

Ako je URL interna IP adresa, provjerite rutu iz mreže u kojoj klijent zaista sjedi, dozvoljeni raspon izvora i regionalnu ili globalnu postavku pristupa klastera. Raspon kontrolne ravni i podmreža čvorova nisu isto odredište, pa radna ruta do čvorova ne dokazuje ništa o krajnjoj tački. Za DNS pristup putanja je povezanost s Google API-jem uz dokumentovani Private Google Access, a ne ruta do podmreže radnika. Testirajte krajnju tačku običnom TCP vezom prije nego što okrivite kubectl.

Istek vremena je problem putanje. 403 je problem politike. Ne dijele isto rješenje.

Provjera 4: odvojite dnevnike i exec od API poziva

Ako obični API zahtjevi uspijevaju, a kubectl logs ili kubectl exec ne uspije, već ste prošli odabir krajnje tačke. Te operacije traže odgovarajuće Kubernetes dozvole i zavise od komunikacije kontrolne ravni s čvorovima, a neuspjeh može biti odgovor Forbidden, a ne istek vremena. SSH pristup čvoru testira sasvim drugu uslugu i ne uspostavlja ih.

Pročitajte klasu greške prije nego što ponovo otvorite VPN tiket, jer te dvije klase žive na različitim mjestima.

Provjera 5: ostavite tri zapažanja za sljedeću osobu

Zapišite odabrani API URL, da li jedan ovlašteni API zahtjev radi i tačno koja kasnija operacija ne uspijeva, uz tekst greške. Ta tri reda razdvajaju odabir krajnje tačke od pristupa čvorovima i sprječavaju da potpuno dobra VPN ruta bude okrivljena za zahtjev koji nikada nije nosila.

Sljedeći inženjer će pitati je li tunel pokvaren. Vaša bilješka bi to već trebalo da odgovori.