VPN per Pod în Kubernetes versus gateway de ieșire: cui îi aparține tunelul?
Un Pod este propriul spațiu de nume de rețea, așa că alegerea reală este ce strat deține tunelul: identitate pentru fiecare sarcină de lucru sau ieșire ghidată de CNI cu o singură sursă partajată.
Implementezi un Pod numit vpn-gateway, îndrepți un client de test către adresa lui și vezi pachetele dispărând. Nimic din manifest nu este greșit, iar kubelet-ul nu are nicio obiecție. Motivul este structural, nu de configurare: Kubernetes oferă fiecărui Pod propriul spațiu de nume de rețea, așa că un nume, o etichetă sau un spațiu de nume API partajat nu schimbă nimic în privința locului unde ajung pachetele. De aceea, decizia privind modul în care traficul VPN părăsește clusterul începe cu o întrebare despre proprietate, nu despre imaginile de container.
Două mecanisme acoperă majoritatea implementărilor reale și nu sunt interschimbabile. Unul pune tunelul în spațiul de nume de rețea al sarcinii de lucru. Celălalt cere CNI-ului să direcționeze traficul selectat printr-un nod de gateway desemnat. Ele eșuează diferit, se scalează diferit și răspund unor echipe diferite, motiv pentru care întrebarea despre containere produce de obicei dispute care nu se încheie niciodată.
Limita unui Pod este un spațiu de nume, nu un host de salt
Un spațiu de nume de rețea Linux deține interfețele, adresele, rutele și regulile de firewall, iar fiecare Pod primește unul. Containerele din acel Pod i se alătură, și exact de aceea un container auxiliar poate rescrie rute pe care aplicația le urmează apoi. Un Pod vecin are un stack identic ca aspect, dar complet separat. Nu există un tabel partajat pe care un Pod de gateway să-l poată moșteni și nicio predare implicită de trafic dintr-un spațiu de nume în altul.
De aceea modelul Pod de gateway funcționează doar când ceva din amonte chiar trimite pachete către el: un Service, o rută statică pe nod sau o politică de direcționare în CNI. O adresă singură nu atrage nimic.
Ce cumpără un tunel per Pod și cât costă
Un tunel care rulează în spațiul de nume al sarcinii de lucru îi dă acelei sarcini propria identitate de client, pe care multe servicii de acces la distanță o cer înainte de a autoriza sau contabiliza o sesiune. Raza de impact rămâne și ea locală: un tunel stricat scoate din funcțiune un Deployment în locul căii partajate folosite de toate. Modul în care rulează depinde de implementare, iar aici oamenii ghicesc greșit.
O configurare care are nevoie doar de starea nucleului poate termina într-un container init și poate ieși. Un demon din spațiul utilizator care trebuie să rămână viu pe toată durata de viață a Podului are nevoie de forma de container init repornibil introdusă ca sidecar nativ în Kubernetes 1.29, iar această distincție vine din implementarea tunelului, nu din gust. Costul acestui model este duplicarea: fiecare replică se autentifică, primește propria adresă de tunel și consumă un loc de sesiune la distanță, așa că un eveniment de autoscalare devine un eveniment de capacitate la celălalt capăt al legăturii. Copierea unei singure acreditări în toate replicile nu elimină acel cost, ci elimină urma de audit. Permisiunile merită aceeași examinare, pentru că un tunel care vrea NET_ADMIN în propriul spațiu de nume nu are niciun motiv să moștenească autoritatea asupra întregului host dintr-un exemplu cu privileged: true.
Când CNI-ul deține ieșirea
Dacă CNI-ul o permite, un gateway de ieșire selectează traficul după sarcina de lucru și intervalul de destinație, apoi îl trimite prin nodurile alese sub o singură adresă de sursă previzibilă. Versiunea Cilium este referința obișnuită, iar documentația sa spune clar că funcția necesită o configurare Cilium specifică plus noduri de gateway prevăzute cu interfețele și adresele corecte. Ea menționează și o perioadă inițială după crearea Podului în care direcționarea nu este încă aplicată, ceea ce este o intrare de proiectare, nu o notă de subsol.
Citește acea întârziere față de propria promisiune. Dacă regula este că niciun trafic nu poate ieși pe altă cale, un Pod nou care transmite în timpul golului a încălcat-o deja, așa că secvența de pornire are nevoie de propriul răspuns: ține aplicația până când politica se aplică, sau acceptă fereastra și documenteaz-o.
Păstrează afirmația îngustă. Un gateway de ieșire alege și traduce o cale. Nu termină un VPN și nu transformă clusterul în clientul rețelei tale la distanță fără o conexiune suportată în spate.
| Question | Per-Pod tunnel | CNI egress gateway |
|---|---|---|
| Who holds the client identity | Each workload | The gateway, shared |
| What scaling changes | Enrollment and sessions per replica | Throughput and capacity per node |
| What the remote side sees | Distinct addresses | One translated source |
| Failure scope | One Deployment | Every workload behind the gateway |
Traducerea schimbă în tăcere ce vede partea îndepărtată
Odată ce gateway-ul rescrie sursa, adresele per Pod dispar, așa că o listă de permisiuni bazată pe identitate devine o listă bazată pe o singură adresă partajată. Este un schimb și nu un defect: mai puține reguli de întreținut, atribuire mai grosieră când ceva se comportă prost.
Autentificarea la nivel de aplicație și jurnalizarea cererilor trebuie să poarte ce rețeaua nu mai raportează. Tratează capacitatea și înlocuirea gateway-ului ca infrastructură partajată, pentru că repornirea unui singur nod întrerupe acum fiecare sarcină de lucru din spatele lui, și verifică devreme calea de întoarcere: capătul îndepărtat trebuie să știe cum să ajungă la adresa tradusă, de obicei printr-o rută sau NAT pe care o persoană, nu un manifest, trebuie să o dețină. Și planificarea adreselor aparține aici, pentru că intervalele suprapuse de cluster și la distanță strică ambele modele, iar adoptarea IPv6 nu scuză un plan contradictoriu.
Decide după proprietate, apoi testează eșecul pe care l-ai promis
Alege tunelul per Pod când serviciul la distanță autentifică sarcini de lucru individuale, când doar câteva Deployment au nevoie de legătură și când un eșec trebuie să rămână local. Alege gateway-ul când o echipă de rețea deține deja calea, când multe sarcini partajează o destinație și când o adresă de sursă stabilă este întregul scop al exercițiului.
În orice caz, verifică proprietatea pe care ai vândut-o, nu starea staționară. Creează un Pod, lasă-l să transmită imediat și urmărește primele secunde dacă promisiunea a fost că nimic nu scapă din tunel. Scalează la cinci replici și numără sesiunile pe care le raportează capătul îndepărtat dacă promisiunea a fost identitatea per sarcină. Aceste două verificări expun limitele mecanismului mult mai repede decât o revizuire a manifestului și îți spun cărei echipe îi aparține următorul incident.