Miért nem érik el a GKE podok a helyi kiszolgálókat VPN-en át

A ping működik a csomópontról és meghiúsul a podról, és semmi nem érkezik meg a helyi hálózatra. Az alagút és az útvonal rendben van; a vezetéken lévő forrásoldali cím nem. A két eset közötti különbség az, hogy a csomag minek mondja magát, amikor elhagyja a klasztert, és a GKE-nek erről véleménye van. A mechanizmus egy masquerade-kivétellista, és annak elolvasásához egyetlen parancs kell.

Olvassa el az érvényes listát, mielőtt bármit módosítana

A GKE egy ügynököt szállít, amely célonként eldönti, hogy a podforgalom kifelé menet átíródik-e a csomópont címére. A szállított konfiguráció a három RFC1918 blokkot, 10.0.0.0/8, 172.16.0.0/12 és 192.168.0.0/16, kivételként nevezi meg. Ezért minden, amit egy podból egy helyi 10.x kiszolgálónak küld, a pod saját címével a csomópontról távozik. A csomópont saját forgalma nem íródik át, és pontosan ezért működik a pingje.

Olvassa el a szándékolt konfigurációt és a telepített szabályokat, mert eltérhetnek. A kubectl -n kube-system get configmap ip-masq-agent -o yaml megmutatja, mit mondtak az ügynöknek, a kubectl -n kube-system get pods -l k8s-app=ip-masq-agent pedig azt, hogy fut-e valami, ami alkalmazza. Egy csomóponton a iptables-save | grep -i masq mutatja a kernelben ténylegesen létező szabályokat. Amikor a ConfigMap az egyiket mondja, a szabályok a másikat, a gyanúsított az ügynök, nem a hálózat.

Erősítse meg a forrásoldali címet egy elfogással

Az elfogást még a lista módosítása előtt végezze el. Az egyetlen célra szűrő szabály olvashatóan tartja a kimenetet: tcpdump -ni any host 10.20.30.40.

Hasonlítsa össze ezt azzal, amit a túloldal jelent. A helyi oldalon készült elfogás, amely a pod címét mutatja és választ nem, bezárja a kört: a kivétellista magyarázza az aszimmetriát alagúthiba nélkül. Egyetlen forrásoldali cím két megfigyelése elég ahhoz, hogy ne találgasson tovább a CNI-ről.

Szűkítse a kivételt a pod CIDR-re

A támogatott javítás szűkíti a kivételt ahelyett, hogy eltávolítaná: tartsa kivételként a pod CIDR-t, és dobja el a 10.x tér többi részét. Ez a lista az ügynök ConfigMapjében, a nonMasqueradeCIDRs alatt található, és módosítása szerkesztés, amit kitelepítés követ. Cserélje a széles bejegyzést a klaszter tényleges podtartományára, tartsa meg a többi privát blokkot, ha a klaszteren belüli forgalomnak még szüksége van rájuk, és hagyja békén a resyncInterval-et, hacsak nincs oka rá. Alkalmazza, erősítse meg, hogy az ügynök podjai újraindultak, és erősítse meg, hogy a kernel szabályai megváltoztak.

Ez egy klaszter szintű változtatás valódi hatókörrel. Miután érvénybe lép, a korábban podforrását megtartó forgalom most a csomópontra átírva érkezik, így minden, ami azokra a podcímekre épült, más feladót lát. Az áldozatok a podcímeket megnevező naplók, engedélyezési listák és helyi tűzfalszabályok, és ezek csendben meghiúsulnak. A változást viselkedésváltozásként hirdesse meg, ne javításként.

Több csomópontkészlettel rendelkező klaszterben ellenőrizze, hogy az ügynök azokon a csomópontokon van-e ütemezve, ahol az érintett podok ténylegesen futnak. A DaemonSet nélküli készlet megtartja a régi szabályait, és ezt semmi nem fogja mutatni a ConfigMapben.

Az alternatíva és annak ára

A másik lehetőség érintetlenül hagyja a podcímeket, és megtanítja az útvonalat rájuk. A pod CIDR bekerül a Cloud VPN forgalomválasztóiba, a helyi oldalnak pedig visszatérési útvonalra van szüksége hozzá, hogy a válaszok tudják, hová menjenek. Ez megőrzi a pod identitását, amit egyes biztonsági modellek kívánnak, és kiterjeszti mind az útválasztás, mind a tűzfal hatókörét, amit a túloldalnak el kell fogadnia.

Az üzlet az olvashatóság a hatókör ellenében. A fordítás azt eredményezi, hogy a helyi oldal csomópontonként egy címet lát, ami könnyen felvehető az engedélyezési listára, és elrejti, melyik pod mit küldött. A fordítás nélkül a podcím végponttól végpontig megmarad, ami jobb az attribúcióhoz és rosszabb minden eszköznek az útvonalon, amelynek új tartományt kell megtanulnia. Egyik lehetőség sem Docker- vagy CNI-hiba; mindkettő útválasztási döntés üzemeltetési számlával. Válassza azt, amelynek számláját a csapata ki tudja fizetni, és írja le, miért.

Ellenőrizze és állítsa vissza

Futtassa újra ugyanazt az elfogást. Egy csomópontszintű elfogás, amely a szerkesztés után is a pod címét írja ki, azt jelenti, hogy a szabályok soha nem változtak, bármit is mond a ConfigMap. A vezeték a tény; minden más következtetés.

Ezután ellenőrizze az ellenkező irányt, mert ezeknek a változtatásoknak csak a felét ellenőrzik kifelé. Erősítse meg, hogy a válasz eléri a kérést küldő csomópontot vagy podot, és erősítse meg, hogy az alkalmazás befejeződött, nem csak SYN-t kapott. A válasz nélküli kérést mutató elfogás a túloldal útválasztási problémája, nem ezen az oldalon lévő masquerade-probléma.

A visszaállítás az előző ConfigMap, ugyanúgy alkalmazva, ugyanazzal a megerősítéssel, hogy az ügynök újraindult és a szabályok megváltoztak. Őrizze meg egy ismert kérés forrásoldali címét előtte és utána a változásnaplóban, mert éppen az az egy sor bizonyítja, hogy a változtatás azt tette, amit mondott. A GKE IP-masquerade ügynök útmutatója dokumentálja az alapértelmezéseket és a ConfigMap mezőit. Ha a forrásoldali cím a kitelepítés után változatlan, az ügynök nem fut azon a csomóponton, és semmilyen YAML-szerkesztés nem fogja megjavítani.