A VPN-mellékkonténernek kell egy indítási és egy hiba-szabály

A pod az alkalmazás előtt indítja az alagút konténerét, és az első kérések sikerülnek, ez pedig éppen az az eset, amely elrejti a problémát. A sorrend egy versenyhelyzetet javít, és semmit sem mond arról a forgalomról, amelyet az alkalmazás négy órával később indít, miután az alagút meghibásodott. Ez két külön döntés. Általában csak az egyiket tervezik meg.

A sorrend csak az első kérést zárja el

A Kubernetes támogatja az újraindítható init konténerekből épülő mellékkonténer-életciklust. Ebben a modellben egy indítási próba visszatarthatja a következő inicializálási lépést, amíg az alagút nem jelenti a készenlétet. Ez valódi javulás, és érdemes tudatosan használni ahelyett, hogy sleepet tennénk a belépési pont szkriptjébe. A kapu csak annyira jó, amilyen a feltétel, amelyet vizsgál.

Ezen a modellen kívül a sorrend szemantikája ahhoz a futtatókörnyezethez vagy függőségi rendszerhez tartozik, amelyet használ, és ezeknek nem kell egyezniük. Egy másik platformról másolt telepítés úgy tűnhet, mintha az alagútra várna, mert az alkalmazás véletlenül lassan indul. Ez nem ugyanaz a garancia, és terhelés alatt megbukik.

Mondja meg, mit figyel meg a kapu: létezik egy folyamat, létezik egy interfész, befejeződött egy handshake. Ezek mindegyike gyengébb állítás annál, hogy „az adatút a pod által igényelt célokhoz működik”.

Kényszerítse ki az adatutat, ne feltételezze

A próba egy pillanat ellenőrzése, a tűzfal pedig pillanatok között érvényes tulajdonság. Ha a követelmény az, hogy az alkalmazás forgalma soha ne hagyja el az alagutat, akkor ezt a megosztott hálózati névtérben elfogad-vagy-elvet szabályként kell kifejezni. A konténerek indítási sorrendje nem tudja ezt a követelményt hordozni. Csak egy szabály tudja.

Az egy podban lévő konténerek megosztják ezt a névteret, így a kikényszerítés pontja maga a névtér. Amit csak ír, annak elérhetővé kell hagynia magának az alagútnak a külső kapcsolatát, mert annak blokkolása az alkalmazás védelmében elvágja az alkalmazás számára szükséges utat.

Döntse el a hiba politikáját kifejezetten: teljesen leálljon-e az alkalmazás forgalma, amikor az alagút nem egészséges, vagy folytatódjon és legyen megjelölve nem védettként? Mindkettő védhető, és egyik sem az, amit a konténerek meghatározott sorrendben való indításával kap.

Tesztelje a forgalmat, amelyet nem említett

Küldjön új kérést egy ellenőrzött alagúthiba alatt, és nézze meg, kimegy-e. Ezután ismételje meg az ellenőrzést azokra az utakra, amelyeket egy kilépési cím teszt soha nem érint: DNS-feloldás a klaszteren belül, IPv6-célok, és a nyilvános internet helyett klaszteren belüli címeken elért szolgáltatások. Ezek azok az utak, amelyek az alagút halála után csendesen tovább működnek.

Egy kilépési cím oldal bizonyítja, hogy egy kérés abban a pillanatban oda ment, ahova várta. Nem tudja leltározni a többi utat, és a tesztelt és a pod által elérhető dolgok közötti rés az, ahol az érdekes hibák élnek.

Ismételje meg a tesztet mellékkonténer újraindítása után, ne csak tiszta indítás után. Az újraindított alagút konténer köztes állapotban hagyhatja a névteret útvonalakkal és politikával.

Írja meg a telepítési feljegyzést

Három tény tartozik a telepítési jegyzetekbe: a készenléti teszt és hogy mit figyel meg, a helyreállítási művelet, amikor ez a teszt meghibásodik, és a kimenő forgalmat szabályozó kikényszerítési szabály. A mellékkonténerek dokumentációja lefedi az életciklus mechanikáját, és ezt a politikai döntést Önre hagyja. Ez a felosztás helyes, és ezért is hiányzik általában a politika.

A védelemmel összetévesztett állapotellenőrzés a legdrágább fajta zöld jelző, mert megakadályozza, hogy az emberek kérdezzenek. Pontos elnevezése a dokumentációban egy mondatba kerül, és ezt megelőzi.

Végül tesztelje a helyreállítási utat egyszer, futó alkalmazás mellett. Az a terv, amely a pod újralétrehozását igényli a kimenő forgalom helyreállításához, döntés, és annak kell lennie, amelyet Ön hozott, nem annak, amelyet felfedezett.