En VPN-sidecar trenger en startregel og en feilregel

En pod starter tunnelcontaineren før applikasjonen, og de første forespørslene lykkes, som er nettopp tilfellet som skjuler problemet. Rekkefølgen løser ett kappløp og sier ingenting om trafikken applikasjonen starter fire timer senere, etter at tunnelen har feilet. Det er to separate beslutninger. Vanligvis designes bare én av dem.

Rekkefølgen gater bare den første forespørselen

Kubernetes støtter en sidecar-livssyklus bygget av omstartbare init-containere. I den modellen kan en oppstartsprobe holde igjen det neste initialiseringstrinnet til tunnelen rapporterer beredskap. Det er en ekte forbedring, og den er verdt å bruke bevisst i stedet for å legge til en sleep i et entrypoint-skript. Gaten er bare så god som betingelsen den tester.

Utenfor den modellen tilhører rekkefølgesemantikken den kjøretiden eller det avhengighetssystemet du bruker, og de trenger ikke stemme overens. En utrulling kopiert fra en annen plattform kan se ut som den venter på tunnelen fordi applikasjonen tilfeldigvis starter sakte. Det er ikke den samme garantien, og den feiler under last.

Si hva gaten observerer: en prosess finnes, et grensesnitt finnes, en handshake er fullført. Hver av dem er en svakere påstand enn «dataløypen til destinasjonene denne poden trenger virker».

Håndhev dataløypen i stedet for å anta den

En probe er en sjekk på ett tidspunkt og en brannmur er en egenskap som gjelder mellom tidspunkter. Hvis kravet er at applikasjonstrafikk aldri forlater tunnelen, må det uttrykkes i det delte nettverksnavnerommet som en aksepter-eller-slipp-regel. Containerstartrekkefølge kan ikke bære det kravet. Bare en regel kan.

Containere i én pod deler det navnerommet, så håndhevelsespunktet er selve navnerommet. Uansett hva du skriver, må det la tunnelens egen ytre forbindelse være tilgjengelig, fordi å blokkere den for å beskytte applikasjonen kutter løypen applikasjonen trenger.

Bestem feilpolicyen eksplisitt: skal applikasjonstrafikk stoppe helt når tunnelen er usunn, eller fortsette og merkes som ubeskyttet? Begge er forsvarlige, og ingen av dem er det du får ved å starte containere i en bestemt rekkefølge.

Test trafikken du ikke nevnte

Ta en ny forespørsel under en kontrollert tunnelfeil og se om den slipper ut. Gjenta deretter sjekken for løypene en exit-adresse-test aldri berører: DNS-oppslag inne i klyngen, IPv6-destinasjoner og tjenester som nås via klyngeinterne adresser i stedet for det offentlige internettet. Det er løypene som stille fortsetter å virke etter at tunnelen dør.

En exit-adresse-side beviser at én forespørsel gikk dit du forventet i det øyeblikket. Den kan ikke kartlegge de andre løypene, og gapet mellom det du testet og det poden kan nå er der de interessante feilene bor.

Gjenta testen etter en sidecar-omstart i stedet for bare etter en ren start. En omstartet tunnelcontainer kan etterlate navnerommet med ruter og policy i en mellomtilstand.

Skriv utrulingsnotatet

Tre fakta hører hjemme i utrulingsnotatene: beredskapstesten og hva den observerer, gjenopprettingshandlingen når den testen feiler, og håndhevelsesregelen som styrer utgående trafikk. Dokumentasjonen for sidecar-containere dekker livssyklusmekanikken og overlater den policybeslutningen til deg. Den oppdelingen er riktig, og det er også grunnen til at policyen vanligvis mangler.

En helsesjekk forvekslet med beskyttelse er den dyreste typen grønn indikator, fordi den stopper folk fra å stille spørsmål. Å navngi den nøyaktig i dokumentasjonen koster én setning og forhindrer det.

Til slutt, test gjenopprettingsløypen én gang med applikasjonen kjørende. Et design som krever at poden gjenskapes for å gjenopprette utgående trafikk, er en beslutning, og det bør være en du tok, ikke en du oppdaget.