eBPF e Go: como observar a stack de rede do kernel sem escrever C

Em times cloud-native, o discurso é que o desenvolvedor é dono do serviço de ponta a ponta. Na prática, a visibilidade costuma parar na fronteira da aplicação. Tudo o que vem abaixo (a stack de rede do kernel Linux, o container runtime, o CNI) vira uma caixa-preta da qual o serviço depende, mas que ninguém do time consegue observar. Quando algo quebra nessa camada, o dev fica esperando outro time responder um ticket.

É esse problema que um workshop de meio período agendado para a GopherCon 2026 se propõe a atacar. Segundo a descrição oficial na agenda do evento, a sessão é conduzida por Donia Chaiehloudj e Chris Tarazi, ambos engenheiros da Isovalent (parte da Cisco, empresa por trás do Cilium). O ângulo é direto: dar a desenvolvedores Go a base para trabalhar com eBPF e a stack de rede do Linux, e então construir uma ferramenta real de observabilidade do zero.

O que é eBPF, resumindo

eBPF permite anexar pequenos programas diretamente à stack de rede do kernel Linux para observar tráfego, medir latência e rastrear falhas, tudo isso sem modificar o código da aplicação, sem adicionar sidecars e sem depender do time de infra. É a tecnologia que sustenta projetos como Cilium, Hubble e Tetragon.

Historicamente, mexer com eBPF significava escrever a parte que roda no kernel em C, compilá-la e depois amarrar isso ao seu programa em espaço de usuário. O ponto de venda do workshop é justamente cortar esse atrito: usando a biblioteca cilium/ebpf com a ferramenta bpf2go, dá para permanecer em Go o tempo todo. O bpf2go gera código Go a partir dos objetos eBPF compilados, deixando o carregamento, os mapas e a comunicação kernel-userspace com uma cara idiomática de Go.

Por que isso importa para quem escreve Go

A proposta interessa a um perfil bem específico: quem constrói tooling cloud-native (operators, CLIs, componentes de service mesh, plugins de CNI, ferramentas de segurança) e SRE-developers que querem adicionar visibilidade de rede em nível de kernel ao repertório. Não é observabilidade que você só consome via dashboard pronto; é observabilidade que você constrói.

O valor prático aparece em três frentes que a descrição destaca:

• Developer tooling: uma CLI que mostra exatamente por onde os pacotes de um pod estão passando.
• Debug de produção: quando a latência sobe e o APM não explica, olhar direto no kernel muda o jogo.
• Contribuir para infra cloud-native: entender como Cilium e Hubble funcionam por baixo dos panos é pré-requisito para colaborar nesses projetos.

O pré-requisito declarado é conforto com Go e noções básicas de rede (TCP/IP, DNS, portas, sockets) mais conceitos de Kubernetes (pods, services, namespaces). Nenhuma experiência prévia com eBPF ou kernel é exigida.

Trade-offs que vale ter em mente

eBPF não é bala de prata, e é aí que o pragmatismo entra. Alguns pontos a pesar antes de sair anexando programas ao kernel:

• Portabilidade e versão de kernel: recursos de eBPF variam conforme a versão do kernel. Programas que rodam num ambiente podem não carregar em outro mais antigo. CO-RE (Compile Once, Run Everywhere) ajuda, mas não elimina o problema.
• Curva de mental model: ficar em Go remove o C, não remove a necessidade de entender como o pacote atravessa o kernel. Sem essa intuição, você anexa a ferramenta no hook errado e mede a coisa errada.
• Quando NÃO usar: se um simples tcpdump, um log estruturado ou uma métrica de aplicação já respondem sua pergunta, eBPF é peso morto. Ele brilha quando a resposta está justamente na camada que você não controla, não como substituto de observabilidade que você já poderia ter no código.
• Ambiente de execução: carregar programas eBPF exige privilégios elevados (CAP_BPF ou root). Em clusters gerenciados com restrições fortes, isso pode esbarrar em políticas de segurança.

Para começar antes de qualquer workshop

Quem quer explorar o tema sem esperar por um evento pode partir do guia oficial do cilium/ebpf, que é o mesmo ponto de partida sugerido na preparação recomendada. Um ambiente local com Docker, Kind (para um cluster Kubernetes local) e Go 1.26+ já cobre o setup básico. A partir daí, construir uma ferramenta mínima que conta pacotes por conexão costuma ser o primeiro exercício que revela se a abstração do bpf2go faz sentido para o seu caso.

O recado central é menos sobre a linguagem e mais sobre autonomia: eBPF com Go transforma uma camada opaca da infraestrutura em algo observável pelo próprio time de aplicação. O contexto decide se essa autonomia compensa a complexidade adicional.

Fonte: Agenda oficial — Meeting Room 438, Level 4, SCC | Summit