Pod, Node oder Cluster: was eine VPN-Sidecar wirklich umleitet

Eine VPN-Sidecar in einem Kubernetes-Pod sieht aus wie ein VPN auf Host-Ebene mit besseren Manieren, und die Ähnlichkeit endet an der Namespace-Grenze. Container in einem Pod teilen sich den Netzwerk-Namespace, einschließlich Adress- und Portraum, daher ändert eine Sidecar, die Routen und Policy installiert, tatsächlich, wohin die Pakete der Anwendung gehen. Für die anderen Pods auf dem Node ändert sie nichts, und sie berührt den eigenen Stack des Nodes nicht, sofern Sie sie nicht entsprechend konfigurieren. Diese Grenze richtig zu ziehen entscheidet sowohl darüber, was Sie ausrollen können, als auch darüber, was Sie testen müssen. Die folgenden Abschnitte folgen ihr vom Namespace nach außen.

Gemeinsamer Namespace, gemeinsame Folgen

Zwei Container in einem Pod sprechen über Loopback und sehen dieselben Schnittstellen, und genau deshalb funktioniert das Sidecar-Muster überhaupt: Die Anwendung muss nicht wissen, dass ein Tunnel existiert, weil die Route, zu der sie auflöst, im verwendeten Namespace installiert wurde. Dieselbe Eigenschaft bedeutet, dass die Fehler der Sidecar die Fehler der Anwendung sind. Eine Route, die zu viel erfasst, oder eine DNS-Änderung, die auf einen Resolver innerhalb des Tunnels zeigt, gilt sofort für jeden Prozess in diesem Pod. In einem gemeinsamen Namespace gibt es kein Routing pro Container, daher lässt sich eine Sidecar nicht auf einen Prozess beschränken.

Das ist der Mechanismus, den man bei der Prüfung im Kopf behalten sollte: Der Wirkungsradius ist der Pod, nicht der Node und nicht der Cluster.

Was die Sidecar nicht erreicht

Andere Pods behalten ihre eigenen Namespaces und ihr eigenes Routing, daher braucht eine Workload mit demselben Egress dieselbe Sidecar oder stattdessen ein Design auf Node-Ebene. Auch der Verkehr des Nodes liegt außerhalb des Pod-Namespace, und Pods mit Host-Netzwerk verzichten bewusst vollständig auf diese Isolation. Wenn Sie die Sidecar mit Host-Netzwerk betreiben, um bequem etwas zu erreichen, haben Sie den Geltungsbereich von einem Pod auf den ganzen Node erweitert, und das sollten Sie laut sagen.

Cluster-Service-Verkehr ist die andere häufige Überraschung. Eine breite Default-Route im Pod kann Anfragen abfangen, die für den API-Server oder einen ClusterIP-Service bestimmt sind, und diese schlagen dann so fehl, dass es aussieht, als sei der Tunnel kaputt.

Routenplan: Pod-, Service-, Node- und VPN-Bereiche

Schreiben Sie die vier Bereiche auf und prüfen Sie sie vor dem Deployment auf Überschneidungen: Pod-CIDR, Service-CIDR, Node-Adressen und die Ziele hinter dem VPN. Überschneidungen zwischen den privaten Bereichen des VPN und dem eigenen Raum des Clusters sind nicht selten, und eine Default-Route ist die falsche Lösung dafür. Der Routenplan gehört in dasselbe Repository wie das Manifest, denn der nächste Cluster kann ganz andere Pod- und Service-Bereiche vergeben.

DNS ist Teil des Plans und kein separates Anliegen. Eine Sidecar, die die Resolver-Konfiguration umschreibt, kann die Service-Discovery im Cluster brechen, während externe Abfragen einwandfrei funktionieren.

Start und Ausfall sind ausdrückliche Zustände

Ein laufender Sidecar-Prozess ist keine Egress-Policy. Entscheiden Sie, welcher Verkehr fließen darf, bevor der Tunnel bereit ist, und was passiert, wenn er danach stirbt, und setzen Sie diese Entscheidung dann um: eine Probe, die den Anwendungscontainer gated, eine Netzwerk-Policy, die standardmäßig verweigert, oder beides. Ohne eines davon startet die Anwendung, löst auf und schickt Verkehr über den normalen Pfad des Nodes hinaus, während der Tunnel noch verbindet.

Diese Lücke ist in einem gesunden Cluster kurz und in einem kaputten dauerhaft, und genau diese Eigenschaft bevorzugt ein Angreifer oder ein versehentliches Datenleck.

Koppeln Sie die Reihenfolge an einen Ausfalltest. Töten Sie die Sidecar und bestätigen Sie, dass die Anwendung ihren vorgesehenen Egress verliert, statt still zurückzufallen.

Capabilities, Policies und Tests aus dem App-Container

Die Capabilities zu vergeben, die zum Erstellen von Schnittstellen und Ändern von Routen nötig sind, ist eine Privilegienentscheidung, und ein Privileg, das für einen isolierten Pod passt, passt nicht automatisch auf den Node-Stack. Nutzen Sie die unterstützten Mechanismen für Netzwerk- und Sicherheits-Policy des Clusters und nehmen Sie nicht an, dass jede CNI- oder Policy-Implementierung eine VPN-Schnittstelle gleich behandelt; die Unterschiede zeigen sich genau in den Ausfallfällen, die Sie interessieren.

Testen Sie aus dem echten Anwendungscontainer, mit frischen Anfragen an ein privates Ziel, einen Cluster-Service und das öffentliche Internet. Ein Test aus der Sidecar beweist, dass der Tunnel funktioniert, nicht dass die Anwendung erreicht, was sie braucht.

Dokumentieren Sie die Netzwerkannahmen des Clusters neben der VPN-Konfiguration. Die Workload in einen anderen Cluster zu verschieben ist dann eine Übung im Prüfen des Routenplans statt eine Image-Änderung, die still aufhört zu funktionieren.