En VPN-sidecar behöver en startregel och en felregel

En pod startar tunnelbehållaren före applikationen och de första förfrågningarna lyckas, vilket är precis det fall som döljer problemet. Ordningen löser ett kapplöpning och säger ingenting om trafiken som applikationen startar fyra timmar senare, efter att tunneln har fallerat. Det är två separata beslut. Vanligtvis designas bara ett av dem.

Ordningen grindar bara den första förfrågan

Kubernetes stöder en sidecar-livscykel byggd av omstartbara init-behållare. I den modellen kan en startprobe hålla tillbaka nästa initieringssteg tills tunneln rapporterar beredskap. Det är en verklig förbättring, och den är värd att använda medvetet i stället för att lägga till en sleep i ett entrypoint-skript. Grinden är bara så bra som villkoret den testar.

Utanför den modellen tillhör ordningssemantiken den körmiljö eller det beroendesystem du använder, och de behöver inte stämma överens. En distribution kopierad från en annan plattform kan se ut att vänta på tunneln eftersom applikationen råkar starta långsamt. Det är inte samma garanti, och den fallerar under last.

Säg vad grinden observerar: en process finns, ett gränssnitt finns, en handskakning är slutförd. Var och en av dem är ett svagare påstående än ”datavägen till de destinationer denna pod behöver fungerar”.

Tvinga fram datavägen i stället för att anta den

En probe är en kontroll vid ett tillfälle och en brandvägg är en egenskap som gäller mellan tillfällen. Om kravet är att applikationstrafik aldrig lämnar tunneln, måste det uttryckas i det delade nätverksnamnrymden som en acceptera-eller-släpp-regel. Behållarstartordning kan inte bära det kravet. Bara en regel kan.

Behållare i en pod delar det namnrymden, så tvingandepunkten är själva namnrymden. Vad du än skriver måste det lämna tunnelns egen yttre anslutning tillgänglig, eftersom att blockera den för att skydda applikationen skär av den väg applikationen behöver.

Bestäm felpolicyn uttryckligen: ska applikationstrafik stanna helt när tunneln är ohälsosam, eller fortsätta och markeras som oskyddad? Båda är försvarbara, och ingen av dem är det du får genom att starta behållare i en viss ordning.

Testa trafiken du inte nämnde

Ta en ny förfrågan under ett kontrollerat tunnelfel och se om den tar sig ut. Upprepa sedan kontrollen för de vägar ett exit-adresstest aldrig rör: DNS-uppslagning inne i klustret, IPv6-destinationer och tjänster som nås via klusterinterna adresser i stället för det publika internet. Det är de vägar som tyst fortsätter att fungera efter att tunneln dör.

En exit-adressida bevisar att en förfrågan gick dit du förväntade dig i det ögonblicket. Den kan inte inventera de andra vägarna, och gapet mellan det du testade och det poden kan nå är där de intressanta felen bor.

Upprepa testet efter en sidecar-omstart i stället för bara efter en ren start. En omstartad tunnelbehållare kan lämna namnrymden med rutter och policy i ett mellanläge.

Skriv distributionsposten

Tre fakta hör hemma i distributionsanteckningarna: beredskapstestet och vad det observerar, återställningsåtgärden när det testet fallerar, och den tvingande regeln som styr utgående trafik. Dokumentationen för sidecar-behållare täcker livscykelmekaniken och lämnar det policybeslutet till dig. Den uppdelningen är korrekt, och det är också därför policyn vanligtvis saknas.

En hälsokontroll som misstas för skydd är den dyraste typen av grön indikator, eftersom den stoppar människor från att ställa frågor. Att namnge den korrekt i dokumentationen kostar en mening och förhindrar det.

Testa slutligen återställningsvägen en gång med applikationen igång. En design som kräver att poden återskapas för att återställa utgående trafik är ett beslut, och det bör vara ett du fattade, inte ett du upptäckte.