Cilium Service Mesh: cuando no necesitas sidecars

Actualizado: 2026-05-03

Cilium^[1] empezó como CNI basado en eBPF y evolucionó hasta ser una alternativa completa a service meshes tradicionales — sin sidecars. Su arquitectura aprovecha que eBPF puede hacer policy, observabilidad y encryption en el kernel, sin proxy por pod. Para clusters grandes, el ahorro de recursos es significativo. Istio respondió con Ambient Mode (filosofía similar). 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 L7 policies (verbs HTTP, paths), 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 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 per-pod-identity es mejor.

L7 policies

Para traffic que requiere L7 (HTTP verbs, paths), 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.

Resource comparisons

Benchmark orientativo (cluster 100 nodos, 1000 pods):

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

Cuándo elegir Cilium

Buenos fits:

• 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 Cilium

• Cluster pequeño donde los sidecars no son un problema real.
• Ya corriendo Istio con features 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 en 2024, señalando validación enterprise pero también potential vendor push. La alternativa open-source sigue funcionando sin dependencia comercial.

Conclusión

Cilium representa una evolución genuina del service mesh: sidecarless, eBPF-native, integrado con CNI. Para clusters grandes y equipos con capacidad técnica, ofrece ventajas reales en recursos y features. No es la elección correcta para todos: Linkerd sigue siendo válido para simplicidad, Istio clásico para feature-completeness, Istio Ambient como alternativa sidecarless con diferentes 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 equipo, no en la moda.

1. Cilium
2. Isovalent