VPN pre Pod v Kubernetes verzus výstupná brána: komu patrí tunel?

Nasadíte Pod s názvom vpn-gateway, namierite testovacieho klienta na jeho adresu a sledujete, ako pakety miznú. V manifeste nie je nič zlé a kubelet nemá čo vytknúť. Dôvod je štrukturálny, nie konfiguračný: Kubernetes dáva každému Podu vlastný sieťový menný priestor, takže názov, štítok ani spoločný menný priestor API nič nemenia na tom, kam pakety idú. Preto rozhodnutie, ako VPN prevádzka opúšťa klaster, začína otázkou vlastníctva, nie obrazov kontajnerov.

Dva mechanizmy pokrývajú väčšinu reálnych nasadení a nie sú zameniteľné. Jeden umiestňuje tunel do vlastného sieťového menného priestoru záťaže. Druhý žiada CNI, aby vybranú prevádzku viedlo cez určený uzol brány. Zlyhávajú inak, škálujú inak a podliehajú iným tímom, a preto otázka kontajnerov zvyčajne vytvára spory, ktoré sa nikdy neuzavrú.

Hranica Podu je menný priestor, nie odrazový hostiteľ

Sieťový menný priestor Linuxu vlastní svoje rozhrania, adresy, trasy a pravidlá firewallu a každý Pod dostane jeden. Kontajnery v tomto Pode sa k nemu pripájajú, a práve preto môže pomocný kontajner prepísať trasy, ktoré aplikácia potom nasleduje. Susedný Pod má rovnako vyzerajúci, ale úplne oddelený zásobník. Neexistuje spoločná tabuľka, ktorú by Pod brány mohol zdediť, ani implicitné odovzdanie prevádzky z jedného menného priestoru do druhého.

Preto vzor Podu brány funguje len vtedy, keď niečo proti prúdu skutočne posiela pakety k nemu: Service, statická trasa na uzle alebo politika smerovania v CNI. Samotná adresa nič nepriťahuje.

Čo tunel pre každý Pod prináša a čo stojí

Tunel bežiaci v mennom priestore záťaže dáva tejto záťaži vlastnú klientsku identitu, ktorú mnohé služby vzdialeného prístupu vyžadujú pred autorizáciou alebo zaúčtovaním relácie. Dosah zlyhania zostáva lokálny: pokazený tunel vyradí jeden Deployment namiesto spoločnej cesty, ktorú používa všetko. Ako beží, závisí od implementácie, a práve tu ľudia hádžu nesprávne.

Konfigurácia, ktorá potrebuje len stav jadra, môže skončiť v init kontajneri a skončiť. Používateľský démon, ktorý musí zostať živý počas celej životnosti Podu, potrebuje reštartovateľnú formu init kontajnera zavedenú ako natívny bočný kontajner v Kubernetes 1.29, a tento rozdiel vychádza z implementácie tunela, nie z vkusu. Cena tohto modelu je duplikácia: každá replika sa autentifikuje, dostáva vlastnú adresu tunela a zaberá miesto vzdialenej relácie, takže udalosť automatického škálovania sa stáva udalosťou kapacity na druhej strane spojenia. Kopírovanie jedného poverenia do všetkých replík túto cenu neodstráni, odstráni audítorskú stopu. Oprávnenia si zaslúžia rovnaké preskúmanie, pretože tunel, ktorý chce NET_ADMIN vo svojom mennom priestore, nemá dôvod dediť právomoc nad celým hostiteľom z príkladu s privileged: true.

Keď výstup vlastní CNI

Ak to CNI podporuje, výstupná brána vyberá prevádzku podľa záťaže a rozsahu cieľa a potom ju posiela cez zvolené uzly pod jednou predvídateľnou zdrojovou adresou. Verzia Cilium je bežný odkaz a jej dokumentácia jasne uvádza, že funkcia vyžaduje špecifickú konfiguráciu Cilium plus uzly brány vybavené správnymi rozhraniami a adresami. Uvádza aj počiatočné obdobie po vytvorení Podu, keď sa smerovanie ešte neuplatňuje, čo je vstup pre návrh, nie poznámka pod čiarou.

Čítajte toto oneskorenie proti svojmu vlastnému sľubu. Ak pravidlom je, že žiadna prevádzka nesmie odísť inou cestou, nový Pod, ktorý vysiela počas medzery, ho už porušil, takže spúšťacia sekvencia potrebuje vlastnú odpoveď: podržať aplikáciu, kým sa politika neuplatní, alebo okno prijať a zdokumentovať.

Držte tvrdenie úzke. Výstupná brána vyberá a prekladá cestu. Neukončuje VPN a nepremieňa klaster na klienta vašej vzdialenej siete bez podporovaného spojenia za ňou.

Preklad ticho mení to, čo vzdialená strana vidí

Akonáhle brána prepíše zdroj, adresy jednotlivých Podov zmiznú, takže zoznam povolených viazaný na identitu sa zmení na zoznam viazaný na jednu spoločnú adresu. Je to výmena, nie chyba: menej pravidiel na údržbu, hrubšie priradenie, keď sa niečo správa zle.

Autentifikácia na úrovni aplikácie a protokolovanie požiadaviek musia niesť to, čo sieť už nehlási. Berte kapacitu a výmenu brány ako zdieľanú infraštruktúru, pretože reštart jedného uzla teraz prerušuje každú záťaž za ním, a skontrolujte spiatočnú cestu včas: vzdialený koniec musí vedieť, ako sa dostať k preloženej adrese, zvyčajne cez trasu alebo NAT, ktorý musí vlastniť človek, nie manifest. Plánovanie adries sem tiež patrí, pretože prekrývajúce sa rozsahy klastra a vzdialenej siete kazia oba modely a prijatie IPv6 neospravedlňuje protirečivý plán.

Rozhodnite podľa vlastníctva, potom otestujte zlyhanie, ktoré ste sľúbili

Zvoľte tunel pre každý Pod, keď vzdialená služba autentifikuje jednotlivé záťaže, keď spojenie potrebuje len niekoľko Deploymentov a keď má zlyhanie zostať lokálne. Zvoľte bránu, keď cestu už vlastní sieťový tím, keď mnohé záťaže zdieľajú jeden cieľ a keď je stabilná zdrojová adresa celým zmyslom cvičenia.

Tak či tak overte vlastnosť, ktorú ste predali, nie ustálený stav. Vytvorte Pod, nechajte ho okamžite vysielať a sledujte prvé sekundy, ak sľubom bolo, že z tunela nič neuniká. Namnožte na päť replík a spočítajte relácie, ktoré vzdialený koniec hlási, ak sľubom bola identita pre každú záťaž. Tieto dve kontroly odhalia hranice mechanizmu oveľa rýchlejšie než recenzia manifestu a povedia vám, ktorému tímu patrí ďalší incident.