En VPN-sidecar har brug for en startregel og en fejlregel

En pod starter tunnelcontaineren før applikationen, og de første anmodninger lykkes, hvilket netop er det tilfælde, der skjuler problemet. Rækkefølgen løser ét kapløb og siger intet om den trafik, applikationen starter fire timer senere, efter tunnelen er fejlet. Det er to separate beslutninger. Normalt designes kun den ene.

Rækkefølgen gater kun den første anmodning

Kubernetes understøtter en sidecar-livscyklus bygget af genstartbare init-containere. I den model kan en opstartsprobe holde det næste initialiseringstrin tilbage, indtil tunnelen melder klar. Det er en ægte forbedring, og den er værd at bruge bevidst i stedet for at tilføje et sleep til et entrypoint-script. Gaten er kun så god som den betingelse, den tester.

Uden for den model tilhører rækkefølgesemantikken den runtime eller det afhængighedssystem, du bruger, og de behøver ikke at stemme overens. En udrulning kopieret fra en anden platform kan se ud til at vente på tunnelen, fordi applikationen tilfældigvis starter langsomt. Det er ikke den samme garanti, og det fejler under belastning.

Sig, hvad gaten observerer: en proces findes, et interface findes, et handshake er fuldført. Hver af dem er en svagere påstand end “datastien til de destinationer, denne pod har brug for, virker”.

Håndhæv datastien i stedet for at antage den

En probe er et tjek på et øjeblik, og en firewall er en egenskab, der gælder mellem øjeblikke. Hvis kravet er, at applikationstrafik aldrig forlader tunnelen, skal det udtrykkes i det delte netværksnamespace som en accepter-eller-drop-regel. Containerstartrækkefølge kan ikke bære det krav. Kun en regel kan.

Containere i én pod deler det namespace, så håndhævelsespunktet er selve namespacet. Uanset hvad du skriver, skal det lade tunnelens egen ydre forbindelse være tilgængelig, fordi blokering af den for at beskytte applikationen skærer den sti over, applikationen har brug for.

Beslut fejlpolitikken eksplicit: skal applikationstrafik stoppe helt, når tunnelen er usund, eller fortsætte og markeres som ubeskyttet? Begge er forsvarlige, og ingen af dem er det, du får ved at starte containere i en bestemt rækkefølge.

Test den trafik, du ikke nævnte

Tag en ny anmodning under en kontrolleret tunnelfejl og se, om den forlader. Gentag derefter tjekket for de stier, en exit-adresse-test aldrig rører: DNS-opløsning inde i klyngen, IPv6-destinationer og tjenester nået via klyngeinterne adresser i stedet for det offentlige internet. Det er de stier, der stille fortsætter med at virke, efter tunnelen dør.

En exit-adresse-side beviser, at én anmodning gik, hvor du forventede i det øjeblik. Den kan ikke opgøre de andre stier, og kløften mellem det, du testede, og det, poden kan nå, er hvor de interessante fejl bor.

Gentag testen efter en sidecar-genstart i stedet for kun efter en ren start. En genstartet tunnelcontainer kan efterlade namespacet med ruter og politik i en mellemtilstand.

Skriv udrulningsnotatet

Tre fakta hører i udrulningsnotaterne: parathedstesten og hvad den observerer, gendannelseshandlingen når den test fejler, og håndhævelsesreglen, der styrer udgående trafik. Dokumentationen for sidecar-containere dækker livscyklusmekanikken og overlader den politiske beslutning til dig. Den opdeling er korrekt, og det er også grunden til, at politikken normalt mangler.

Et sundhedstjek forvekslet med beskyttelse er den dyreste slags grøn indikator, fordi det stopper folk med at stille spørgsmål. At navngive det præcist i dokumentationen koster én sætning og forhindrer det.

Til sidst, test gendannelsesstien én gang med applikationen kørende. Et design, der kræver, at poden genskabes for at gendanne udgående trafik, er en beslutning, og det bør være en, du traf, snarere end en, du opdagede.