Pod-VPN i Kubernetes kontra utgangsgateway: hvem eier tunnelen?

Du ruller ut en Pod som heter vpn-gateway, peker en testklient mot adressen og ser pakkene forsvinne. Ingenting i manifestet er galt, og kubelet har ingenting å klage på. Årsaken er strukturell og ikke konfigurasjonsmessig: Kubernetes gir hver Pod sitt eget nettverksnavnerom, så et navn, en etikett eller et delt API-navnerom endrer ingenting på hvor pakkene går. Å avgjøre hvordan VPN-trafikk forlater klyngen begynner derfor med et spørsmål om eierskap, ikke om containerbilder.

To mekanismer dekker de fleste reelle utrullinger, og de er ikke utbyttbare. Den ene setter tunnelen inne i arbeidsbelastningens eget nettverksnavnerom. Den andre ber CNI-et lede utvalgt trafikk gjennom en utpekt gateway-node. De feiler ulikt, skalerer ulikt og svarer til ulike team, og derfor gir containerspørsmålet vanligvis diskusjoner som aldri avsluttes.

En Pod-grense er et navnerom, ikke en sprettserver

Et Linux-nettverksnavnerom eier sine grensesnitt, adresser, ruter og brannmurregler, og hver Pod får ett. Containere i den Poden slutter seg til det, og det er nettopp derfor en hjelpecontainer kan skrive om ruter som applikasjonen deretter følger. En nabopod har en identisk utseende, men helt separat stabel. Det finnes ingen delt tabell som en gateway-Pod kan arve, og ingen implisitt overlevering av trafikk fra ett navnerom til et annet.

Det er også derfor gateway-Pod-mønsteret bare virker når noe oppstrøms faktisk sender pakker til det: en Service, en statisk rute på noden eller styringsregel i CNI-et. En adresse alene tiltrekker ingenting.

Hva en tunnel per Pod kjøper, og hva den koster

En tunnel som kjører i arbeidsbelastningens navnerom gir den arbeidsbelastningen sin egen klientidentitet, som mange fjernaksess-tjenester krever før de autoriserer eller fører regnskap for en økt. Skadens radius holder seg lokal også: en ødelagt tunnel slår ut én Deployment i stedet for den delte veien alt bruker. Hvordan den kjører avhenger av implementasjonen, og det er her folk gjetter feil.

Et oppsett som bare trenger kjernetilstand kan fullføres i en init-container og avsluttes. En brukerroms-demon som må leve hele Podens levetid trenger den omstartbare init-container-formen som ble introdusert som innebygd sidecar i Kubernetes 1.29, og den forskjellen kommer fra tunnelimplementasjonen og ikke fra smak. Kostnaden ved denne modellen er duplisering: hver replika autentiserer, får sin egen tunneladresse og bruker en fjernøktplass, så en autoskalering blir en kapasitetshendelse på den andre siden av forbindelsen. Å kopiere én legitimasjon til alle replikaer fjerner ikke den kostnaden, det fjerner revisjonssporet. Rettigheter fortjener samme gransking, for en tunnel som vil ha NET_ADMIN i sitt eget navnerom har ingen grunn til å arve hele vertens myndighet fra et privileged: true-eksempel.

Når CNI-et eier utgangen

Hvis CNI-et støtter det, velger en utgangsgateway trafikk etter arbeidsbelastning og målområde, og sender den deretter gjennom utvalgte noder under én forutsigbar kildeadresse. Ciliums versjon er den vanlige referansen, og dokumentasjonen sier tydelig at funksjonen krever en bestemt Cilium-konfigurasjon pluss gateway-noder utstyrt med de riktige grensesnittene og adressene. Den nevner også en innledende periode etter at Poden er opprettet der styringen ennå ikke håndheves, noe som er et designinnspill og ikke en fotnote.

Les denne forsinkelsen mot ditt eget løfte. Hvis regelen er at ingen trafikk kan forlate på en annen vei, har en ny Pod som sender i gapet allerede brutt den, så oppstartssekvensen trenger sitt eget svar: hold applikasjonen tilbake til policyen gjelder, eller godta vinduet og dokumenter det.

Hold påstanden smal. En utgangsgateway velger og oversetter en vei. Den avslutter ikke en VPN, og den gjør ikke klyngen til klient i fjernnettet ditt uten en støttet forbindelse bak.

Oversettelse endrer stille hva fjernsiden ser

Når gatewayen skriver om kilden, er adressene per Pod borte, så en tillatelsesliste basert på identitet blir en liste basert på én delt adresse. Det er en byttehandel og ikke en defekt: færre regler å vedlikeholde, grovere tilskrivning når noe oppfører seg dårlig.

Autentisering på applikasjonsnivå og forespørselslogging må bære det nettverket ikke lenger rapporterer. Behandle gateway-kapasitet og -utskifting som delt infrastruktur, fordi en enkelt node-omstart nå avbryter hver arbeidsbelastning bak den, og kontroller returveien tidlig: fjernenden må vite hvordan den når den oversatte adressen, vanligvis via en rute eller NAT som et menneske, ikke et manifest, må eie. Adresseplanlegging hører også hjemme her, fordi overlappende klynge- og fjernområder ødelegger begge modellene, og IPv6 gjør ikke en motstridende plan akseptabel.

Bestem etter eierskap, og test så feilen du lovet

Velg tunnelen per Pod når fjertjenesten autentiserer individuelle arbeidsbelastninger, når bare noen få Deployment trenger forbindelsen, og når en feil skal forbli lokal. Velg gatewayen når et nettverksteam allerede eier veien, når mange arbeidsbelastninger deler ett mål, og når en stabil kildeadresse er hele poenget.

Uansett, verifiser egenskapen du solgte snarere enn steady state. Opprett en Pod, la den sende umiddelbart, og se de første sekundene hvis løftet var at ingenting unnslipper tunnelen. Skaler til fem replikaer, og tell øktene fjernenden rapporterer hvis løftet var identitet per arbeidsbelastning. De to kontrollene avdekker mekanismens grenser mye raskere enn en gjennomgang av manifestet, og de forteller deg hvilket team som eier neste hendelse.