Pod, uzol alebo cluster: čo VPN sidecar naozaj presmerúva

VPN sidecar v Kubernetes Pode vyzerá ako VPN na úrovni hostiteľa s lepšími spôsobmi a podobnosť sa končí na hranici menného priestoru. Kontajnery v jednom Pode zdieľajú sieťový menný priestor vrátane adresného a portového priestoru, takže sidecar, ktorý inštaluje trasy a politiku, skutočne mení, kam idú pakety aplikácie. Pre ostatné Pody na uzle nemení nič a nedotýka sa vlastného zásobníka uzla, ak ho tak nenastavíte. Správne pochopenie tejto hranice určuje, čo môžete nasadiť aj čo musíte otestovať. Nasledujúce časti to sledujú od menného priestoru von.

Zdieľaný menný priestor, zdieľané dôsledky

Dva kontajnery v Pode spolu hovoria cez loopback a vidia rovnaké rozhrania, a preto vzor so sidecarom vôbec funguje: aplikácia nemusí vedieť, že tunel existuje, pretože trasa, na ktorú sa dostane, bola nainštalovaná v mennom priestore, ktorý používa. Tá istá vlastnosť znamená, že chyby sidecaru sú chybami aplikácie. Trasa, ktorá zachytí príliš veľa, alebo zmena DNS ukazujúca na resolver vnútri tunela, sa okamžite prejaví pri každom procese v tomto Pode. V zdieľanom mennom priestore neexistuje smerovanie po kontajneroch, takže sidecar nemožno obmedziť na jeden proces.

To je mechanizmus, ktorý treba mať pri revízii na pamäti: dosah je Pod, nie uzol a nie cluster.

Kam sa sidecar nedostane

Ostatné Pody si držia vlastné menné priestory a vlastné smerovanie, takže úloha, ktorá potrebuje rovnaký výstup, potrebuje rovnaký sidecar alebo namiesto toho návrh na úrovni uzla. Ani prevádzka uzla nie je vnútri menného priestoru Podu a Pody s hostiteľskou sieťou sa tejto izolácii zámerne úplne vyhýbajú. Ak sidecar spustíte s hostiteľskou sieťou, aby ste sa dostali k niečomu pohodlnému, rozšírili ste rozsah z jedného Podu na celý uzol a mali by ste to povedať nahlas.

Prevádzka k službám clusteru je druhé časté prekvapenie. Široká predvolená trasa v Pode môže zachytiť požiadavky určené serveru API alebo službe ClusterIP, ktoré potom zlyhávajú spôsobom, ktorý vyzerá ako rozbitý tunel.

Plán trás: rozsahy Podu, služieb, uzla a VPN

Zapíšte štyri rozsahy a pred nasadením čohokoľvek skontrolujte ich prekrytie: Pod CIDR, CIDR služieb, adresy uzla a ciele za VPN. Prekrytie medzi privátnymi rozsahmi VPN a vlastným priestorom clusteru nie je zriedkavé a predvolená trasa je na to nesprávne riešenie. Plán trás patrí do rovnakého repozitára ako manifest, pretože ďalší cluster môže prideliť úplne iné rozsahy Podov a služieb.

DNS je súčasťou plánu, nie samostatná starosť. Sidecar, ktorý prepisuje konfiguráciu resolvera, môže rozbiť objavovanie služieb vnútri clusteru, kým externé dopyty fungujú dokonale.

Štart a zlyhanie sú explicitné stavy

Bežiaci proces sidecaru nie je výstupná politika. Rozhodnite, aká prevádzka smie tiecť pred pripravenosťou tunela a čo sa stane, ak potom zomrie, a potom to rozhodnutie zaveďte: sonda, ktorá pustí kontajner aplikácie, sieťová politika, ktorá predvolene odmieta, alebo oboje. Bez jedného z toho aplikácia naštartuje, vyrieši mená a odošle prevádzku normálnou cestou uzla, kým sa tunel ešte pripája.

Tá medzera je v zdravom clusteri krátka a v pokazenom trvalá, a to je presne vlastnosť, ktorú uprednostňuje útočník alebo náhodný únik dát.

Spojte poradie s testom zlyhania. Zabite sidecar a potvrďte, že aplikácia stratí zamýšľaný výstup, namiesto toho aby sa ticho vrátila späť.

Oprávnenia, politiky a testovanie z kontajnera aplikácie

Udelenie oprávnení potrebných na vytváranie rozhraní a zmenu trás je rozhodnutie o privilégiách a privilégium vhodné pre izolovaný Pod nie je automaticky vhodné na zásobníku uzla. Používajte mechanizmy sieťovej a bezpečnostnej politiky, ktoré cluster podporuje, a nepredpokladajte, že každá implementácia CNI alebo politiky zaobchádza s VPN rozhraním rovnako; rozdiely sa ukážu práve v prípadoch zlyhania, na ktorých vám záleží.

Testujte zo skutočného kontajnera aplikácie, s novými požiadavkami na privátny cieľ, službu clusteru a verejný internet. Test zo sidecaru dokazuje, že tunel funguje, nie že sa aplikácia dostane k tomu, čo potrebuje.

Zdokumentujte sieťové predpoklady clusteru vedľa konfigurácie VPN. Presun úlohy do iného clusteru je potom cvičením v kontrole plánu trás, nie zmenou image, ktorá ticho prestane fungovať.