La característica definitoria de Cilium no es una función concreta, sino que el networking, la seguridad y la observabilidad se implementan como programas que se ejecutan directamente en el kernel de Linux, mediante eBPF, en lugar de añadirse con reglas de iptables o un proxy sidecar. Esta guía cubre lo que eso significa en la práctica: qué ocurre cuando arranca un Pod, cómo se toma una decisión de política y por qué la ruta de red de Cilium es más rápida que las alternativas que reemplaza.

eBPF en un párrafo

eBPF te permite cargar pequeños programas con un propósito concreto en el kernel de Linux en tiempo de ejecución, sin escribir un módulo del kernel ni parchear el kernel. Antes de que se permita cargar cualquiera de estos programas, un verificador dentro del kernel lo analiza estáticamente: confirma que termina (sin bucles no acotados), que se mantiene dentro de límites de memoria seguros y que no puede bloquear ni colgar el kernel. Un programa que no supera esa comprobación se rechaza de plano, y eso es lo que hace seguro permitir que herramientas del espacio de usuario carguen lógica arbitraria en el espacio del kernel. Cada programa eBPF se compila y se carga en el momento, no se distribuye como un binario del kernel precompilado.

Qué ocurre cuando arranca un Pod

El kubelet de Kubernetes le pide al plugin CNI configurado que prepare el networking de un nuevo Pod. Con Cilium como esa CNI:

1. Cilium asigna al Pod un network namespace y la configuración IP habitual, el mismo trabajo base que realiza cualquier CNI.
2. Cilium asigna al Pod una identidad de seguridad, derivada de sus etiquetas de Kubernetes, no de su dirección IP. Todos los Pods que comparten las mismas etiquetas relevantes (normalmente incluyendo cosas como las etiquetas del selector de su Deployment) comparten la misma identidad. Esto importa porque las IP de los Pods son efímeras y se reasignan constantemente; una identidad ligada a etiquetas se mantiene estable entre reinicios y reprogramaciones de una forma en que una dirección IP nunca podría.
3. Cilium adjunta un programa eBPF al network namespace del Pod. Desde ese momento, ese programa ve y puede actuar sobre cada evento de red que involucre a este Pod: una conexión que se abre, un paquete que llega, una petición que sale hacia otro servicio o hacia el exterior.

Las decisiones de política se toman por paquete, no por sesión

Los firewalls tradicionales suelen implementar “allow established”: una vez que se permite una conexión, cada paquete posterior pasa sin volver a evaluarse, y solo las conexiones nuevas se comprueban contra la política. La aplicación de políticas basada en eBPF de Cilium evalúa cada paquete individual contra la política vigente, no solo la configuración inicial de la conexión.

La consecuencia práctica: cuando cambias una network policy, el cambio es efectivo de inmediato sobre todo el tráfico, incluidas las conexiones que ya estaban abiertas. No hay una ventana en la que una sesión ya establecida siga fluyendo bajo reglas obsoletas hasta que casualmente se cierre y se vuelva a abrir.

La observabilidad sale del mismo flujo de eventos, gratis

La misma instrumentación eBPF que toma las decisiones de política también genera un evento por cada interacción de red que observa: intentos de conexión, tráfico permitido y denegado, peticiones a destinos externos. Así es también como Cilium puede atribuir el tráfico al proceso real que lo generó, no solo “este Pod habló con aquel Pod”, sino qué proceso concreto dentro del Pod abrió la conexión, un nivel de detalle que enfoques como la inspección profunda de paquetes en el borde de un sidecar normalmente no pueden reconstruir a posteriori. Este flujo de eventos es la base de la herramienta de observabilidad de Cilium, Hubble, que se cubre en los conceptos clave de la página de inicio de esta tecnología.

Balanceo de carga a nivel de socket: sin reescribir paquetes

Llegar a un Service de Kubernetes tradicionalmente significa que un paquete dirigido a la IP virtual del Service se reescribe (NAT) hacia la IP de un Pod backend real, un paso históricamente implementado con reglas de iptables o IPVS por las que debe pasar cada paquete. Cilium en cambio realiza esta traducción en la capa de socket, en el momento de la conexión, usando hooks eBPF adjuntos donde un proceso llama a connect() o envía datos. La conexión de la aplicación se establece apuntando directamente a un backend elegido desde el principio, en lugar de que cada paquete posterior se reescriba individualmente sobre la marcha. Esto elimina una cantidad significativa de sobrecarga por paquete, algo especialmente notable en el tráfico de alto rendimiento o sensible a la latencia entre servicios.

Reemplazar kube-proxy por completo

kube-proxy, incluido en los binarios estándar de Kubernetes, es lo que implementa el enrutamiento de Services (ClusterIP, NodePort, etc.) usando reglas de iptables o IPVS por defecto. Cilium puede reemplazar kube-proxy por completo, implementando esa misma lógica de enrutamiento de Services en eBPF. Además del rendimiento bruto, esto cambia una característica operativa que conviene conocer: un conjunto grande de reglas de iptables es una única estructura interdependiente, y cambiar una regla puede implicar recargar todo el conjunto. Las reglas basadas en eBPF de Cilium se parecen más a entradas independientes y atómicas, de modo que un cambio en una no requiere tocar el resto.

Por qué esto importa más allá de “es rápido”

El rendimiento es el titular, pero el punto de fondo es arquitectónico: como Cilium opera a nivel de kernel en lugar de mediante una pila de reglas de iptables o un sidecar por Pod, el networking, la política de seguridad, el balanceo de carga y la observabilidad se alimentan del mismo flujo de eventos subyacente y del mismo punto de aplicación en el kernel, en lugar de ser cuatro sistemas separados que hay que configurar, mantener sincronizados y confiar en que estén de acuerdo entre sí. El resto de esta serie se construye sobre esa base: preparación del clúster, Gateway API, redacción de network policies y anuncio de rutas BGP.