Pod-VPN in Kubernetes versus uitgangsgateway: wie bezit de tunnel?

Je implementeert een Pod met de naam vpn-gateway, wijst een testclient naar het adres en ziet de pakketten verdwijnen. Niets in het manifest is verkeerd en de kubelet heeft niets te klagen. De reden is structureel en niet configurationeel: Kubernetes geeft elke Pod zijn eigen netwerknamespace, dus een naam, een label of een gedeelde API-namespace verandert niets aan waar de pakketten heen gaan. De beslissing hoe VPN-verkeer het cluster verlaat begint daarom met een vraag over eigenaarschap, niet over containerimages.

Twee mechanismen dekken de meeste echte implementaties, en ze zijn niet uitwisselbaar. De ene plaatst de tunnel in de eigen netwerknamespace van de workload. De andere vraagt het CNI geselecteerd verkeer via een aangewezen gateway-node te leiden. Ze falen anders, schalen anders en vallen onder andere teams, waardoor de containervraag meestal discussies oplevert die nooit worden beslecht.

Een Pod-grens is een namespace, geen spronghost

Een Linux-netwerknamespace bezit zijn interfaces, adressen, routes en firewallregels, en elke Pod krijgt er een. Containers in die Pod sluiten zich erbij aan, en dat is precies waarom een hulpcontainer routes kan herschrijven die de applicatie daarna volgt. Een naburige Pod heeft een identiek uitziende maar volledig aparte stack. Er is geen gedeelde tabel die een gateway-Pod kan erven, en geen impliciete overdracht van verkeer van de ene namespace naar de andere.

Daarom werkt het gateway-Pod-patroon alleen wanneer iets stroomopwaarts er echt pakketten naartoe stuurt: een Service, een statische route op de node of stuurbeleid in het CNI. Een adres alleen trekt niets aan.

Wat een tunnel per Pod koopt, en wat hij kost

Een tunnel die in de namespace van de workload draait geeft die workload zijn eigen clientidentiteit, die veel externe toegangsdiensten eisen voordat ze een sessie autoriseren of verantwoorden. De impactradius blijft ook lokaal: een kapotte tunnel schakelt één Deployment uit in plaats van het gedeelde pad dat alles gebruikt. Hoe hij draait hangt van de implementatie af, en hier gissen mensen verkeerd.

Een opstelling die alleen kernelstatus nodig heeft, kan in een init-container eindigen en afsluiten. Een userspace-daemon die het hele leven van de Pod in leven moet blijven, heeft de herstartbare init-containervorm nodig die in Kubernetes 1.29 als native sidecar is geïntroduceerd, en dat onderscheid komt uit de tunnelimplementatie en niet uit smaak. De kosten van dit model zijn duplicatie: elke replica authenticeert, krijgt zijn eigen tunneladres en neemt een externe sessieplaats in, waardoor een autoscaling-gebeurtenis een capaciteitsgebeurtenis aan de andere kant van de verbinding wordt. Eén credential naar alle replica’s kopiëren verwijdert die kosten niet, het verwijdert het auditspoor. Machtigingen verdienen dezelfde toets, want een tunnel die NET_ADMIN in zijn eigen namespace wil, heeft geen reden om de hostbrede autoriteit van een voorbeeld met privileged: true te erven.

Wanneer het CNI de uitgang bezit

Als het CNI het ondersteunt, kiest een uitgangsgateway verkeer op basis van workload en bestemmingsbereik en stuurt het dan via gekozen nodes onder één voorspelbaar bronadres. De versie van Cilium is de gangbare referentie, en de documentatie zegt duidelijk dat de functie een specifieke Cilium-configuratie plus gateway-nodes met de juiste interfaces en adressen vereist. Ze noemt ook een beginperiode na het aanmaken van de Pod waarin sturing nog niet wordt afgedwongen, wat een ontwerpinput is en geen voetnoot.

Lees die vertraging tegen je eigen belofte. Als de regel is dat geen verkeer via een andere route mag vertrekken, heeft een nieuwe Pod die tijdens de opening zendt die al gebroken, dus de opstartvolgorde heeft zijn eigen antwoord nodig: houd de applicatie tegen tot het beleid geldt, of accepteer het venster en documenteer het.

Houd de bewering smal. Een uitgangsgateway kiest en vertaalt een pad. Hij beëindigt geen VPN, en hij maakt het cluster niet tot client van je externe netwerk zonder een ondersteunde verbinding erachter.

Vertaling verandert stil wat de externe kant ziet

Zodra de gateway de bron herschrijft, zijn de adressen per Pod weg, dus een toelatingslijst op basis van identiteit wordt een lijst op basis van één gedeeld adres. Dat is een ruil en geen defect: minder regels te onderhouden, grovere toewijzing wanneer iets zich slecht gedraagt.

Authenticatie op applicatieniveau en requestlogging moeten dragen wat het netwerk niet meer meldt. Behandel gatewaycapaciteit en -vervanging als gedeelde infrastructuur, want een enkele node-herstart onderbreekt nu elke workload erachter, en controleer het retourpad vroeg: de externe kant moet weten hoe hij het vertaalde adres bereikt, meestal via een route of NAT die een mens, niet een manifest, moet bezitten. Adresplanning hoort hier ook bij, want overlappende cluster- en externe bereiken breken beide modellen en IPv6 adopteren verontschuldigt geen tegenstrijdig plan.

Beslis op eigenaarschap en test dan de fout die je beloofde

Kies de tunnel per Pod wanneer de externe dienst individuele workloads authenticeert, wanneer slechts enkele Deployment de verbinding nodig hebben en wanneer een fout lokaal moet blijven. Kies de gateway wanneer een netwerkteam het pad al bezit, wanneer veel workloads één bestemming delen en wanneer een stabiel bronadres het hele doel van de oefening is.

Hoe dan ook, verifieer de eigenschap die je hebt verkocht en niet de stabiele toestand. Maak een Pod, laat hem meteen zenden en kijk naar de eerste seconden als de belofte was dat niets aan de tunnel ontsnapt. Schaal naar vijf replica’s en tel de sessies die de externe kant meldt als de belofte identiteit per workload was. Die twee controles leggen de grenzen van het mechanisme veel sneller bloot dan een beoordeling van het manifest, en ze vertellen je welk team het volgende incident bezit.