Privatūs GKE mazgai nenustato, kurią API naudoja kubectl

Mazgai privatūs, VPN juos pasiekia, o kubectl vis tiek negali kalbėtis su klasteriu. Šie du faktai nesusiję. Adresas, kurį naudoja kubectl, ateina iš serverio URL, įrašyto kubeconfig faile gaunant prisijungimo duomenis, ir jokia jūsų pridėta maršruto taisyklė jo nekeičia. Tuo tarpu mazgai apskritai nėra tai, ką kubectl bando pasiekti.

Penki patikrinimai, pradedant vienintele verte, kuri svarbi.

1 patikrinimas: perskaitykite serverio URL kubeconfig faile

Atspausdinkite galinį tašką neišlieję prisijungimo duomenų: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ši viena eilutė pasako, ar klientas nukreiptas į IP adresą, DNS vardą, ar į išorinį adresą, kurio neketinote. Visa kita šiame tyrime kyla iš to.

Jei URL nėra tas galinis taškas, kurį, kaip manėte, sukonfigūravote, likusi diagnostika tėra dėmesio atitraukimas.

2 patikrinimas: suderinkite URL su galinio taško tipu

Dabartinis GKE palaiko ir IP, ir DNS pagrįstą valdymo plokštumos prieigą, o gauti prisijungimo duomenys pasirenka vieną iš jų. gcloud container clusters get-credentials NAME --location REGION --internal-ip įrašo vidinio IP galinį tašką, o --dns-endpoint pasirenka DNS pagrįstą prieigą. Nė viena vėliavėlė nesukuria tinklo kelio, o tai stebina tuos, kurie tikisi, kad duomenų gavimas sutvarkys ryšį. Sąmoningai pakartokite gavimą ir po to dar kartą perskaitykite URL.

Vėliavėlių keitimas neskaitant URL iš naujo yra būdas, kuriuo nešiojamasis kompiuteris lieka su dviejų klasterių prisijungimo duomenimis ir viena painia klaida.

Leidžiamojo tinklo įrašas nustato, kas gali pasiekti išorinį galinį tašką, ir netaikomas vidiniam. Jo išplėtimas testuojant privatų kelią keičia jūsų atskleidimą, o ne diagnostiką.

3 patikrinimas: įrodykite kelią iki to galinio taško

Jei URL yra vidinis IP, patikrinkite maršrutą iš tinklo, kuriame klientas iš tikrųjų yra, leidžiamą šaltinio diapazoną ir klasterio regioninę ar pasaulinę prieigos nuostatą. Valdymo plokštumos diapazonas ir mazgų potinklis nėra tas pats tikslas, todėl veikiantis maršrutas iki mazgų nieko neįrodo apie galinį tašką. DNS pagrįstai prieigai kelias yra Google API ryšys su dokumentuota Private Google Access tvarka, o ne maršrutas į darbuotojų potinklį. Išbandykite galinį tašką paprastu TCP ryšiu prieš kaltindami kubectl.

Laiko limitas yra kelio problema. 403 yra politikos problema. Jie neturi bendro sprendimo.

4 patikrinimas: atskirkite žurnalus ir exec nuo API iškvietimų

Jei įprasti API užklausos pavyksta, o kubectl logs arba kubectl exec nepavyksta, jūs jau praėjote galinio taško pasirinkimą. Šioms operacijoms reikia atitinkamų Kubernetes leidimų ir jos priklauso nuo valdymo plokštumos ryšio su mazgais, o nesėkmė gali būti Forbidden atsakymas, o ne laiko limitas. SSH prieiga prie mazgo tikrina visai kitą paslaugą ir jų nenustato.

Perskaitykite klaidos klasę prieš vėl atidarydami VPN bilietą, nes šios dvi klasės gyvena skirtingose vietose.

5 patikrinimas: palikite tris pastebėjimus kitam žmogui

Užrašykite pasirinktą API URL, ar viena leidžiama API užklausa veikia, ir kuri tiksliai vėlesnė operacija nepavyksta, kartu su klaidos tekstu. Šios trys eilutės atskiria galinio taško pasirinkimą nuo prieigos prie mazgų ir neleidžia visiškai gero VPN maršruto apkaltinti užklausa, kurios jis niekada negabeno.

Kitas inžinierius paklaus, ar tunelis sugedęs. Jūsų užrašas jau turėtų į tai atsakyti.