Pod, uzel nebo cluster: co vlastně VPN sidecar přesměrovává

VPN sidecar v Kubernetes Podu vypadá jako VPN na úrovni hostitele s lepšími způsoby a podoba končí na hranici jmenného prostoru. Kontejnery v jednom Podu sdílejí síťový jmenný prostor včetně adresního a portového prostoru, takže sidecar, který instaluje trasy a politiku, skutečně mění, kam pakety aplikace míří. Pro ostatní Pody na uzlu nemění nic a nedotýká se vlastního zásobníku uzlu, pokud ho tak nenastavíte. Správné pochopení této hranice určuje, co můžete nasadit i co musíte testovat. Následující oddíly to sledují od jmenného prostoru ven.

Sdílený jmenný prostor, sdílené důsledky

Dva kontejnery v Podu spolu mluví přes loopback a vidí stejná rozhraní, a proto vzor se sidecarem vůbec funguje: aplikace nemusí vědět, že tunel existuje, protože trasa, kterou si vyřeší, byla nainstalována do jmenného prostoru, který používá. Stejná vlastnost znamená, že chyby sidecaru jsou chybami aplikace. Trasa, která zachytí příliš mnoho, nebo změna DNS ukazující na resolver uvnitř tunelu se okamžitě projeví u každého procesu v tomto Podu. Ve sdíleném jmenném prostoru neexistuje směrování po kontejnerech, takže sidecar nelze omezit na jeden proces.

To je mechanismus, který je třeba mít při revizi na paměti: dosah je Pod, ne uzel a ne cluster.

Kam se sidecar nedostane

Ostatní Pody si drží vlastní jmenné prostory a vlastní směrování, takže úloha, která potřebuje stejný výstup, potřebuje stejný sidecar, nebo místo toho návrh na úrovni uzlu. Ani provoz uzlu není uvnitř jmenného prostoru Podu a Pody s hostitelskou sítí se této izolaci záměrně úplně vyhýbají. Pokud sidecar spustíte s hostitelskou sítí, abyste dosáhli na něco pohodlného, rozšířili jste rozsah z jednoho Podu na celý uzel a měli byste to říct nahlas.

Provoz ke službám clusteru je druhé časté překvapení. Široká výchozí trasa uvnitř Podu může zachytit požadavky určené serveru API nebo službě ClusterIP, které pak selhávají způsobem, jenž vypadá jako rozbitý tunel.

Plán tras: rozsahy Podu, služeb, uzlu a VPN

Zapište čtyři rozsahy a před nasazením čehokoli zkontrolujte jejich překryv: Pod CIDR, CIDR služeb, adresy uzlu a cíle za VPN. Překryv mezi privátními rozsahy VPN a vlastním prostorem clusteru není vzácný a výchozí trasa je pro něj špatné řešení. Plán tras patří do stejného repozitáře jako manifest, protože příští cluster může přidělit úplně jiné rozsahy Podů a služeb.

DNS je součástí plánu, ne samostatná starost. Sidecar, který přepisuje konfiguraci resolveru, může rozbít objevování služeb uvnitř clusteru, zatímco externí dotazy fungují dokonale.

Start a selhání jsou explicitní stavy

Běžící proces sidecaru není výstupní politika. Rozhodněte, jaký provoz smí proudit před připraveností tunelu a co se stane, když potom zemře, a pak to rozhodnutí zaveďte: sonda, která pustí kontejner aplikace, síťová politika, která ve výchozím stavu odmítá, nebo obojí. Bez jednoho z toho aplikace nastartuje, vyřeší jména a odešle provoz normální cestou uzlu, zatímco se tunel ještě připojuje.

Ta mezera je ve zdravém clusteru krátká a v rozbitém trvalá, a to je přesně vlastnost, kterou preferuje útočník nebo náhodný únik dat.

Spojte pořadí s testem selhání. Zabijte sidecar a potvrďte, že aplikace ztratí zamýšlený výstup, místo aby tiše přešla zpět.

Oprávnění, politiky a testování z kontejneru aplikace

Udělení oprávnění potřebných k vytváření rozhraní a změně tras je rozhodnutí o privilegiích a privilegium vhodné pro izolovaný Pod není automaticky vhodné na zásobníku uzlu. Používejte mechanismy síťové a bezpečnostní politiky, které cluster podporuje, a nepředpokládejte, že každá implementace CNI nebo politik zachází s VPN rozhraním stejně; rozdíly se ukážou právě v případech selhání, na kterých vám záleží.

Testujte ze skutečného kontejneru aplikace, s novými požadavky na privátní cíl, službu clusteru a veřejný internet. Test ze sidecaru dokazuje, že tunel funguje, ne že se aplikace dostane k tomu, co potřebuje.

Zdokumentujte síťové předpoklady clusteru vedle konfigurace VPN. Přesun úlohy do jiného clusteru je pak cvičením v kontrole plánu tras, ne změnou image, která tiše přestane fungovat.