Nyjet private të GKE nuk vendosin se cilën API përdor kubectl

Nyjet janë private, VPN-i arrin deri te ato, e megjithatë kubectl nuk mund të flasë me klusterin. Këto dy fakte nuk kanë lidhje me njëra-tjetrën. Adresa që përdor kubectl vjen nga URL-ja e serverit e ruajtur në kubeconfig kur u morën kredencialet, dhe asnjë rrugë që shtoni nuk e ndryshon atë. Ndërkohë, nyjet nuk janë fare ajo që kubectl po përpiqet të arrijë.

Pesë kontrolle, duke filluar me vlerën e vetme që ka rëndësi.

Kontroli 1: lexoni URL-në e serverit në kubeconfig

Printo pikën fundore pa derdhur kredencialet: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Ai një varg i vetëm ju tregon nëse klienti drejtohet drejt një adrese IP, një emri DNS apo një adrese të jashtme që nuk e kishit ndërmend. Gjithçka tjetër në këtë hetim rrjedh prej tij.

Nëse URL-ja nuk është pika fundore që menduat se kishit konfiguruar, pjesa tjetër e diagnozës është thjesht shpërqendrim.

Kontroli 2: përputhni URL-në me llojin e pikës fundore

GKE aktual mbështet aksesin në rrafshin e kontrollit si me bazë IP ashtu edhe me bazë DNS, dhe kredencialet që merrni zgjedhin njërën prej tyre. gcloud container clusters get-credentials NAME --location REGION --internal-ip shkruan pikën fundore të IP-së së brendshme, ndërsa --dns-endpoint zgjedh aksesin me bazë DNS. Asnjëri prej flamujve nuk siguron një rrugë rrjeti, gjë që i habit ata që presin që marrja e kredencialeve të rregullojë lidhshmërinë. Përsëriteni marrjen me qëllim dhe më pas lexoni përsëri URL-në.

Ndryshimi i flamujve pa lexuar përsëri URL-në është mënyra se si një laptop përfundon me kredencialet e dy klustereve dhe një gabim konfuz.

Një hyrje në rrjetin e autorizuar përcakton kush mund të arrijë një pikë fundore të jashtme dhe nuk zbatohet për atë të brendshme. Zgjerimi i saj për të testuar një rrugë private ndryshon ekspozimin tuaj, jo diagnozën tuaj.

Kontroli 3: vërtetoni rrugën drejt asaj pike fundore

Nëse URL-ja është një IP e brendshme, verifikoni rrugën nga rrjeti ku klienti ndodhet vërtet, diapazonin e lejuar të burimit dhe cilësimin e aksesit rajonal ose global të klusterit. Diapazoni i rrafshit të kontrollit dhe nënrrjeti i nyjeve nuk janë i njëjti destinacion, prandaj një rrugë që funksionon drejt nyjeve nuk dëshmon asgjë për pikën fundore. Për aksesin me bazë DNS, rruga është lidhshmëria me Google API me mekanizmin e dokumentuar Private Google Access, jo një rrugë drejt nënrrjetit të punëtorëve. Testoni pikën fundore me një lidhje të thjeshtë TCP përpara se të fajësoni kubectl.

Një afat kohor është problem rruge. Një 403 është problem politike. Nuk ndajnë të njëjtën zgjidhje.

Kontroli 4: ndani regjistrat dhe exec nga thirrjet API

Nëse kërkesat normale API kanë sukses dhe kubectl logs ose kubectl exec dështon, ju tashmë e keni kaluar zgjedhjen e pikës fundore. Këto veprime kërkojnë lejet përkatëse të Kubernetes dhe varen nga komunikimi i rrafshit të kontrollit me nyjet, dhe dështimi mund të jetë një përgjigje Forbidden në vend të një afati kohor. Aksesi SSH në një nyje teston një shërbim krejt tjetër dhe nuk i vendos ato.

Lexoni klasën e gabimit përpara se të rihapni biletën e VPN-së, sepse të dyja klasat jetojnë në vende të ndryshme.

Kontroli 5: ruani tre vëzhgime për personin tjetër

Shënoni URL-në e API-së të zgjedhur, nëse një kërkesë e autorizuar API funksionon dhe saktësisht cila veprim i mëvonshëm dështon, së bashku me tekstin e gabimit. Ato tre rreshta ndajnë zgjedhjen e pikës fundore nga aksesi në nyje, dhe parandalojnë që një rrugë VPN krejt e mirë të fajësohet për një kërkesë që nuk e mbajti kurrë.

Inxhinieri tjetër do të pyesë nëse tuneli është prishur. Shënimi juaj duhet ta ketë përgjigjur tashmë këtë.