Privaatsed GKE-sõlmed ei otsusta, millist API-t kubectl kasutab

Sõlmed on privaatsed, VPN jõuab nendeni ja ometi ei saa kubectl klastriga suhelda. Need kaks asjaolu ei ole omavahel seotud. Aadress, mida kubectl kasutab, pärineb serveri URL-ist, mis salvestati kubeconfigi mandaatide hankimise ajal, ja ükski lisatud marsruut seda ei muuda. Samal ajal ei ole sõlmed üldse see, mida kubectl proovib kätte saada.

Viis kontrolli, alustades ainsast väärtusest, mis loeb.

Kontroll 1: lugege kubeconfigis olevat serveri URL-i

Prindi lõpp-punkt ilma mandaate välja kirjutamata: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". See üks string ütleb, kas klient osutab IP-aadressile, DNS-nimele või välisele aadressile, mida te ei kavatsenud. Kõik muu selles uurimises tuleneb sellest.

Kui URL ei ole lõpp-punkt, mille te arvasite olevat seadistanud, on ülejäänud diagnostika tähelepanu kõrvalejuhtimine.

Kontroll 2: sobitage URL lõpp-punkti tüübiga

Praegune GKE toetab nii IP-põhist kui ka DNS-põhist juhtimistasandi juurdepääsu ning hangitud mandaadid valivad neist ühe. gcloud container clusters get-credentials NAME --location REGION --internal-ip kirjutab sisemise IP lõpp-punkti, samas kui --dns-endpoint valib DNS-põhise juurdepääsu. Kumbki lipp ei loo võrgumarsruuti, mis üllatab neid, kes loodavad, et hankimine parandab ühenduvuse. Korrake hankimist teadlikult ja lugege seejärel URL uuesti läbi.

Lippude muutmine ilma URL-i uuesti lugemata on viis, kuidas sülearvutile jäävad kahe klastri mandaadid ja üks segane viga.

Lubatud võrgu kirje määrab, kes tohib välisele lõpp-punktile ligi pääseda, ja ei kehti sisemise kohta. Selle laiendamine privaatse tee testimiseks muudab teie kokkupuudet, mitte diagnoosi.

Kontroll 3: tõestage tee selle lõpp-punktini

Kui URL on sisemine IP, kontrollige marsruuti võrgust, kus klient tegelikult asub, lubatud lähtevahemikku ja klastri piirkondlikku või globaalset juurdepääsu seadet. Juhtimistasandi vahemik ja sõlmede alamvõrk ei ole sama sihtkoht, seega töötav marsruut sõlmedeni ei tõesta lõpp-punkti kohta midagi. DNS-põhise juurdepääsu puhul on teeks Google API ühenduvus koos dokumenteeritud Private Google Accessi korraldusega, mitte marsruut töötajate alamvõrku. Testige lõpp-punkti tavalise TCP-ühendusega enne, kui süüdistate kubectl-i.

Aegumine on tee probleem. 403 on poliitika probleem. Neil ei ole ühist parandust.

Kontroll 4: eraldage logid ja exec API-kutsetest

Kui tavalised API-päringud õnnestuvad ja kubectl logs või kubectl exec ebaõnnestub, olete lõpp-punkti valiku juba mööda läinud. Need toimingud vajavad vastavaid Kubernetesi õigusi ja sõltuvad juhtimistasandi suhtlusest sõlmedega ning tõrge võib olla Forbidden-vastus, mitte aegumine. SSH-juurdepääs sõlmele testib hoopis teist teenust ega tuvasta neid.

Lugege veaklassi enne VPN-pileti uuesti avamist, sest need kaks klassi elavad erinevates kohtades.

Kontroll 5: jätke järgmisele inimesele kolm tähelepanekut

Kirjutage üles valitud API URL, kas üks volitatud API-päring töötab, ja täpselt, milline hilisem toiming ebaõnnestub, koos veatekstiga. Need kolm rida eraldavad lõpp-punkti valiku sõlmede juurdepääsust ja hoiavad ära, et täiesti korralikku VPN-marsruuti süüdistatakse päringus, mida see kunagi ei kandnud.

Järgmine insener küsib, kas tunnel on katki. Teie märkus peaks sellele juba vastama.