A privát GKE-csomópontok nem döntik el, melyik API-t használja a kubectl

A csomópontok privátak, a VPN eléri őket, a kubectl mégsem tud beszélni a fürttel. Ez a két tény nem függ össze. A kubectl által használt cím a kubeconfigban tárolt kiszolgáló-URL-ből származik, amelyet a hitelesítő adatok lekérésekor mentettek el, és semmilyen hozzáadott útvonal nem változtat rajta. Eközben a csomópontok egyáltalán nem azok, amelyeket a kubectl el akar érni.

Öt ellenőrzés, az egyetlen számító értékkel kezdve.

1. ellenőrzés: olvassa el a kiszolgáló-URL-t a kubeconfigban

Nyomtassa ki a végpontot a hitelesítő adatok kiírása nélkül: kubectl config view --minify -o jsonpath="{.clusters[0].cluster.server}". Az az egyetlen karakterlánc megmondja, hogy az ügyfél IP-címre, DNS-névre vagy egy nem szándékolt külső címre mutat-e. Ebben a vizsgálatban minden más ebből következik.

Ha az URL nem az a végpont, amelyet konfiguráltnak hitt, a diagnózis többi része csak elterelés.

2. ellenőrzés: feleltesse meg az URL-t a végpont típusának

A jelenlegi GKE támogatja a vezérlősík IP-alapú és DNS-alapú elérését is, és a lekért hitelesítő adatok egyet választanak közülük. A gcloud container clusters get-credentials NAME --location REGION --internal-ip a belső IP végpontját írja, míg a --dns-endpoint a DNS-alapú hozzáférést választja. Egyik kapcsoló sem hoz létre hálózati útvonalat, ami meglepi azokat, akik azt várják, hogy a lekérés helyreállítja a kapcsolatot. Szándékosan ismételje meg a lekérést, majd utána olvassa el újra az URL-t.

A kapcsolók módosítása az URL újraolvasása nélkül az az út, amelyen egy laptop két fürt hitelesítő adataival és egy zavaró hibával marad.

Az engedélyezett hálózat bejegyzése szabályozza, ki érhet el külső végpontot, és nem vonatkozik a belsőre. Kiszélesítése egy privát útvonal teszteléséhez a kitettségét változtatja meg, nem a diagnózisát.

3. ellenőrzés: bizonyítsa az útvonalat ehhez a végponthoz

Ha az URL belső IP, ellenőrizze az útvonalat abból a hálózatból, ahol az ügyfél valójában van, az engedélyezett forrástartományt és a fürt regionális vagy globális hozzáférési beállítását. A vezérlősík tartománya és a csomópontok alhálózata nem ugyanaz a cél, ezért a csomópontokig működő útvonal semmit sem bizonyít a végpontról. DNS-alapú hozzáférés esetén az útvonal a Google API-kapcsolat a dokumentált Private Google Access-elrendezéssel, nem pedig útvonal a munkavégzők alhálózatához. Tesztelje a végpontot egyszerű TCP-kapcsolattal, mielőtt a kubectl-t hibáztatja.

Az időtúllépés útvonalprobléma. A 403 szabályzatprobléma. Nem közös a megoldásuk.

4. ellenőrzés: válassza szét a naplókat és az exec-et az API-hívásoktól

Ha a szokásos API-kérések sikerülnek, és a kubectl logs vagy a kubectl exec meghiúsul, már túl van a végpont kiválasztásán. Ezekhez a műveletekhez a megfelelő Kubernetes-jogosultságok kellenek, és a vezérlősík és a csomópontok közötti kommunikációtól függenek, a hiba pedig lehet Forbidden-válasz is időtúllépés helyett. A csomóponthoz intézett SSH-hozzáférés egészen más szolgáltatást tesztel, és nem igazolja ezeket.

Olvassa el a hibaosztályt, mielőtt újranyitja a VPN-jegyet, mert a két osztály különböző helyeken él.

5. ellenőrzés: őrizzen meg három megfigyelést a következő embernek

Jegyezze fel a kiválasztott API-URL-t, hogy működik-e egy engedélyezett API-kérés, és hogy pontosan melyik későbbi művelet hiúsul meg, a hiba szövegével együtt. Ez a három sor választja szét a végpont kiválasztását a csomópont-hozzáféréstől, és megakadályozza, hogy egy teljesen jó VPN-útvonalat olyan kérésért hibáztassanak, amelyet soha nem szállított.

A következő mérnök megkérdezi, hogy elromlott-e az alagút. A jegyzetének erre már válaszolnia kellene.