Pod, nod sau cluster: ce redirecționează de fapt un sidecar VPN

Un sidecar VPN într-un Pod Kubernetes arată ca un VPN la nivel de gazdă cu maniere mai bune, iar asemănarea se oprește la granița spațiului de nume. Containerele dintr-un Pod partajează spațiul de nume de rețea, inclusiv spațiul de adrese și porturi, așa că un sidecar care instalează rute și politici schimbă într-adevăr unde ajung pachetele aplicației. Nu schimbă nimic pentru celelalte Poduri de pe nod și nu atinge stiva proprie a nodului decât dacă îl configurezi astfel. Înțelegerea corectă a acestei granițe decide atât ce poți implementa, cât și ce trebuie să testezi. Secțiunile de mai jos urmăresc asta dinspre spațiul de nume spre exterior.

Spațiu de nume comun, consecințe comune

Două containere dintr-un Pod comunică prin loopback și văd aceleași interfețe, și de aceea modelul sidecar funcționează: aplicația nu trebuie să știe că există un tunel, pentru că ruta pe care o rezolvă a fost instalată în spațiul de nume pe care îl folosește. Aceeași proprietate înseamnă că greșelile sidecarului sunt greșelile aplicației. O rută care captează prea mult, sau o schimbare DNS care indică un resolver din interiorul tunelului, se aplică imediat fiecărui proces din acel Pod. Într-un spațiu de nume comun nu există rutare pe container, așa că un sidecar nu poate fi limitat la un singur proces.

Acesta este mecanismul de reținut în timpul revizuirii: raza de impact este Podul, nu nodul și nu clusterul.

Unde sidecarul nu ajunge

Celelalte Poduri își păstrează spațiile de nume și rutarea proprie, așa că o încărcare de lucru care are nevoie de aceeași ieșire are nevoie de același sidecar sau, în schimb, de un proiect la nivel de nod. Nici traficul nodului nu este în spațiul de nume al Podului, iar Podurile cu rețea de gazdă renunță deliberat la această izolare în totalitate. Dacă rulezi sidecarul cu rețea de gazdă pentru a ajunge la ceva comod, ai extins domeniul de la un Pod la întregul nod și ar trebui să spui asta cu voce tare.

Traficul către serviciile clusterului este cealaltă surpriză obișnuită. O rută implicită largă în interiorul Podului poate prinde cereri destinate serverului API sau unui serviciu ClusterIP, care apoi eșuează în feluri care arată ca un tunel stricat.

Plan de rute: intervale Pod, serviciu, nod și VPN

Notează cele patru intervale și verifică suprapunerea înainte de a implementa ceva: CIDR-ul Podului, CIDR-ul serviciului, adresele nodului și destinațiile din spatele VPN-ului. Suprapunerea dintre intervalele private ale VPN-ului și spațiul propriu al clusterului nu este rară, iar o rută implicită este soluția greșită pentru asta. Planul de rute aparține aceluiași depozit ca manifestul, pentru că următorul cluster poate aloca intervale de Pod și serviciu complet diferite.

DNS-ul face parte din plan, nu este o grijă separată. Un sidecar care rescrie configurația resolverului poate rupe descoperirea serviciilor în cluster în timp ce interogările externe funcționează perfect.

Pornirea și eșecul sunt stări explicite

Un proces sidecar care rulează nu este o politică de ieșire. Decide ce trafic poate curge înainte ca tunelul să fie gata și ce se întâmplă dacă moare după aceea, apoi implementează acea decizie: o sondă care condiționează containerul aplicației, o politică de rețea care refuză implicit, sau ambele. Fără una dintre ele, aplicația pornește, rezolvă și trimite trafic pe calea normală a nodului în timp ce tunelul încă se conectează.

Acel gol este scurt într-un cluster sănătos și permanent într-unul stricat, și exact aceasta este proprietatea pe care o preferă un atacator sau o scurgere accidentală de date.

Asociază ordinea cu un test de eșec. Omoară sidecarul și confirmă că aplicația își pierde ieșirea dorită în loc să revină în tăcere.

Capabilități, politici și teste din containerul aplicației

Acordarea capabilităților necesare pentru a crea interfețe și a modifica rute este o decizie privind privilegiile, iar un privilegiu potrivit pentru un Pod izolat nu este automat potrivit pe stiva nodului. Folosește mecanismele de politică de rețea și de securitate acceptate de cluster și nu presupune că fiecare implementare de CNI sau de politică tratează o interfață VPN la fel; diferențele apar exact în cazurile de eșec care te interesează.

Testează din containerul real al aplicației, cu cereri noi către o destinație privată, un serviciu din cluster și internetul public. Un test din sidecar demonstrează că tunelul funcționează, nu că aplicația ajunge la ce are nevoie.

Documentează ipotezele de rețea ale clusterului lângă configurația VPN. Mutarea încărcării de lucru într-un alt cluster devine atunci un exercițiu de verificare a planului de rute, nu o schimbare de imagine care încetează în tăcere să funcționeze.