Een VPN-sidecar heeft een startregel en een faalregel nodig

Een pod start de tunnelcontainer vóór de applicatie en de eerste verzoeken slagen, en dat is precies het geval dat het probleem verbergt. Ordening lost één race op en zegt niets over het verkeer dat de applicatie vier uur later start, nadat de tunnel is uitgevallen. Dat zijn twee afzonderlijke beslissingen. Meestal wordt er maar één ontworpen.

Ordening blokkeert alleen het eerste verzoek

Kubernetes ondersteunt een sidecar-levenscyclus opgebouwd uit herstartbare init-containers. In dat model kan een opstartprobe de volgende initialisatiestap tegenhouden tot de tunnel gereedheid meldt. Dat is een echte verbetering, en het loont om die bewust te gebruiken in plaats van een sleep aan een entrypoint-script toe te voegen. De poort is alleen zo goed als de voorwaarde die hij toetst.

Buiten dat model hoort de ordeningssemantiek bij de runtime of het afhankelijkheidssysteem dat je gebruikt, en die hoeven niet overeen te komen. Een deployment die van een ander platform is gekopieerd, kan lijken te wachten op de tunnel omdat de applicatie toevallig langzaam start. Dat is niet dezelfde garantie, en het faalt onder belasting.

Zeg wat de poort waarneemt: er bestaat een proces, er bestaat een interface, een handshake is voltooid. Elk daarvan is een zwakkere bewering dan „het datapad naar de bestemmingen die deze pod nodig heeft, werkt”.

Dwing het datapad af in plaats van het aan te nemen

Een probe is een controle op één moment en een firewall is een eigenschap die tussen momenten geldt. Als de eis is dat applicatieverkeer de tunnel nooit verlaat, moet die in de gedeelde netwerknaamruimte als accepteer-of-verwerpregel worden uitgedrukt. Containerstartvolgorde kan die eis niet dragen. Alleen een regel kan dat.

Containers in één pod delen die naamruimte, dus het handhavingspunt is de naamruimte zelf. Wat je ook schrijft, het moet de eigen buitenverbinding van de tunnel beschikbaar laten, want die blokkeren om de applicatie te beschermen snijdt het pad door dat de applicatie nodig heeft.

Beslis het faalbeleid expliciet: moet applicatieverkeer volledig stoppen wanneer de tunnel ongezond is, of doorgaan en als onbeschermd worden gemarkeerd? Beide zijn verdedigbaar, en geen van beide is wat je krijgt door containers in een bepaalde volgorde te starten.

Test het verkeer dat je niet noemde

Neem een nieuw verzoek tijdens een gecontroleerde tunnelstoring en kijk of het naar buiten gaat. Herhaal daarna de controle voor de paden die een exit-adrestest nooit raakt: DNS-resolutie binnen het cluster, IPv6-bestemmingen en diensten die via clusterinterne adressen in plaats van het openbare internet worden bereikt. Dat zijn de paden die na de dood van de tunnel stilletjes blijven werken.

Een exit-adrespagina bewijst dat één verzoek op dat moment ging waar je het verwachtte. Hij kan de andere paden niet inventariseren, en de kloof tussen wat je hebt getest en wat de pod kan bereiken is waar de interessante storingen leven.

Herhaal de test na een sidecar-herstart en niet alleen na een schone start. Een herstarte tunnelcontainer kan de naamruimte met routes en beleid in een tussenstatus achterlaten.

Schrijf het deploymentrecord

Drie feiten horen in de deploymentnotities: de gereedheidstest en wat die waarneemt, de herstelactie wanneer die test faalt, en de handhavingsregel die egress beheert. De documentatie over sidecar-containers behandelt de levenscyclusmechanica en laat die beleidsbeslissing aan jou. Die verdeling is juist, en dat is ook waarom het beleid meestal ontbreekt.

Een gezondheidscheck die voor bescherming wordt aangezien is de duurste soort groene indicator, omdat hij mensen ervan weerhoudt vragen te stellen. Hem in de documentatie nauwkeurig benoemen kost één zin en voorkomt dat.

Test ten slotte het herstelpad één keer met de applicatie draaiend. Een ontwerp dat vereist dat de pod opnieuw wordt gemaakt om egress te herstellen is een beslissing, en het zou er een moeten zijn die je nam in plaats van een die je ontdekte.