eBPF em produção: observabilidade de escala sem overhead de sidecar

O custo oculto da observabilidade tradicional

Em arquiteturas Kubernetes tradicionais, a observabilidade vem com um preço alto. Cada pod que você deploya é acompanhado por uma pequena frota de sidecars: um para coletar métricas, outro para capturar logs, um terceiro para tracing, e talvez um quarto para segurança de rede.

Essa abordagem multiplica seus recursos de infraestrutura. Uma aplicação modesta que consome 200MB de memória e 100m de CPU pode facilmente inflar para 500MB+ e 300m+ quando você considera todos os sidecars de observabilidade. Em escala de centenas ou milhares de pods, isso representa custos significativos e complexidade operacional.

eBPF (Extended Berkeley Packet Filter) oferece uma alternativa radical: observe tudo do kernel, sem modificar suas aplicações e sem sidecars.

O que é eBPF e por que importa agora

eBPF permite que você execute programas sandboxed no kernel Linux de forma segura e eficiente. Originalmente desenvolvido para networking de alto desempenho, eBPF evoluiu para se tornar o mecanismo universal para observabilidade, segurança e profiling em produção.

Por que eBPF mudou o jogo em 2026

Execução no kernel significa zero overhead no espaço do usuário

• Seus programas eBPF rodam no contexto do kernel
• Apenas os dados relevantes são copiados para o espaço do usuário
• Sem context switches, sem marshaling de dados, sem overhead de IPC

Sem modificação de código

• Instrumentação automática de syscalls, networking, filesystem, e processos
• Funciona com aplicações legadas, binários compilados, e containers sem qualquer mudança
• Sem reinicialização de pods para adicionar observabilidade

Segurança inata

• Programas eBPF são verificados pelo kernel antes da execução
• Sandbox rigoroso previne crashes e vulnerabilidades
• Permissões granulares controlam o que cada programa pode observar

Ferramentas eBPF para Kubernetes em produção

Cilium: Networking e segurança orientada a eBPF

Cilium substitui kube-proxy com implementação eBPF nativa, entregando networking e segurança com throughput de ordens de magnitude superior.

yaml# Exemplo de política de rede Cilium
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
  name: frontend-to-backend
spec:
  endpointSelector:
    matchLabels:
      app: frontend
  egress:
  - toEndpoints:
    - matchLabels:
        app: backend
    toPorts:
    - ports:
      - port: "8080"
        protocol: TCP
      rules:
        http:
        - method: "GET"
          path: "/api/v1/products"

Benefícios em produção:

• Latência reduzida em 40-60% comparado a iptables/kube-proxy
• Políticas L7-aware que entendem HTTP, gRPC, Kafka
• Observabilidade de fluxo de rede integrada sem sidecars adicionais

Pixie: Observabilidade automática sem código

Pixie captura tráfego de rede, chamadas de sistema, eventos de pod e métricas de performance automaticamente, expondo através de uma interface PXL (Pixie Query Language).

pxl# Consulta Pixie para identificar latência de endpoint HTTP
px/display(px.merge(trace_cols=['time_',
  'http.resp_status',
  'http.latency',
  'http.req.path',
  'service_name'])
  | where http.resp_status >= 400
  | group_by(['service_name', 'http.req.path'])
  | agg(http.latency_p99 := quantile(99.0, http.latency)
       , error_rate := pct(100.0, http.resp_status >= 400))
)

Casos de uso práticos:

• Identificar o pod responsável por latência de 99º percentil
• Rastrear requests através de múltiplos serviços automaticamente
• Detectar anomalias de tráfego sem configurar dashboards prévios

Parca: Continuous profiling com eBPF

Parca fornece profiling contínuo de todas as suas workloads, identificando hotspots de CPU, memória e I/O sem sampling tradicional que introduz overhead.

yaml# Deployment do Parca Agent
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: parca-agent
  namespace: monitoring
spec:
  selector:
    matchLabels:
      app: parca-agent
  template:
    spec:
      hostPID: true  # Necessário para profiling de todos os processos
      containers:
      - name: parca-agent
        image: ghcr.io/parca-dev/parca-agent:latest
        args:
        - --storage-path=/data
        - --upload-url=http://parca-server.monitoring.svc.cluster.local:4100
        volumeMounts:
        - name: data
          mountPath: /data
        securityContext:
          privileged: true
      volumes:
      - name: data
        emptyDir: {}

O que o profiling contínuo revela:

• Funções específicas causando degradação de performance
• Memory leaks em tempo real, não só após crash
• Impacto de rolling updates em perfil de performance

Implementando eBPF em produção: estratégias de rollout

Fase 1: Piloto read-only

Antes de usar eBPF para decisões críticas, comece com monitoramento passivo.

bash# Instale Cilium em modo relatório (não enforcement)
cilium install --set policy.enforcement=reporting

# Ative coleta de métricas sem impactar networking
kubectl apply -f cilium-metrics-prometheus.yaml

Objetivos da fase de piloto:

• Validar compatibilidade com kernel versions em seus nós
• Calcular baseline de overhead para diferentes workload types
• Identificar políticas de rede que seriam bloqueadas

Fase 2: Rollout gradual

Quando confiar nos dados, comece a aplicar políticas e recursos de eBPF gradualmente.

yaml# Progressive rollout usando feature flags
apiVersion: cilium.io/v2
kind: CiliumClusterwideNetworkPolicy
metadata:
  name: progressive-enforcement
spec:
  endpointSelector:
    matchLabels:
      environment: production
  egress:
  - toEndpoints:
    - matchLabels:
        k8s-app: kube-dns
  toPorts:
  - ports:
    - port: "53"
      protocol: UDP
    - port: "53"
      protocol: TCP
  # Aplicar inicialmente apenas em namespace staging
  applyOn: staging
  # Gradualmente estender para production após validação

Fase 3: Migração completa

Remova sidecars de observabilidade progressivamente.

yaml# Exemplo: removendo Datadog Agent DaemonSet
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: datadog-agent
spec:
  # Reduza réplicas gradualmente enquanto eBPF assume
  replicas: 10  # de 50 inicialmente
  # Use nodeSelector para segmentar rollout
  nodeSelector:
    kubernetes.io/hostname: node-1-3

Comparação de overhead: eBPF vs. tradicional

Implicações financeiras: Em um cluster de 1000 pods, eBPF pode economizar 150-200GB de RAM e 40-70 CPU cores—custos que se traduzem diretamente em economia na nuvem.

Desafios e considerações de produção

Compatibilidade de kernel

eBPF requer kernels Linux relativamente recentes (4.10+ para features básicas, 5.10+ para features completas).

yaml# Node affinity para workloads eBPF-críticas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: critical-service
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kernel.version.full
                operator: Gt
                values:
                - "5.10.0"

Estratégia para clusters heterogêneos:

• Use node taints para marcar nós com kernel legacy
• Coloque workloads sem eBPF nos nós legacy
• Migre nós legacy gradualmente ou retire-os do cluster

Debugging de programas eBPF

Quando um programa eBPF falha ou produz resultados inesperados, debugging pode ser desafiante.

bash# Verificar logs do kernel relacionados a eBPF
dmesg | grep -i bpf

# Listar programas eBPF carregados
bpftool prog list

# Inspecionar mapa eBPF
bpftool map show name my_map
bpftool map dump name my_map

Aprendizado de PXL e consultas

Para maximizar o valor de ferramentas como Pixie, sua equipe precisa aprender PXL e modelagem de dados.

pxl# Consulta complexa: correlacionando métricas com traces
px/display(
  px.merge(
    trace_cols=['time_', 'trace_id', 'service_name', 'http.latency'],
    metric_cols=['cpu_usage', 'memory_usage']
  )
  | where http.latency > 1000  # latência > 1s
  | group_by(['service_name'])
  | agg(
    latency_p99 := quantile(99.0, http.latency),
    cpu_avg := avg(cpu_usage),
    mem_avg := avg(memory_usage)
  )
)

Padrões de observabilidade com eBPF

Padrão 1: Tracing distribuído sem instrumentação

Aproveite eBPF para capturar traces automaticamente sem modificar seu código.

pxl# Trace HTTP requests através de todos os pods
px/display(px.GetTraceData(
  start_time='-5m',
  filter={'http.resp_status': '>= 400'}
))

Vantagens sobre tracing tradicional:

• Zero alteração de código
• Captura automaticamente novos endpoints
• Funciona para serviços que você não controla (bibliotecas third-party)

Padrão 2: Anomaly detection em tempo real

Use eBPF para detectar anomalias de tráfego antes que impactem usuários.

pxl# Detectar picos de requests incomuns
px/display(
  px.ServiceRequestStats()
  | window(1m)
  | stddev(req_count, stddev)
  | where req_count > 3 * stddev  # >3 desvios padrão
)

Padrão 3: Network topology discovery

Mapeie automaticamente dependências de serviço observando tráfego real.

pxl# Construir grafo de dependências de serviço
px/display(
  px.NetworkFlow()
  | group_by(['src_service', 'dst_service'])
  | agg(flow_count := count())
  | where flow_count > 10  # Apenas conexões significativas
)

Integração com seu stack existente

Exportando métricas para Prometheus

Cilium e outras ferramentas eBPF expõem métricas em formato Prometheus.

yaml# ServiceMonitor para Cilium
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: cilium-metrics
  namespace: kube-system
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: cilium
  endpoints:
  - port: metrics
    interval: 15s
    path: /metrics

Enviando traces para Jaeger/Tempo

Configure Cilium para enviar traces para seu backend de tracing existente.

yamlapiVersion: v1
kind: ConfigMap
metadata:
  name: cilium-config
  namespace: kube-system
data:
  enable-hubble: "true"
  hubble-metrics: "dns,drop,tcp,flow,port-distribution,icmp,http"
  hubble-socket-path: "/var/run/cilium/hubble.sock"
  hubble-tls-enabled: "true"
  hubble-export-jaeger-enabled: "true"
  hubble-export-jaeger-endpoint: "http://jaeger-collector.monitoring.svc:14268/api/traces"

Conclusão

eBPF transformou observabilidade de um trade-off inevitável para uma capacidade quase mágica: ver tudo sem impactar nada. Ao eliminar sidecars, reduzir overhead e fornecer visibilidade automática, eBPF permite que equipes de engenharia operem com mais confiança e menos custo de infraestrutura.

A curva de aprendizado é real—você precisa entender PXL, conceitos de kernel Linux e novos padrões de deployment. Mas os benefícios em escala são inegáveis: clusters menores, contas de nuvem reduzidas, debugging mais rápido e visibilidade sem precedentes de seus sistemas distribuídos.

Comece com pilotos read-only, estenda gradualmente, e remova legado de observabilidade à medida que eBPF se torna o novo normal. O futuro da observabilidade é observabilidade invisível.

Seu cluster Kubernetes está crescendo e os custos de observabilidade impactam seu orçamento? Fale com especialistas em DevOps da Imperialis para projetar uma estratégia de observabilidade baseada em eBPF que reduza overhead e maximize visibilidade.

Fontes

• Cilium Documentation — Networking e segurança orientada a eBPF
• Pixie Documentation — Observabilidade automática sem código
• Parca Documentation — Continuous profiling com eBPF
• eBPF.io Learning Resources — Recursos de aprendizado eBPF
• Linux Kernel eBPF Documentation — Documentação oficial do kernel