Creas un Service, apuntas un cliente a su IP virtual y los paquetes llegan a un Pod. Ese gesto parece sencillo porque Kubernetes se ocupa de esconder el camino. Pero cuando el trafico deja de llegar, o cuando el cluster crece, la pregunta reaparece: ¿quien decidio realmente el siguiente salto?
Con kube-proxy, Kubernetes observa Services y EndpointSlices y programa reglas locales para llevar el trafico hacia endpoints disponibles. Historicamente el modo mas comun ha sido iptables; IPVS tambien ha existido como alternativa. Es un mecanismo conocido, con años de operacion detras, y para muchos clusters sigue siendo suficiente.
Cilium propone mover buena parte de esa decision a programas eBPF en el kernel. En su modo de reemplazo de kube-proxy, el mismo plano que implementa conectividad y politica puede ocuparse de los Services. La diferencia no es un logo en el manifiesto: cambia donde buscas las pistas cuando un paquete se pierde.
Lo que compararia antes del benchmark
Si tu cluster es pequeno, estable y el equipo ya entiende como depurar kube-proxy, cambiar solo porque eBPF suena moderno es una mala razon. La operacion tiene valor. Saber leer reglas, endpoints y conntrack puede resolver mas incidentes que una migracion apresurada.
Si la red es parte central del producto, si necesitas observabilidad de flujos, politicas ligadas a identidades o quieres estudiar un datapath eBPF con profundidad, Cilium abre una superficie distinta. Hubble y las herramientas de Cilium permiten preguntar por drops y decisiones de politica con una cercania que resulta dificil cuando todo se observa desde reglas acumuladas.
Tampoco hay magia gratuita. Reemplazar kube-proxy exige entender los modos de instalacion, la compatibilidad con tu plataforma, el manejo de Services especiales y el procedimiento de migracion. Cuando la red vive mas cerca del kernel, el equipo debe estar dispuesto a mirarla mas cerca del kernel.
Una prueba honesta
Yo no compararia ambos caminos con una grafica prestada. Levantaria dos clusters pequenos, publicaria el mismo Deployment y seguiria una peticion: primero la lista de EndpointSlices, luego el camino local y finalmente el comportamiento cuando un pod desaparece. La pregunta no es solo cual tiene menos milisegundos. Es cual te permite explicar con claridad lo que ocurre el dia que el Service ya no responde.
Fuentes: la mecanica de Services y EndpointSlices esta documentada en Kubernetes Services; el reemplazo de kube-proxy se describe en la documentacion oficial de Cilium.
Conversacion
Se el primero en comentar