Sidecar VPN potrebuje pravidlo spustenia a pravidlo zlyhania

Pod spustí kontajner tunela pred aplikáciou a prvé požiadavky uspejú, čo je presne ten prípad, ktorý problém skrýva. Poradie opravuje jeden pretek a nehovorí nič o prevádzke, ktorú aplikácia začne o štyri hodiny neskôr, po zlyhaní tunela. Sú to dve samostatné rozhodnutia. Zvyčajne sa navrhuje len jedno z nich.

Poradie obmedzuje len prvú požiadavku

Kubernetes podporuje životný cyklus sidecaru postavený z reštartovateľných init kontajnerov. V tomto modeli môže štartovacia sonda zdržať ďalší inicializačný krok, kým tunel neohlási pripravenosť. Je to skutočné zlepšenie a oplatí sa ho používať zámerne namiesto pridávania sleep do skriptu vstupného bodu. Brána je len taká dobrá, aká je podmienka, ktorú testuje.

Mimo tohto modelu patrí sémantika poradia tomu runtime alebo systému závislostí, ktorý používate, a nemusia sa zhodovať. Nasadenie skopírované z inej platformy môže vyzerať, že čaká na tunel, pretože aplikácia náhodou štartuje pomaly. To nie je tá istá záruka a pod záťažou zlyháva.

Povedzte, čo brána pozoruje: proces existuje, rozhranie existuje, handshake sa dokončil. Každé z toho je slabšie tvrdenie ako „dátová cesta k cieľom, ktoré tento pod potrebuje, funguje“.

Vynucujte dátovú cestu, namiesto toho aby ste ju predpokladali

Sonda je kontrola v jednom okamihu a firewall je vlastnosť, ktorá platí medzi okamihmi. Ak je požiadavka, aby prevádzka aplikácie nikdy neopúšťala tunel, musí byť vyjadrená v zdieľanom sieťovom mennom priestore ako pravidlo prijať-alebo-zahodiť. Poradie spúšťania kontajnerov túto požiadavku uniesť nemôže. Len pravidlo môže.

Kontajnery v jednom pode zdieľajú ten menný priestor, takže miestom vynútenia je samotný menný priestor. Čokoľvek napíšete, musí ponechať dostupné vlastné vonkajšie spojenie tunela, pretože jeho zablokovanie na ochranu aplikácie prerezáva cestu, ktorú aplikácia potrebuje.

Rozhodnite politiku zlyhania explicitne: má sa prevádzka aplikácie pri nezdravom tuneli úplne zastaviť, alebo pokračovať a byť označená ako nechránená? Obe sú obhájiteľné a ani jedno nie je to, čo získate spustením kontajnerov v určitom poradí.

Otestujte prevádzku, ktorú ste nespomenuli

Pošlite novú požiadavku počas riadeného zlyhania tunela a pozrite, či vychádza. Potom zopakujte kontrolu pre cesty, ktorých sa test výstupnej adresy nikdy nedotkne: preklad DNS vnútri clusteru, ciele IPv6 a služby dosahované cez adresy vnútri clusteru, nie cez verejný internet. To sú cesty, ktoré po smrti tunela ticho fungujú ďalej.

Stránka s výstupnou adresou dokazuje, že jedna požiadavka v tom okamihu išla tam, kam ste čakali. Nedokáže zinventarizovať ostatné cesty a medzera medzi tým, čo ste otestovali, a tým, čo pod dokáže dosiahnuť, je miesto, kde žijú zaujímavé zlyhania.

Zopakujte test po reštarte sidecaru, nielen po čistom štarte. Reštartovaný kontajner tunela môže zanechať menný priestor s trasami a politikou v prechodnom stave.

Zapíšte záznam o nasadení

Do poznámok k nasadeniu patria tri skutočnosti: test pripravenosti a čo pozoruje, akcia obnovy, keď tento test zlyhá, a pravidlo vynútenia, ktoré riadi odchádzajúcu prevádzku. Dokumentácia sidecar kontajnerov pokrýva mechaniku životného cyklu a toto politické rozhodnutie necháva na vás. Toto rozdelenie je správne a práve preto politika zvyčajne chýba.

Kontrola stavu zamenená za ochranu je najdrahší druh zeleného indikátora, pretože ľuďom zabráni klásť otázky. Pomenovať ju v dokumentácii presne stojí jednu vetu a zabráni tomu.

Nakoniec raz otestujte cestu obnovy za behu aplikácie. Návrh, ktorý vyžaduje znovuvytvorenie podu na obnovenie odchádzajúcej prevádzky, je rozhodnutie a malo by byť tým, ktoré ste urobili vy, nie tým, ktoré ste objavili.