Nodurile private GKE nu decid ce API folosește kubectl

Nodurile sunt private, VPN-ul ajunge la ele, iar kubectl tot nu poate vorbi cu clusterul. Aceste două fapte nu au legătură. Adresa pe care o folosește kubectl provine din URL-ul serverului salvat în kubeconfig când au fost obținute credențialele, iar nicio rută pe care o adăugați nu o schimbă. Între timp, nodurile nu sunt deloc ceea ce încearcă kubectl să atingă.

Cinci verificări, începând cu singura valoare care contează.

Verificarea 1: citiți URL-ul serverului din kubeconfig

Afișați punctul final fără a vărsa credențialele: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Acel singur șir vă spune dacă clientul indică o adresă IP, un nume DNS sau o adresă externă pe care nu o intenționați. Restul acestei investigații decurge din el.

Dacă URL-ul nu este punctul final pe care credeați că l-ați configurat, restul diagnosticului este o distragere.

Verificarea 2: potriviți URL-ul cu tipul punctului final

GKE actual acceptă accesul la planul de control atât bazat pe IP, cât și pe DNS, iar credențialele pe care le obțineți aleg unul dintre ele. gcloud container clusters get-credentials NAME --location REGION --internal-ip scrie punctul final de IP intern, în timp ce --dns-endpoint selectează accesul bazat pe DNS. Niciunul dintre indicatori nu asigură o cale de rețea, ceea ce îi surprinde pe cei care se așteaptă ca obținerea să repare conectivitatea. Repetați obținerea în mod deliberat și apoi citiți din nou URL-ul.

Schimbarea indicatorilor fără a reciti URL-ul este modul în care un laptop ajunge cu credențialele a două clustere și o eroare confuză.

O intrare în rețeaua autorizată stabilește cine poate ajunge la un punct final extern și nu se aplică celui intern. Lărgirea ei pentru a testa o cale privată schimbă expunerea, nu diagnosticul.

Verificarea 3: demonstrați calea către acel punct final

Dacă URL-ul este un IP intern, verificați ruta din rețeaua în care se află de fapt clientul, intervalul de sursă permis și setarea de acces regional sau global a clusterului. Intervalul planului de control și subrețeaua nodurilor nu sunt aceeași destinație, așa că o rută funcțională către noduri nu demonstrează nimic despre punctul final. Pentru accesul bazat pe DNS, calea este conectivitatea la Google API cu mecanismul documentat Private Google Access, nu o rută către subrețeaua lucrătorilor. Testați punctul final cu o conexiune TCP simplă înainte de a da vina pe kubectl.

Un timeout este o problemă de cale. Un 403 este o problemă de politică. Nu împart aceeași soluție.

Verificarea 4: separați logurile și exec de apelurile API

Dacă cererile API obișnuite reușesc și kubectl logs sau kubectl exec eșuează, ați trecut deja de selecția punctului final. Acele operații necesită permisiunile Kubernetes corespunzătoare și depind de comunicarea dintre planul de control și noduri, iar eșecul poate fi un răspuns Forbidden în loc de un timeout. Accesul SSH la un nod testează un serviciu complet diferit și nu le stabilește.

Citiți clasa erorii înainte de a redeschide tichetul VPN, pentru că cele două clase trăiesc în locuri diferite.

Verificarea 5: păstrați trei observații pentru următoarea persoană

Notați URL-ul API selectat, dacă o cerere API autorizată funcționează și exact ce operație ulterioară eșuează, împreună cu textul erorii. Acele trei linii separă selecția punctului final de accesul la noduri și împiedică o rută VPN perfect bună să fie învinuită pentru o cerere pe care nu a transportat-o niciodată.

Următorul inginer va întreba dacă tunelul este stricat. Nota dumneavoastră ar trebui să răspundă deja la asta.