Pod, nodo o clúster: qué redirige realmente un sidecar VPN

Un sidecar VPN dentro de un Pod de Kubernetes parece una VPN a nivel de host con mejores modales, y el parecido termina en la frontera del espacio de nombres. Los contenedores de un Pod comparten el espacio de nombres de red, incluido el espacio de direcciones y puertos, así que un sidecar que instala rutas y políticas cambia de verdad a dónde van los paquetes de la aplicación. No cambia nada para los demás Pods del nodo, y no toca la pila propia del nodo salvo que lo configures para ello. Acertar con esa frontera decide tanto lo que puedes desplegar como lo que debes probar. Las secciones siguientes lo siguen desde el espacio de nombres hacia fuera.

Espacio de nombres compartido, consecuencias compartidas

Dos contenedores de un Pod hablan por loopback y ven las mismas interfaces, y por eso el patrón de sidecar funciona: la aplicación no necesita saber que existe un túnel, porque la ruta que resuelve se instaló en el espacio de nombres que usa. La misma propiedad implica que los errores del sidecar son errores de la aplicación. Una ruta que captura demasiado, o un cambio de DNS que apunta a un resolutor dentro del túnel, se aplica de inmediato a cada proceso de ese Pod. En un espacio de nombres compartido no hay enrutamiento por contenedor, así que un sidecar no puede limitarse a un proceso.

Ese es el mecanismo que conviene tener presente durante la revisión: el radio de impacto es el Pod, no el nodo ni el clúster.

Hasta dónde no llega el sidecar

Los demás Pods conservan sus espacios de nombres y su propio enrutamiento, así que una carga de trabajo que necesita la misma salida necesita el mismo sidecar o, en su lugar, un diseño a nivel de nodo. El tráfico del nodo también queda fuera del espacio de nombres del Pod, y los Pods con red de host se excluyen deliberadamente de este aislamiento por completo. Si ejecutas el sidecar con red de host para llegar a algo cómodo, has ampliado el alcance de un Pod a todo el nodo y deberías decirlo en voz alta.

El tráfico hacia los servicios del clúster es la otra sorpresa habitual. Una ruta predeterminada amplia dentro del Pod puede capturar peticiones destinadas al servidor de API o a un servicio ClusterIP, que luego fallan de formas que parecen un túnel roto.

Plan de rutas: rangos de Pod, servicio, nodo y VPN

Anota los cuatro rangos y compruébalos en busca de solapamiento antes de desplegar nada: CIDR del Pod, CIDR del servicio, direcciones del nodo y destinos detrás de la VPN. El solapamiento entre los rangos privados de la VPN y el espacio propio del clúster no es raro, y una ruta predeterminada es la solución equivocada. El plan de rutas pertenece al mismo repositorio que el manifiesto, porque el siguiente clúster puede repartir rangos de Pod y de servicio completamente distintos.

El DNS es parte del plan y no una preocupación aparte. Un sidecar que reescribe la configuración del resolutor puede romper el descubrimiento de servicios dentro del clúster mientras hace que las consultas externas funcionen a la perfección.

El arranque y el fallo son estados explícitos

Un proceso de sidecar en marcha no es una política de salida. Decide qué tráfico puede fluir antes de que el túnel esté listo y qué pasa si muere después, y luego implementa esa decisión: una sonda que condicione el contenedor de la aplicación, una política de red que deniegue por defecto, o ambas. Sin ninguna de las dos, la aplicación arranca, resuelve y envía tráfico por la ruta normal del nodo mientras el túnel aún se está conectando.

Ese hueco es breve en un clúster sano y permanente en uno roto, y es exactamente la propiedad que prefiere un atacante o una fuga de datos accidental.

Combina el orden con una prueba de fallo. Mata el sidecar y confirma que la aplicación pierde su salida prevista en lugar de retroceder en silencio.

Capacidades, políticas y pruebas desde el contenedor de la aplicación

Conceder las capacidades necesarias para crear interfaces y alterar rutas es una decisión de privilegios, y un privilegio adecuado para un Pod aislado no lo es automáticamente en la pila del nodo. Usa los mecanismos de política de red y seguridad que admite el clúster, y no des por hecho que toda implementación de CNI o de políticas trata una interfaz VPN igual; las diferencias aparecen justo en los casos de fallo que te importan.

Prueba desde el contenedor real de la aplicación, con peticiones nuevas a un destino privado, un servicio del clúster e internet público. Una prueba desde el sidecar demuestra que el túnel funciona, no que la aplicación llegue a lo que necesita.

Documenta los supuestos de red del clúster junto a la configuración de la VPN. Mover la carga de trabajo a otro clúster es entonces un ejercicio de comprobar el plan de rutas y no un cambio de imagen que deja de funcionar en silencio.