Como o eBPF está revolucionando a segurança e a observabilidade no Kubernetes
Explore como o eBPF e o XDP estão transformando o gerenciamento de rede e a segurança no Kubernetes, superando as limitações do iptables e oferecendo novas possibilidades para observabilidade e políticas de segurança de camada 7.
MundiX News·19 de junho de 2026·7 min de leitura·👁 2 views
Atualmente, a frase "utilizamos Kubernetes em ambiente de produção" já não surpreende ninguém. O que ainda causa espanto é a quantidade de equipes que se contentam com pilhas de rede improvisadas, baseadas em iptables e muita sorte. Enquanto isso, o kube-proxy trabalha metodicamente, percorrendo cadeias de regras como um arquivista em um porão empoeirado. Estamos na era do eBPF, onde a mágica da rede acontece diretamente no kernel, sem a necessidade de movimentos desnecessários e cópias de dados.
Neste artigo, analisaremos sem rodeios por que a abordagem clássica com iptables falha sob as primeiras cargas de trabalho, como o eBPF com XDP está reescrevendo as regras do jogo e por que, mesmo em 2026, a questão do "aceleramento gratuito" não é tão simples.
Por que o iptables não aguenta mais
Vamos aos números. Em comparações entre Flannel (overlay), Calico (routing) e Cilium (eBPF), um fato desagradável foi descoberto: soluções tradicionais baseadas em iptables ou IPVS introduzem latência mensurável mesmo sob cargas médias. Pode parecer insignificante, mas em uma arquitetura de microsserviços, onde uma única requisição passa por 10, 20 ou 50 serviços, essa "insignificância" se traduz em segundos de espera para o usuário.
A causa do gargalo reside no funcionamento do kube-proxy clássico no modo iptables, que opera por meio de uma varredura linear. Cada pacote que chega a um Service IP deve passar por uma cadeia de regras até que sua correspondência seja encontrada. Se você tem mil serviços (o que não é incomum em um cluster normal), um pacote recebido "bate" em cada regra até chegar à correta. A complexidade é O(n), onde n é o número de serviços. É como procurar um livro em uma biblioteca onde o catálogo não está sistematizado, apenas lista todos os livros em ordem.
Existe também o modo IPVS, que utiliza tabelas hash e opera mais rapidamente, mas mesmo ele não resolve completamente o problema. Sob altas cargas e atualizações frequentes de regras (por exemplo, durante o escalonamento horizontal de pods), os custos adicionais aumentam significativamente.
A Isovalent (criadora do Cilium) apresenta os seguintes dados: em testes de TCP Connect/Request/Response (CRR), o eBPF supera o modo iptables do kube-proxy em uma ordem de magnitude, e essa diferença aumenta proporcionalmente ao número de serviços. Quanto maior o seu cluster, mais você sentirá as latências do kube-proxy.
eBPF e XDP: quando o kernel se torna programável
Agora, sobre o que há de belo: o eBPF (Extended Berkeley Packet Filter). Esqueça tudo o que você sabia sobre o bom e velho BPF, usado para sniffing de pacotes. O eBPF moderno é uma máquina virtual dentro do kernel Linux, permitindo a execução de programas em um sandbox seguro em resposta a eventos do sistema.
O que isso significa na prática? Anteriormente, para adicionar alguma lógica ao processamento de pacotes, era necessário escrever um módulo de kernel (arriscado, complexo, exigindo recompilação) ou levantar um proxy em user-space (lento devido à cópia de dados). O eBPF permite carregar um programa diretamente no kernel em execução, e um verificador garante que esse programa não travará o sistema (sem loops infinitos, sem operações perigosas).
Mas o mais interessante é o XDP (eXpress Data Path). O XDP permite anexar um programa eBPF à fase mais inicial do processamento de pacotes – diretamente no driver da placa de rede, antes mesmo que o pacote entre na pilha de rede do kernel. Imagine: o pacote acabou de chegar à NIC, ainda não houve nenhuma interrupção (interrupt) ou troca de contexto – e seu programa já decidiu o que fazer com ele. DROP? PASS para a pilha? REDIRECT diretamente para outra interface? Tudo isso na velocidade de milhões de pacotes por segundo.
Algumas placas de rede avançadas suportam até mesmo o offload do XDP diretamente para o hardware, o que significa que o programa é executado sem carregar a CPU. Mas isso já é um nível de processamento de hardware.
Cilium: Hubble, mapas e nenhum kube-proxy
O Cilium não é apenas um plugin CNI, mas um ecossistema completo em torno do eBPF. Arquiteturalmente, o Cilium funciona da seguinte forma: em vez de manter enormes cadeias de iptables, ele armazena regras de roteamento e segurança em BPF maps – tabelas hash especiais dentro do kernel. A complexidade da busca é O(1). Um pacote que chega a um Service IP (ClusterIP) acessa o mapa, encontra instantaneamente o IP do endpoint (pod) e é direcionado diretamente, contornando todo o zoológico de NAT e roteamento.
Além disso, o Cilium pode substituir completamente o kube-proxy. No modo kube-proxy replacement, ele assume toda a lógica de serviços, e o componente padrão kube-proxy é desativado. Isso simplifica a depuração (não é necessário investigar iptables) e elimina custos adicionais.
Como isso se parece em nível de código? Em sua apresentação no FOSDEM, engenheiros da Isovalent demonstraram o conceito: um programa eBPF, anexado a um hook XDP na interface, pode interceptar um pacote, acessar um mapa BPF com o mapeamento "Service IP → Pod IP" e enviar o pacote diretamente para o namespace de rede do pod através de um par veth, sem sequer entrar na pilha de rede completa do host.
E isso não é apenas sobre velocidade. O Hubble – a camada de observabilidade do Cilium – usa os mesmos hooks eBPF para coletar métricas, logs de fluxo e até insights de segurança sem a necessidade de instalar sidecar containers ou implantar agentes adicionais.
E a segurança em sockets?
As NetworkPolicies tradicionais no Kubernetes (por exemplo, Calico) operam em L3/L4 e utilizam filtragem no kernel, frequentemente no nível do iptables. Isso é aceitável, mas tem suas limitações: você não pode dizer "bloquear HTTP POST para /admin", apenas "bloquear a porta TCP 443". Para políticas L7, geralmente é necessário um service mesh (Istio, Linkerd) com um proxy sidecar, que fica entre os serviços.
O Cilium implementa políticas L7 através do eBPF, subindo para o nível do protocolo. Ele pode inspecionar cabeçalhos HTTP, métodos gRPC, tópicos Kafka, e tudo isso diretamente dentro do kernel, sem ser transferido para user-space. Isso proporciona um enorme ganho de desempenho em comparação com proxies clássicos.
Mas atenção, há um porém!
Pesquisas recentes de 2025-2026 mostram que o processamento L7 do eBPF não é uma bala de prata. Um trabalho recente na IEEE Access (2025) comparou o desempenho de CNIs com políticas L7 ativadas.
Resultado: o Cilium baseado em eBPF em L7 reduz o throughput de 8.9 Gbps para meros 94 Mbps. Sim, você leu certo. Isso ocorre porque a análise de HTTP/1.1 ou gRPC dentro do kernel é complexa. O kernel não consegue analisar protocolos de texto de forma tão eficiente quanto o Envoy em user-space.
Ao testar o overhead do mTLS em um service mesh, o Cilium mostrou um overhead de 99% (devido à cópia de contextos kernel → user-space), enquanto o Istio Ambient com proxy user-space teve apenas 8%. No entanto, em L4 puro (sem inspeção profunda) e com um grande número de serviços (>500), as soluções eBPF vencem de forma clara.
Quando cavar mais fundo: as armadilhas ocultas do AF_XDP
Para cenários onde o XDP não é suficiente (por exemplo, quando é necessária uma lógica complexa que não se encaixa nos limites de tamanho ou complexidade de código do eBPF), existe o AF_XDP. Este mecanismo permite encaminhar um pacote do XDP para user-space através de um socket especial com zero-copy.
Aparentemente, é ideal: um caminho rápido no kernel mais a flexibilidade do user-space.
Mas mesmo aqui há uma nuance.
Se o tráfego deve ir para uma aplicação local em um contêiner, o AF_XDP requer uma manobra peculiar: o pacote da UMEM (memória compartilhada entre o kernel e o user-space) precisa ser copiado para um veth ou outra interface para ser entregue à pilha de rede e, consequentemente, ao pod.
No final, em vez de uma cópia, obtemos duas, ou trabalhamos no modo copy-mode, perdendo todo o benefício. Em um teste com memcached, o XDP (kernel) superou o AF_XDP em 42% em termos de throughput. Portanto, se o seu tráfego é local, o XDP é preferível.
Matriz de decisão final
Então, o que escolher para o cluster? Se você tem um cluster pequeno (até 500 nós) e tráfego L4 primitivo, desative o kube-proxy, instale o Cilium no modo de roteamento direto (Direct Routing) e aproveite. Você obterá uma redução nas latências de dezenas de milissegundos.
Se você tem um cluster enorme (milhares de nós) ou precisa de filtragem L7 / mTLS de forma verdadeiramente eficiente, considere soluções híbridas ou até mesmo redes user-space como o Istio Ambient. Pesquisas mostram que o Istio lida melhor com a troca frequente de pods do que os agentes distribuídos do Cilium, oferecendo um ganho de throughput de 56% com o mesmo hardware. Portanto, o eBPF é uma tecnologia grandiosa, mas não anula as leis da física nem torna o parsing de HTTP gratuito.
E um último conselho: não hesite em testar com suas próprias cargas de trabalho.
Um engenheiro migrou a produção para o Cilium com política L7 ativada e obteve uma queda de 10 vezes no RPS.
Outro desativou o kube-proxy, configurou o XDP para proteção DDoS (através dos mesmos programas eBPF no driver da NIC) e seu gateway de API começou a suportar 40% mais tráfego.
Ou seja, a mágica da rede exige compreensão. E, espero, este artigo o aproximou um pouco mais de transformar sua tempestade de rede em uma brisa suave.
A tecnologia eBPF está rapidamente expandindo a conversa sobre Kubernetes para além do habitual "configuramos o cluster – então tudo funciona". Para se aprofundar em segurança, observabilidade e operação de infraestrutura, você pode conferir as aulas abertas da OTUS. Elas são gratuitas e ocorrem no âmbito de cursos online, onde você pode conhecer os instrutores e fazer perguntas.
24 de junho, 20:00. "Gerenciamento de Incidentes em SRE. Como encontrar, corrigir e prevenir falhas no sistema rapidamente". Inscrever-se
1 de julho, 20:00. "Métodos clássicos de interceptação de controle no Linux". Inscrever-se
Mais aulas gratuitas – no digest.
Artigos relacionados:
Deploy self-service: como parar de esperar pelo DevOps e acelerar a equipe. Sobre como a abordagem de plataforma ajuda a eliminar gargalos manuais no deploy.
Adeus, Fail2Ban: fortalecendo a proteção do Netbird e Caddy com CrowdSec. Análise prática da proteção de infraestrutura através da análise de logs e trabalho com tráfego suspeito.
Seu docker-compose.yml vai quebrar: 5 configurações que todos esquecem. Checklist de operação de contêineres: limites, healthcheck, política de reinicialização, logs e backups.
🛡️⚡
Pare de pesquisar. Comece a hackear.
O MundiX é seu copiloto de pentest com IA: comandos exatos, análise de outputs e próximo passo na kill chain — em segundos.
Sem cartão para começar · Planos a partir de R$49/mês
Atualmente, a frase "utilizamos Kubernetes em ambiente de produção" já não surpreende ninguém. O que ainda causa espanto é a quantidade de equipes que se contentam com pilhas de rede improvisadas, baseadas em iptables e muita sorte. Enquanto isso, o kube-proxy trabalha metodicamente, percorrendo cadeias de regras como um arquivista em um porão empoeirado. Estamos na era do eBPF, onde a mágica da rede acontece diretamente no kernel, sem a necessidade de movimentos desnecessários e cópias de dados.
Neste artigo, analisaremos sem rodeios por que a abordagem clássica com iptables falha sob as primeiras cargas de trabalho, como o eBPF com XDP está reescrevendo as regras do jogo e por que, mesmo em 2026, a questão do "aceleramento gratuito" não é tão simples.
Por que o iptables não aguenta mais
Vamos aos números. Em comparações entre Flannel (overlay), Calico (routing) e Cilium (eBPF), um fato desagradável foi descoberto: soluções tradicionais baseadas em iptables ou IPVS introduzem latência mensurável mesmo sob cargas médias. Pode parecer insignificante, mas em uma arquitetura de microsserviços, onde uma única requisição passa por 10, 20 ou 50 serviços, essa "insignificância" se traduz em segundos de espera para o usuário.
A causa do gargalo reside no funcionamento do kube-proxy clássico no modo iptables, que opera por meio de uma varredura linear. Cada pacote que chega a um Service IP deve passar por uma cadeia de regras até que sua correspondência seja encontrada. Se você tem mil serviços (o que não é incomum em um cluster normal), um pacote recebido "bate" em cada regra até chegar à correta. A complexidade é O(n), onde n é o número de serviços. É como procurar um livro em uma biblioteca onde o catálogo não está sistematizado, apenas lista todos os livros em ordem.
Existe também o modo IPVS, que utiliza tabelas hash e opera mais rapidamente, mas mesmo ele não resolve completamente o problema. Sob altas cargas e atualizações frequentes de regras (por exemplo, durante o escalonamento horizontal de pods), os custos adicionais aumentam significativamente.
A Isovalent (criadora do Cilium) apresenta os seguintes dados: em testes de TCP Connect/Request/Response (CRR), o eBPF supera o modo iptables do kube-proxy em uma ordem de magnitude, e essa diferença aumenta proporcionalmente ao número de serviços. Quanto maior o seu cluster, mais você sentirá as latências do kube-proxy.
eBPF e XDP: quando o kernel se torna programável
Agora, sobre o que há de belo: o eBPF (Extended Berkeley Packet Filter). Esqueça tudo o que você sabia sobre o bom e velho BPF, usado para sniffing de pacotes. O eBPF moderno é uma máquina virtual dentro do kernel Linux, permitindo a execução de programas em um sandbox seguro em resposta a eventos do sistema.
O que isso significa na prática? Anteriormente, para adicionar alguma lógica ao processamento de pacotes, era necessário escrever um módulo de kernel (arriscado, complexo, exigindo recompilação) ou levantar um proxy em user-space (lento devido à cópia de dados). O eBPF permite carregar um programa diretamente no kernel em execução, e um verificador garante que esse programa não travará o sistema (sem loops infinitos, sem operações perigosas).
Mas o mais interessante é o XDP (eXpress Data Path). O XDP permite anexar um programa eBPF à fase mais inicial do processamento de pacotes – diretamente no driver da placa de rede, antes mesmo que o pacote entre na pilha de rede do kernel. Imagine: o pacote acabou de chegar à NIC, ainda não houve nenhuma interrupção (interrupt) ou troca de contexto – e seu programa já decidiu o que fazer com ele. DROP? PASS para a pilha? REDIRECT diretamente para outra interface? Tudo isso na velocidade de milhões de pacotes por segundo.
Algumas placas de rede avançadas suportam até mesmo o offload do XDP diretamente para o hardware, o que significa que o programa é executado sem carregar a CPU. Mas isso já é um nível de processamento de hardware.
Cilium: Hubble, mapas e nenhum kube-proxy
O Cilium não é apenas um plugin CNI, mas um ecossistema completo em torno do eBPF. Arquiteturalmente, o Cilium funciona da seguinte forma: em vez de manter enormes cadeias de iptables, ele armazena regras de roteamento e segurança em BPF maps – tabelas hash especiais dentro do kernel. A complexidade da busca é O(1). Um pacote que chega a um Service IP (ClusterIP) acessa o mapa, encontra instantaneamente o IP do endpoint (pod) e é direcionado diretamente, contornando todo o zoológico de NAT e roteamento.
Além disso, o Cilium pode substituir completamente o kube-proxy. No modo kube-proxy replacement, ele assume toda a lógica de serviços, e o componente padrão kube-proxy é desativado. Isso simplifica a depuração (não é necessário investigar iptables) e elimina custos adicionais.
Como isso se parece em nível de código? Em sua apresentação no FOSDEM, engenheiros da Isovalent demonstraram o conceito: um programa eBPF, anexado a um hook XDP na interface, pode interceptar um pacote, acessar um mapa BPF com o mapeamento "Service IP → Pod IP" e enviar o pacote diretamente para o namespace de rede do pod através de um par veth, sem sequer entrar na pilha de rede completa do host.
E isso não é apenas sobre velocidade. O Hubble – a camada de observabilidade do Cilium – usa os mesmos hooks eBPF para coletar métricas, logs de fluxo e até insights de segurança sem a necessidade de instalar sidecar containers ou implantar agentes adicionais.
E a segurança em sockets?
As NetworkPolicies tradicionais no Kubernetes (por exemplo, Calico) operam em L3/L4 e utilizam filtragem no kernel, frequentemente no nível do iptables. Isso é aceitável, mas tem suas limitações: você não pode dizer "bloquear HTTP POST para /admin", apenas "bloquear a porta TCP 443". Para políticas L7, geralmente é necessário um service mesh (Istio, Linkerd) com um proxy sidecar, que fica entre os serviços.
O Cilium implementa políticas L7 através do eBPF, subindo para o nível do protocolo. Ele pode inspecionar cabeçalhos HTTP, métodos gRPC, tópicos Kafka, e tudo isso diretamente dentro do kernel, sem ser transferido para user-space. Isso proporciona um enorme ganho de desempenho em comparação com proxies clássicos.
Mas atenção, há um porém!
Pesquisas recentes de 2025-2026 mostram que o processamento L7 do eBPF não é uma bala de prata. Um trabalho recente na IEEE Access (2025) comparou o desempenho de CNIs com políticas L7 ativadas.
Resultado: o Cilium baseado em eBPF em L7 reduz o throughput de 8.9 Gbps para meros 94 Mbps. Sim, você leu certo. Isso ocorre porque a análise de HTTP/1.1 ou gRPC dentro do kernel é complexa. O kernel não consegue analisar protocolos de texto de forma tão eficiente quanto o Envoy em user-space.
Ao testar o overhead do mTLS em um service mesh, o Cilium mostrou um overhead de 99% (devido à cópia de contextos kernel → user-space), enquanto o Istio Ambient com proxy user-space teve apenas 8%. No entanto, em L4 puro (sem inspeção profunda) e com um grande número de serviços (>500), as soluções eBPF vencem de forma clara.
Quando cavar mais fundo: as armadilhas ocultas do AF_XDP
Para cenários onde o XDP não é suficiente (por exemplo, quando é necessária uma lógica complexa que não se encaixa nos limites de tamanho ou complexidade de código do eBPF), existe o AF_XDP. Este mecanismo permite encaminhar um pacote do XDP para user-space através de um socket especial com zero-copy.
Aparentemente, é ideal: um caminho rápido no kernel mais a flexibilidade do user-space.
Mas mesmo aqui há uma nuance.
Se o tráfego deve ir para uma aplicação local em um contêiner, o AF_XDP requer uma manobra peculiar: o pacote da UMEM (memória compartilhada entre o kernel e o user-space) precisa ser copiado para um veth ou outra interface para ser entregue à pilha de rede e, consequentemente, ao pod.
No final, em vez de uma cópia, obtemos duas, ou trabalhamos no modo copy-mode, perdendo todo o benefício. Em um teste com memcached, o XDP (kernel) superou o AF_XDP em 42% em termos de throughput. Portanto, se o seu tráfego é local, o XDP é preferível.
Matriz de decisão final
Então, o que escolher para o cluster? Se você tem um cluster pequeno (até 500 nós) e tráfego L4 primitivo, desative o kube-proxy, instale o Cilium no modo de roteamento direto (Direct Routing) e aproveite. Você obterá uma redução nas latências de dezenas de milissegundos.
Se você tem um cluster enorme (milhares de nós) ou precisa de filtragem L7 / mTLS de forma verdadeiramente eficiente, considere soluções híbridas ou até mesmo redes user-space como o Istio Ambient. Pesquisas mostram que o Istio lida melhor com a troca frequente de pods do que os agentes distribuídos do Cilium, oferecendo um ganho de throughput de 56% com o mesmo hardware. Portanto, o eBPF é uma tecnologia grandiosa, mas não anula as leis da física nem torna o parsing de HTTP gratuito.
E um último conselho: não hesite em testar com suas próprias cargas de trabalho.
Um engenheiro migrou a produção para o Cilium com política L7 ativada e obteve uma queda de 10 vezes no RPS.
Outro desativou o kube-proxy, configurou o XDP para proteção DDoS (através dos mesmos programas eBPF no driver da NIC) e seu gateway de API começou a suportar 40% mais tráfego.
Ou seja, a mágica da rede exige compreensão. E, espero, este artigo o aproximou um pouco mais de transformar sua tempestade de rede em uma brisa suave.
A tecnologia eBPF está rapidamente expandindo a conversa sobre Kubernetes para além do habitual "configuramos o cluster – então tudo funciona". Para se aprofundar em segurança, observabilidade e operação de infraestrutura, você pode conferir as aulas abertas da OTUS. Elas são gratuitas e ocorrem no âmbito de cursos online, onde você pode conhecer os instrutores e fazer perguntas.
24 de junho, 20:00. "Gerenciamento de Incidentes em SRE. Como encontrar, corrigir e prevenir falhas no sistema rapidamente". Inscrever-se
1 de julho, 20:00. "Métodos clássicos de interceptação de controle no Linux". Inscrever-se
Mais aulas gratuitas – no digest.
Artigos relacionados:
Deploy self-service: como parar de esperar pelo DevOps e acelerar a equipe. Sobre como a abordagem de plataforma ajuda a eliminar gargalos manuais no deploy.
Adeus, Fail2Ban: fortalecendo a proteção do Netbird e Caddy com CrowdSec. Análise prática da proteção de infraestrutura através da análise de logs e trabalho com tráfego suspeito.
Seu docker-compose.yml vai quebrar: 5 configurações que todos esquecem. Checklist de operação de contêineres: limites, healthcheck, política de reinicialização, logs e backups.
📤 Compartilhar & Baixar
🧰 Ferramentas recomendadas
Divulgação: alguns links são patrocinados. Podemos receber comissão se você comprar — sem custo extra para você. Só indicamos o que faz sentido para a comunidade.
