Un sidecar VPN are nevoie de o regulă de pornire și de o regulă de eșec
Pornirea tunelului înaintea aplicației rezolvă o cursă. Decideți separat ce poate trimite aplicația înainte de disponibilitate, în timpul unei defecțiuni a tunelului și după o repornire.
Un pod pornește containerul tunelului înaintea aplicației și primele cereri reușesc, iar acesta este exact cazul care ascunde problema. Ordinea rezolvă o cursă și nu spune nimic despre traficul pe care aplicația îl începe patru ore mai târziu, după ce tunelul a eșuat. Sunt două decizii separate. De obicei este proiectată doar una dintre ele.
Ordinea blochează doar prima cerere
Kubernetes acceptă un ciclu de viață de sidecar construit din containere init repornibile. În acel model, o sondă de pornire poate reține pasul de inițializare următor până când tunelul raportează disponibilitatea. Este o îmbunătățire reală și merită folosită deliberat, în loc să adăugăm un sleep la un script de punct de intrare. Poarta este doar atât de bună cât este condiția pe care o testează.
În afara acelui model, semantica ordinii aparține mediului de rulare sau sistemului de dependențe pe care îl folosiți și nu trebuie să coincidă. O implementare copiată de pe altă platformă poate părea că așteaptă tunelul pentru că aplicația pornește încet din întâmplare. Nu este aceeași garanție și eșuează sub sarcină.
Spuneți ce observă poarta: există un proces, există o interfață, un handshake s-a încheiat. Fiecare dintre acestea este o afirmație mai slabă decât „calea de date către destinațiile de care are nevoie acest pod funcționează”.
Impuneți calea de date în loc să o presupuneți
O sondă este o verificare într-un moment, iar un firewall este o proprietate valabilă între momente. Dacă cerința este ca traficul aplicației să nu iasă niciodată în afara tunelului, ea trebuie exprimată în spațiul de nume de rețea partajat ca regulă de acceptare sau de eliminare. Ordinea de pornire a containerelor nu poate purta această cerință. Doar o regulă poate.
Containerele dintr-un pod partajează acel spațiu de nume, deci punctul de impunere este spațiul de nume însuși. Orice ați scrie, trebuie să lase disponibilă conexiunea exterioară proprie a tunelului, pentru că blocarea ei pentru a proteja aplicația taie calea de care aplicația are nevoie.
Decideți explicit politica de eșec: traficul aplicației trebuie să se oprească complet când tunelul nu este sănătos, sau să continue și să fie marcat ca neprotejat? Ambele sunt justificabile și niciuna nu este ceea ce obțineți pornind containerele într-o anumită ordine.
Testați traficul pe care nu l-ați menționat
Faceți o cerere nouă în timpul unei defecțiuni controlate a tunelului și vedeți dacă iese. Apoi repetați verificarea pentru căile pe care un test de adresă de ieșire nu le atinge niciodată: rezolvarea DNS în interiorul clusterului, destinații IPv6 și servicii accesate prin adrese interne ale clusterului în locul internetului public. Acestea sunt căile care continuă să funcționeze în tăcere după ce tunelul moare.
O pagină de adresă de ieșire demonstrează că o cerere a mers unde vă așteptați în acel moment. Nu poate inventaria celelalte căi, iar diferența dintre ce ați testat și ce poate atinge podul este locul unde trăiesc eșecurile interesante.
Repetați testul după o repornire a sidecarului, nu doar după o pornire curată. Un container de tunel repornit poate lăsa spațiul de nume cu rute și politică într-o stare intermediară.
Scrieți înregistrarea de implementare
Trei fapte aparțin notițelor de implementare: testul de disponibilitate și ce observă, acțiunea de recuperare când acel test eșuează și regula de impunere care guvernează ieșirea. Documentația containerelor sidecar acoperă mecanica ciclului de viață și lasă acea decizie de politică în seama dumneavoastră. Acea împărțire este corectă și tot de aceea politica lipsește de obicei.
O verificare de sănătate confundată cu o protecție este cel mai scump tip de indicator verde, pentru că îi oprește pe oameni să pună întrebări. Numirea ei precisă în documentație costă o propoziție și previne asta.
În final, testați calea de recuperare o dată cu aplicația în funcțiune. Un design care cere recrearea podului pentru a restabili ieșirea este o decizie și ar trebui să fie una pe care ați luat-o, nu una pe care ați descoperit-o.