Ein VPN-Sidecar braucht eine Startregel und eine Fehlerregel

Ein Pod startet den Tunnelcontainer vor der Anwendung, und die ersten Anfragen gelingen — genau der Fall, der das Problem verbirgt. Die Reihenfolge behebt ein Rennen und sagt nichts über den Verkehr, den die Anwendung vier Stunden später beginnt, nachdem der Tunnel ausgefallen ist. Das sind zwei getrennte Entscheidungen. Meist wird nur eine davon entworfen.

Die Reihenfolge sperrt nur die erste Anfrage

Kubernetes unterstützt einen Sidecar-Lebenszyklus aus neustartbaren Init-Containern. In diesem Modell kann eine Startprobe den nächsten Initialisierungsschritt zurückhalten, bis der Tunnel Bereitschaft meldet. Das ist eine echte Verbesserung, und man sollte sie bewusst nutzen, statt ein Sleep in ein Entrypoint-Skript einzubauen. Das Tor ist nur so gut wie die Bedingung, die es prüft.

Außerhalb dieses Modells gehört die Reihenfolgesemantik zu der Laufzeitumgebung oder dem Abhängigkeitssystem, das Sie verwenden, und sie muss nicht übereinstimmen. Ein von einer anderen Plattform kopiertes Deployment kann auf den Tunnel zu warten scheinen, weil die Anwendung zufällig langsam startet. Das ist nicht dieselbe Garantie, und unter Last scheitert es.

Sagen Sie, was das Tor beobachtet: ein Prozess existiert, eine Schnittstelle existiert, ein Handshake ist abgeschlossen. Jede dieser Aussagen ist schwächer als „der Datenpfad zu den Zielen, die dieser Pod braucht, funktioniert“.

Den Datenpfad erzwingen statt annehmen

Eine Probe ist eine Prüfung zu einem Zeitpunkt, und eine Firewall ist eine Eigenschaft, die zwischen Zeitpunkten gilt. Wenn die Anforderung lautet, dass Anwendungsverkehr den Tunnel nie verlässt, muss sie im gemeinsamen Netzwerk-Namespace als Akzeptieren-oder-Verwerfen-Regel ausgedrückt werden. Die Startreihenfolge von Containern kann diese Anforderung nicht tragen. Nur eine Regel kann es.

Container in einem Pod teilen diesen Namespace, also ist der Durchsetzungspunkt der Namespace selbst. Was auch immer Sie schreiben, muss die eigene äußere Verbindung des Tunnels verfügbar lassen, denn sie zu blockieren, um die Anwendung zu schützen, kappt den Pfad, den die Anwendung braucht.

Entscheiden Sie die Ausfallpolitik ausdrücklich: Soll Anwendungsverkehr vollständig aufhören, wenn der Tunnel ungesund ist, oder weiterlaufen und als ungeschützt markiert werden? Beides ist vertretbar, und keines davon erhält man durch das Starten von Containern in einer bestimmten Reihenfolge.

Den Verkehr testen, den Sie nicht erwähnt haben

Stellen Sie während eines kontrollierten Tunnelausfalls eine neue Anfrage und prüfen Sie, ob sie hinausgeht. Wiederholen Sie dann die Prüfung für die Pfade, die ein Exit-Adress-Test nie berührt: DNS-Auflösung innerhalb des Clusters, IPv6-Ziele und Dienste, die über clusterinterne Adressen statt das öffentliche Internet erreicht werden. Das sind die Pfade, die nach dem Tod des Tunnels still weiter funktionieren.

Eine Exit-Adress-Seite beweist, dass eine Anfrage in diesem Moment dorthin ging, wo Sie es erwarteten. Sie kann die anderen Pfade nicht inventarisieren, und die Lücke zwischen dem, was Sie getestet haben, und dem, was der Pod erreichen kann, ist der Ort, an dem die interessanten Fehler leben.

Wiederholen Sie den Test nach einem Sidecar-Neustart und nicht nur nach einem sauberen Start. Ein neu gestarteter Tunnelcontainer kann den Namespace mit Routen und Richtlinie in einem Zwischenzustand zurücklassen.

Den Deployment-Eintrag schreiben

Drei Fakten gehören in die Deployment-Notizen: der Bereitschaftstest und was er beobachtet, die Wiederherstellungsaktion, wenn dieser Test scheitert, und die Durchsetzungsregel, die den ausgehenden Verkehr regelt. Die Dokumentation zu Sidecar-Containern deckt die Lebenszyklusmechanik ab und überlässt diese Richtlinienentscheidung Ihnen. Diese Aufteilung ist richtig, und sie ist auch der Grund, warum die Richtlinie meist fehlt.

Eine für Schutz gehaltene Gesundheitsprüfung ist die teuerste Art grüner Anzeige, weil sie Menschen davon abhält, Fragen zu stellen. Sie in der Dokumentation korrekt zu benennen kostet einen Satz und verhindert das.

Testen Sie schließlich den Wiederherstellungspfad einmal bei laufender Anwendung. Ein Design, das das Neuerstellen des Pods erfordert, um ausgehenden Verkehr wiederherzustellen, ist eine Entscheidung, und es sollte eine sein, die Sie getroffen haben, nicht eine, die Sie entdeckt haben.