VPN al Pod de Kubernetes o passarel·la de sortida: qui posseeix el túnel?
Un Pod és el seu propi espai de noms de xarxa, així que l’elecció real és quina capa posseeix el túnel: identitat per càrrega de treball o sortida guiada pel CNI amb una font compartida.
Desplegueu un Pod anomenat vpn-gateway, apunteu-hi un client de prova i veieu com els paquets desapareixen. No hi ha res de malament al manifest i el kubelet no té cap queixa. La raó és estructural i no de configuració: Kubernetes dona a cada Pod el seu propi espai de noms de xarxa, així que un nom, una etiqueta o un espai de noms d’API compartit no canvien res sobre on van els paquets. Per tant, decidir com surt el trànsit VPN del clúster comença amb una pregunta sobre la propietat, no sobre les imatges de contenidor.
Dos mecanismes cobreixen la majoria de desplegaments reals, i no són intercanviables. Un posa el túnel dins de l’espai de noms de xarxa de la mateixa càrrega de treball. L’altre demana al CNI que dirigeixi el trànsit seleccionat per un node de passarel·la designat. Falles de maneres diferents, escalen de maneres diferents i responen a equips diferents, i per això la pregunta del contenidor sol produir discussions que no s’acaben mai.
La frontera d’un Pod és un espai de noms, no un host de salt
Un espai de noms de xarxa de Linux posseeix les seves interfícies, adreces, rutes i regles de tallafoc, i cada Pod en rep un. Els contenidors dins d’aquell Pod s’hi uneixen, i és exactament per això que un contenidor auxiliar pot reescriure rutes que l’aplicació després segueix. Un Pod veí té una pila d’aspecte idèntic però completament separada. No hi ha cap taula compartida que un Pod de passarel·la pugui heretar, ni cap traspàs implícit de trànsit d’un espai de noms a un altre.
També és per això que el patró de Pod de passarel·la només funciona quan alguna cosa aigües amunt hi envia paquets de debò: un Service, una ruta estàtica al node o una política de direcció al CNI. Una adreça sola no atrau res.
Què compra un túnel per Pod i què costa
Un túnel que s’executa a l’espai de noms de la càrrega de treball dona a aquesta càrrega la seva pròpia identitat de client, que molts serveis d’accés remot exigeixen abans d’autoritzar o comptabilitzar una sessió. El radi d’impacte també es queda local: un túnel trencat elimina un Deployment en lloc del camí compartit que fa servir tot. Com s’executa depèn de la implementació, i és aquí on la gent s’equivoca.
Una configuració que només necessita estat del nucli pot acabar en un contenidor init i sortir. Un dimoni d’espai d’usuari que ha de romandre viu tota la vida del Pod necessita la forma de contenidor init reiniciable introduïda com a contenidor lateral natiu a Kubernetes 1.29, i aquesta distinció ve de la implementació del túnel i no del gust. El cost d’aquest model és la duplicació: cada rèplica s’autentica, rep la seva pròpia adreça de túnel i consumeix una plaça de sessió remota, així que un esdeveniment d’escalat automàtic es converteix en un esdeveniment de capacitat a l’altre costat de l’enllaç. Copiar una sola credencial a totes les rèpliques no elimina aquest cost, elimina el rastre d’auditoria. Les capacitats mereixen el mateix escrutini, perquè un túnel que vol NET_ADMIN al seu propi espai de noms no té cap motiu per heretar l’autoritat de tot l’amfitrió d’un exemple amb privileged: true.
Quan el CNI posseeix la sortida
Si el CNI ho admet, una passarel·la de sortida selecciona el trànsit per càrrega de treball i rang de destinació, i després l’envia per nodes triats sota una adreça d’origen predictible. La versió de Cilium és la referència habitual, i la seva documentació diu clarament que la funció necessita una configuració específica de Cilium més nodes de passarel·la proveïts amb les interfícies i adreces correctes. També assenyala un període inicial després de crear el Pod en què la direcció encara no s’aplica, cosa que és una dada de disseny i no una nota al peu.
Llegiu aquest retard contra la vostra pròpia promesa. Si la regla és que cap trànsit no pot sortir per un altre camí, un Pod nou que transmet durant el buit ja l’ha trencada, així que la seqüència d’arrencada necessita la seva pròpia resposta: retenir l’aplicació fins que s’apliqui la política, o acceptar la finestra i documentar-la.
Manteniu l’afirmació estreta. Una passarel·la de sortida tria i tradueix un camí. No acaba una VPN, i no converteix el clúster en client de la vostra xarxa remota sense una connexió suportada al darrere.
| 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 |
La traducció canvia en silenci el que veu el costat remot
Quan la passarel·la reescriu l’origen, les adreces per Pod desapareixen, així que una llista blanca basada en la identitat es converteix en una llista basada en una sola adreça compartida. És un intercanvi i no un defecte: menys regles a mantenir, atribució més grossa quan alguna cosa es comporta malament.
L’autenticació a nivell d’aplicació i el registre de peticions han de portar allò que la xarxa ja no informa. Tracteu la capacitat i la substitució de la passarel·la com a infraestructura compartida, perquè reiniciar un sol node ara interromp cada càrrega de treball al darrere, i comproveu el camí de tornada aviat: l’extrem remot ha de saber com arribar a l’adreça traduïda, normalment mitjançant una ruta o NAT que una persona, no un manifest, ha de posseir. La planificació d’adreces també hi pertany, perquè rangs de clúster i remots solapats trenquen qualsevol dels dos models i adoptar IPv6 no excusa un pla en conflicte.
Decidiu per propietat i després proveu la fallada que heu promès
Trieu el túnel per Pod quan el servei remot autentica càrregues de treball individuals, quan només uns quants Deployment necessiten l’enllaç i quan una fallada ha de quedar local. Trieu la passarel·la quan un equip de xarxa ja posseeix el camí, quan moltes càrregues comparteixen una destinació i quan una adreça d’origen estable és tot l’objectiu de l’exercici.
De qualsevol manera, verifiqueu la propietat que heu venut i no l’estat estacionari. Creeu un Pod, deixeu que transmeti immediatament i observeu els primers segons si la promesa era que res no s’escapa del túnel. Escaleu a cinc rèpliques i compteu les sessions que informa l’extrem remot si la promesa era identitat per càrrega de treball. Aquestes dues comprovacions exposen els límits del mecanisme molt més de pressa que una revisió del manifest, i us diuen quin equip posseeix el proper incident.