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 saobraćaju 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 ponovo 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 uslov koji provjerava.

Izvan tog modela, semantika redoslijeda pripada onom runtimeu ili sistemu zavisnosti 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 ista garancija i pada pod opterećenjem.

Recite šta kapija posmatra: proces postoji, interfejs 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 važi između trenutaka. Ako je zahtjev da saobraćaj 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. Šta 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 saobraćaj 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 dobijate pokretanjem kontejnera u određenom redoslijedu.

Testirajte saobraćaj koji niste spomenuli

Uzmite novi zahtjev tokom kontroliranog kvara tunela i pogledajte da li izlazi. 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 šta posmatra, radnja oporavka kada taj test padne i pravilo primjene koje upravlja izlaznim saobraćajem. 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. Tač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 saobraćaj jest odluka i treba biti ona koju ste donijeli, a ne ona koju ste otkrili.