Kube-proxy Explicado: iptables vs IPVS vs Userspace

¿Alguna vez te has preguntado quién dirige el tráfico dentro de tu clúster de Kubernetes? Ese componente se llama kube-proxy. Aquí vas a ver qué es realmente kube-proxy, los tres modos en los que puede trabajar y por qué muchos equipos ya lo están reemplazando por Cilium.

Por qué kube-proxy importa más de lo que parece#

Operar contenedores está bien: crear Pods, escalar, hacer deploys. Pero todo eso depende de una cosa muy simple, que el tráfico llegue al Pod correcto, en el menor tiempo posible y sin romper nada por el camino. Cuando ese camino está bien construido, pasan tres cosas buenas:

• La latencia baja, porque el enrutado ocurre directamente en el kernel, sin pasos innecesarios.
• El clúster escala de verdad: puedes sumar réplicas sin que aumente la complejidad de las reglas de red.
• Se reducen los errores de red, porque la tabla que lleva el kernel, la que registra qué conexión va a qué destino, se mantiene limpia. Eso evita time-outs y caos en producción.

Pero si el mecanismo de red no escala, todo lo demás se resiente. Te encuentras con reglas infinitas, la CPU disparada y clientes esperando respuestas que nunca llegan.

Para entender por qué pasa todo eso hay que ver cómo kube-proxy maneja el tráfico. Y para eso, primero hay que entender qué es exactamente y cómo se despliega en el clúster.

Qué es kube-proxy#

kube-proxy es un proceso que corre en cada nodo de Kubernetes y que se encarga de convertir la IP virtual de un Service en conexiones reales hacia los Pods que corresponden. Para lograrlo, observa en tiempo casi real los cambios que publica el API Server y, según el modo configurado, genera reglas en iptables o tablas en IPVS dentro del kernel.

Cómo funciona kube-proxy, con un ejemplo#

Vamos a partir de un ejemplo simple, pero representativo. Imagina un Service con la IP 10.96.49.10. Esa dirección es estable y es la puerta de entrada para el cliente.

El clúster tiene dos nodos worker, 172.19.0.3 y 172.19.0.4, y en cada uno se ejecuta kube-proxy como DaemonSet, lo que garantiza una instancia idéntica en todos los nodos. Por encima está el API Server, que expone la información del clúster. kube-proxy mantiene ahí un watch permanente para recibir los eventos de Service y Endpoint sin necesidad de sondear.

Cuando llega un paquete dirigido a 10.96.49.10, entra en uno de los nodos y pasa directamente al kernel. Ahí, las reglas instaladas por kube-proxy cambian su destino a la IP de uno de los Pods disponibles, por ejemplo 10.244.2.3 o 10.244.1.4. Todo esto ocurre antes de que el paquete suba al espacio de usuario, por eso el desvío es rápido y transparente para el cliente.

En resumen, kube-proxy convierte la IP virtual del Service en rutas reales hacia los Pods. Lo hace escuchando eventos del API Server y escribiendo reglas, con iptables o con IPVS, que el kernel ejecuta directamente. El tráfico llega, se redirige dentro del nodo y acaba en el Pod correcto sin que el cliente note nada.

Los tres modos de funcionamiento#

Todo eso que acabas de ver, kube-proxy no siempre lo hizo de la misma forma. En sus inicios procesaba cada conexión dentro del espacio de usuario, como intermediario directo. Con el tiempo aprendió a delegar esa responsabilidad al kernel, y hoy puede apoyarse en subsistemas mucho más eficientes, diseñados para escalar. Esa evolución se refleja en sus tres modos: userspace, iptables e IPVS. Vamos a verlos uno por uno, empezando por el principio.

Modo userspace: dos cruces entre kernel y user space#

Userspace fue la primera solución que tuvo kube-proxy para balancear tráfico. Se eliminó en Kubernetes 1.26, pero es clave para entender por qué nacieron los otros dos modos. Antes de entrar en detalles, hay dos conceptos que conviene aclarar:

• Kernel space es la parte del sistema operativo que controla directamente la red, la memoria y el hardware.
• User space es donde se ejecutan los procesos normales, como los contenedores, y también kube-proxy.

Cada vez que un paquete cruza entre los dos espacios, ya sea subiendo desde el kernel o bajando de nuevo, se produce una copia física de datos en memoria. Ese movimiento no es gratis: consume CPU, cambia el contexto de ejecución y añade latencia.

Así funciona el modo userspace, paso a paso:

• El cliente envía tráfico a la ClusterIP del Service.
• El paquete entra al kernel del nodo. Allí encuentra una regla de iptables, creada por kube-proxy, que hace DNAT y lo redirige a 127.0.0.1, al puerto en el que kube-proxy escucha para ese Service.
• Dentro del kernel, el paquete se desvía al socket en el que está escuchando kube-proxy. Aquí ocurre el primer cruce: el paquete sube al espacio de usuario.
• kube-proxy, ya en user space, selecciona un Pod backend y abre una nueva conexión hacia su IP. Ese reenvío provoca el segundo cruce: el paquete vuelve a bajar al kernel para entregarse al Pod.
• Cuando el Pod responde, todo el recorrido se repite en sentido inverso, con los mismos dos cruces.

Dos cambios de contexto por cada petición implican:

• Más latencia, porque cada salto añade tiempo.
• Más carga de CPU, porque kube-proxy procesa el tráfico byte a byte.
• Poca escalabilidad, porque el propio proceso del proxy se convierte en un cuello de botella a medida que crece el tráfico.

El modo userspace fue útil en los comienzos, pero no aguanta las exigencias actuales. Sus limitaciones abrieron el camino a soluciones más eficientes que delegan el enrutamiento al kernel: primero con iptables y después con IPVS.

Modo iptables: la redirección la hace el kernel#

El segundo modo de funcionamiento de kube-proxy es iptables. Es el modo por defecto en Linux y el más habitual en los clústeres.

A diferencia del modo userspace, aquí kube-proxy no intercepta el tráfico. Su papel es más pasivo: observa los cambios en Services y Endpoints a través del API Server y, con esa información, genera reglas DNAT en iptables que quedan instaladas dentro del kernel. Lo importante es que el tráfico ya no pasa por kube-proxy, porque la redirección la hace directamente el kernel usando esas reglas.

Así funciona el modo iptables, paso a paso:

• El cliente envía tráfico a la IP del Service y al puerto correspondiente.
• El paquete entra al kernel del nodo.
• Una regla DNAT de iptables, que kube-proxy creó previamente, intercepta ese tráfico y cambia su destino hacia uno de los Pods asociados al Service.
• El paquete se enruta directamente al Pod seleccionado, sin pasar por ningún proceso en user space.

Este modo tiene ventajas claras respecto a userspace:

• Menos latencia, porque no hay doble cruce entre kernel y user space.
• Mejor rendimiento, ya que kube-proxy no toca el tráfico en tiempo real.
• Menor uso de CPU, porque todo ocurre dentro del kernel.

Pero no todo es perfecto. iptables genera una regla por cada Pod, y esas reglas se evalúan de arriba abajo, como una lista secuencial. A pequeña escala no hay problema, pero en clústeres con cientos o miles de endpoints esas reglas pueden volverse pesadas de mantener. Además, iptables no tiene algoritmos de balanceo: elige el Pod al azar, con una probabilidad en cada regla.

Aun así, iptables fue un gran salto adelante, porque eliminó el cuello de botella del modo userspace y delegó el trabajo al kernel. El siguiente paso en esta evolución fue IPVS, que mejora justo donde iptables empieza a flaquear: en rendimiento y escalabilidad.

Modo IPVS: búsqueda por hash y balanceo real#

El tercer modo de funcionamiento de kube-proxy aprovecha una tecnología del kernel de Linux llamada IP Virtual Server, o IPVS, diseñada específicamente para hacer balanceo de carga a nivel de red con alto rendimiento.

Igual que en el modo iptables, kube-proxy no toca los paquetes. Su papel es únicamente observar los cambios en los Services y Endpoints y luego configurar IPVS a través de netlink, una interfaz que le permite insertar reglas directamente en el kernel. La diferencia clave está en cómo gestiona el kernel ese tráfico.

Así funciona el modo IPVS, paso a paso:

• El cliente envía tráfico a la IP del Service.
• Ese tráfico entra al kernel del nodo, igual que antes.
• En lugar de pasar por una lista secuencial de reglas, como con iptables, IPVS usa una tabla hash que permite encontrar el Service de forma instantánea.
• Cada Service es un servidor virtual con su lista de Pods detrás, e IPVS elige uno según el algoritmo de balanceo configurado, que por defecto es round-robin.
• El tráfico se enruta directamente al Pod seleccionado, todo dentro del kernel.

Este diseño tiene varias ventajas:

• Rendimiento superior, ya que la búsqueda es por hash y no por escaneo.
• Escala mejor con miles de endpoints.
• Algoritmos reales de balanceo, como round-robin, least connections o source hashing.

Pero tampoco es perfecto. IPVS aún depende de conntrack para mantener el estado de las conexiones, lo que puede volverse un cuello de botella en entornos de altísima carga. Además, a diferencia de Cilium, IPVS no ofrece observabilidad ni políticas de red avanzadas.

Aun así, para muchas cargas tradicionales, IPVS ofrece un equilibrio sólido entre rendimiento y simplicidad. Con esto cerramos los tres modos de kube-proxy.

La alternativa moderna: Cilium con eBPF#

Después de conocer los tres modos de kube-proxy, es natural preguntarse si no hay una forma más moderna, más eficiente y más cloud native. La respuesta es sí, y se llama Cilium.

En vez de depender de iptables o IPVS, Cilium se basa en eBPF, una tecnología que permite ejecutar código directamente dentro del kernel de Linux, en puntos clave del flujo de red. El resultado es menos saltos, menos overhead y más visibilidad del tráfico en tiempo real.

En el camino tradicional hay múltiples pasos por iptables, reglas, cambios de contexto y sobrecarga por conntrack. Con Cilium y eBPF, el tráfico sigue rutas más directas y eficientes. Y además de ser más rápido, es más seguro y trae observabilidad de forma nativa.

Cilium lo explico en profundidad en la lección de Cilium. Por ahora, quédate con esta idea: Cilium no es solo una alternativa, es el siguiente paso en la evolución del networking en Kubernetes.

kube-proxy frente a Cilium#

Si comparas los dos enfoques, el patrón es claro. kube-proxy, ya sea con iptables o con IPVS, depende de reglas, conntrack y NAT para tomar decisiones. El resultado es este:

• Más latencia.
• Cero visibilidad entre Pods.
• Políticas que se rompen cuando cambia la IP.

Cilium, en cambio, decide desde el kernel, en un solo salto y sin reglas. Ofrece observabilidad en tiempo real, políticas por identidad y cifrado opcional con WireGuard o IPsec.

Esa diferencia no es un detalle menor. Es lo que decide si un clúster sigue respondiendo bajo carga o se rompe justo cuando más lo necesitas.

Lo que hemos visto#

• kube-proxy corre en cada nodo como DaemonSet, escucha al API Server y escribe reglas en el kernel para convertir la IP virtual de un Service en la IP de un Pod real.
• El modo userspace hacía pasar cada paquete por kube-proxy, con dos cruces entre kernel y user space por petición, y se eliminó en Kubernetes 1.26.
• El modo iptables deja la redirección al kernel con reglas DNAT, pero esas reglas se evalúan una por una y pesan en clústeres con miles de endpoints.
• El modo IPVS busca el Service en una tabla hash y ofrece algoritmos de balanceo reales, aunque sigue dependiendo de conntrack.
• Cilium sustituye todo eso por programas eBPF en el kernel, con políticas por identidad y observabilidad en tiempo real.