Kubernetes-Pod-VPN kontra udgangsgateway: hvem ejer tunnelen?

Du udruller en Pod ved navn vpn-gateway, peger en testklient på dens adresse og ser pakkerne forsvinde. Intet i manifestet er forkert, og kubelet har intet at klage over. Årsagen er strukturel snarere end konfigurationsmæssig: Kubernetes giver hver Pod sit eget netværksnavnerum, så et navn, en etiket eller et delt API-navnerum ændrer intet ved, hvor pakkerne går hen. At beslutte, hvordan VPN-trafik forlader klyngen, begynder derfor med et spørgsmål om ejerskab, ikke om containerbilleder.

To mekanismer dækker de fleste reelle udrulninger, og de kan ikke udskiftes. Den ene placerer tunnelen i arbejdsbyrdens eget netværksnavnerum. Den anden beder CNI’en om at lede udvalgt trafik gennem en udpeget gateway-node. De fejler forskelligt, skalerer forskelligt og svarer til forskellige teams, og derfor skaber containerspørgsmålet normalt diskussioner, der aldrig bilægges.

En Pod-grænse er et navnerum, ikke en springserver

Et Linux-netværksnavnerum ejer sine interfaces, adresser, ruter og firewallregler, og hver Pod får et. Containere i den Pod slutter sig til det, og det er netop derfor en hjælpecontainer kan omskrive ruter, som applikationen derefter følger. En nabopod har en identisk udseende, men helt adskilt stak. Der er ingen delt tabel, som en gateway-Pod kan arve, og ingen implicit overdragelse af trafik fra ét navnerum til et andet.

Det er også derfor, at gateway-Pod-mønstret kun virker, når noget opstrøms faktisk sender pakker til det: en Service, en statisk rute på noden eller styringspolitik i CNI’en. En adresse alene tiltrækker intet.

Hvad en tunnel pr. Pod køber, og hvad den koster

En tunnel, der kører i arbejdsbyrdens navnerum, giver den arbejdsbyrde sin egen klientidentitet, hvilket mange fjernadgangstjenester kræver, før de autoriserer eller bogfører en session. Skadesradius forbliver også lokal: en brudt tunnel slår én Deployment ud i stedet for den delte vej, som alt bruger. Hvordan den kører, afhænger af implementeringen, og det er her, folk gætter forkert.

Opsætning, der kun kræver kernetilstand, kan afsluttes i en init-container og afslutte. En brugerspace-dæmon, der skal leve hele Pod’ens levetid, kræver den genstartbare init-container-form, der blev indført som native sidecar i Kubernetes 1.29, og den forskel kommer fra tunnelimplementeringen snarere end fra smag. Omkostningen ved denne model er duplikering: hver replika autentificerer, modtager sin egen tunneladresse og optager en fjernsessionsplads, så en autoskalering bliver en kapacitetshændelse i den anden ende af forbindelsen. At kopiere én legitimationsoplysning til alle replikaer fjerner ikke den omkostning, den fjerner revisionssporet. Kapabiliteter fortjener samme granskning, for en tunnel, der vil have NET_ADMIN i sit eget navnerum, har ingen grund til at arve hele værtens myndighed fra et privileged: true-eksempel.

Når CNI’en ejer udgangen i stedet

Hvis CNI’en understøtter det, vælger en udgangsgateway trafik efter arbejdsbyrde og destinationsinterval og sender den derefter gennem udvalgte noder under én forudsigelig kildeadresse. Ciliums version er den gængse reference, og dens dokumentation er tydelig om, at funktionen kræver en specifik Cilium-konfiguration plus gateway-noder, der er udstyret med de rigtige interfaces og adresser. Den nævner også en indledende periode efter Pod-oprettelsen, hvor styringen endnu ikke håndhæves, hvilket er et designinput snarere end en fodnote.

Læs den forsinkelse op mod dit eget løfte. Hvis reglen er, at ingen trafik må forlade systemet ad en anden vej, har en ny Pod, der sender i hullet, allerede brudt den, så opstartssekvensen har brug for sit eget svar: hold applikationen tilbage, indtil politikken gælder, eller accepter vinduet og dokumentér det.

Hold påstanden snæver. En udgangsgateway vælger og oversætter en vej. Den afslutter ikke en VPN og gør ikke klyngen til klient i dit fjernnetværk uden en understøttet forbindelse bag den.

Oversættelse ændrer stille, hvad fjernsiden ser

Når gatewayen omskriver kilden, er adresserne pr. Pod væk, så en tilladelsesliste baseret på identitet bliver en tilladelsesliste baseret på én delt adresse. Det er en byttehandel snarere end en defekt: færre regler at vedligeholde, grovere tilskrivning, når noget opfører sig dårligt.

Autentificering på applikationsniveau og anmodningslogning skal bære det, netværket ikke længere rapporterer. Behandl gateway-kapacitet og -udskiftning som delt infrastruktur, fordi en enkelt node-genstart nu afbryder hver arbejdsbyrde bag den, og kontroller returvejen tidligt: fjernenden skal vide, hvordan den når den oversatte adresse, normalt gennem en rute eller NAT, som et menneske, ikke et manifest, skal eje. Adresseplanlægning hører også hertil, fordi overlappende klynge- og fjernintervaller ødelægger begge modeller, og IPv6 gør ikke en modstridende plan acceptabel.

Beslut efter ejerskab, og test så den fejl, du lovede

Vælg tunnelen pr. Pod, når fjertjenesten autentificerer individuelle arbejdsbyrder, når kun få Deployment har brug for forbindelsen, og når en fejl skal forblive lokal. Vælg gatewayen, når et netværksteam allerede ejer vejen, når mange arbejdsbyrder deler én destination, og når en stabil kildeadresse er hele pointen.

Uanset hvad, verificér den egenskab, du solgte, snarere end steady state. Opret en Pod, lad den sende med det samme, og se de første sekunder, hvis løftet var, at intet undslipper tunnelen. Skalér til fem replikaer, og tæl de sessioner, fjernenden rapporterer, hvis løftet var identitet pr. arbejdsbyrde. De to kontroller afslører mekanismens grænser meget hurtigere end en gennemgang af manifestet, og de fortæller dig, hvilket team der ejer næste hændelse.