Observabilidad sin instrumentación: cómo eBPF reemplazó la flota de sidecars
Engineering Team
El 67% de los equipos de Kubernetes han cambiado a observabilidad eBPF
Según la Encuesta Anual CNCF 2026, el 67% de los equipos de Kubernetes ahora usan herramientas basadas en eBPF para al menos un pilar de observabilidad (métricas, trazas o logs) — frente al 29% en 2024 y el 41% en 2025.
La razón es simple: la observabilidad tradicional basada en sidecars (proxies Envoy, sidecars OpenTelemetry Collector, agentes Datadog) consume recursos enormes, añade latencia a cada solicitud y requiere cambios de código. eBPF hace todo desde el kernel — sin ningún cambio de aplicación.
Qué es eBPF y por qué importa
eBPF (extended Berkeley Packet Filter) es una tecnología que permite ejecutar programas sandboxed dentro del kernel Linux sin cambiar el código fuente del kernel.
Cómo funciona
- Escribir un programa pequeño en C o Rust
- Adjuntarlo a un punto de enganche del kernel — syscalls, eventos de red, tracepoints
- El verificador eBPF del kernel comprueba la seguridad del programa
- El compilador JIT traduce el bytecode eBPF a instrucciones máquina nativas
- El programa se ejecuta en el punto de enganche con rendimiento casi nativo
// Programa eBPF simplificado para rastrear solicitudes HTTP
SEC("kprobe/tcp_v4_connect")
int trace_connect(struct pt_regs *ctx) {
struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);
u32 pid = bpf_get_current_pid_tgid() >> 32;
u16 dport = sk->__sk_common.skc_dport;
u32 daddr = sk->__sk_common.skc_daddr;
struct event_t event = {
.pid = pid,
.dport = ntohs(dport),
.daddr = daddr,
.timestamp = bpf_ktime_get_ns(),
};
bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,
&event, sizeof(event));
return 0;
}
Por qué importa para la observabilidad
La observabilidad tradicional requiere instrumentación. Este enfoque tiene tres problemas fundamentales:
- Overhead de recursos — cada sidecar consume CPU y memoria. En un clúster de 500 pods con sidecars Envoy, los sidecars pueden consumir el 30-40% de los recursos totales.
- Brechas de cobertura — solo puede observar lo que instrumenta.
- Carga de mantenimiento — cada lenguaje necesita su propia biblioteca de instrumentación.
eBPF resuelve los tres: se ejecuta en el kernel (cero overhead de aplicación), ve todo lo que el kernel ve (sin brechas), y funciona independientemente del lenguaje.
El stack de observabilidad eBPF en 2026
Cilium + Hubble: observabilidad de red
Cilium es el CNI de facto para Kubernetes. Hubble proporciona:
- Visibilidad de flujos L3/L4 — cada conexión TCP/UDP entre pods
- Parsing de protocolos L7 — HTTP, gRPC, Kafka, DNS, PostgreSQL sin cambios de aplicación
- Auditoría de políticas de red — ver qué políticas permiten o deniegan tráfico en tiempo real
- Mapeo de dependencias de servicios — generación automática del grafo de servicios
Pixie: monitoreo de rendimiento de aplicaciones
Pixie (proyecto sandbox CNCF) proporciona APM sin instrumentación:
- Rastreo automático de protocolos — HTTP/1.1, HTTP/2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS
- Profiling de CPU continuo — flamegraphs desde stack traces eBPF
- Logging dinámico — agregar trace points sin redespliegue
- Captura completa de solicitud/respuesta — headers HTTP, queries SQL, payloads gRPC
Tetragon: seguridad runtime y auditoría
Tetragon (por Isovalent/Cilium):
- Seguimiento de ejecución de procesos — cada evento exec, fork y exit
- Monitoreo de acceso a archivos — rastrear lecturas, escrituras y cambios de permisos
- Auditoría de conexiones de red — registrar cada conexión saliente con contexto de proceso
- Aplicación de políticas de seguridad — bloquear actividades sospechosas en tiempo real
Grafana Beyla: auto-instrumentación
Grafana Beyla genera trazas y métricas compatibles con OpenTelemetry:
- Detecta solicitudes HTTP, gRPC, SQL y Redis a nivel de kernel
- Emite spans OpenTelemetry con propagación de contexto de traza
- Se integra con Grafana Cloud, Tempo, Mimir y cualquier backend OpenTelemetry
Rendimiento: los números que importan
Benchmarks de un clúster Kubernetes de producción de 500 pods:
Comparación de uso de memoria
| Componente | Enfoque sidecar | Enfoque eBPF | Ahorro |
|---|---|---|---|
| Sidecars Envoy (500 pods) | 50 GB | 0 (Cilium CNI) | 50 GB |
| Sidecars OTel Collector (500 pods) | 15 GB | 0 (Beyla DaemonSet) | 15 GB |
| Agentes Cilium (20 nodos) | N/A | 8 GB | -8 GB |
| Agentes Beyla (20 nodos) | N/A | 2 GB | -2 GB |
| Total | 75 GB | 12 GB | Reducción del 84% |
Overhead de CPU
| Métrica | Enfoque sidecar | Enfoque eBPF |
|---|---|---|
| Latencia añadida por solicitud | 1-5ms | <0.1ms |
| Overhead de CPU por nodo | 8-12% | <1% |
| Impacto en latencia de cola (p99) | +15-30ms | <1ms |
Guía de migración: de sidecars a eBPF
Fase 1: desplegar herramientas eBPF junto a sidecars (semanas 1-2)
- Instalar Cilium como CNI
- Desplegar Hubble para observabilidad de red
- Desplegar Beyla como DaemonSet
- Ejecutar ambos stacks en paralelo
Fase 2: validar y ajustar (semanas 3-4)
- Verificar que las herramientas eBPF capturan las mismas señales
- Ajustar la detección de protocolos de Beyla
- Configurar dashboards espejo
Fase 3: eliminar sidecars gradualmente (semanas 5-8)
- Comenzar con servicios no críticos
- Monitorear regresiones de calidad de datos
- Eliminar sidecars Envoy de servicios que no necesitan gestión de tráfico avanzada
Fase 4: stack eBPF completo (semanas 9-12)
- Eliminar sidecars restantes
- Desplegar Tetragon para seguridad runtime
- Consolidar alertas en señales eBPF
- Recuperar recursos liberados
Preguntas frecuentes
¿La observabilidad eBPF funciona con cargas no-Kubernetes?
Sí. eBPF se ejecuta a nivel del kernel Linux, funcionando con cualquier carga de trabajo.
¿eBPF puede reemplazar el tracing distribuido?
Para muchos equipos, sí. Pero las trazas eBPF están limitadas a las fronteras solicitud/respuesta.
¿Qué hay del tráfico cifrado (TLS)?
Las herramientas eBPF pueden rastrear tráfico TLS adjuntándose a funciones de la biblioteca TLS.
¿eBPF es seguro? ¿Un programa eBPF defectuoso puede crashear el kernel?
No. El verificador eBPF revisa cada programa antes de cargarlo. Un programa defectuoso fallará al cargar.
¿Cómo maneja eBPF servicios de alto throughput (100K+ solicitudes/segundo)?
Mediante agregación in-kernel y muestreo. Los programas eBPF calculan histogramas en los maps del kernel.