VPN prateći kontejner treba pravilo pokretanja i pravilo kvara

Pod pokreće kontejner tunela prije aplikacije i prvi zahtjevi uspijevaju, što je upravo slučaj koji skriva problem. Redoslijed rješava jednu utrku i ne govori ništa o prometu koji aplikacija započne četiri sata kasnije, nakon što tunel otkaže. To su dvije odvojene odluke. Obično se dizajnira samo jedna od njih.

Redoslijed samo blokira prvi zahtjev

Kubernetes podržava životni ciklus pratećeg kontejnera izgrađen od init kontejnera koji se mogu ponovno pokrenuti. U tom modelu startup proba može zadržati sljedeći korak inicijalizacije dok tunel ne prijavi spremnost. To je stvarno poboljšanje i vrijedi ga koristiti namjerno, umjesto dodavanja sleep u skriptu ulazne točke. Kapija je samo onoliko dobra koliko je uvjet koji provjerava.

Izvan tog modela, semantika redoslijeda pripada onom runtimeu ili sustavu ovisnosti koji koristite i ne mora se podudarati. Implementacija kopirana s druge platforme može izgledati kao da čeka tunel jer aplikacija slučajno sporo kreće. To nije isto jamstvo i pada pod opterećenjem.

Recite što kapija promatra: proces postoji, sučelje postoji, handshake je završen. Svaka od tih tvrdnji slabija je od „data put do odredišta koja su ovom podu potrebna radi“.

Nametnite data put umjesto da ga pretpostavljate

Proba je provjera u jednom trenutku, a firewall je svojstvo koje vrijedi između trenutaka. Ako je zahtjev da promet aplikacije nikada ne izađe izvan tunela, to se mora izraziti u zajedničkom mrežnom namespaceu kao pravilo prihvati-ili-odbaci. Redoslijed pokretanja kontejnera ne može nositi taj zahtjev. Samo pravilo može.

Kontejneri u jednom podu dijele taj namespace, pa je točka primjene sam namespace. Što god napišete, mora ostaviti dostupnom vlastitu vanjsku vezu tunela, jer blokiranje iste radi zaštite aplikacije presijeca put koji aplikaciji treba.

Odluku o politici kvara donesite izričito: treba li promet aplikacije potpuno stati kada tunel nije zdrav, ili nastaviti i biti označen kao nezaštićen? Oba su održiva i nijedno nije ono što dobivate pokretanjem kontejnera u određenom redoslijedu.

Testirajte promet koji niste spomenuli

Uzmite novi zahtjev tijekom kontroliranog kvara tunela i pogledajte izlazi li. Zatim ponovite provjeru za putanje koje test izlazne adrese nikada ne dotiče: DNS razrješavanje unutar klastera, IPv6 odredišta i servise do kojih se dolazi preko klaster-internih adresa, a ne javnog interneta. To su putanje koje tiho nastavljaju raditi nakon što tunel umre.

Stranica izlazne adrese dokazuje da je jedan zahtjev otišao tamo gdje ste očekivali u tom trenutku. Ona ne može popisati ostale putanje, a jaz između onoga što ste testirali i onoga do čega pod može doći mjesto je gdje žive zanimljivi kvarovi.

Ponovite test nakon ponovnog pokretanja pratećeg kontejnera, a ne samo nakon čistog starta. Ponovno pokrenut kontejner tunela može ostaviti namespace s rutama i politikom u srednjem stanju.

Zapišite zapis o implementaciji

Tri činjenice pripadaju u bilješke o implementaciji: test spremnosti i što promatra, radnja oporavka kada taj test padne i pravilo primjene koje upravlja izlaznim prometom. Dokumentacija o pratećim kontejnerima pokriva mehaniku životnog ciklusa i ostavlja tu odluku o politici vama. Ta podjela je ispravna i zato politika obično nedostaje.

Zdravstvena provjera zamijenjena sa zaštitom najskuplja je vrsta zelenog indikatora, jer zaustavlja ljude da postavljaju pitanja. Točno imenovanje u dokumentaciji košta jednu rečenicu i to sprječava.

Na kraju, testirajte put oporavka jednom dok aplikacija radi. Dizajn koji zahtijeva ponovno stvaranje poda da bi se vratio izlazni promet jest odluka i treba biti ona koju ste donijeli, a ne ona koju ste otkrili.