⏱️ Lectura: 10 min
Si en los últimos años escuchaste hablar de eBPF sin terminar de entender qué es, no estás solo. eBPF es una de las tecnologías más importantes del Linux moderno y, al mismo tiempo, una de las más invisibles para quien no trabaja con infraestructura. En esta guía completa de eBPF en 2026 vamos a desmenuzar qué es, cómo funciona por dentro, qué problemas resuelve y por qué empresas como Netflix, Meta, Google y Cloudflare lo usan para correr gran parte de su infraestructura sin que sus usuarios se enteren.
📑 En este artículo
La promesa de eBPF es enorme: ejecutar código propio dentro del kernel de Linux, con garantías de seguridad y a velocidad casi nativa, sin modificar el código del kernel ni cargar módulos. Dicho así suena a magia. Pero cuando entiendas la mecánica, vas a darte cuenta de que eBPF es, sobre todo, una idea elegante llevada hasta sus últimas consecuencias.
¿Qué es eBPF?
eBPF significa extended Berkeley Packet Filter. El nombre suena intimidante y además es engañoso: aunque nació en 1992 como un filtro para capturar paquetes de red (de ahí el BPF original), hoy no tiene mucho que ver con eso. eBPF es una máquina virtual integrada dentro del kernel de Linux que permite ejecutar pequeños programas, escritos en un dialecto de C o Rust, en respuesta a eventos del sistema: una syscall que se dispara, un paquete que llega por la tarjeta de red, una función del kernel que se ejecuta, un archivo que se abre.
La analogía que suele funcionar es pensar en JavaScript dentro del navegador. Nadie recompila Chrome cada vez que quiere ejecutar un script en una página: el navegador carga JavaScript, lo valida, lo compila y lo corre de forma segura. eBPF hace exactamente lo mismo, pero dentro del kernel. Eso significa que podemos observar, medir, filtrar o incluso modificar el comportamiento del sistema operativo en caliente, sin reiniciar nada y sin tocar el código fuente del kernel.
💭 Clave: eBPF es al kernel de Linux lo que JavaScript es al navegador: una manera segura de ejecutar lógica propia dentro de un entorno que antes era intocable.
Cómo funciona eBPF por dentro
Para entender el verdadero superpoder de eBPF, hay que mirar qué pasa cuando cargás un programa. El flujo tiene cinco etapas, todas orquestadas por el propio kernel:
- Escritura: el desarrollador escribe el programa en C (o Rust, Go con cilium/ebpf, etc.) y lo compila a bytecode eBPF con Clang/LLVM.
- Carga: una aplicación en userspace usa la syscall
bpf()para enviar ese bytecode al kernel. - Verificación: el verifier del kernel analiza el bytecode estáticamente. Rechaza cualquier programa que pueda entrar en un loop infinito, acceder a memoria inválida, hacer punteros sin chequear o tardar más de lo permitido.
- JIT: si pasa la verificación, un compilador just-in-time traduce el bytecode a código nativo de la arquitectura (x86_64, ARM64, etc.) para que corra a velocidad casi igual al kernel compilado.
- Ejecución: el programa queda attached a un punto del kernel (un tracepoint, un kprobe, un hook de red, un uprobe en userspace, etc.) y se ejecuta cada vez que ese evento ocurre.
La joya de la corona es el verifier. Sin él, eBPF sería una puerta abierta para que cualquier programa tumbe la máquina. Gracias al verifier, Linux garantiza que un programa eBPF no puede colgar el kernel, ni leer memoria arbitraria, ni quedarse corriendo eternamente. Esa garantía es lo que hace que administradores y empresas acepten ejecutar código de terceros dentro del corazón del sistema operativo.
graph LR;
A[Código C/Rust] --> B[Clang/LLVM];
B --> C[Bytecode eBPF];
C --> D[Syscall bpf];
D --> E[Verifier];
E --> F[JIT Compiler];
F --> G[Hook del kernel];
G --> H[Mapa eBPF];
H --> I[Userspace]
Los programas eBPF no viven aislados: se comunican con userspace a través de mapas (estructuras de datos como hash tables, arrays, ring buffers) que permiten pasar información en ambos sentidos. Así una aplicación puede leer en vivo lo que un programa eBPF está observando dentro del kernel, o empujar configuración hacia él sin recargar nada.
Ejemplos prácticos de eBPF
La forma más rápida de probar eBPF en 2026 es usando bcc o bpftrace, dos proyectos que exponen la potencia de eBPF detrás de interfaces amigables. Veamos tres ejemplos reales.
Contar llamadas a una syscall en tiempo real
Con bpftrace podemos escribir programas eBPF en un lenguaje muy parecido a awk. Este one-liner cuenta cuántas veces cada proceso llama a la syscall openat (es decir, cada vez que se abre un archivo):
sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat { @[comm] = count(); }'Al pulsar Ctrl+C, bpftrace imprime una tabla con los procesos más activos abriendo archivos. Esto, que parece trivial, es imposible de hacer con la misma eficiencia y sin afectar el rendimiento sin eBPF.
Latencia de lecturas al disco
Otro clásico: medir cuánto tarda cada lectura al disco y generar un histograma. bcc incluye la herramienta biolatency:
sudo biolatency-bpfcc 5 1
Tracing block device I/O... Hit Ctrl-C to end.
usecs : count distribution
0 -> 1 : 0 | |
128 -> 255 : 42 |****** |
256 -> 511 : 311 |*********************************** |
512 -> 1023 : 168 |******************* |Con eso sabés, en producción y en vivo, si tu disco está respondiendo bien o hay colas inesperadas.
Bloqueo de tráfico con XDP
XDP (eXpress Data Path) es el punto más temprano donde se puede enganchar eBPF: justo cuando un paquete entra por la tarjeta de red, antes de que el kernel siquiera lo procese. Esto permite construir un firewall o DDoS mitigator que descarta paquetes maliciosos a velocidad de línea, con costo de CPU ínfimo.
SEC("xdp")
int xdp_drop_port(struct xdp_md *ctx) {
void *data = (void *)(long)ctx->data;
void *data_end = (void *)(long)ctx->data_end;
struct ethhdr *eth = data;
if ((void *)(eth + 1) > data_end) return XDP_PASS;
if (eth->h_proto != htons(ETH_P_IP)) return XDP_PASS;
struct iphdr *ip = (struct iphdr *)(eth + 1);
if ((void *)(ip + 1) > data_end) return XDP_PASS;
if (ip->protocol == IPPROTO_TCP) {
struct tcphdr *tcp = (struct tcphdr *)((__u8 *)ip + ip->ihl * 4);
if ((void *)(tcp + 1) > data_end) return XDP_PASS;
if (tcp->dest == htons(23)) return XDP_DROP;
}
return XDP_PASS;
}Este programa corta cualquier paquete TCP dirigido al puerto 23 (telnet) antes de que el kernel lo mire. En servidores reales, XDP puede descartar decenas de millones de paquetes por segundo por núcleo.
Casos de uso reales de eBPF
La explosión de eBPF se explica mejor mirando qué herramientas de producción lo usan hoy. Todas son open source y, juntas, mueven una porción enorme del tráfico mundial:
- Cilium — Red y seguridad para Kubernetes. Reemplaza iptables y kube-proxy por programas eBPF, logrando menos latencia y políticas mucho más finas. Es el CNI por defecto en Google GKE Dataplane V2 y en buena parte de los clústeres en 2026.
- Katran — El balanceador de carga de Meta. Maneja el tráfico de Facebook e Instagram con eBPF + XDP, reemplazando IPVS. Maneja millones de conexiones por segundo por nodo.
- Pixie — Observabilidad auto-instrumented. Te muestra requests HTTP, queries a MySQL, llamadas gRPC, sin tocar una línea de tu aplicación. Compra del equipo de New Relic.
- Falco — Runtime security. Detecta comportamiento sospechoso (un shell dentro de un contenedor, un binario ejecutándose desde
/tmp) usando eBPF para observar syscalls. - Parca y Polar Signals — Profiling continuo de CPU en todo el fleet, con overhead prácticamente nulo gracias a eBPF.
- Cloudflare usa eBPF para mitigar ataques DDoS, balancear tráfico y aplicar reglas de firewall en el edge.
💡 Tip: Si usás Kubernetes en 2026 y querés entender dónde están los cuellos de botella de red sin agregar sidecars, empezá probando cilium hubble. Es la forma más amable de ver eBPF aplicado.
Ventajas y desventajas de eBPF
Ventajas
- Rendimiento: el código corre dentro del kernel, con compilación JIT nativa. Para casos como XDP, es la forma más rápida de tocar paquetes en Linux.
- Seguridad: el verifier impide programas peligrosos; no podés tirar el kernel por accidente como sí pasaba con los módulos tradicionales.
- Sin reinicios: cargás y descargás programas en caliente. No hay downtime para probar un nuevo hook.
- Visibilidad: podés observar literalmente cualquier evento del kernel, lo que transformó la observabilidad en los últimos cinco años.
- Ecosistema maduro: bcc, bpftrace, libbpf, cilium/ebpf (Go), Aya (Rust), Pixie, Falco. En 2026 hay tooling sólido para casi cualquier lenguaje.
Desventajas
- Curva de aprendizaje: entender el verifier, los mapas, los helpers y los tipos de programa lleva tiempo.
- Dependencia del kernel: algunos hooks requieren versiones recientes. En servidores muy viejos, te vas a topar con límites.
- Depuración: un verifier que rechaza tu programa con un mensaje críptico es frustrante. Afortunadamente,
BPF CO-REy mejoras recientes suavizan esto. - Sólo Linux: Windows tiene una implementación propia (eBPF for Windows), pero madura muchísimo más lento que la de Linux.
📖 Resumen en Telegram: Ver resumen
Preguntas frecuentes
¿eBPF reemplaza a los módulos del kernel?
Para la mayoría de los casos, sí. Si lo único que querías era observar, filtrar o decidir sobre eventos, eBPF es mejor: más seguro, más portable y cargable en caliente. Los módulos siguen siendo necesarios cuando hace falta agregar lógica que eBPF no puede expresar (por ejemplo, drivers de hardware nuevos).
¿Qué lenguaje se usa para escribir eBPF?
Históricamente C con Clang/LLVM. En 2026 hay excelentes opciones en Rust (Aya), Go (cilium/ebpf) y scripts con bpftrace. Internamente todo termina compilando a bytecode eBPF.
¿eBPF es solo para redes?
No. Empezó en redes, pero hoy se usa para observabilidad, profiling, seguridad, tracing, scheduling e incluso para acelerar sistemas de archivos. Cualquier evento del kernel es un potencial hook.
¿Necesito privilegios de root para usar eBPF?
Históricamente sí. Desde Linux 5.8 existe la capacidad CAP_BPF que permite cargar programas sin ser root pleno. Aun así, cargar eBPF sigue siendo una acción privilegiada y debés tratarlo como tal.
¿En qué distros funciona?
En cualquier Linux moderno: Ubuntu 22.04+, Debian 12+, Fedora, Alpine, Amazon Linux 2023. Para features avanzadas como BPF CO-RE conviene un kernel 5.8 o superior; en 2026 eso ya es el estándar.
¿Cuál es la mejor forma de empezar?
Instalar bpftrace y jugar con one-liners. En paralelo, leer el libro de Liz Rice sobre eBPF (O’Reilly) y probar el tutorial oficial en ebpf.io. Si tu foco es Kubernetes, el camino corto es levantar un cluster con Cilium y explorar Hubble.
Referencias
- ebpf.io — Sitio oficial del proyecto eBPF con documentación, tutoriales y casos de estudio.
- Documentación de Cilium — El proyecto que popularizó eBPF en Kubernetes; referencia obligada para networking y seguridad.
- iovisor/bcc en GitHub — Colección de herramientas y frontends para construir programas eBPF.
- Documentación oficial del kernel de Linux — La referencia técnica definitiva sobre cómo funciona eBPF internamente.
- eBPF en Wikipedia — Visión general e historia del proyecto, con enlaces a papers y timeline de features.
📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.
0 Comentarios