Proč se pody GKE přes VPN nedostanou na místní servery

Ping funguje z uzlu a selhává z podu a na místní síť nedorazí nic. Tunel a trasa jsou v pořádku; zdrojová adresa na drátě ne. Rozdíl mezi těmito dvěma případy je v tom, co paket tvrdí, že je, když opouští cluster, a GKE na to má názor. Mechanismus je seznam vyloučení masquerade a jeho přečtení zabere jeden příkaz.

Přečtěte si platný seznam, než cokoli změníte

GKE dodává agenta, který pro každý cílový rozsah rozhoduje, zda se provoz z podů při odchodu přepíše na adresu uzlu. Jeho dodávaná konfigurace uvádí tři bloky RFC1918, 10.0.0.0/8, 172.16.0.0/12 a 192.168.0.0/16, jako vyloučené cíle. Vše, co z podu pošlete na místní 10.x hostitel, proto opouští uzel s vlastní adresou podu stále připojenou. Provoz samotného uzlu se nepřepisuje, a právě proto jeho ping funguje.

Přečtěte si zamýšlenou konfiguraci a nainstalovaná pravidla, protože se mohou rozcházet. kubectl -n kube-system get configmap ip-masq-agent -o yaml ukazuje, co bylo agentovi řečeno, a kubectl -n kube-system get pods -l k8s-app=ip-masq-agent ukazuje, zda něco běží, aby to aplikovalo. Na uzlu iptables-save | grep -i masq ukazuje pravidla, která v jádře skutečně existují. Když ConfigMap říká jedno a pravidla druhé, podezřelý je agent, ne síť.

Potvrďte zdrojovou adresu odchytem

Než změníte seznam, pořiďte odchyt. Filtr na jediný cíl udrží výstup čitelný: tcpdump -ni any host 10.20.30.40.

Porovnejte to s tím, co hlásí druhá strana. Odchyt na místní síti, který ukazuje adresu podu a žádnou odpověď, uzavírá smyčku: seznam vyloučení vysvětluje asymetrii bez jakékoli závady tunelu. Dvě pozorování jedné zdrojové adresy stačí k tomu, abyste přestali hádat o CNI.

Zúžte vyloučení na CIDR podů

Podporovaná oprava vyloučení zúží, místo aby ho odstranila: ponechte CIDR podů vyloučený a zbytek prostoru 10.x vypusťte. Tento seznam žije v ConfigMapu agenta pod nonMasqueradeCIDRs a jeho změna je úprava následovaná nasazením. Nahraďte široký záznam skutečným rozsahem podů clusteru, ostatní privátní bloky ponechte, pokud je provoz uvnitř clusteru stále potřebuje, a resyncInterval nechte být, pokud k tomu nemáte důvod. Aplikujte to, potvrďte, že se pody agenta restartovaly, a potvrďte, že se pravidla v jádře změnila.

Toto je změna v rámci celého clusteru se skutečným dopadem. Po jejím nasazení provoz, který si dřív zachovával zdroj podu, dorazí přepsaný na uzel, takže vše, co bylo navázané na tyto adresy podů, vidí jiného odesílatele. Oběťmi jsou logy, seznamy povolených a místní pravidla firewallu, která uvádějí adresy podů, a selhávají tiše. Oznamte změnu jako změnu chování, ne jako opravu.

V clusteru s několika skupinami uzlů zkontrolujte, zda je agent naplánován na uzlech, kde postižené pody skutečně běží. Skupina bez DaemonSet si drží svá stará pravidla a v ConfigMapu to nic neukáže.

Alternativa a její cena

Druhá možnost nechává adresy podů nedotčené a učí cestu o nich. CIDR podů jde do selektorů provozu Cloud VPN a místní strana pro něj potřebuje zpětnou trasu, aby odpovědi věděly, kam jít. To zachovává identitu podu, kterou některé bezpečnostní modely chtějí, a rozšiřuje jak rozsah směrování, tak rozsah firewallu, který druhá strana musí přijmout.

Obchod je čitelnost proti rozsahu. Překlad způsobí, že místní strana vidí jednu adresu na uzel, což se snadno přidává do seznamu povolených a skrývá, který pod co poslal. Bez překladu zůstává adresa podu end-to-end, což je lepší pro přisouzení a horší pro každé zařízení na cestě, které se musí naučit nový rozsah. Ani jedna možnost není závada Dockeru nebo CNI; obě jsou rozhodnutí o směrování s provozním účtem. Vyberte tu, jejíž účet váš tým zaplatí, a napište proč.

Ověřte a vraťte zpět

Spusťte stejný odchyt znovu. Odchyt na úrovni uzlu, který po vaší úpravě stále vypisuje adresu podu, znamená, že se pravidla nikdy nezměnila, ať ConfigMap říká cokoli. Drát je fakt; všechno ostatní je úsudek.

Pak zkontrolujte opačný směr, protože polovina těchto změn se ověřuje jen směrem ven. Potvrďte, že odpověď dorazí na uzel nebo pod, který žádost odeslal, a potvrďte, že aplikace dokončila práci, místo aby jen přijala SYN. Odchyt, který ukazuje žádost bez odpovědi, je problém směrování na druhé straně, ne problém masquerade na této.

Vrácení zpět je předchozí ConfigMap aplikovaný stejným způsobem, se stejným potvrzením, že se agent restartoval a pravidla se změnila. V záznamu změny si uchovejte zdrojovou adresu před a po pro jeden známý požadavek, protože právě ten jediný řádek dokazuje, že změna udělala, co jste řekl. Průvodce agentem IP masquerade v GKE dokumentuje výchozí hodnoty a pole ConfigMapu. Pokud se zdrojová adresa po nasazení nezmění, agent na tom uzlu neběží a žádné úpravy YAML to nespraví.