Pod-VPN in Kubernetes oder Egress-Gateway: Wem gehört der Tunnel?

Sie setzen einen Pod namens vpn-gateway ein, richten einen Testclient auf seine Adresse und sehen die Pakete verschwinden. Am Manifest ist nichts falsch, und der kubelet hat nichts zu beanstanden. Der Grund ist struktureller und nicht konfigurationstechnischer Natur: Kubernetes gibt jedem Pod seinen eigenen Netzwerk-Namespace, daher ändern ein Name, ein Label oder ein gemeinsamer API-Namespace nichts daran, wohin Pakete gehen. Die Entscheidung, wie VPN-Verkehr den Cluster verlässt, beginnt deshalb mit einer Frage nach dem Eigentum und nicht nach Container-Images.

Zwei Mechanismen decken die meisten realen Deployments ab, und sie sind nicht austauschbar. Der eine legt den Tunnel in den eigenen Netzwerk-Namespace des Workloads. Der andere bittet das CNI, ausgewählten Verkehr über einen bestimmten Gateway-Knoten zu lenken. Sie scheitern unterschiedlich, skalieren unterschiedlich und unterstehen unterschiedlichen Teams, weshalb die Container-Frage meist Diskussionen erzeugt, die nie enden.

Eine Pod-Grenze ist ein Namespace, kein Sprunghost

Ein Linux-Netzwerk-Namespace besitzt seine Schnittstellen, Adressen, Routen und Firewall-Regeln, und jeder Pod erhält einen. Container in diesem Pod treten ihm bei, und genau deshalb kann ein Hilfscontainer Routen umschreiben, denen die Anwendung dann folgt. Ein benachbarter Pod hat einen identisch aussehenden, aber völlig getrennten Stack. Es gibt keine gemeinsame Tabelle, die ein Gateway-Pod erben könnte, und keine implizite Übergabe von Verkehr von einem Namespace an einen anderen.

Deshalb funktioniert das Gateway-Pod-Muster nur, wenn etwas vorgelagert tatsächlich Pakete dorthin schickt: ein Service, eine statische Route auf dem Knoten oder eine Steuerungsrichtlinie im CNI. Eine Adresse allein zieht nichts an.

Was ein Tunnel pro Pod bringt und was er kostet

Ein Tunnel, der im Namespace des Workloads läuft, gibt diesem Workload seine eigene Client-Identität, die viele Fernzugriffsdienste verlangen, bevor sie eine Sitzung autorisieren oder abrechnen. Auch der Wirkungsradius bleibt lokal: ein defekter Tunnel schaltet ein Deployment aus statt des gemeinsamen Pfads, den alles nutzt. Wie er läuft, hängt von der Implementierung ab, und genau hier raten Menschen falsch.

Ein Setup, das nur Kernel-Zustand braucht, kann in einem Init-Container enden und sich beenden. Ein Userspace-Daemon, der über die Lebensdauer des Pods am Leben bleiben muss, benötigt die neustartfähige Init-Container-Form, die in Kubernetes 1.29 als nativer Sidecar eingeführt wurde, und dieser Unterschied kommt aus der Tunnel-Implementierung und nicht aus Geschmack. Die Kosten dieses Modells sind Duplizierung: Jede Replik authentifiziert sich, erhält ihre eigene Tunneladresse und belegt einen entfernten Sitzungsplatz, sodass ein Autoscaling-Ereignis zu einem Kapazitätsereignis auf der anderen Seite der Verbindung wird. Ein einzelnes Credential in alle Replikate zu kopieren beseitigt diese Kosten nicht, es beseitigt die Prüfspur. Fähigkeiten verdienen dieselbe Prüfung, denn ein Tunnel, der NET_ADMIN im eigenen Namespace will, hat keinen Grund, die hostweite Autorität eines privileged: true-Beispiels zu erben.

Wenn stattdessen das CNI den Egress besitzt

Wenn das CNI es unterstützt, wählt ein Egress-Gateway Verkehr nach Workload und Zielbereich aus und schickt ihn dann über ausgewählte Knoten unter einer vorhersagbaren Quelladresse. Ciliums Variante ist die übliche Referenz, und seine Dokumentation stellt klar, dass die Funktion eine bestimmte Cilium-Konfiguration plus Gateway-Knoten mit den richtigen Schnittstellen und Adressen erfordert. Sie erwähnt außerdem eine Anfangsphase nach der Pod-Erstellung, in der die Steuerung noch nicht erzwungen wird, was eine Designvorgabe und keine Fußnote ist.

Lesen Sie diese Verzögerung gegen Ihr eigenes Versprechen. Wenn die Regel lautet, dass kein Verkehr einen anderen Weg nehmen darf, hat ein neuer Pod, der in der Lücke sendet, sie bereits gebrochen, also braucht die Startsequenz eine eigene Antwort: die Anwendung zurückhalten, bis die Richtlinie greift, oder das Fenster akzeptieren und dokumentieren.

Halten Sie die Behauptung eng. Ein Egress-Gateway wählt und übersetzt einen Pfad. Es beendet kein VPN und macht den Cluster nicht zu einem Client Ihres entfernten Netzwerks, ohne eine unterstützte Verbindung dahinter.

Übersetzung verändert still, was die Gegenseite sieht

Sobald das Gateway die Quelle umschreibt, sind die Adressen pro Pod weg, sodass eine auf Identität gestützte Positivliste zu einer auf eine gemeinsame Adresse gestützten wird. Das ist ein Tausch und kein Defekt: weniger Regeln zu pflegen, gröbere Zuordnung, wenn etwas aus dem Ruder läuft.

Authentifizierung auf Anwendungsebene und Request-Logging müssen tragen, was das Netzwerk nicht mehr meldet. Behandeln Sie Gateway-Kapazität und -Ersatz als gemeinsame Infrastruktur, denn ein einzelner Knoten-Neustart unterbricht jetzt jeden Workload dahinter, und prüfen Sie den Rückweg früh: Die Gegenseite muss wissen, wie sie die übersetzte Adresse erreicht, meist über eine Route oder NAT, die ein Mensch und nicht ein Manifest besitzen muss. Adressplanung gehört hierher, denn überlappende Cluster- und Fernbereiche brechen beide Modelle, und IPv6 entschuldigt keinen widersprüchlichen Plan.

Entscheiden Sie nach Eigentum und testen Sie dann den versprochenen Fehler

Wählen Sie den Tunnel pro Pod, wenn der entfernte Dienst einzelne Workloads authentifiziert, wenn nur wenige Deployments die Verbindung brauchen und wenn ein Fehler lokal bleiben soll. Wählen Sie das Gateway, wenn ein Netzwerkteam den Pfad bereits besitzt, wenn viele Workloads ein Ziel teilen und wenn eine stabile Quelladresse der ganze Zweck der Übung ist.

Wie auch immer, prüfen Sie die Eigenschaft, die Sie verkauft haben, statt den Dauerzustand. Erstellen Sie einen Pod, lassen Sie ihn sofort senden und beobachten Sie die ersten Sekunden, wenn das Versprechen lautete, dass nichts dem Tunnel entkommt. Skalieren Sie auf fünf Replikate und zählen Sie die Sitzungen, die die Gegenseite meldet, wenn das Versprechen Identität pro Workload war. Diese beiden Prüfungen legen die Grenzen des Mechanismus viel schneller offen als eine Durchsicht des Manifests, und sie sagen Ihnen, welches Team den nächsten Vorfall besitzt.