VPN por Pod en Kubernetes frente a puerta de enlace de salida: ¿quién es dueño del túnel?

Despliega un Pod llamado vpn-gateway, apunta un cliente de prueba a su dirección y observa cómo los paquetes desaparecen. Nada en el manifiesto está mal y el kubelet no tiene ninguna queja. La razón es estructural y no de configuración: Kubernetes da a cada Pod su propio espacio de nombres de red, así que un nombre, una etiqueta o un espacio de nombres de API compartido no cambian nada sobre adónde van los paquetes. Por eso, decidir cómo sale el tráfico VPN del clúster empieza con una pregunta sobre la propiedad, no sobre las imágenes de contenedor.

Dos mecanismos cubren la mayoría de los despliegues reales, y no son intercambiables. Uno pone el túnel dentro del propio espacio de nombres de red de la carga de trabajo. El otro pide al CNI que dirija el tráfico seleccionado a través de un nodo de puerta de enlace designado. Fallan de forma distinta, escalan de forma distinta y responden ante equipos distintos, y por eso la pregunta del contenedor suele producir discusiones que nunca se resuelven.

El límite de un Pod es un espacio de nombres, no un host de salto

Un espacio de nombres de red de Linux posee sus interfaces, direcciones, rutas y reglas de cortafuegos, y cada Pod recibe uno. Los contenedores dentro de ese Pod se le unen, y es exactamente por eso que un contenedor auxiliar puede reescribir rutas que la aplicación luego sigue. Un Pod vecino tiene una pila de aspecto idéntico pero completamente separada. No hay una tabla compartida que un Pod de puerta de enlace pueda heredar, ni una entrega implícita de tráfico de un espacio de nombres a otro.

También es por eso que el patrón de Pod de puerta de enlace solo funciona cuando algo aguas arriba envía realmente paquetes hacia él: un Service, una ruta estática en el nodo o una política de direccionamiento en el CNI. Una dirección por sí sola no atrae nada.

Qué compra un túnel por Pod y qué cuesta

Un túnel que se ejecuta en el espacio de nombres de la carga de trabajo le da a esa carga su propia identidad de cliente, que muchos servicios de acceso remoto exigen antes de autorizar o contabilizar una sesión. El radio de impacto también se queda local: un túnel roto elimina un Deployment en lugar de la ruta compartida que usa todo. Cómo se ejecuta depende de la implementación, y aquí es donde la gente adivina mal.

Una configuración que solo necesita estado del núcleo puede terminar en un contenedor init y salir. Un demonio de espacio de usuario que debe permanecer vivo durante toda la vida del Pod necesita la forma de contenedor init reiniciable introducida como sidecar nativo en Kubernetes 1.29, y esa distinción viene de la implementación del túnel y no del gusto. El coste de este modelo es la duplicación: cada réplica se autentica, recibe su propia dirección de túnel y consume una plaza de sesión remota, así que un evento de autoescalado se convierte en un evento de capacidad al otro lado del enlace. Copiar una sola credencial en todas las réplicas no elimina ese coste, elimina el rastro de auditoría. Las capacidades merecen el mismo escrutinio, porque un túnel que quiere NET_ADMIN en su propio espacio de nombres no tiene motivo para heredar la autoridad sobre todo el host de un ejemplo con privileged: true.

Cuando el CNI posee la salida

Si el CNI lo admite, una puerta de enlace de salida selecciona el tráfico por carga de trabajo y rango de destino, y luego lo envía por nodos elegidos bajo una dirección de origen predecible. La versión de Cilium es la referencia habitual, y su documentación dice claramente que la función necesita una configuración específica de Cilium además de nodos de puerta de enlace provistos con las interfaces y direcciones correctas. También señala un periodo inicial tras crear el Pod en el que el direccionamiento aún no se aplica, lo que es un dato de diseño y no una nota al pie.

Lea ese retraso contra su propia promesa. Si la regla es que ningún tráfico puede salir por otra ruta, un Pod nuevo que transmita durante el hueco ya la ha roto, así que la secuencia de arranque necesita su propia respuesta: retener la aplicación hasta que se aplique la política, o aceptar la ventana y documentarla.

Mantenga la afirmación estrecha. Una puerta de enlace de salida elige y traduce una ruta. No termina una VPN, y no convierte el clúster en cliente de su red remota sin una conexión compatible detrás.

La traducción cambia en silencio lo que ve el lado remoto

Una vez que la puerta de enlace reescribe el origen, las direcciones por Pod desaparecen, así que una lista de permitidos basada en la identidad se convierte en una lista basada en una dirección compartida. Es un intercambio y no un defecto: menos reglas que mantener, atribución más gruesa cuando algo se comporta mal.

La autenticación a nivel de aplicación y el registro de solicitudes tienen que cargar con lo que la red ya no informa. Trate la capacidad y el reemplazo de la puerta de enlace como infraestructura compartida, porque reiniciar un solo nodo ahora interrumpe cada carga de trabajo detrás, y compruebe pronto la ruta de retorno: el extremo remoto debe saber cómo llegar a la dirección traducida, normalmente mediante una ruta o NAT que una persona, no un manifiesto, debe poseer. La planificación de direcciones también pertenece aquí, porque rangos de clúster y remotos solapados rompen cualquiera de los dos modelos y adoptar IPv6 no excusa un plan en conflicto.

Decida por propiedad y luego pruebe el fallo que prometió

Elija el túnel por Pod cuando el servicio remoto autentique cargas de trabajo individuales, cuando solo unos pocos Deployment necesiten el enlace y cuando un fallo deba quedarse local. Elija la puerta de enlace cuando un equipo de red ya sea dueño de la ruta, cuando muchas cargas compartan un destino y cuando una dirección de origen estable sea todo el propósito del ejercicio.

En cualquier caso, verifique la propiedad que vendió y no el estado estacionario. Cree un Pod, déjelo transmitir de inmediato y observe los primeros segundos si la promesa era que nada escapa del túnel. Escale a cinco réplicas y cuente las sesiones que informa el extremo remoto si la promesa era identidad por carga de trabajo. Esas dos comprobaciones exponen los límites del mecanismo mucho más rápido que una revisión del manifiesto, y le dicen qué equipo es dueño del siguiente incidente.