kube-proxy es el componente más invisible de Kubernetes: convierte en silencio la IP virtual de un Service en la dirección de un pod concreto. Mientras tienes unas pocas decenas de Services, nadie piensa en él. Los problemas empiezan a escala — y en 2026 este viejo mecanismo por fin tiene un motivo serio para ser reemplazado.
Por qué el modo iptables choca contra un techo
En su modo por defecto, kube-proxy recorre linealmente una cadena de reglas iptables por cada paquete. Por debajo de ~1000 Services eso es invisible; por encima, el coste de CPU crece en proporción al tamaño del catálogo. Pero peor que la escala es la ceguera. iptables elige un pod de backend al azar — el kernel «lanza una moneda ponderada» — y la decisión de enrutamiento no ve ni la latencia, ni la profundidad de la cola de conexiones, ni el estado de salud del pod. El tráfico irá a un pod sobrecargado o cruzará una zona de disponibilidad incluso cuando hay un pod sano justo al lado, en el mismo nodo. Bajo carga esto degenera en reintentos → fallos en cascada → picos de P99.
1.36 eliminó IPVS, y nftables arregla lo que no toca
Kubernetes 1.36 eliminó el modo IPVS de kube-proxy — para quienes alguna vez escaparon de iptables hacia IPVS en busca de búsquedas en tiempo constante, las opciones se han estrechado. Desde 1.31 kube-proxy se movió a un backend nftables: eso arregla la escalabilidad y la velocidad de actualización de reglas, pero deja intacta la raíz del problema. Las decisiones se siguen tomando en L4 y permanecen ciegas al estado de la aplicación.
Cómo eBPF cambia las reglas
Cilium reemplaza kube-proxy con un solo flag — kubeProxyReplacement: true. En lugar de recorrer una cadena de reglas, obtienes una búsqueda en tiempo constante dentro de un programa eBPF compilado en el kernel. El modelo mental es simple: iptables pregunta «¿qué regla coincide con este paquete?», eBPF responde «ya sé qué hacer».
El truco clave es socket-LB. El kube-proxy clásico hace DNAT sobre el paquete después de connect(), y cada paquete pasa por conntrack. Cilium reescribe el destino a nivel de syscall — antes de que el paquete siquiera exista. Sin conntrack, sin sobrecarga de SNAT, menor latencia. Encima de eso, el hashing consistente Maglev fija una 5-tupla (IP origen/destino, puerto origen/destino, protocolo) al mismo pod — crítico para capas de caché como Redis, donde la selección aleatoria de backend dispersa las peticiones y arruina la tasa de aciertos. Un efecto secundario al depurar: tcpdump en el lado del pod muestra el destino ya reescrito en lugar de la ClusterIP del Service — lo primero que desconcierta.
Dónde compensa y dónde no
El contrapunto honesto importa más que el marketing. En un clúster de 1–3 nodos, kube-proxy sobre iptables puede ganarle a Cilium en latencia para tráfico puro pod-a-pod: la sobrecarga de eBPF no se amortiza con una tabla conntrack pequeña de un par de cientos de Services. Cilium también cuesta más de operar — requiere un kernel de Linux ≥5.x, añade más perillas, y los incidentes de eBPF son más difíciles de depurar que leer reglas iptables.
La regla de decisión: reemplazar kube-proxy por eBPF se justifica con ≥5 nodos, ≥100 Services, o cuando necesitas explícitamente políticas L7, observabilidad mediante Hubble o Cluster Mesh. Es una elección consciente para la carga, no un «por defecto siempre».
Por dónde empezar
Primero comprueba la versión del kernel (≥5.x) en cada nodo — es un requisito duro, no una recomendación. Despliégalo mediante nodos canary: los problemas de red a nivel de kernel dan más miedo que depurar iptables. Activa Hubble desde el primer día — la visibilidad de flujos convierte «el paquete desapareció en algún sitio» en «el datapath descartó el paquete por este motivo concreto», y compensa ya en el primer incidente. En un stack bare-metal (kubeadm + Cilium con kubeProxyReplacement=true) este conjunto es estándar desde hace tiempo.
Y al revés: si no necesitas políticas L7, una malla ni observabilidad avanzada, Calico + kube-proxy sigue siendo perfectamente suficiente. El principio rector de la capa de red es el mismo que en toda la infraestructura — no pagues en operación por capacidades que nunca usas.