eBPF y observability en Kubernetes: monitoreo profundo de microservicios sin modificar el código

Introducción: eBPF — una revolución en la observabilidad

El enfoque tradicional de observability en Kubernetes giraba en torno a agentes sidecar, instrumentación del código y soluciones APM pesadas. Cada microservicio requería la adición manual de SDKs, configuración del tracing y un contenedor agente adicional junto al principal. En 2026, este enfoque cede cada vez más terreno a una tecnología revolucionaria: eBPF (extended Berkeley Packet Filter).

eBPF permite ejecutar código seguro y verificado directamente en el kernel de Linux sin modificar su código fuente ni reiniciar el sistema. Para Kubernetes y los microservicios, esto significa una observabilidad profunda a nivel de syscall, red y CPU, sin cambiar una sola línea del código de la aplicación. Las herramientas basadas en eBPF recopilan telemetría a nivel de kernel y la transmiten al espacio de usuario con un overhead mínimo.

eBPF hace por Linux lo que JavaScript hizo por los navegadores: permite ampliar dinámicamente las capacidades del kernel sin modificarlo. — Brendan Gregg

Cómo funciona eBPF en el contexto de Kubernetes

En un entorno Kubernetes, cada Pod opera en un espacio de nombres Linux aislado (network namespace, PID namespace). Los programas eBPF cargados en el kernel se adjuntan a distintos puntos de rastreo:

• kprobes/kretprobes — interceptación de llamadas a funciones del kernel
• tracepoints — puntos de rastreo estáticos en el kernel
• XDP (eXpress Data Path) — interceptación de paquetes de red a nivel de tarjeta de red
• tc (traffic control) — interceptación de tráfico a nivel del stack de red
• uprobe — rastreo de funciones en el espacio de usuario

La ventaja clave en el contexto de Kubernetes es que un único agente eBPF por nodo (DaemonSet) cubre todos los pods de ese nodo. No se necesita un contenedor sidecar separado para cada microservicio. Esto reduce el consumo de CPU y memoria varias veces y simplifica la gestión operativa.

Los programas eBPF utilizan estructuras de datos especiales denominadas maps para intercambiar información entre el kernel y el espacio de usuario. Los datos sobre llamadas al sistema, conexiones de red, latencias y errores se recopilan en tiempo real y se exportan en formatos compatibles con Prometheus, OpenTelemetry y Grafana.

Herramientas basadas en eBPF: Cilium, Hubble, Pixie, Tetragon

Cilium

Cilium es un plugin CNI (Container Network Interface) para Kubernetes construido completamente sobre eBPF. Reemplaza las reglas tradicionales de iptables por programas eBPF, ofreciendo mayor rendimiento y flexibilidad en las políticas de red. Cilium admite políticas L3/L4/L7, cifrado WireGuard/IPsec e integración con service meshes sin sidecar Envoy.

Hubble

Hubble es la capa de observability sobre Cilium. Proporciona visibilidad completa de los flujos de red entre servicios: quién se comunica con quién, qué endpoints HTTP se invocan, dónde aparecen latencias y errores. Hubble funciona sin modificar el código de las aplicaciones y sin sidecar: toda la información se extrae de los programas eBPF de Cilium.

Pixie

Pixie (de New Relic, open-source) es una plataforma de observability basada en eBPF para Kubernetes. Soporta detección automática de protocolos (HTTP/2, gRPC, MySQL, PostgreSQL, Redis), rastreo de solicitudes y profiling de CPU. Utiliza su propio lenguaje de consultas PxL, similar a Python/pandas. Pixie opera completamente in-cluster y no envía datos al exterior por defecto.

Tetragon

Tetragon, de Isovalent, es una herramienta de runtime security y observability basada en eBPF. Ofrece visibilidad a nivel de syscall, ejecución de procesos, conexiones de red y acceso a archivos. Puede aplicar políticas de seguridad directamente en el kernel, bloqueando acciones sospechosas en tiempo real.

Comparando las herramientas: Cilium+Hubble es la mejor opción para observability de red y políticas; Pixie, para un inicio rápido con un stack completo sin configuración; Tetragon, para escenarios de seguridad y compliance. En producción en 2026, es habitual utilizarlos los tres en conjunto.

Práctica: instalación de Cilium y Hubble en un clúster Kubernetes

La instalación de Cilium mediante Helm es el camino estándar para un clúster de producción. Asegúrese de que la versión del kernel de Linux sea al menos 5.4 (se recomienda 5.15+).

# Añadimos el repositorio Helm de Cilium
helm repo add cilium https://helm.cilium.io/
helm repo update

# Instalamos Cilium con Hubble habilitado
helm install cilium cilium/cilium \
  --version 1.15.0 \
  --namespace kube-system \
  --set hubble.enabled=true \
  --set hubble.relay.enabled=true \
  --set hubble.ui.enabled=true \
  --set hubble.metrics.enabled="{dns,drop,tcp,flow,port-distribution,icmp,httpV2}" \
  --set kubeProxyReplacement=true \
  --set k8sServiceHost=YOUR_API_SERVER_IP \
  --set k8sServicePort=6443

Tras la instalación, verificamos el estado de Cilium:

# Verificación del estado de los agentes
kubectl -n kube-system get pods -l app.kubernetes.io/name=cilium

# Verificación mediante cilium CLI
cilium status --wait

# Verificación de Hubble
cilium hubble port-forward &
hubble status
hubble observe --follow

La UI de Hubble es accesible mediante port-forward:

kubectl port-forward -n kube-system svc/hubble-ui 12000:80

En el navegador, en la dirección http://localhost:12000, verá el grafo de dependencias entre servicios en tiempo real: qué pods se comunican, por qué puertos y con qué códigos de respuesta HTTP. Esto funciona para cualquier microservicio sin ningún cambio en su código.

Ejemplo de NetworkPolicy a nivel L7 mediante Cilium CRD:

apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: allow-api-to-backend
  namespace: production
spec:
  endpointSelector:
    matchLabels:
      app: backend-service
  ingress:
  - fromEndpoints:
    - matchLabels:
        app: api-gateway
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/.*"
        - method: "POST"
          path: "/api/v1/orders"

Profiling de microservicios Go mediante eBPF: continuous profiling

El profiling de servicios Go en producción ha sido históricamente doloroso: el pprof integrado requería habilitar explícitamente un endpoint HTTP, y el continuous profiling consumía recursos considerables. eBPF cambia esto de forma radical.

Parca y Pyroscope (ahora parte del Grafana Stack como Grafana Pyroscope) utilizan eBPF para el profiling continuo de CPU sin instrumentar el código. Capturan periódicamente stack traces mediante programas eBPF adjuntos a perf_event y construyen flame graphs en tiempo real.

Instalación de Pyroscope mediante Helm:

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm install pyroscope grafana/pyroscope \
  --namespace monitoring \
  --create-namespace \
  --set pyroscope.components.querier.resources.limits.memory=512Mi

Instalación de Grafana Alloy (agente) con profiling eBPF:

helm install alloy grafana/alloy \
  --namespace monitoring \
  --set alloy.configMap.content='
pyroscope.ebpf "ebpf_profiler" {
  targets = discovery.kubernetes.pods.targets
  forward_to = [pyroscope.write.default.receiver]
}

pyroscope.write "default" {
  endpoint {
    url = "http://pyroscope:4040"
  }
}

discovery.kubernetes "pods" {
  role = "pod"
}'

Para los servicios Go, el profiler eBPF desenrolla automáticamente los stack traces utilizando la información de depuración DWARF o los frame pointers. A partir de Go 1.21, los frame pointers están habilitados por defecto, lo que mejora significativamente la calidad de los perfiles. Los flame graphs en Grafana permiten ver qué funciones del microservicio consumen más CPU, sin modificar una sola línea del código del servicio.

Importante: para un profiling correcto de binarios Go mediante eBPF, se recomienda compilar con el flag -gcflags="all=-trimpath" y asegurarse de que el binario no esté stripped (o que los símbolos estén disponibles por separado).

Seguridad mediante eBPF: Tetragon y runtime security

Tetragon lleva la runtime security a un nuevo nivel. En lugar de analizar logs o eventos post-factum, opera in-kernel: los programas eBPF interceptan las llamadas al sistema y pueden tanto registrarlas como bloquearlas en tiempo real.

Instalación de Tetragon:

helm repo add cilium https://helm.cilium.io/
helm install tetragon cilium/tetragon \
  --namespace kube-system \
  --set tetragon.grpc.address="localhost:54321"

Ejemplo de TracingPolicy para detectar la ejecución de binarios sospechosos:

apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: detect-shell-execution
spec:
  kprobes:
  - call: "sys_execve"
    syscall: true
    args:
    - index: 0
      type: "string"
    selectors:
    - matchArgs:
      - index: 0
        operator: "Postfix"
        values:
        - "/sh"
        - "/bash"
        - "/python3"
      matchActions:
      - action: Sigkill

Esta política termina automáticamente el proceso si se lanza un shell dentro del contenedor, señal clásica de un ataque. Tetragon exporta eventos en formato JSON compatible con sistemas SIEM (Elastic, Splunk). La integración con Falco y OPA permite construir una protección multicapa.

En el contexto de Kubernetes, Tetragon observa cada fork/exec, cada conexión de red y cada operación sobre el sistema de archivos dentro de los pods, sin modificar los manifiestos de los deployments.

Comparación con el enfoque clásico: sidecar + OpenTelemetry

El enfoque clásico de observability en Kubernetes implica:

• Un contenedor sidecar (Envoy, agente Jaeger) en cada pod
• Instrumentación del código mediante el SDK de OpenTelemetry
• Configuración manual del tracing en cada microservicio
• Recursos adicionales: ~50-100 MB de RAM y ~0,1 CPU por pod

El enfoque basado en eBPF ofrece:

• Un único DaemonSet por nodo en lugar de sidecar en cada pod
• Instrumentación zero-code — el código de la aplicación no se modifica
• Datos desde el kernel: más completos y fiables
• Menor overhead: ~10-30 MB de RAM y ~0,05 CPU por nodo

Cuándo usar OpenTelemetry + sidecar: cuando se necesita tracing de lógica de negocio (contexto de solicitud, atributos personalizados), spans detallados dentro de un mismo servicio, o cuando se usan versiones antiguas del kernel Linux (anteriores a 5.4). En pipelines de CI/CD para pruebas de servicios, la instrumentación del código proporciona datos más precisos sobre el comportamiento interno.

Cuándo usar eBPF: para monitoreo de infraestructura, observability de red, seguridad, profiling y en situaciones donde modificar el código es indeseable o imposible (servicios de terceros, legacy). En 2026, la mejor práctica es un enfoque híbrido: eBPF para la capa de infraestructura, OpenTelemetry para el tracing de negocio.

Limitaciones de eBPF: versiones del kernel, permisos, compatibilidad

eBPF es una tecnología potente, pero con limitaciones importantes que hay que considerar en producción:

• Versión del kernel Linux: mínimo 4.9 para eBPF básico, 5.4+ para la mayoría de las funcionalidades, 5.15+ para el conjunto completo de capacidades (BTF, CO-RE). Los Kubernetes gestionados (EKS, GKE, AKS) suelen usar kernels 5.15+, pero verifique las AMI/node images específicas.
• Permisos: cargar programas eBPF requiere CAP_BPF (Linux 5.8+) o CAP_SYS_ADMIN. En Kubernetes, el agente DaemonSet debe ejecutarse con privilegios elevados, lo que exige una revisión de seguridad específica.
• Nodos Windows: eBPF for Windows existe (proyecto de Microsoft), pero está muy por detrás de la implementación en Linux. Los clústeres mixtos con nodos Windows requerirán una estrategia de observability separada.
• Verificador eBPF: los programas pasan una verificación estricta en el kernel. Los programas complejos pueden no superar la verificación en kernels antiguos debido al límite de instrucciones.
• BTF (BPF Type Format): para CO-RE (Compile Once, Run Everywhere) es necesario el soporte de BTF en el kernel (CONFIG_DEBUG_INFO_BTF=y). La mayoría de las distribuciones modernas lo incluyen por defecto.
• eBPF en Kubernetes gestionado: Fargate (EKS) y algunos node pools gestionados tienen restricciones sobre eBPF debido a la arquitectura del hipervisor.

Roadmap de observability en 2026

El ecosistema de observability basado en eBPF evoluciona rápidamente en 2026. Las tendencias clave son:

• eBPF + OpenTelemetry: el proyecto OpenTelemetry eBPF Agent (otebi) permite generar automáticamente telemetría compatible con OTLP a partir de datos eBPF, cerrando la brecha entre el nivel de kernel y el de aplicación.
• Profiling como estándar: el continuous profiling se convierte en parte fundamental de la observability junto a métricas, logs y trazas — los llamados «4 pilares» en lugar de tres.
• Detección de anomalías asistida por IA: los datos eBPF, con su alta granularidad, se convierten en la base para modelos de ML de detección de anomalías en tiempo real.
• Kubernetes Gateway API + Cilium: Cilium se convierte en implementación de referencia para Gateway API, unificando ingress, service mesh y observability en una sola solución.
• eBPF en CI/CD: uso de eBPF en entornos de prueba para construir automáticamente mapas de dependencias y detectar interacciones de red inesperadas en integration tests.

Los microservicios Go se benefician especialmente: el runtime de Go se presta bien al rastreo con eBPF, y el compilador gc desde la versión 1.21 genera frame pointers por defecto, algo crítico para el profiling de CPU de calidad mediante eBPF.

Conclusión

eBPF transforma radicalmente el enfoque de la observability en Kubernetes. La posibilidad de obtener telemetría profunda —de red, de sistema, de profiling y de seguridad— sin modificar el código de los microservicios y sin el overhead de la arquitectura sidecar convierte a eBPF en una herramienta imprescindible para ingenieros DevOps y SRE en 2026.

El camino práctico para comenzar: instale Cilium como CNI con Hubble habilitado para obtener visibilidad de red de inmediato, añada Pyroscope para el continuous profiling de servicios Go y configure Tetragon para la runtime security. Este stack cubrirá tres de los cuatro pilares de la observability sin cambiar una sola línea del código de las aplicaciones.

El enfoque clásico con OpenTelemetry no desaparece, sino que evoluciona hacia la integración con la capa eBPF, creando un modelo híbrido en el que el nivel de kernel aporta telemetría de infraestructura y el SDK aporta el contexto de negocio. Precisamente esta combinación define el futuro de la observability en arquitecturas de microservicios en la nube.