Quién balancea realmente el tráfico de producción en Kubernetes

Cualquier ingeniero de redes experimenta un momento muy concreto cuando empieza a profundizar en Kubernetes.

Has pasado años optimizando balanceadores de carga físicos. Conoces bien el flujo habitual: cliente → balanceador de carga → servidores. ¿Terminación TLS? Sencillo. ¿Sesiones persistentes? Resuelto. ¿200,000 sesiones TCP simultáneas? Sin problemas.

Entonces llega Kubernetes y el vocabulario explota de repente: Services, Ingress, API Gateways, balanceadores de carga en la nube, service meshes, NodePort, el tipo LoadBalancer, MetalLB y Cilium. Da la sensación de que alguien tomó un diagrama limpio y ordenado y derramó capas de abstracción por encima.

¿Qué ocurre realmente en un entorno de producción?

Kubernetes no sustituye a tu balanceador de carga

Una de las respuestas más votadas en el debate de la comunidad va directa al grano:

«No, solo controla balanceadores de carga... Kubernetes no viene con un balanceador de carga integrado».

Eso lo resume todo. Kubernetes no es tu F5. No termina TLS por arte de magia desde la nada ni gestiona en secreto 200k sesiones TCP dentro de una caja negra. Lo que hace es orquestar y configurar, delegando el trabajo pesado en otros componentes.

Ese «otro componente» depende por completo de tu entorno. En la nube, un recurso Service de tipo LoadBalancer indica al controlador de la nube que aprovisione un balanceador externo de forma automática. En entornos on-premise o bare metal, puedes utilizar MetalLB para anunciar las IP del servicio mediante BGP o ARP, o apoyarte en Cilium para gestionar BGP y la distribución L2/L3.

Kubernetes es el plano de control; el motor que mueve el tráfico vive en otra parte. Cuando lo enfocas de ese modo, el resto de conceptos encaja de inmediato.

Ingress no es un balanceador de carga (en sentido estricto)

Este punto confundió a varias personas en el hilo y merece una pausa.

Un recurso Ingress es una colección de reglas, un objeto de configuración. El verdadero músculo reside en el controlador Ingress que se ejecuta dentro del clúster, que suele ser NGINX, Traefik o HAProxy.

Un ingeniero lo explicaba con total claridad: un recurso Ingress para ingress-nginx se traduce en un archivo nginx.conf, y esa configuración gestiona luego el enrutamiento. Así pues, Kubernetes define la intención, el controlador la traduce a una configuración real de proxy y el proxy efectúa el balanceo efectivo.

Es abstracción sobre abstracción, y al principio parece complejo. En cuanto comprendes que se trata de automatización de configuraciones, todo cobra sentido.

¿Dónde termina realmente TLS?

Aquí es donde las arquitecturas de producción empiezan a bifurcarse. No existe una única respuesta correcta, sino varios patrones habituales.

Patrón 1: Terminar en el borde (el más habitual)

Un balanceador de carga externo, físico o gestionado en la nube, termina TLS. Los motivos principales:

• Puedes ejecutar inspecciones de WAF directamente en el perímetro
• Reduces los intercambios SSL internos
• La gestión de certificados queda centralizada

Varios ingenieros del hilo prefieren este modelo: dejar que el hardware dedicado (o el balanceador de la nube) procese TLS y mantener el clúster centrado en el enrutamiento de las aplicaciones.

Algunos entornos incluso vuelven a cifrar el tráfico hacia el clúster: TLS termina en el borde, se inicia una segunda sesión TLS hacia el Ingress y mTLS toma el control dentro del clúster. Así consigues seguridad por capas y una clara separación de responsabilidades.

Patrón 2: Terminar en el controlador Ingress

En lugar de delegar en el balanceador de la nube, configuras la gestión de certificados directamente dentro de Kubernetes. Las anotaciones en un recurso Ingress pueden activar el aprovisionamiento de certificados mediante herramientas como cert-manager, y el propio controlador Ingress asume la terminación TLS.

Esto encaja muy bien en:

• Entornos nativos de la nube
• Clústeres pequeños o medianos
• Equipos que prefieren el control total dentro de Kubernetes

Simplifica la infraestructura externa, aunque exige escalar la capa de Ingress según el volumen de tráfico.

Patrón 3: Delegar en una malla de servicios (service mesh)

Aquí las cosas se vuelven más complejas. Con Istio, TLS puede gestionarse en la pasarela o mediante inyección de contenedores sidecar en las cargas de trabajo, y la malla aplica mTLS automáticamente entre servicios.

Es una solución potente pero operativamente pesada. No se adopta a la ligera; se implementa cuando necesitas cifrado servicio a servicio, modelado de tráfico, observabilidad y políticas de seguridad a gran escala.

¿Qué pasa con las 200k sesiones TCP?

Esta parte tranquilizará a los ingenieros de redes. Si utilizas un balanceador físico o un balanceador de la nube en la entrada, el rendimiento es exactamente el mismo de siempre. Kubernetes no debilita mágicamente el protocolo TCP; utiliza bajo el capó la misma pila de red de Linux en la que confían muchos balanceadores de carga tradicionales.

Un comentarista que llevaba montando clústeres de HPC mucho antes de que existiera Kubernetes lo resumió sin rodeos: es la misma pila de red de siempre, solo que automatizada de otra forma.

Si ejecutas Ingress basado en software dentro del clúster, el escalado se vuelve horizontal: más pods de Ingress, más nodos y más endpoints. Los mecanismos de autoescalado intervienen y el balanceo L2/L3 reparte el tráfico. En ese punto, se convierte en una planificación de capacidad estándar.

Kubernetes no contabiliza sesiones por sí mismo; delega esa tarea en la capa de infraestructura encargada del balanceo.

Bare metal se pone interesante

La nube simplifica las cosas; en bare metal es donde aparece el ingenio.

Algunos ingenieros ejecutan MetalLB con BGP, anunciando las IP de servicio directamente a sus routers. Uno mencionaba haberlo combinado con un MikroTik RB5009 gestionando rutas BGP.

Otros mantienen un proxy inverso tradicional fuera del clúster, como Traefik o HAProxy, y reenvían el tráfico a servicios de tipo NodePort dentro de Kubernetes.

Y sí, algunos todavía integran balanceadores físicos reales, permitiendo que Kubernetes ajuste dinámicamente la configuración mientras los equipos de infraestructura conservan el control de los equipos físicos. Ese modelo híbrido es mucho más común de lo que se admite: infraestructura gestiona el hardware, desarrollo define las reglas de enrutamiento y cada uno mantiene su ámbito.

El patrón real en producción

Elimina la terminología accesoria y la gran mayoría de arquitecturas reales se resume en esto:

Cliente → Balanceador de carga externo → Controlador Ingress → Service → Pods

Todo lo demás son detalles de implementación. En ocasiones el balanceador externo está gestionado en la nube, otras veces es un F5 o un Citrix, y en otras es MetalLB anunciando direcciones VIP mediante BGP.

Kubernetes se sitúa en el centro, coordinando el flujo del tráfico una vez cruza el perímetro del clúster. Los balanceadores siguen presentes; lo que cambia con Kubernetes es que su configuración pasa a estar completamente industrializada.

Por qué este modelo resulta tan distinto

En entornos tradicionales, los equipos de redes diseñaban y operaban todo el flujo de tráfico. En Kubernetes, los equipos de aplicaciones pueden definir reglas de enrutamiento de manera declarativa. Es un cambio cultural tanto como técnico.

Ya no configuras a mano servidores virtuales en un dispositivo físico. Escribes archivos YAML, y ese código activa una automatización que configura otros componentes. Ese nivel de indirección puede resultar incómodo si estás acostumbrado a controlar cada parámetro de forma directa.

También resulta sumamente potente, porque ahora:

• Los desarrolladores despliegan servicios sin abrir tickets al equipo de red
• La infraestructura puede fijar límites y salvaguardas
• El escalado pasa a estar gobernado por API

Y lo más importante: los errores de configuración son reproducibles y están sujetos a control de versiones.

¿Simplifica o complica Kubernetes el balanceo de carga?

Ambas cosas. Simplifica el aprovisionamiento y complica el modelo mental.

En lugar de un único dispositivo con la etiqueta «Balanceador de carga», ahora intervienen:

• Objetos Service
• Recursos Ingress
• Controladores Ingress
• Controladores de nube (cloud controller managers)
• Service meshes opcionales
• Balanceadores internos L2/L3 opcionales

Por debajo de todo ello, se aplican los mismos principios clásicos: Capa 4 frente a Capa 7, puntos de terminación TLS, gestión de sesiones, comprobaciones de estado (health checks) y lógica de enrutamiento. Lo que cambia es quién gestiona cada parte y el grado de automatización alcanzado.

A qué se reduce la red de Kubernetes en producción

Kubernetes no sustituye por arte de magia a los balanceadores tradicionales: estandariza el modo en que te comunicas con ellos.

Si necesitas un rendimiento masivo y una concurrencia elevada de sesiones TCP, sigues dependiendo de infraestructura contrastada, ya sean balanceadores en la nube, equipos físicos o proxies de software de alto rendimiento. Kubernetes simplemente garantiza que:

• Estén configurados de forma homogénea
• Se aprovisionen automáticamente
• Sigan reglas declarativas
• Los desarrolladores no rompan por accidente los patrones globales de tráfico

La red en sí no cambia; Kubernetes se encarga de orquestarla. En cuanto dejas de esperar que sea el balanceador y comienzas a entenderlo como el cerebro de automatización entre bambalinas, todo cobra sentido. El flujo tradicional sigue ahí; ahora simplemente cuenta con un plano de control.