eBPF: perguntando ao kernel o que está acontecendo

Por que tanta ferramenta nova de observabilidade, rede e segurança fala em eBPF? Porque ele permite rodar pequenos programas dentro do kernel Linux, com segurança, sem reiniciar nada e sem mexer na aplicação.

Fala pessoal, tudo bem?

Se você acompanha o ecossistema cloud native, já viu a sigla em todo canto: CNIs como o Cilium, ferramentas de segurança como Falco e Tetragon, perfis contínuos de CPU, monitoramento de rede. Quase tudo que é novo nessas áreas usa eBPF.

A ideia em uma imagem

ESPAÇO DE USUÁRIO Seu programa eBPF bpftrace, Cilium, Falco Resultado métricas, eventos, alertas KERNEL Verificador é seguro? termina? Anexado a um evento syscall, rede, função Mapas eBPF dados compartilhados Se o verificador não aprovar, o programa nem carrega. É isso que torna o eBPF seguro o bastante para rodar em produção.

Uma analogia: o eBPF é para o kernel o que o JavaScript foi para o navegador. Em vez de esperar a próxima versão para ganhar um recurso, você "programa" o comportamento dele em tempo real, numa área isolada.

Por que isso mudou a observabilidade

O jeito tradicional de observar uma aplicação é instrumentar: adicionar biblioteca, log, métrica, e fazer deploy. Com eBPF, dá para observar por fora, a partir do kernel, porque toda aplicação, em qualquer linguagem, acaba fazendo chamadas de sistema.

• Sem alterar código e sem reiniciar o serviço.
• Baixo custo: o programa roda dentro do kernel, sem copiar tudo para fora.
• Visão completa: todos os processos e containers da máquina, de uma vez.

Exemplo: experimentando com bpftrace

O bpftrace é o jeito mais fácil de sentir o poder do eBPF. No Debian/Ubuntu:

$ sudo apt install bpftrace

# quais arquivos cada processo está abrindo, em tempo real
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_openat
    { printf("%-16s %s\n", comm, str(args->filename)); }'

# quais comandos estão sendo executados na máquina
$ sudo bpftrace -e 'tracepoint:syscalls:sys_enter_execve
    { printf("%-16s %s\n", comm, str(args->filename)); }'

# quem mais faz chamadas de sistema (Ctrl+C para ver o resumo)
$ sudo bpftrace -e 'tracepoint:raw_syscalls:sys_enter { @[comm] = count(); }'

Rode o segundo e, em outro terminal, faça um kubectl apply ou um apt update. Você vai ver cada processo que nasce, inclusive os que rodam dentro de containers.

💡 Ótimo para o lab: rode o exemplo de execve num node do seu cluster kind e crie um pod. Dá para ver o runtime de container, o pause container e a sua aplicação nascendo, um processo de cada vez.

Onde você já usa eBPF sem saber

Área	O que o eBPF faz
Rede no Kubernetes	Roteamento e políticas de rede sem depender de milhares de regras iptables
Segurança em runtime	Detectar shell aberto em container, leitura de arquivo sensível
Observabilidade	Latência de rede, perfil de CPU contínuo, métricas sem instrumentar
Systemd	Filtros de rede e de dispositivos por serviço

⚠️ Poder exige cuidado: carregar programas eBPF exige privilégio alto. Uma ferramenta eBPF mal-intencionada vê tudo o que acontece na máquina. Avalie bem o que você instala com esse nível de acesso.

Considerações Finais

O eBPF é uma das mudanças mais importantes do Linux nos últimos anos, e quase invisível para quem só usa as ferramentas. Não precisa virar especialista: entender o conceito e brincar com o bpftrace já muda a forma como você investiga problemas.

Na próxima vez que alguém disser "não dá para saber o que esse processo está fazendo", você vai saber que dá.

Abs e até a próxima!!!

:wq!