Cilium y el futuro de la red de contenedores con eBPF

javi
Visualización de red de datos entre nodos distribuidos

Cilium es el proyecto que está redefiniendo cómo funcionan las redes en Kubernetes. A diferencia de CNIs tradicionales como Calico o Flannel que se apoyan en iptables, Cilium reemplaza gran parte del stack de red con programas eBPF cargados en el kernel. El resultado: rendimiento significativamente mejor, visibilidad más profunda y políticas de seguridad más expresivas.

El problema con iptables

iptables ha sido el estándar de red en Linux desde 1998. En clusters K8s pequeños funciona bien. En clusters grandes, es un cuello de botella medible:

  • Escalado O(n). Cada regla nueva añade una entrada al final de la cadena. Con 5.000 servicios, cada paquete pasa por miles de comparaciones.
  • Actualizaciones costosas. Cambiar una regla requiere recrear toda la cadena, con impacto en el rendimiento durante el cambio.
  • Debugging opaco. Seguir por qué un paquete específico se aceptó o descartó requiere habilidad profunda.

kube-proxy en modo iptables refleja estos problemas: con miles de servicios, la CPU de los nodos se satura solo gestionando reglas.

Qué hace Cilium diferente

Cilium carga programas eBPF en puntos de hook del kernel (XDP, tc, socket, cgroup). Cuando un paquete llega:

  • El programa eBPF lo procesa directamente en el kernel, sin pasar por el stack de networking convencional.
  • Lookups en tablas hash O(1) reemplazan las cadenas lineales de iptables.
  • Sin copia de datos entre espacio de usuario y kernel para operaciones de red.

Concretamente, los benchmarks muestran:

  • Reducción de latencia: 30-50% menos latencia p95 vs iptables en cargas de servicio mesh.
  • Mayor throughput: 2-3x paquetes/segundo en nodos grandes.
  • Menor consumo de CPU: hasta 70% menos CPU kernel en clusters con miles de servicios.

Funcionalidades más allá del CNI básico

Cilium va mucho más allá de “red de pods”. Capacidades adicionales relevantes:

Políticas de red L7

Cilium puede aplicar políticas no solo por IP/puerto (L3/L4) sino por contenido de aplicación (L7). Por ejemplo:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: "allow-frontend-api"
spec:
  endpointSelector:
    matchLabels:
      app: api
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: frontend
    toPorts:
    - ports:
      - port: "80"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"

Esto deniega por defecto cualquier POST o path fuera de /api/v1/. Con iptables esta granularidad no es posible — requeriría un proxy adicional.

Observabilidad integrada (Hubble)

Hubble es la capa de observabilidad de Cilium. Muestra en tiempo real qué paquetes se procesan, qué políticas se aplican, qué conexiones se establecen. Un dashboard que reemplaza gran parte del trabajo que antes exigía tcpdump + conntrack.

Cifrado transparente

Cilium puede cifrar todo el tráfico pod-a-pod con WireGuard o IPsec, activado con un flag. Sin service mesh adicional.

Modo ambient mesh (Istio integration)

En 2023, Istio lanzó ambient mesh que elimina sidecars usando ztunnel + waypoint. Cilium se integra como CNI que hace posible parte de ese diseño, con rendimiento que sidecars tradicionales no podían igualar.

Cuándo adoptar Cilium

Cilium tiene sentido claro cuando:

  • Clusters K8s grandes (>50 nodos, >1000 servicios). Los beneficios de escala se notan.
  • Service mesh sin sidecars. Si estabas considerando Istio tradicional, Cilium con Hubble + políticas L7 puede sustituir gran parte.
  • Requisitos de seguridad estrictos. Políticas L7, cifrado transparente, identidad fuerte entre servicios.
  • Observabilidad profunda necesaria. Hubble da visibilidad que otros CNIs no ofrecen nativamente.

Casos donde puede no compensar:

  • Clusters pequeños (<20 nodos). El overhead operativo de Cilium supera los beneficios.
  • Kernel antiguo (<4.19). Sin kernel moderno, las features eBPF están limitadas.
  • Equipos sin experiencia con eBPF. El debugging de Cilium requiere comprensión de eBPF — curva de aprendizaje real.

Migración desde otro CNI

Migrar de Calico o Flannel a Cilium no es trivial, pero el proceso está bien documentado. Pasos típicos:

  1. Prueba en staging con un node pool dedicado.
  2. Rolling deployment reemplazando Calico nodo a nodo (la app debe tolerar la reconexión breve por pod).
  3. Validación de políticas de red existentes — sintaxis es similar pero hay diferencias sutiles.
  4. Activación gradual de features avanzadas (Hubble, cifrado, L7 policies) tras estabilización.

Organizaciones como Datadog, Adobe, Bell Canada y la propia AWS en su servicio EKS han documentado migraciones exitosas.

Relacionado, ver nuestra cobertura de Pixie para observabilidad K8s y eBPF como tecnología de monitorización — ambos se apoyan en los mismos primitives del kernel.

Conclusión

Cilium no es solo otro CNI: es un cambio arquitectónico que pone eBPF en el centro del networking de Kubernetes. Para clusters grandes o con requisitos avanzados de seguridad/observabilidad, es difícil justificar no adoptarlo. Para clusters pequeños, la recomendación es conocer el proyecto y estar preparado para la transición cuando el crecimiento lo justifique.

Síguenos en jacar.es para más sobre eBPF, Kubernetes y arquitectura de plataformas cloud-native.

Entradas relacionadas