Privátne uzly GKE nerozhodujú, ktoré API kubectl používa

Uzly sú privátne, VPN sa k nim dostane, a napriek tomu kubectl nedokáže hovoriť s clusterom. Tieto dve skutočnosti spolu nesúvisia. Adresa, ktorú kubectl používa, pochádza z URL servera uloženej v kubeconfig pri získaní prihlasovacích údajov, a žiadna pridaná trasa ju nemení. Uzly navyše vôbec nie sú to, na čo sa kubectl snaží dosiahnuť.

Päť kontrol, počnúc jedinou hodnotou, na ktorej záleží.

Kontrola 1: prečítajte si URL servera v kubeconfig

Vypíšte koncový bod bez toho, aby ste vyplavili prihlasovacie údaje: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ten jediný reťazec vám povie, či klient mieri na IP adresu, názov DNS alebo na externú adresu, ktorú ste nezamýšľali. Všetko ostatné v tomto vyšetrovaní z toho vyplýva.

Ak URL nie je koncový bod, ktorý ste si mysleli, že ste nastavili, zvyšok diagnostiky je len rozptýlenie.

Kontrola 2: priraďte URL k typu koncového bodu

Súčasné GKE podporuje prístup k riadiacej rovine cez IP aj cez DNS a získané prihlasovacie údaje vyberú jeden z nich. gcloud container clusters get-credentials NAME --location REGION --internal-ip zapíše koncový bod internej IP, zatiaľ čo --dns-endpoint vyberie prístup cez DNS. Ani jeden príznak nevytvára sieťovú cestu, čo prekvapí ľudí, ktorí očakávajú, že získanie údajov opraví konektivitu. Zámerne zopakujte získanie a potom URL znova prečítajte.

Menit príznaky bez opätovného prečítania URL je spôsob, akým notebook skončí s prihlasovacími údajmi dvoch clusterov a jednou mätúcou chybou.

Záznam v povolenej sieti určuje, kto sa môže dostať k externému koncovému bodu, a nevzťahuje sa na interný. Rozšírenie kvôli testovaniu privátnej cesty mení vašu expozíciu, nie vašu diagnostiku.

Kontrola 3: dokážte cestu k tomuto koncovému bodu

Ak je URL interná IP, overte trasu zo siete, v ktorej klient skutočne sedí, povolený rozsah zdrojov a regionálne alebo globálne nastavenie prístupu clusteru. Rozsah riadiacej roviny a podsiet uzlov nie sú ten istý cieľ, takže funkčná trasa k uzlom o koncovom bode nič nedokazuje. Pre prístup cez DNS je cestou konektivita ku Google API s dokumentovaným usporiadaním Private Google Access, nie trasa do podsiete pracovných uzlov. Otestujte koncový bod bežným TCP pripojením, skôr než obviníte kubectl.

Časový limit je problém cesty. 403 je problém politiky. Nemajú spoločné riešenie.

Kontrola 4: oddeľte logy a exec od volaní API

Ak bežné požiadavky API uspejú a kubectl logs alebo kubectl exec zlyhá, už ste za voľbou koncového bodu. Tieto operácie potrebujú príslušné oprávnenia Kubernetes a závisia od komunikácie riadiacej roviny s uzlami, a zlyhanie môže byť odpoveď Forbidden namiesto časového limitu. SSH prístup k uzlu testuje úplne inú službu a nepreukazuje ich.

Prečítajte si triedu chyby, skôr než znova otvoríte tiket VPN, pretože obe triedy žijú na rôznych miestach.

Kontrola 5: nechajte tri pozorovania pre ďalšieho človeka

Zapíšte zvolenú URL API, či jeden autorizovaný API prístup funguje a presne ktorá neskoršia operácia zlyháva, spolu s textom chyby. Tieto tri riadky oddeľujú voľbu koncového bodu od prístupu k uzlom a bránia tomu, aby bola úplne dobrá trasa VPN obviňovaná zo žiadosti, ktorú nikdy neprepravila.

Ďalší inžinier sa opýta, či je tunel pokazený. Vaša poznámka by na to už mala odpovedať.