Ein VPN-sidecar treng ein startregel og ein feilregel

Ein pod startar tunnelbehaldaren før applikasjonen, og dei første førespurnadene lukkast, som er nettopp tilfellet som skjuler problemet. Rekkjefølgja løyser eitt kappløp og seier ingenting om trafikken applikasjonen startar fire timar seinare, etter at tunnelen har feila. Det er to separate avgjerder. Vanlegvis vert berre éi av dei designa.

Rekkjefølgja gatar berre den første førespurnaden

Kubernetes støttar ein sidecar-livssyklus bygd av omstartbare init-behaldarar. I den modellen kan ein oppstartsprobe halde attende det neste initialiseringstrinnet til tunnelen rapporterer beredskap. Det er ei ekte betring, og ho er verd å bruke medvite i staden for å leggje til ein sleep i eit entrypoint-skript. Gata er berre så god som vilkåret ho testar.

Utanfor den modellen høyrer rekkjefølgjesemantikken til den køyretida eller det avhengigheitssystemet du brukar, og dei treng ikkje stemme overeins. Ei utrulling kopiert frå ein annan plattform kan sjå ut som ho ventar på tunnelen fordi applikasjonen tilfeldigvis startar sakte. Det er ikkje den same garantien, og han feilar under last.

Sei kva gata observerer: ein prosess finst, eit grensesnitt finst, ein handshake er fullført. Kvar av dei er ein svakare påstand enn «dataløypa til destinasjonane denne poden treng verkar».

Handhev dataløypa i staden for å ta henne for gitt

Ein probe er ein sjekk på eitt tidspunkt og ein brannmur er ein eigenskap som gjeld mellom tidspunkt. Viss kravet er at applikasjonstrafikk aldri forlèt tunnelen, må det uttrykkjast i det delte nettverksnamnerommet som ein aksepter-eller-slepp-regel. Behaldarstartrekkjefølgja kan ikkje bera det kravet. Berre ein regel kan.

Behaldarar i éin pod deler det namnerommet, så handhevingspunktet er sjølve namnerommet. Kva du enn skriv, må det la den eigne ytre sambindinga til tunnelen vere tilgjengeleg, fordi å blokkere henne for å verne applikasjonen skjer løypa applikasjonen treng.

Bestem feilpolicyen eksplisitt: skal applikasjonstrafikk stoppe heilt når tunnelen er usunn, eller halde fram og merkast som uverna? Begge er forsvarlege, og ingen av dei er det du får ved å starte behaldarar i ei bestemd rekkjefølgje.

Test trafikken du ikkje nemnde

Ta ein ny førespurnad under ein kontrollert tunnelfeil og sjå om han slepp ut. Gjenta deretter sjekken for løypene ein exit-adresse-test aldri rører: DNS-oppslag inne i klynga, IPv6-destinasjonar og tenester som ein når via klyngeinterne adresser i staden for det offentlege internettet. Det er løypene som stille held fram med å verke etter at tunnelen døyr.

Ei exit-adresse-side beviser at éin førespurnad gjekk dit du venta i det augneblinken. Ho kan ikkje kartleggje dei andre løypene, og gapet mellom det du testa og det poden kan nå er der dei interessante feila bur.

Gjenta testen etter ein sidecar-omstart i staden for berre etter ein rein start. Ein omstarta tunnelbehaldar kan late namnerommet att med ruter og policy i ein mellomtilstand.

Skriv utrullingsnotatet

Tre fakta høyrer heime i utrullingsnotata: beredskapstesten og kva han observerer, gjenopprettingshandlinga når den testen feilar, og handhevingsregelen som styrer utgåande trafikk. Dokumentasjonen for sidecar-behaldarar dekkjer livssyklusmekanikken og overlèt den policyavgjerda til deg. Den oppdelinga er rett, og det er også grunnen til at policyen vanlegvis manglar.

Ein helsesjekk forveksla med vern er den dyraste typen grøn indikator, fordi han stoppar folk frå å stille spørsmål. Å namngje han nøyaktig i dokumentasjonen kostar éi setning og hindrar det.

Til slutt, test gjenopprettingsløypa éin gong med applikasjonen køyrande. Eit design som krev at poden vert gjenoppretta for å gjenopprette utgåande trafikk, er ei avgjerd, og det bør vere ei du tok, ikkje ei du oppdaga.