VPN v Podu na Kubernetes versus výstupní brána: komu patří tunel?

Nasadíte Pod jménem vpn-gateway, namíříte na jeho adresu testovacího klienta a sledujete, jak pakety mizí. V manifestu není nic špatně a kubelet nemá co vytknout. Důvod je strukturální, ne konfigurační: Kubernetes dává každému Podu vlastní síťový jmenný prostor, takže jméno, štítek ani sdílený jmenný prostor API nic nemění na tom, kam pakety jdou. Rozhodnutí, jak VPN provoz opouští cluster, proto začíná otázkou vlastnictví, ne otázkou obrazů kontejnerů.

Většinu skutečných nasazení pokrývají dva mechanismy a nejsou zaměnitelné. Jeden umísťuje tunel do vlastního síťového jmenného prostoru zátěže. Druhý žádá CNI, aby vybraný provoz vedlo přes určený uzel brány. Selhávají různě, škálují různě a odpovídají různým týmům, a proto otázka kontejnerů obvykle plodí spory, které se nikdy nevyřeší.

Hranice Podu je jmenný prostor, ne odrazový hostitel

Síťový jmenný prostor Linuxu vlastní svá rozhraní, adresy, trasy a pravidla firewallu a každý Pod dostane jeden. Kontejnery v tomto Podu se k němu připojují, a právě proto může pomocný kontejner přepsat trasy, které aplikace potom následuje. Sousední Pod má stejně vypadající, ale zcela oddělený stack. Neexistuje sdílená tabulka, kterou by Pod brány mohl zdědit, ani implicitní předání provozu z jednoho jmenného prostoru do druhého.

Proto vzor Podu brány funguje jen tehdy, když proti proudu něco skutečně posílá pakety k němu: Service, statická trasa na uzlu nebo politika směrování v CNI. Samotná adresa nic nepřitáhne.

Co tunel pro každý Pod přináší a co stojí

Tunel běžící ve jmenném prostoru zátěže dává této zátěži vlastní identitu klienta, kterou mnoho služeb vzdáleného přístupu vyžaduje, než relaci autorizují nebo zaúčtují. Dosah selhání zůstává lokální: rozbitý tunel vyřadí jeden Deployment místo sdílené cesty, kterou používá všechno. Jak běží, závisí na implementaci, a právě zde lidé hádají špatně.

Nastavení, které potřebuje jen stav jádra, může skončit v init kontejneru a ukončit se. Uživatelský démon, který musí zůstat živý po celou dobu života Podu, potřebuje restartovatelnou formu init kontejneru zavedenou jako nativní postranní kontejner v Kubernetes 1.29, a tento rozdíl vychází z implementace tunelu, ne z vkusu. Cena tohoto modelu je duplikace: každá replika se autentizuje, dostává vlastní adresu tunelu a zabírá slot vzdálené relace, takže událost automatického škálování se stává událostí kapacity na druhé straně spoje. Kopírování jednoho pověření do všech replik tuto cenu neodstraní, odstraní auditní stopu. Oprávnění si zaslouží stejnou pozornost, protože tunel, který chce NET_ADMIN ve svém vlastním jmenném prostoru, nemá důvod dědit pravomoc nad celým hostitelem z příkladu s privileged: true.

Když výstup vlastní CNI

Pokud to CNI podporuje, výstupní brána vybírá provoz podle zátěže a rozsahu cíle a poté jej posílá přes zvolené uzly pod jednou předvídatelnou zdrojovou adresou. Verze Cilium je běžný odkaz a její dokumentace jasně uvádí, že funkce vyžaduje specifickou konfiguraci Cilium plus uzly brány vybavené správnými rozhraními a adresami. Uvádí také počáteční období po vytvoření Podu, kdy se směrování ještě neuplatňuje, což je vstup pro návrh, ne poznámka pod čarou.

Čtěte toto zpoždění proti svému vlastnímu slibu. Pokud platí pravidlo, že žádný provoz nesmí odejít jinou cestou, nový Pod, který během mezery vysílá, je už porušil, takže startovní sekvence potřebuje vlastní odpověď: podržet aplikaci, dokud se politika neuplatní, nebo okno přijmout a zdokumentovat.

Držte tvrzení úzké. Výstupní brána vybírá a překládá cestu. Neukončuje VPN a nepřeměňuje cluster v klienta vaší vzdálené sítě bez podporovaného připojení za ní.

Překlad tiše mění to, co vzdálená strana vidí

Jakmile brána přepíše zdroj, adresy jednotlivých Podů zmizí, takže seznam povolených vázaný na identitu se změní na seznam vázaný na jednu sdílenou adresu. To je výměna, ne vada: méně pravidel k údržbě, hrubší přiřazení, když se něco chová špatně.

Autentizace na úrovni aplikace a protokolování požadavků musí nést to, co síť už nehlásí. Berte kapacitu a výměnu brány jako sdílenou infrastrukturu, protože restart jediného uzlu nyní přeruší každou zátěž za ním, a kontrolujte zpětnou cestu včas: vzdálený konec musí vědět, jak dosáhnout přeložené adresy, obvykle přes trasu nebo NAT, které musí vlastnit člověk, ne manifest. Plánování adres sem také patří, protože překrývající se rozsahy clusteru a vzdálené sítě rozbíjejí oba modely a přijetí IPv6 neomlouvá konfliktní plán.

Rozhodněte podle vlastnictví, pak otestujte selhání, které jste slíbili

Zvolte tunel pro každý Pod, když vzdálená služba autentizuje jednotlivé zátěže, když spojení potřebuje jen několik Deploymentů a když má selhání zůstat lokální. Zvolte bránu, když cestu už vlastní síťový tým, když mnoho zátěží sdílí jeden cíl a když je stabilní zdrojová adresa celým smyslem cvičení.

Ať tak či tak, ověřte vlastnost, kterou jste prodali, ne ustálený stav. Vytvořte Pod, nechte ho okamžitě vysílat a sledujte první sekundy, pokud slibem bylo, že z tunelu nic neuniká. Namnožte na pět replik a spočítejte relace, které vzdálený konec hlásí, pokud slibem byla identita pro každou zátěž. Tyto dvě kontroly odhalí hranice mechanismu mnohem rychleji než recenze manifestu a řeknou vám, který tým vlastní příští incident.