VPN por Pod en Kubernetes fronte á porta de saída: quen é o dono do túnel?

Despregas un Pod chamado vpn-gateway, apuntas un cliente de proba ao seu enderezo e ves como os paquetes desaparecen. Nada no manifesto está mal e o kubelet non ten queixa ningunha. A razón é estrutural e non de configuración: Kubernetes dá a cada Pod o seu propio espazo de nomes de rede, así que un nome, unha etiqueta ou un espazo de nomes de API compartido non cambian nada sobre onde van os paquetes. Por iso, decidir como sae o tráfico VPN do clúster comeza cunha pregunta sobre a propiedade, non sobre as imaxes de contedor.

Dous mecanismos cobren a maioría dos despregamentos reais, e non son intercambiables. Un pon o túnel dentro do propio espazo de nomes de rede da carga de traballo. O outro pide ao CNI que dirixa o tráfico seleccionado a través dun nodo de porta designado. Fallan de xeito distinto, escalan de xeito distinto e responden ante equipos distintos, e por iso a pregunta do contedor adoita producir discusións que nunca se resolven.

O límite dun Pod é un espazo de nomes, non un host de salto

Un espazo de nomes de rede de Linux posúe as súas interfaces, enderezos, rutas e regras de firewall, e cada Pod recibe un. Os contedores dentro dese Pod únense a el, e é exactamente por iso que un contedor auxiliar pode reescribir rutas que a aplicación despois segue. Un Pod veciño ten unha pila de aspecto idéntico pero completamente separada. Non hai ningunha táboa compartida que un Pod de porta poida herdar, nin unha entrega implícita de tráfico dun espazo de nomes a outro.

Tamén é por iso que o patrón de Pod de porta só funciona cando algo augas arriba lle envía realmente paquetes: un Service, unha ruta estática no nodo ou unha política de direccionamento no CNI. Un enderezo por si só non atrae nada.

Que compra un túnel por Pod e que custa

Un túnel que se executa no espazo de nomes da carga de traballo dá a esa carga a súa propia identidade de cliente, que moitos servizos de acceso remoto esixen antes de autorizar ou contabilizar unha sesión. O radio de impacto tamén queda local: un túnel roto elimina un Deployment en lugar da ruta compartida que usa todo. Como se executa depende da implementación, e aquí é onde a xente adiviña mal.

Unha configuración que só necesita estado do núcleo pode rematar nun contedor init e saír. Un daemon de espazo de usuario que debe permanecer vivo durante toda a vida do Pod necesita a forma de contedor init reiniciable introducida como sidecar nativo en Kubernetes 1.29, e esa distinción vén da implementación do túnel e non do gusto. O custo deste modelo é a duplicación: cada réplica autentícase, recibe o seu propio enderezo de túnel e consume unha praza de sesión remota, así que un evento de autoescalado convértese nun evento de capacidade no outro lado da ligazón. Copiar unha soa credencial en todas as réplicas non elimina ese custo, elimina o rastro de auditoría. As capacidades merecen o mesmo escrutinio, porque un túnel que quere NET_ADMIN no seu propio espazo de nomes non ten motivo para herdar a autoridade sobre todo o host dun exemplo con privileged: true.

Cando o CNI posúe a saída

Se o CNI o admite, unha porta de saída selecciona o tráfico por carga de traballo e rango de destino, e logo envíao por nodos escollidos baixo un enderezo de orixe previsible. A versión de Cilium é a referencia habitual, e a súa documentación di claramente que a función necesita unha configuración específica de Cilium ademais de nodos de porta provistos coas interfaces e enderezos correctos. Tamén sinala un período inicial tras crear o Pod no que o direccionamento aínda non se aplica, o que é un dato de deseño e non unha nota ao pé.

Lea ese atraso contra a súa propia promesa. Se a regra é que ningún tráfico pode saír por outra ruta, un Pod novo que transmita durante o oco xa a rompeu, así que a secuencia de arranque necesita a súa propia resposta: reter a aplicación ata que se aplique a política, ou aceptar a xanela e documentala.

Manteña a afirmación estreita. Unha porta de saída escolle e traduce unha ruta. Non termina unha VPN, e non converte o clúster en cliente da súa rede remota sen unha conexión compatible detrás.

A tradución cambia en silencio o que ve o lado remoto

Unha vez que a porta reescribe a orixe, os enderezos por Pod desaparecen, así que unha lista de permitidos baseada na identidade convértese nunha lista baseada nun enderezo compartido. É un intercambio e non un defecto: menos regras que manter, atribución máis grosa cando algo se comporta mal.

A autenticación a nivel de aplicación e o rexistro de solicitudes teñen que cargar co que a rede xa non informa. Trate a capacidade e a substitución da porta como infraestrutura compartida, porque reiniciar un só nodo agora interrompe cada carga de traballo detrás, e comprobe pronto a ruta de volta: o extremo remoto debe saber como chegar ao enderezo traducido, normalmente mediante unha ruta ou NAT que unha persoa, non un manifesto, debe posuír. A planificación de enderezos tamén pertence aquí, porque rangos de clúster e remotos solapados rompen calquera dos dous modelos e adoptar IPv6 non escusa un plan en conflito.

Decida por propiedade e logo probe o fallo que prometeu

Escolla o túnel por Pod cando o servizo remoto autentica cargas de traballo individuais, cando só uns poucos Deployment necesitan a ligazón e cando un fallo debe quedar local. Escolla a porta cando un equipo de rede xa é dono da ruta, cando moitas cargas comparten un destino e cando un enderezo de orixe estable é todo o propósito do exercicio.

De calquera xeito, verifique a propiedade que vendeu e non o estado estacionario. Cree un Pod, déixeo transmitir de inmediato e observe os primeiros segundos se a promesa era que nada escapa do túnel. Escale a cinco réplicas e conte as sesións que informa o extremo remoto se a promesa era identidade por carga de traballo. Esas dúas comprobacións expoñen os límites do mecanismo moito máis rápido que unha revisión do manifesto, e dinnos que equipo é dono do seguinte incidente.