VPN-sivukontti tarvitsee käynnistyssäännön ja vikasäännön

Pod käynnistää tunnelin kontin ennen sovellusta ja ensimmäiset pyynnöt onnistuvat, ja juuri tämä tapaus piilottaa ongelman. Järjestys korjaa yhden kilpailun eikä kerro mitään liikenteestä, jonka sovellus aloittaa neljä tuntia myöhemmin, sen jälkeen kun tunneli on vioittunut. Nämä ovat kaksi erillistä päätöstä. Yleensä vain toinen niistä suunnitellaan.

Järjestys portittaa vain ensimmäisen pyynnön

Kubernetes tukee sidecar-elinkaarta, joka rakennetaan uudelleenkäynnistettävistä init-kontteista. Siinä mallissa käynnistysprobe voi pidätellä seuraavaa alustusvaihetta, kunnes tunneli ilmoittaa valmiudesta. Se on todellinen parannus, ja sitä kannattaa käyttää tietoisesti sen sijaan, että sisääntulopisteen skriptiin lisätään sleep. Portti on vain niin hyvä kuin ehto, jota se testaa.

Tämän mallin ulkopuolella järjestyksen semantiikka kuuluu käyttämällesi ajonaikaiselle ympäristölle tai riippuvuusjärjestelmälle, eikä niiden tarvitse vastata toisiaan. Toiselta alustalta kopioitu käyttöönotto voi näyttää odottavan tunnelia, koska sovellus sattuu käynnistymään hitaasti. Se ei ole sama tae, ja se pettää kuormituksessa.

Kerro, mitä portti havaitsee: prosessi on olemassa, rajapinta on olemassa, handshake on valmistunut. Jokainen näistä on heikompi väite kuin ”tietopolku tämän podin tarvitsemiin kohteisiin toimii”.

Pakota tietopolku sen sijaan että oletat sen

Probe on tarkistus yhdellä hetkellä ja palomuuri ominaisuus, joka pätee hetkien välillä. Jos vaatimus on, ettei sovellusliikenne koskaan poistu tunnelin ulkopuolelle, se on ilmaistava jaetussa verkkonimiavaruudessa hyväksy-tai-hylkää-sääntönä. Konttien käynnistysjärjestys ei voi kantaa tätä vaatimusta. Vain sääntö voi.

Yhden podin kontit jakavat tämän nimiavaruuden, joten toteutuskohta on nimiavaruus itse. Mitä ikinä kirjoitat, sen on jätettävä tunnelin oma ulkoyhteys käytettäväksi, koska sen blokkaaminen sovelluksen suojaamiseksi katkaisee polun, jota sovellus tarvitsee.

Päätä vikakäytäntö nimenomaisesti: pitääkö sovellusliikenteen pysähtyä kokonaan, kun tunneli ei ole terve, vai jatkua ja merkitä suojaamattomaksi? Molemmat ovat perusteltavissa, eikä kumpikaan ole se, minkä saat käynnistämällä kontit tietyssä järjestyksessä.

Testaa liikenne, jota et maininnut

Tee uusi pyyntö hallitun tunnelivian aikana ja katso, meneekö se ulos. Toista sitten tarkistus poluille, joihin lähtöosoitetesti ei koskaan osu: DNS-selvitys klusterin sisällä, IPv6-kohteet ja palvelut, joihin päästään klusterin sisäisten osoitteiden kautta julkisen internetin sijaan. Ne ovat polut, jotka jatkavat hiljaa toimintaansa tunnelin kuoltua.

Lähtöosoitesivu todistaa, että yksi pyyntö meni sinne, minne odotit sillä hetkellä. Se ei pysty luetteloimaan muita polkuja, ja kuilu testaamasi ja sen välillä, mitä pod voi tavoittaa, on paikka, jossa kiinnostavat viat elävät.

Toista testi sidecarin uudelleenkäynnistyksen jälkeen eikä vain puhtaan käynnistyksen jälkeen. Uudelleenkäynnistetty tunnelikontti voi jättää nimiavaruuden reitit ja käytännön välitilaan.

Kirjoita käyttöönoton merkintä

Käyttöönoton muistiinpanoihin kuuluu kolme tosiasiaa: valmiustesti ja mitä se havaitsee, palautustoimenpide kun testi epäonnistuu, ja toteutussääntö, joka ohjaa lähtevää liikennettä. Sidecar-konttien dokumentaatio kattaa elinkaarimekaniikan ja jättää tämän käytäntöpäätöksen sinulle. Tämä jako on oikea, ja juuri siksi käytäntö yleensä puuttuu.

Suojaukseksi luultu terveystarkistus on kallein vihreä indikaattori, koska se estää ihmisiä kysymästä. Sen täsmällinen nimeäminen dokumentaatiossa maksaa yhden lauseen ja estää sen.

Lopuksi testaa palautumispolku kerran sovelluksen ollessa käynnissä. Suunnittelu, joka vaatii podin uudelleenluomista lähtevän liikenteen palauttamiseksi, on päätös, ja sen pitäisi olla sinun tekemäsi eikä sinun löytämäsi.