# Qué es Cilium y por qué todos lo usan en Kubernetes | Red, Seguridad y eBPF explicados en español > Qué es Cilium, cómo nació y por qué usa eBPF en vez de iptables para mover el tráfico, aplicar políticas y dar visibilidad en Kubernetes. - Autor: Alexander Zelada, Cloud Architect - URL: https://alexanderzelada.com/que-es-cilium/ - Ruta: Redes por dentro (lección 2 de 4) — https://alexanderzelada.com/redes/ - Publicado: 2026-10-16 - Actualizado: 2026-10-16 - Idioma: español En esta lección vas a ver qué problema tiene kube-proxy en modo iptables cuando el clúster crece, cómo nació Cilium y qué hace en la práctica. La idea central es que Cilium usa eBPF para procesar el tráfico dentro del kernel de Linux, sin tablas enormes de reglas, y aplica las políticas por identidad en vez de por IP. [Vídeo en YouTube](https://www.youtube.com/watch?v=_iN8ZyVZFRE) ¿Sigues usando kube-proxy con iptables en tu clúster de Kubernetes? Hoy existe Cilium, un CNI moderno basado en eBPF que procesa el tráfico dentro del kernel de Linux, sin reglas infinitas y sin capas extra. Con él tienes menos latencia, más rendimiento, seguridad de serie y observabilidad nativa en tiempo real. Vamos a ver cómo funciona. ## El problema de kube-proxy con iptables En la mayoría de instalaciones de Kubernetes, el componente que enruta el tráfico entre los Pods y los Services es kube-proxy. Y kube-proxy puede funcionar en tres modos: - **iptables** , el más común. - **IPVS** . - **userspace** , que está prácticamente olvidado. ¿Qué hace kube-proxy cuando está en modo iptables? Genera reglas dentro del kernel para redirigir el tráfico hacia los endpoints correctos. Cada vez que creas o modificas un Service, kube-proxy reconstruye con iptables una tabla enorme de reglas. Al principio todo va bien. Pero cuando tienes docenas o cientos de Services, y los Pods están cambiando constantemente, esa tabla se vuelve gigantesca. El kernel tiene que recorrer todas esas reglas una por una, y eso afecta directamente al rendimiento: hay más uso de CPU, más latencia y menos escalabilidad. Ahí es donde Cilium propone otra forma de hacerlo, sin tablas gigantes y sin reglas que se reescriben cada vez que algo cambia. ## Cómo nació Cilium Retrocedamos a 2015. Kubernetes acababa de despegar y buscaba su sitio. Ese año, dos ingenieros de redes, Thomas Graf y Dan Wendlandt, vieron llegar algo nuevo al kernel de Linux: eBPF. eBPF es una especie de sandbox dentro del kernel que permite cargar pequeños programas, seguros y de alto rendimiento, sin reiniciar la máquina. Thomas y Dan se preguntaron: «Si podemos ejecutar lógica dentro del kernel, ¿por qué seguimos llenando iptables con reglas estáticas?». De ahí salió Cilium, un CNI que usa eBPF para mover paquetes, aplicar políticas y ofrecer visibilidad, todo desde dentro del kernel. La idea funcionó tan bien que en 2023 la CNCF graduó a Cilium como proyecto estable, y hoy es la base de la red de GKE con Dataplane V2 y de Azure CNI Powered by Cilium en AKS. ## Qué hace Cilium en la práctica ### Networking sin kube-proxy Primero, se encarga del networking. Reemplaza kube-proxy y mueve todo el tráfico dentro del kernel con eBPF: sin reglas gigantes, con su propio seguimiento de conexiones en mapas eBPF y sin recorrer iptables regla a regla. El resultado es menos latencia, menor uso de CPU y un clúster mucho más eficiente y predecible. ### Control de acceso basado en identidades Después entra en juego el control de acceso basado en identidades, que es donde empieza lo interesante. Cilium traduce los labels de Kubernetes, como `app=frontend` o `env=prod`, en identificadores numéricos únicos, y mete esa lógica directamente dentro del kernel gracias a eBPF. Las políticas se aplican comparando identidades, no direcciones IP. Por eso resisten reinicios, escalados y migraciones, y no hace falta reescribir reglas cada vez que algo cambia. ¿Qué implica eso? Que puedes definir, por ejemplo: «Permitir que los Pods con `app=frontend` se comuniquen con los de `app=backend` por el puerto 8080». Y da igual cuántas veces cambien de IP o de nodo: la política sigue funcionando. Además, Cilium puede cifrar el tráfico entre Pods usando WireGuard o IPsec, sin que tengas que tocar ni una línea de tu código. Todo esto lo puedes observar en tiempo real con Hubble, un mapa interactivo de quién se comunica con quién, por qué puerto y por qué motivo, con la información sacada directamente del kernel. ### Más allá de la red Cilium no se queda solo en la red. También puede manejar el tráfico entre microservicios, como lo haría un service mesh, pero sin sidecars ni contenedores adicionales. Soporta llamadas HTTP, gRPC y flujos Kafka, con balanceo de carga, reintentos automáticos y autenticación basada en SPIFFE. Y con Tetragon suma seguridad en tiempo de ejecución. Puede detectar si alguien lanza un bash sospechoso, accede a `/etc/shadow` o ejecuta procesos anómalos, y bloquearlo en caliente o, al menos, reportarlo al instante. Todo eso se exporta sin fricciones a Prometheus, Grafana, Fluentd u OpenTelemetry. Y funciona igual en AWS, GCP, Azure, on-prem, OpenShift o bare metal. En resumen, Cilium junta conectividad, visibilidad y seguridad en un mismo plano gracias a eBPF, y eso lo hace más rápido, más seguro y más fácil de operar. ## El camino de un paquete antes y después de Cilium Antes de Cilium, cuando un paquete entraba al nodo, tenía que atravesar muchas etapas. Primero pasaba por conntrack, para validar las conexiones activas. Luego por varias cadenas de iptables: PREROUTING, FORWARD, POSTROUTING… y en cada etapa había nuevas reglas. Todo ese camino no solo consume más CPU. También añade latencia y hace que los problemas sean más difíciles de diagnosticar. Con Cilium y eBPF, el paquete entra por la interfaz de red y, en lugar de pasar por toda esa cadena de reglas, lo intercepta un programa eBPF desde el principio. Ahí mismo, en el kernel, se decide su ruta, se aplican las políticas de seguridad, se cifra si es necesario, y el paquete sigue directo hacia el Pod. No hay reglas infinitas ni saltos innecesarios: la traducción de la IP del Service a la del Pod se hace en el mismo programa eBPF, sin pasar por iptables. ¿El resultado? Menos carga para el kernel, latencia mínima y una red que puedes ver y entender en tiempo real. Y todo eso sin perder compatibilidad con lo que ya usas. ## Lo que hemos visto - En modo iptables, kube-proxy reconstruye una tabla de reglas que crece con cada Service, y el kernel la recorre regla a regla, lo que sube la CPU y la latencia. - Cilium nació en 2015, cuando Thomas Graf y Dan Wendlandt decidieron usar eBPF en lugar de reglas estáticas de iptables. La CNCF lo graduó en 2023. - Cilium reemplaza a kube-proxy: un programa eBPF intercepta cada paquete al entrar y decide en el kernel su ruta, las políticas y el cifrado. - Las políticas de Cilium comparan identidades numéricas calculadas a partir de los labels, no IPs, así que siguen funcionando aunque los Pods cambien de IP o de nodo. - Además, Cilium cifra con WireGuard o IPsec, da visibilidad con Hubble, ofrece funciones de service mesh sin sidecars y seguridad en tiempo de ejecución con Tetragon.