Prečo sa pody GKE nedostanú cez VPN na lokálne hosty
Uzol sa dostane do lokálnej siete, pod nie. Výnimky masquerade v GKE nechávajú adresy podov nepreložené pre ciele 10.x.
Ping funguje z uzla a zlyháva z podu a lokálne nič neprichádza. Tunel a trasa sú v poriadku; zdrojová adresa na drôte nie. Tieto dva prípady odlišuje to, za čo sa paket vydáva pri odchode z klastra, a GKE na to má názor. Mechanizmom je zoznam výnimiek masquerade a jeho prečítanie si vyžaduje jeden príkaz.
Prečítajte si platný zoznam, kým čokoľvek zmeníte
GKE dodáva agenta, ktorý pre každý cieľový rozsah rozhoduje, či sa prevádzka podov pri odchode prepíše na adresu uzla. Jeho dodávaná konfigurácia uvádza tri bloky RFC1918, 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16, ako vylúčené ciele. Preto všetko, čo pošlete z podu na lokálny host 10.x, opúšťa uzol s ešte pripojenou adresou samotného podu. Prevádzka samotného uzla sa neprepisuje, a práve preto jeho ping funguje.
Prečítajte si zamýšľanú konfiguráciu a nainštalované pravidlá, pretože sa môžu rozchádzať. kubectl -n kube-system get configmap ip-masq-agent -o yaml ukazuje, čo bolo agentovi povedané, a kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ukazuje, či niečo beží, aby to uplatnilo. Na uzle iptables-save | grep -i masq ukazuje pravidlá, ktoré v jadre skutočne existujú. Keď ConfigMap hovorí jedno a pravidlá druhé, podozrivý je agent, nie sieť.
Potvrďte zdrojovú adresu odchytom
Urobte odchyt predtým, než zmeníte zoznam. Filter na jediný cieľ udrží výstup čitateľný: tcpdump -ni any host 10.20.30.40.
Porovnajte to s tým, čo hlási druhá strana. Odchyt lokálne, ktorý ukazuje adresu podu a žiadnu odpoveď, uzatvára kruh: zoznam výnimiek vysvetľuje asymetriu bez akejkoľvek poruchy tunela. Dve pozorovania jednej zdrojovej adresy stačia na to, aby ste prestali hádať o CNI.
Zúžte výnimku na CIDR podov
Podporovaná oprava zužuje výnimku namiesto toho, aby ju odstránila: ponechajte CIDR podov vylúčený a zvyšok priestoru 10.x vynechajte. Ten zoznam žije v ConfigMap agenta pod nonMasqueradeCIDRs a jeho zmena je úprava, po ktorej nasleduje nasadenie. Nahraďte široký záznam skutočným rozsahom podov klastra, ponechajte ostatné privátne bloky, ak ich prevádzka vnútri klastra ešte potrebuje, a resyncInterval nechajte na pokoji, ak na to nemáte dôvod. Aplikujte to, potvrďte, že sa pody agenta reštartovali, a potvrďte, že sa pravidlá jadra zmenili.
Toto je zmena v rámci celého klastra so skutočným dopadom. Po jej nasadení prevádzka, ktorá si predtým zachovávala zdroj podu, prichádza teraz prepísaná na uzol, takže všetko, čo bolo naviazané na tieto adresy podov, vidí iného odosielateľa. Obete sú logy, zoznamy povolených a lokálne pravidlá firewallu, ktoré uvádzajú adresy podov, a zlyhávajú potichu. Oznamte zmenu ako zmenu správania, nie ako opravu.
V klastri s niekoľkými skupinami uzlov skontrolujte, či je agent naplánovaný na uzloch, kde postihnuté pody skutočne bežia. Skupina bez DaemonSet si drží svoje staré pravidlá a v ConfigMap to nič neukáže.
Alternatíva a jej cena
Druhá možnosť necháva adresy podov nedotknuté a učí cestu o nich. CIDR podov ide do selektorov prevádzky Cloud VPN a lokálna strana preň potrebuje spätnú trasu, aby odpovede vedeli, kam ísť. To zachováva identitu podu, ktorú chcú niektoré bezpečnostné modely, a rozširuje ako rozsah smerovania, tak rozsah firewallu, ktorý musí druhá strana prijať.
Obchod je čitateľnosť proti rozsahu. Preklad spôsobí, že lokálna strana vidí jednu adresu na uzol, čo sa ľahko pridáva do zoznamu povolených a skrýva, ktorý pod čo poslal. Bez prekladu zostáva adresa podu od konca do konca, čo je lepšie pre priradenie a horšie pre každé zariadenie na ceste, ktoré sa musí naučiť nový rozsah. Ani jedna možnosť nie je chyba Dockeru alebo CNI; obe sú rozhodnutia o smerovaní s prevádzkovým účtom. Vyberte tú, ktorej účet váš tím dokáže zaplatiť, a napíšte prečo.
Overte a vráťte späť
Spustite ten istý odchyt znova. Odchyt na úrovni uzla, ktorý po vašej úprave stále vypisuje adresu podu, znamená, že sa pravidlá nikdy nezmenili, čokoľvek hovorí ConfigMap. Drôt je fakt; všetko ostatné je úsudok.
Potom skontrolujte opačný smer, pretože polovica týchto zmien sa overuje len smerom von. Potvrďte, že odpoveď dorazí na uzol alebo pod, ktorý žiadosť odoslal, a potvrďte, že aplikácia skončila, a nie len prijala SYN. Odchyt, ktorý ukazuje žiadosť bez odpovede, je problém smerovania na druhej strane, nie problém masquerade na tejto.
Vrátenie je predchádzajúci ConfigMap, aplikovaný rovnakým spôsobom, s rovnakým potvrdením, že sa agent reštartoval a pravidlá zmenili. V zázname zmien si uchovajte zdrojovú adresu pred a po pre jednu známu žiadosť, pretože práve ten jediný riadok dokazuje, že zmena urobila to, čo ste povedali. Príručka GKE k agentovi IP masquerade dokumentuje predvolené hodnoty a polia ConfigMap. Ak sa zdrojová adresa po nasadení nezmení, agent na tom uzle nebeží a žiadna úprava YAML to nespraví.