CNI na Prática: Análise Técnica de Cilium (eBPF) vs. Calico para Redes Kubernetes

Sumário

A Camada de Rede em Kubernetes: O Papel Crítico da CNI

A orquestração de contêineres com kubernetes abstrai complexidades de infraestrutura, mas a comunicação entre os componentes distribuídos de uma aplicação moderna permanece um desafio central. É aqui que a Container Network Interface (CNI) entra em cena. A CNI é uma especificação que define uma interface padrão entre o orquestrador (Kubernetes) e os plugins de rede. A escolha de um plugin CNI não é trivial; ela impacta diretamente a performance, a escalabilidade, a segurança e a observabilidade do cluster. Dentre as dezenas de opções disponíveis, duas se destacam pela popularidade e abordagens tecnológicas distintas: Calico e Cilium.

Calico é conhecido por sua maturidade, escalabilidade e forte integração com a pilha de rede Linux tradicional, utilizando o protocolo BGP. Cilium, por outro lado, representa uma abordagem mais moderna, aproveitando o poder do eBPF (extended Berkeley Packet Filter) para revolucionar o processamento de pacotes diretamente no kernel do Linux. Este artigo técnico oferece uma análise comparativa aprofundada entre Cilium e Calico, explorando suas arquiteturas, mecanismos de funcionamento, performance, políticas de segurança e guias práticos de implementação para auxiliar arquitetos e engenheiros de DevOps a tomar uma decisão informada.

Calico: A Solidez do BGP e a Confiança no Stack de Rede Linux

O Project Calico é um dos plugins CNI mais adotados e testados em produção. Sua filosofia de design se baseia em simplicidade e na utilização de tecnologias de rede bem estabelecidas. Em sua configuração padrão, Calico não utiliza uma rede de overlay (como VXLAN ou IP-in-IP), optando por configurar uma rede L3 pura onde cada pod recebe um endereço IP roteável no cluster. Para propagar as rotas para esses pods entre os nós, Calico utiliza o Border Gateway Protocol (BGP).

Arquitetura e Componentes do Calico

A arquitetura do Calico é composta por alguns componentes chave que rodam em cada nó do cluster:

  • Felix: É o agente principal do Calico, executado como um DaemonSet. Sua principal responsabilidade é programar rotas na tabela de roteamento do kernel Linux e configurar as regras de ACLs (Access Control Lists) para implementar as Network Policies do Kubernetes. Historicamente, Felix utilizava iptables para isso, o que, em clusters muito grandes, poderia levar a cadeias de regras extensas e complexas, impactando a performance. Versões mais recentes podem utilizar IPVS ou até mesmo eBPF em um data plane experimental.
  • BIRD: Um daemon de roteamento BGP que distribui as informações de rotas entre os nós. Cada nó anuncia os IPs dos pods que está executando, permitindo que o tráfego seja roteado diretamente para o nó correto sem a necessidade de encapsulamento.
  • calico-node: O contêiner que agrupa Felix e BIRD, simplificando a implantação.

A grande vantagem dessa abordagem é a performance em redes underlay que suportam BGP. Como não há encapsulamento, o tráfego de pod para pod tem a mesma performance do tráfego nativo do host. Além disso, suas políticas de rede (Kubernetes NetworkPolicy e as CRDs Calico GlobalNetworkPolicy) são extremamente poderosas e granulares para regras de L3/L4, tornando-o uma escolha sólida para ambientes com requisitos de segurança rigorosos.

Cilium: Inovação e Performance com eBPF

Cilium adota uma abordagem fundamentalmente diferente, construída sobre o eBPF. O eBPF é uma tecnologia revolucionária no kernel Linux que permite a execução de programas customizados em um ambiente sandboxed dentro do próprio kernel, sem a necessidade de alterar o código-fonte do kernel ou carregar módulos. Isso abre um leque de possibilidades para networking, segurança e observabilidade.

Arquitetura e o Poder do eBPF

Cilium utiliza programas eBPF para controlar o fluxo de pacotes em vários pontos de hook no kernel. Isso permite que ele implemente funcionalidades de rede de forma muito mais eficiente do que as abordagens baseadas em iptables.

  • Encaminhamento de Pacotes: Ao anexar programas eBPF às interfaces de rede (físicas e virtuais), Cilium pode tomar decisões de roteamento e encaminhamento de pacotes no ponto mais inicial possível, evitando a travessia de toda a pilha de rede do kernel e as complexas cadeias de iptables.
  • Load Balancing: Cilium pode substituir completamente o kube-proxy. Ele implementa o balanceamento de carga para Services (ClusterIP, NodePort, LoadBalancer) usando mapas eBPF, que são estruturas de dados altamente eficientes no kernel. Isso resulta em uma redução significativa de latência e maior throughput.
  • Políticas de Segurança: A implementação de Network Policies em Cilium é baseada em identidade, não apenas em IPs. Ele atribui uma identidade de segurança a cada pod com base em seus labels. As políticas são então aplicadas com base nessas identidades. O mais impressionante é sua capacidade de entender e aplicar políticas em L7 (camada de aplicação), como restringir chamadas a endpoints HTTP específicos (`GET /api/v1/data`) ou a tópicos do Kafka.

Essa profunda integração com o kernel via eBPF confere ao Cilium vantagens significativas em performance, especialmente em cenários de alta densidade de serviços e tráfego intenso. Além disso, ele oferece uma observabilidade sem precedentes através do Hubble, sua ferramenta de visualização e monitoramento.

Análise Comparativa Detalhada: Cilium vs. Calico

A escolha entre Cilium e Calico depende de uma análise cuidadosa de vários fatores técnicos. Vamos detalhar os principais pontos de comparação.

Arquitetura e Mecanismo de Encaminhamento de Pacotes

Calico: Depende primariamente do stack de rede Linux. Para Network Policies e Services, ele manipula regras de iptables ou IPVS. Para roteamento entre nós, utiliza BGP. Embora eficiente, a escala de regras de iptables pode se tornar um gargalo em clusters com milhares de serviços e pods, aumentando a latência de processamento de pacotes.

Cilium: Utiliza eBPF para uma abordagem mais direta. Os programas eBPF implementam a lógica de roteamento, load balancing e políticas de rede. Ao contornar iptables e Netfilter, Cilium consegue um caminho de dados mais curto e eficiente. A substituição do kube-proxy é um diferencial chave, eliminando uma fonte comum de contenção e complexidade.

Desempenho e Latência

Em benchmarks sintéticos e cenários de produção, Cilium geralmente demonstra menor latência e maior throughput, especialmente para a implementação de Services (load balancing). A razão é o processamento direto no socket/TC (Traffic Control) via eBPF, que é inerentemente mais rápido do que a travessia das cadeias de iptables que o Calico (em seu modo padrão) e o kube-proxy utilizam. Para tráfego pod-a-pod em uma rede L3 pura, a performance do Calico é excelente, mas o custo de processamento das políticas e dos services ainda recai sobre o iptables.

Políticas de Rede (Network Policies)

Calico: É extremamente robusto e maduro em políticas de rede de L3/L4. Suas CRDs, como GlobalNetworkPolicy, permitem a criação de políticas que abrangem todo o cluster, namespaces específicos, hosts e até mesmo VMs externas. É a escolha padrão para quem precisa de segmentação de rede baseada em IP/porta de forma rigorosa e comprovada.

Cilium: Vai além. Enquanto suporta totalmente a API padrão de NetworkPolicy, seu poder reside nas CiliumNetworkPolicy (CRDs). Elas permitem políticas baseadas em L7, como: `Allow endpoint A to call GET /public on endpoint B`. Também suporta políticas baseadas em FQDN/DNS, permitindo regras de egress para nomes de domínio específicos (ex: `api.externa.com`), uma funcionalidade crucial em ambientes de segurança zero-trust.

Observabilidade e Troubleshooting

Calico: Oferece métricas Prometheus padrão e logs detalhados sobre as ações do Felix. O troubleshooting geralmente envolve ferramentas Linux padrão como `iptables-save`, `ip route` e `tcpdump`. A versão enterprise, Calico Enterprise, oferece ferramentas de visualização mais avançadas.

Cilium: Este é um dos seus maiores diferenciais. O Hubble, componente de observabilidade do Cilium, fornece uma visibilidade profunda e em tempo real do fluxo de tráfego. Com sua UI e CLI, é possível ver mapas de dependência de serviços, inspecionar fluxos de rede individuais (incluindo metadados de L7 como paths HTTP e tópicos Kafka) e ver por que um pacote foi permitido ou descartado pela política de rede. Isso acelera drasticamente o troubleshooting de problemas de conectividade.

Guia de Implementação Prática

A instalação de ambos os CNIs foi simplificada ao longo do tempo, com métodos de implantação bem documentados.

Instalando o Calico

A instalação mais comum do Calico é através da aplicação de um único manifesto YAML, que pode ser customizado conforme a necessidade.

1. Obtenha o manifesto do site oficial do Project Calico: `kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.26.1/manifests/calico.yaml`

2. Antes de aplicar, é crucial verificar e, se necessário, ajustar o CIDR de pods detectado automaticamente pelo manifesto. Isso pode ser feito editando a variável de ambiente `CALICO_IPV4POOL_CIDR` no DaemonSet `calico-node`.

3. Após a aplicação, monitore o status dos pods no namespace `kube-system` ou `calico-system` até que todos estejam em estado `Running`.

Instalando o Cilium

A forma recomendada de instalar o Cilium é utilizando seu chart Helm oficial, que oferece um alto grau de customização.

1. Adicione o repositório Helm do Cilium: `helm repo add cilium https://helm.cilium.io/`

2. Instale o chart com as configurações desejadas. Um exemplo de instalação que substitui o kube-proxy e habilita o Hubble seria:

“`shell
helm install cilium cilium/cilium –version 1.14.0 –namespace kube-system –set kubeProxyReplacement=strict –set hubble.relay.enabled=true –set hubble.ui.enabled=true
“`

3. É fundamental garantir que o kernel dos nós do cluster atenda aos requisitos mínimos de versão do Cilium para o funcionamento correto do eBPF.

Casos de Uso e Critérios de Decisão

A escolha final deve ser guiada pelos requisitos específicos do seu ambiente e workload.

Quando escolher Calico?

  • Integração com Infraestrutura Existente: Se você opera em um ambiente on-premise com uma infraestrutura de rede que já utiliza BGP, o Calico se integra de forma natural e eficiente.
  • Maturidade e Simplicidade: Para equipes que preferem uma solução amplamente testada, com uma arquitetura baseada em componentes de rede Linux conhecidos, o Calico é uma opção segura.
  • Foco em Políticas L3/L4: Se seus requisitos de segurança se concentram estritamente na segmentação de rede por IP e porta, as políticas do Calico são mais do que suficientes e extremamente poderosas.

Quando escolher Cilium?

  • Performance Extrema: Para aplicações sensíveis à latência, como trading de alta frequência, processamento de dados em tempo real ou gateways de API de alto tráfego, os ganhos de performance do eBPF e da substituição do kube-proxy são significativos.
  • Segurança e Observabilidade Avançadas: Se você precisa de políticas de rede que entendam o tráfego da aplicação (L7) e de uma ferramenta de observabilidade nativa que forneça visibilidade profunda dos fluxos de serviço, Cilium e Hubble são incomparáveis.
  • Ambientes Cloud-Native Modernos: Em arquiteturas de microsserviços complexas, onde a depuração de problemas de conectividade é difícil e a segurança zero-trust é um objetivo, as capacidades do Cilium oferecem um valor imenso.

Posts relacionados