Zasebna vozlišča GKE ne odločajo, kateri API uporablja kubectl

Vozlišča so zasebna, VPN jih doseže, a kubectl se vseeno ne more pogovarjati z gručo. Ti dve dejstvi nista povezani. Naslov, ki ga uporablja kubectl, izhaja iz URL strežnika, shranjenega v kubeconfig ob pridobitvi poverilnic, in nobena dodana pot ga ne spremeni. Medtem vozlišča sploh niso tisto, do česar skuša kubectl priti.

Pet preverjanj, začenši z edino vrednostjo, ki šteje.

Preverjanje 1: preberite URL strežnika v kubeconfig

Natisnite končno točko, ne da bi izlili poverilnice: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ta en sam niz vam pove, ali odjemalec kaže na naslov IP, ime DNS ali zunanji naslov, ki ga niste nameravali. Vse drugo v tej preiskavi izhaja iz njega.

Če URL ni končna točka, za katero ste mislili, da ste jo nastavili, je preostala diagnoza le odvračanje pozornosti.

Preverjanje 2: uskladite URL z vrsto končne točke

Trenutni GKE podpira dostop do krmilne ravnine na podlagi IP in DNS, pridobljene poverilnice pa izberejo enega od njiju. gcloud container clusters get-credentials NAME --location REGION --internal-ip zapiše končno točko notranjega IP, medtem ko --dns-endpoint izbere dostop na podlagi DNS. Nobena zastavica ne zagotavlja omrežne poti, kar preseneti tiste, ki pričakujejo, da bo pridobitev popravila povezljivost. Namerno ponovite pridobitev in nato znova preberite URL.

Spreminjanje zastavic brez ponovnega branja URL je način, kako prenosnik konča s poverilnicami dveh gruč in eno zmedeno napako.

Vnos v dovoljenem omrežju določa, kdo lahko doseže zunanjo končno točko, in ne velja za notranjo. Razširitev zaradi preizkušanja zasebne poti spremeni vašo izpostavljenost, ne vaše diagnoze.

Preverjanje 3: dokažite pot do te končne točke

Če je URL notranji IP, preverite pot iz omrežja, v katerem odjemalec dejansko sedi, dovoljen razpon virov in regionalno ali globalno nastavitev dostopa gruče. Razpon krmilne ravnine in podomrežje vozlišč nista ista destinacija, zato delujoča pot do vozlišč ne dokaže ničesar o končni točki. Za dostop na podlagi DNS je pot povezljivost z Google API z dokumentirano ureditvijo Private Google Access, ne pot do podomrežja delavcev. Preizkusite končno točko z navadno povezavo TCP, preden obtožite kubectl.

Časovna omejitev je težava poti. 403 je težava pravilnika. Nimata skupne rešitve.

Preverjanje 4: ločite dnevnike in exec od klicev API

Če običajne zahteve API uspejo in kubectl logs ali kubectl exec ne uspe, ste izbiro končne točke že prestali. Te operacije potrebujejo ustrezna dovoljenja Kubernetes in so odvisne od komunikacije krmilne ravnine z vozlišči, napaka pa je lahko odgovor Forbidden namesto časovne omejitve. Dostop SSH do vozlišča preizkuša povsem drugo storitev in ju ne vzpostavlja.

Preberite razred napake, preden znova odprete zahtevek VPN, ker oba razreda živita na različnih mestih.

Preverjanje 5: shranite tri ugotovitve za naslednjo osebo

Zapišite izbrani URL API, ali ena pooblaščena zahteva API deluje in katera natanko poznejša operacija ne uspe, skupaj z besedilom napake. Te tri vrstice ločujejo izbiro končne točke od dostopa do vozlišč in preprečujejo, da bi bila povsem dobra pot VPN obtožena za zahtevo, ki je nikoli ni prenesla.

Naslednji inženir bo vprašal, ali je tunel pokvarjen. Vaša opomba bi morala na to že odgovoriti.