VPN-i kõrvakonteiner vajab käivitusreeglit ja tõrkereeglit

Pod käivitab tunneli konteineri enne rakendust ja esimesed päringud õnnestuvad, mis on täpselt see juhtum, mis probleemi varjab. Järjestus parandab ühe võidujooksu ega ütle midagi liikluse kohta, mille rakendus algatab neli tundi hiljem, pärast tunneli tõrget. Need on kaks eraldi otsust. Tavaliselt kavandatakse ainult üks neist.

Järjestus piirab ainult esimest päringut

Kubernetes toetab kõrvakonteineri elutsüklit, mis on üles ehitatud taaskäivitatavatest init-konteineritest. Selles mudelis võib käivitusprobe hoida tagasi järgmise initsialiseerimise sammu, kuni tunnel teatab valmidusest. See on tõeline paranemine ja seda tasub kasutada teadlikult, selle asemel et sisendpunkti skriptile sleep lisada. Värav on ainult nii hea kui tingimus, mida see testib.

Väljaspool seda mudelit kuulub järjestuse semantika teie kasutatavale käituskeskkonnale või sõltuvussüsteemile ja need ei pea kattuma. Teiselt platvormilt kopeeritud juurutus võib tunduda tunneli ootamisena, sest rakendus juhtub aeglaselt käivituma. See ei ole sama garantii ja see ebaõnnestub koormuse all.

Öelge, mida värav jälgib: protsess on olemas, liides on olemas, handshake on lõpetatud. Igaüks neist on nõrgem väide kui „andmetee sihtkohtadesse, mida see pod vajab, töötab“.

Jõustage andmetee, selle asemel et seda eeldada

Probe on kontroll ühel hetkel ja tulemüür on omadus, mis kehtib hetkede vahel. Kui nõue on, et rakenduse liiklus ei lahkuks kunagi tunnelist väljapoole, tuleb see jagatud võrgu nimeruumis väljendada vastuvõtmise või kõrvalejätmise reeglina. Konteinerite käivitamise järjekord ei saa seda nõuet kanda. Ainult reegel saab.

Ühe podi konteinerid jagavad seda nimeruumi, seega on jõustamispunkt nimeruum ise. Mida iganes kirjutate, see peab jätma tunneli enda välisühenduse kättesaadavaks, sest selle blokeerimine rakenduse kaitsmiseks lõikab läbi tee, mida rakendus vajab.

Otsustage tõrkepoliitika selgesõnaliselt: kas rakenduse liiklus peaks täielikult seiskuma, kui tunnel ei ole terve, või jätkuma ja märgitama kaitsmata? Mõlemad on põhjendatavad ja kumbki ei ole see, mille saate konteinereid kindlas järjekorras käivitades.

Testige liiklust, mida te ei maininud

Tehke kontrollitud tunneli tõrke ajal uus päring ja vaadake, kas see väljub. Seejärel korrake kontrolli radadel, mida väljumisaadressi test kunagi ei puuduta: DNS-i lahendamine klasteri sees, IPv6-sihtkohad ja teenused, mida saavutatakse klasteri siseste aadresside, mitte avaliku interneti kaudu. Need on rajad, mis pärast tunneli surma vaikselt edasi töötavad.

Väljumisaadressi leht tõestab, et üks päring läks sinna, kuhu te sel hetkel eeldasite. See ei suuda teisi radu inventeerida ja lünk testitu ja selle vahel, mida pod saab saavutada, on koht, kus huvitavad tõrked elavad.

Korrake testi pärast kõrvakonteineri taaskäivitust, mitte ainult pärast puhast käivitust. Taaskäivitatud tunnelikonteiner võib jätta nimeruumi marsruutide ja poliitikaga vahepealsesse olekusse.

Kirjutage juurutuskirje

Juurutusmärkmetesse kuulub kolm fakti: valmidustest ja see, mida see jälgib, taastamistoiming, kui see test ebaõnnestub, ja jõustamisreegel, mis reguleerib väljaminevat liiklust. Kõrvakonteinerite dokumentatsioon katab elutsükli mehaanikat ja jätab selle poliitikaotsuse teile. See jaotus on õige ja seepärast poliitika tavaliselt puudubki.

Kaitsega segi aetud tervisekontroll on kõige kallim roheline indikaator, sest see peatab inimesed küsimast. Selle täpne nimetamine dokumentatsioonis maksab ühe lause ja hoiab selle ära.

Lõpuks testige taastamisteed üks kord rakenduse töötamise ajal. Disain, mis nõuab väljamineva liikluse taastamiseks podi uuesti loomist, on otsus ja see peaks olema see, mille te tegite, mitte see, mille te avastasite.