Cilium Service Mesh: cuando no necesitas sidecars

Actualizado: 2026-07-07

Cilium^[1] empezó como CNI basado en eBPF y evolucionó hasta ser una alternativa completa a los service meshes tradicionales, sin sidecars. Su arquitectura aprovecha que eBPF puede aplicar políticas, dar observabilidad y cifrar tráfico directamente en el kernel, sin un proxy por pod. Para clusters grandes el ahorro de recursos es considerable. Istio respondió con Ambient Mode, una filosofía parecida. Este artículo compara el enfoque sidecarless y cuándo elegir cada uno.

Puntos clave

• Cilium elimina el overhead de sidecar usando eBPF en kernel: ~5 GB de RAM overhead total en un cluster de 100 nodos frente a ~100 GB del Istio clásico.

• La encriptación WireGuard por nodo es menos granular que mTLS por servicio pero mucho más eficiente.

• Para políticas L7 (verbos y rutas HTTP), Cilium arranca un Envoy por nodo bajo demanda, no por pod.

• Hubble es la capa de observabilidad integrada: flujos, mapas de dependencias y policy verdicts sin herramientas adicionales.

• Cilium tiene más camino recorrido en sidecarless que Istio Ambient (GA 2023 vs GA 2024).

El problema de los sidecars

El modelo sidecar tradicional (Linkerd, Istio clásico) tiene costes reales:

• Un Envoy/linkerd-proxy por pod.

• Overhead de recursos: 50-200 MB RAM + CPU por pod.

• Latencia adicional: 2-5ms round-trip.

• Complejidad operacional: muchos procesos, lifecycle management.

En clusters con miles de pods multiplicado por sidecar, los números son significativos. La comparación con Linkerd que ya usa un proxy Rust más ligero sigue siendo relevante: Linkerd ~10 GB overhead en 100 nodos, Cilium ~5 GB. El tema se profundiza en service mesh Istio vs Linkerd.

El enfoque Cilium

Cilium reemplaza sidecar proxies con:

• eBPF en kernel para policy y encryption simple.

• Envoy centralizado por nodo para L7 features complejas (solo donde se usan).

• Hubble para observabilidad nativa.

• Integración CNI: Cilium es tanto CNI como service mesh en una sola pieza.

El resultado: features comparables con menos overhead.

mTLS con eBPF

Cilium encripta tráfico entre nodos con WireGuard (simple y rápido) o IPsec (más compatible), sin inyección de sidecars:

apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: enforce-encryption
spec:
  endpointSelector: {}
  ingress:
    - fromEntities:
        - cluster

WireGuard por nodo, no por pod. Menos granular que mTLS por servicio pero más eficiente. Para multi-tenant estricto con identidad por pod, Istio Ambient con mTLS por identidad de pod es mejor.

Políticas L7

Para el tráfico que requiere L7 (verbos y rutas HTTP), Cilium arranca un Envoy por nodo (no por pod) bajo demanda:

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

Hubble: observabilidad integrada

Hubble es la capa de observabilidad de Cilium:

• Flow logs detallados por conexión.

• Mapas de dependencias de servicios (quién habla con quién).

• Policy verdicts (por qué un request fue permitido o denegado).

• Integración con Prometheus y Grafana.

Equivalente funcional a Kiali + linkerd-viz pero integrado sin herramientas adicionales.

Cilium vs Istio Ambient

Istio Ambient Mode (GA en 2024) responde a la crítica de sidecars con ztunnel por nodo y Waypoint proxy opcional:

Cilium tiene más camino recorrido en sidecarless. Istio Ambient es más nuevo pero hereda el ecosistema maduro de Istio.

Comparativa de recursos

Benchmark orientativo (cluster 100 nodos, 1000 pods):

Números aproximados que dependen mucho de la configuración específica.

Cuándo elegir Cilium

Encaja bien en estos casos:

• Clusters grandes (más de 500 pods) donde el overhead de sidecar importa.

• Equipos con experiencia en eBPF o dispuestos a invertir en aprenderla.

• Greenfield Kubernetes sin CNI legacy instalado.

• Necesidad de L7 policy con alto throughput.

• Multi-cluster con requisitos de conectividad avanzados.

Cuándo no elegir Cilium

• Cluster pequeño donde los sidecars no son un problema real.

• Ya tienes Istio en producción con funciones complejas: migrar no compensa.

• Equipo sin experiencia en networking de bajo nivel.

• Requisitos de identidad por pod muy finos (prefer Istio Ambient).

• Cambiar el CNI en un cluster existente es un proyecto disruptivo en sí mismo.

Ecosistema comercial

Isovalent^[2] (empresa detrás de Cilium) fue adquirida por Cisco, anunciado en diciembre de 2023 y cerrado en abril de 2024, lo que valida el proyecto a nivel empresarial pero también abre la puerta a que el proveedor empuje su propia agenda comercial. La alternativa open-source sigue funcionando sin dependencia de Cisco.

Conclusión

Cilium representa una evolución genuina del service mesh: sidecarless, nativo en eBPF, integrado con CNI. Para clusters grandes y equipos con capacidad técnica, ofrece ventajas reales en recursos y funciones. No es la elección correcta para todos. Linkerd sigue siendo válido por su simplicidad, Istio clásico por lo completo de sus funciones, e Istio Ambient como alternativa sidecarless con otros trade-offs. La elección del service mesh en 2024 tiene más opciones maduras que nunca; la decisión debe basarse en tu contexto técnico y tu equipo, no en la moda.

¿Lees en inglés? Versión completa: Cilium Service Mesh: When You Don’t Need Sidecars.

Fuentes:

1. Cilium — página oficial de Service Mesh^[1]
2. Istio — Ambient Mode alcanza disponibilidad general en la versión 1.24^[3]
3. Cisco Newsroom — Cisco adquiere Isovalent para el futuro de las redes multicloud^[4]
4. CNCF — página del proyecto Cilium^[5]

Fuentes

1. Cilium
2. Isovalent
3. Istio — Ambient Mode alcanza disponibilidad general en la versión 1.24
4. Cisco Newsroom — Cisco adquiere Isovalent para el futuro de las redes multicloud
5. CNCF — página del proyecto Cilium