Stranski vsebnik VPN potrebuje pravilo zagona in pravilo okvare

Pod zažene vsebnik tunela pred aplikacijo in prve zahteve uspejo, kar je natanko tisti primer, ki skrije težavo. Vrstni red odpravi eno tekmo in ne pove ničesar o prometu, ki ga aplikacija začne štiri ure pozneje, potem ko je tunel odpovedal. To sta dve ločeni odločitvi. Običajno se načrtuje le ena od njiju.

Vrstni red zadrži le prvo zahtevo

Kubernetes podpira življenjski cikel stranskega vsebnika, sestavljen iz zagonskih vsebnikov, ki jih je mogoče znova zagnati. V tem modelu lahko zagonska sonda zadrži naslednji korak inicializacije, dokler tunel ne sporoči pripravljenosti. To je resnična izboljšava in vredno jo je uporabljati namerno, namesto da v zagonsko skripto dodate sleep. Vrata so le toliko dobra, kolikor dober je pogoj, ki ga preverjajo.

Zunaj tega modela semantika vrstnega reda pripada tistemu izvajalnemu okolju ali sistemu odvisnosti, ki ga uporabljate, in se mu ni treba ujemati. Namestitev, kopirana z druge platforme, je lahko videti, kot da čaka na tunel, ker se aplikacija po naključju zažene počasi. To ni isto jamstvo in pod obremenitvijo odpove.

Povejte, kaj vrata opazujejo: proces obstaja, vmesnik obstaja, rokovanje je končano. Vsaka od teh trditev je šibkejša od »podatkovna pot do ciljev, ki jih ta pod potrebuje, deluje«.

Uveljavite podatkovno pot, namesto da bi jo predpostavljali

Sonda je preverjanje v enem trenutku, požarni zid pa lastnost, ki velja med trenutki. Če je zahteva, da promet aplikacije nikoli ne zapusti tunela, jo je treba izraziti v skupnem omrežnem imenskem prostoru kot pravilo sprejmi-ali-zavrzi. Vrstni red zagona vsebnikov te zahteve ne more nositi. Samo pravilo jo lahko.

Vsebniki v enem podu si delijo ta imenski prostor, zato je točka uveljavljanja sam imenski prostor. Karkoli napišete, mora pustiti razpoložljivo lastno zunanjo povezavo tunela, ker njena blokada za zaščito aplikacije prereže pot, ki jo aplikacija potrebuje.

Politiko okvare odločite izrecno: ali naj se promet aplikacije popolnoma ustavi, ko tunel ni zdrav, ali naj se nadaljuje in označi kot nezaščiten? Oboje je zagovorljivo in nobeno ni tisto, kar dobite z zagonom vsebnikov v določenem vrstnem redu.

Preizkusite promet, ki ga niste omenili

Vzemite novo zahtevo med nadzorovano okvaro tunela in poglejte, ali gre ven. Nato ponovite preverjanje za poti, ki se jih preizkus izhodnega naslova nikoli ne dotakne: razreševanje DNS znotraj gruče, cilji IPv6 in storitve, dosežene prek notranjih naslovov gruče namesto javnega interneta. To so poti, ki po smrti tunela tiho delujejo naprej.

Stran z izhodnim naslovom dokazuje, da je ena zahteva v tistem trenutku šla tja, kamor ste pričakovali. Ne more popisati drugih poti, in vrzel med tem, kar ste preizkusili, in tem, do česar pod lahko doseže, je kraj, kjer živijo zanimive okvare.

Ponovite preizkus po ponovnem zagonu stranskega vsebnika, ne le po čistem zagonu. Znova zagnan vsebnik tunela lahko pusti imenski prostor s potmi in politiko v vmesnem stanju.

Zapišite zapis o namestitvi

Tri dejstva sodijo v zapiske o namestitvi: preizkus pripravljenosti in kaj opazuje, dejanje obnovitve, ko ta preizkus odpove, in pravilo uveljavljanja, ki ureja izhodni promet. Dokumentacija o stranskih vsebnikih pokriva mehaniko življenjskega cikla in to politično odločitev prepušča vam. Ta delitev je pravilna in prav zato politika običajno manjka.

Zdravstveno preverjanje, zamenjano z zaščito, je najdražja vrsta zelenega kazalnika, ker ljudem prepreči postavljanje vprašanj. Natančno poimenovanje v dokumentaciji stane en stavek in to prepreči.

Nazadnje enkrat preizkusite pot obnovitve med delovanjem aplikacije. Zasnova, ki zahteva ponovno ustvarjanje poda za obnovitev izhodnega prometa, je odločitev in morala bi biti tista, ki ste jo sprejeli vi, ne tista, ki ste jo odkrili.