VPN sidecar potřebuje pravidlo spuštění a pravidlo selhání

Pod spustí kontejner tunelu dřív než aplikaci a první požadavky uspějí, což je právě ten případ, který problém skrývá. Pořadí opravuje jeden závod a neříká nic o provozu, který aplikace spustí o čtyři hodiny později, poté co tunel selhal. To jsou dvě samostatná rozhodnutí. Obvykle se navrhuje jen jedno z nich.

Pořadí omezuje jen první požadavek

Kubernetes podporuje životní cyklus sidecaru postavený z restartovatelných init kontejnerů. V tomto modelu může startovací sonda zdržet další inicializační krok, dokud tunel neohlásí připravenost. To je skutečné zlepšení a vyplatí se ho používat záměrně, místo abyste do skriptu vstupního bodu přidávali sleep. Brána je jen tak dobrá, jak dobrá je podmínka, kterou testuje.

Mimo tento model patří sémantika pořadí tomu runtime nebo systému závislostí, který používáte, a nemusí se shodovat. Nasazení zkopírované z jiné platformy může vypadat, že čeká na tunel, protože aplikace náhodou startuje pomalu. To není stejná záruka a pod zátěží selhává.

Řekněte, co brána pozoruje: proces existuje, rozhraní existuje, handshake se dokončil. Každé z toho je slabší tvrzení než „datová cesta k cílovým místům, která tento pod potřebuje, funguje“.

Vynucujte datovou cestu, místo abyste ji předpokládali

Sonda je kontrola v jednom okamžiku a firewall je vlastnost, která platí mezi okamžiky. Pokud je požadavek, aby provoz aplikace nikdy nevycházel mimo tunel, musí být vyjádřen ve sdíleném síťovém jmenném prostoru jako pravidlo přijmout nebo zahodit. Pořadí spouštění kontejnerů tento požadavek unést nemůže. Jen pravidlo může.

Kontejnery v jednom podu tento jmenný prostor sdílejí, takže místem vynucení je sám jmenný prostor. Ať napíšete cokoli, musí to ponechat dostupné vlastní vnější spojení tunelu, protože jeho zablokování na ochranu aplikace přerušuje cestu, kterou aplikace potřebuje.

Rozhodněte politiku selhání explicitně: má se provoz aplikace při nezdravém tunelu úplně zastavit, nebo má pokračovat a být označen jako nechráněný? Obojí je obhajitelné a ani jedno není to, co získáte spuštěním kontejnerů v určitém pořadí.

Otestujte provoz, který jste nezmínili

Pošlete nový požadavek během řízeného selhání tunelu a podívejte se, zda vychází. Potom kontrolu zopakujte pro cesty, kterých se test výstupní adresy nikdy nedotkne: překlad DNS uvnitř clusteru, cíle IPv6 a služby dosahované přes adresy uvnitř clusteru, nikoli přes veřejný internet. To jsou cesty, které po smrti tunelu tiše fungují dál.

Stránka s výstupní adresou dokazuje, že jeden požadavek v tu chvíli šel tam, kam jste čekali. Nedokáže zinventarizovat ostatní cesty a mezera mezi tím, co jste otestovali, a tím, čeho pod může dosáhnout, je místo, kde žijí zajímavá selhání.

Zopakujte test po restartu sidecaru, ne jen po čistém startu. Restartovaný kontejner tunelu může zanechat jmenný prostor s trasami a politikou v přechodném stavu.

Zapište záznam o nasazení

Do poznámek k nasazení patří tři skutečnosti: test připravenosti a co pozoruje, akce obnovy, když tento test selže, a pravidlo vynucení, které řídí odchozí provoz. Dokumentace sidecar kontejnerů pokrývá mechaniku životního cyklu a toto politické rozhodnutí nechává na vás. Toto rozdělení je správné a právě proto politika obvykle chybí.

Kontrola stavu zaměněná za ochranu je nejdražší druh zeleného indikátoru, protože lidi přestane zajímat, proč se ptát. Pojmenovat ji v dokumentaci přesně stojí jednu větu a tomu zabrání.

Nakonec jednou otestujte cestu obnovy za běhu aplikace. Návrh, který vyžaduje znovuvytvoření podu k obnovení odchozího provozu, je rozhodnutí a mělo by být tím, které jste učinili, ne tím, které jste objevili.