Pod-VPN i Kubernetes kontra utgangsgateway: kven eig tunnelen?

Du rullar ut ein Pod som heiter vpn-gateway, peikar ein testklient mot adressa og ser pakkane forsvinne. Ingenting i manifestet er gale, og kubelet har ingenting å klage på. Årsaka er strukturell og ikkje konfigurasjonsmessig: Kubernetes gjev kvar Pod sitt eige nettverksnamnerom, så eit namn, ei etikett eller eit delt API-namnerom endrar ingenting på kvar pakkane går. Å avgjere korleis VPN-trafikk forlèt klynga byrjar derfor med eit spørsmål om eigarskap, ikkje om containerbilete.

To mekanismar dekkjer dei fleste reelle utrullingane, og dei er ikkje utbyttbare. Den eine set tunnelen inne i arbeidslasta sitt eige nettverksnamnerom. Den andre ber CNI-et leie utvald trafikk gjennom ein utpeikt gateway-node. Dei feilar ulikt, skalerer ulikt og svarar til ulike team, og difor gir containerspørsmålet vanlegvis diskusjonar som aldri blir avslutta.

Ei Pod-grense er eit namnerom, ikkje ein sprettserver

Eit Linux-nettverksnamnerom eig grensesnitta, adressene, rutene og brannmurreglane sine, og kvar Pod får eitt. Containarar i den Poden sluttar seg til det, og det er nettopp difor ein hjelpecontainer kan skrive om ruter som applikasjonen deretter følgjer. Ein nabopod har ein identisk utsjånad, men heilt separat stabel. Det finst inga delt tabell som ein gateway-Pod kan arve, og inga implisitt overlevering av trafikk frå eitt namnerom til eit anna.

Det er også difor gateway-Pod-mønsteret berre verkar når noko oppstraums faktisk sender pakkar til det: ein Service, ei statisk rute på noden eller styringsregel i CNI-et. Ei adresse åleine tiltrekkjer ingenting.

Kva ein tunnel per Pod kjøper, og kva han kostar

Ein tunnel som køyrer i namnerommet til arbeidslasta gir den arbeidslasta sin eigen klientidentitet, som mange fjernåtkomsttenester krev før dei autoriserer eller fører rekneskap for ei økt. Skadeomfanget held seg også lokalt: ein øydelagd tunnel slår ut ein Deployment i staden for den delte vegen alt brukar. Korleis han køyrer avheng av implementasjonen, og det er her folk gissar feil.

Eit oppsett som berre treng kjernestatus kan fullførast i ein init-container og avsluttast. Ein brukarroms-demon som må leve heile levetida til Poden treng den omstartbare init-container-forma som vart introdusert som innebygd sidecar i Kubernetes 1.29, og den skilnaden kjem frå tunnelimplementasjonen og ikkje frå smak. Kostnaden ved denne modellen er duplisering: kvar replika autentiserer, får si eiga tunneladresse og brukar ein fjernøktplass, så ei autoskalering blir ei kapasitetshending på den andre sida av sambandet. Å kopiere éi legitimasjon til alle replikaer fjernar ikkje den kostnaden, det fjernar revisjonssporet. Rettar fortener same gransking, for ein tunnel som vil ha NET_ADMIN i sitt eige namnerom har ingen grunn til å arve heile verten si makt frå eit privileged: true-døme.

Når CNI-et eig utgangen

Viss CNI-et støttar det, vel ein utgangsgateway trafikk etter arbeidslast og målområde, og sender han deretter gjennom utvalde nodar under éi føreseieleg kjeldeadresse. Versjonen til Cilium er den vanlege referansen, og dokumentasjonen seier tydeleg at funksjonen krev ein bestemd Cilium-konfigurasjon pluss gateway-nodar utstyrte med dei rette grensesnitta og adressene. Han nemner også ein innleiande periode etter at Poden er oppretta der styringa enno ikkje blir handheva, noko som er eit designinnspel og ikkje ei fotnote.

Les denne forseinkinga mot ditt eige løfte. Viss regelen er at ingen trafikk kan forlate på ein annan veg, har ein ny Pod som sender i gapet allereie brote han, så oppstartssekvensen treng sitt eige svar: hald applikasjonen tilbake til politikken gjeld, eller godta vindauget og dokumenter det.

Hald påstanden smal. Ein utgangsgateway vel og omset ein veg. Han avsluttar ikkje ein VPN, og han gjer ikkje klynga til klient i fjernnettet ditt utan ei støtta tilkopling bak.

Omsetjing endrar stille kva fjernsida ser

Når gatewayen skriv om kjelda, er adressene per Pod borte, så ei tillatingsliste basert på identitet blir ei liste basert på éi delt adresse. Det er ein byttehandel og ikkje ein defekt: færre reglar å vedlikehalde, grovare tilskriving når noko oppfører seg dårleg.

Autentisering på applikasjonsnivå og førespurnadslogging må bera det nettverket ikkje lenger rapporterer. Handsame gateway-kapasitet og -utskifting som delt infrastruktur, fordi ein enkel node-omstart no avbryt kvar arbeidslast bak han, og kontroller returvegen tidleg: fjernenda må vite korleis ho når den omsette adressa, vanlegvis via ei rute eller NAT som eit menneske, ikkje eit manifest, må eige. Adresseplanlegging høyrer også heime her, fordi overlappande klynge- og fjernområde øydelegg begge modellane, og IPv6 gjer ikkje ein motstridande plan akseptabel.

Avgjer etter eigarskap, og test så feilen du lova

Vel tunnelen per Pod når fjertenesta autentiserer individuelle arbeidslaster, når berre nokre få Deployment treng sambandet, og når ein feil skal halde fram med å vere lokal. Vel gatewayen når eit nettverksteam allereie eig vegen, når mange arbeidslaster deler eitt mål, og når ei stabil kjeldeadresse er heile poenget.

Uansett, verifiser eigenskapen du selde snarare enn jamvektstilstanden. Opprett ein Pod, la han sende med ein gong, og sjå dei første sekunda viss løftet var at ingenting slepp unna tunnelen. Skaler til fem replikaer, og tel øktene fjernenda rapporterer viss løftet var identitet per arbeidslast. Dei to kontrollane avdekkjer grensene til mekanismen mykje raskare enn ein gjennomgang av manifestet, og dei fortel deg kva team som eig neste hending.