Espero que você tenha curtido a leitura sobre eBPF na Parte 1! Agora vamos analisar o Cilium como uma solução popular de eBPF para Kubernetes e ver como ele se relaciona com o Dataplane V2.
O Cilium 🐝 é uma tecnologia em alta, movida a eBPF. Costuma ser a primeira coisa que vem à mente quando se fala em eBPF, ainda mais no contexto de Kubernetes. Em essência, o Cilium é um software open-source que funciona como plugin CNI para Kubernetes. Ele entrega networking, observabilidade e segurança baseados em eBPF, com escala e performance ideais para times de plataforma que rodam ambientes Kubernetes na nuvem e on-premise.
Aproveitando o Extended Berkeley Packet Filter (eBPF), o Cilium traz uma série de recursos interessantes para o Kubernetes. Vamos olhar mais de perto.
Network Policies 🕸
Adotar o princípio do menor privilégio é uma boa prática quando o assunto é a comunicação entre pods do Kubernetes. As Network Policies básicas do Kubernetes (que operam em L3/L4) cumprem bem o papel, mas dá para ir além com as Cilium Network Policies (que operam em L3-L7).
Isso é muito útil no mundo do Kubernetes e dos microsserviços, porque examinar e controlar o tráfego de rede só com metadados (como IPs e portas) não agrega muito valor. IPs e portas mudam o tempo todo, conforme os serviços sobem e descem. Com o Cilium, você também pode controlar o tráfego usando metadados de Pod, HTTP, gRPC, Kafka, DNS e outros.
Por exemplo, dá para definir regras HTTP que permitam uma chamada de API específica a partir de um determinado pod, com base em path, header e métodos de requisição. Outro exemplo é definir regras de DNS baseadas em FQDN, de forma que apenas consultas a um domínio específico sejam permitidas. Assim conseguimos definir políticas de segurança mais valiosas e aplicáveis aos casos de uso reais do dia a dia.
Conectividade Multi-Cluster 🔗
Por meio de um cluster mesh, o Cilium permite que pods do Kubernetes se comuniquem e sejam descobertos entre clusters. Os casos de uso incluem alta disponibilidade e multi-cloud (conectando clusters Kubernetes entre provedores de nuvem).
Load Balancing ⚖️
O Cilium substitui o kube-proxy por BPF. O kube-proxy usa iptables, que está sendo substituído por BPF. Essa mudança melhora drasticamente a performance.
Recursos adicionais
- Criptografia transparente entre pods. Suporte a IPsec/Wireguard
- Mais performance de rede
- Alta escalabilidade de infraestrutura
- Visibilidade enriquecida dos fluxos de tráfego, não só por IPs e portas, mas também por protocolos L7. Confira este post sobre uma sessão interessante de debug de DNS
- Monitoramento e visibilidade aprimorada de erros de rede entre seus microsserviços. O Cilium fornece métricas compatíveis com Prometheus
Algumas palavras sobre as alternativas. Há outros plugins CNI competentes no mercado. Aqui vai uma comparação (que pode ser tendenciosa). O Calico também lançou recentemente um Dataplane baseado em eBPF.
Dataplane V2 ✈
O Google Cloud Platform está mantendo o GKE (Google Kubernetes Engine) na onda, incorporando o Cilium em seu próprio mecanismo, o Dataplane V2. Mas o Dataplane V2 é mesmo um Cilium gerenciado pelo Google para o GKE? A gente adora um serviço gerenciado, né? Isso pede uma análise mais a fundo.
Ao examinar a documentação do Google sobre os conceitos do Dataplane V2, não há nenhuma indicação ou referência ao projeto Cilium (no momento em que este post foi escrito). Já no post oficial do blog e em parte da documentação, há algumas referências discretas.
O control plane do Dataplane V2 é implantado como um DaemonSet do Kubernetes chamado anetd. Um rápido kubectl describe daemonsets.apps -n kube-system anetd revela que ele usa a imagem gke.gcr.io/cilium/cilium:v1.9.4-gke.17.
Então, é Cilium mesmo? Vamos rodar kubectl exec -n kube-system -ti ds/anetd — cilium version. Aqui está a saída:
Client: 1.9.4 609a63dfb 2021-04-12T15:01:54-07:00 go version go1.15.7 linux/amd64
Sim! É realmente o Cilium 1.9.4! Mas, ao comparar com a imagem oficial do Cilium v1.9.4, o resultado é um pouco diferente:
Client: 1.9.4 07b62884c 2021-02-03T11:45:44-08:00 go version go1.15.7 linux/amd64
Agora vamos comparar as imagens Docker gke.gcr.io/cilium/cilium:v1.9.4-gke.17 e quay.io/cilium/cilium:v1.9.4 com uma ferramenta como o Dive. Parece haver algumas mudanças nas camadas, mas é difícil dizer se existe alguma alteração lógica significativa entre elas no que diz respeito ao que o Cilium oferece.
Vale também mencionar que neste post se afirma que o Google entrou em cena e contribuiu com diversos recursos relevantes para o projeto Cilium. Acho que isso demonstra um certo nível de comprometimento.
Então, Dataplane V2 = Cilium gerenciado?
Até aqui, não dá para concluir se o Dataplane V2 é um Cilium gerenciado para o GKE. E sem essa conclusão oficial, podemos dizer que, pelo menos como produto, Dataplane V2 ≠ Cilium. Tudo indica que o Cilium é usado por baixo dos panos, nos bastidores. A documentação do Google simplesmente não menciona nem te direciona para a documentação do Cilium. É uma oferta completamente diferente.
Pelos testes que fiz, alguns recursos do Cilium parecem funcionar no Dataplane V2. Porém, não há suporte oficial do Google. Nem precisa dizer que recursos do Cilium fora do escopo oficial do Dataplane V2 podem funcionar hoje, mas quebrar de uma hora para outra. Por isso, é melhor não navegar em águas desconhecidas. Para ficar tranquilo, siga a documentação oficial.
Cilium puro ou Dataplane V2? 🤔
Aqui vai uma comparação de recursos:
As funcionalidades em comum entre o Cilium e o Dataplane V2, no momento, são:
- Network Policies do Kubernetes (não CiliumNetworkPolicy, embora o Dataplane V2 não pareça rejeitá-la no momento),
- Substituição do
kube-proxypor eBPF, - Network Policy Logging. Não é exatamente um recurso do Cilium, mas é baseado nele. Permite monitorar o resultado da aplicação das suas network policies.
Minha opinião 💭
Sempre tento optar pela solução mais simples possível. Se for gerenciada, melhor ainda! Economiza um tempo precioso para todos os envolvidos. O Dataplane V2 parece uma solução gerenciada mais simples e fácil, caso tudo o que você precise seja aproveitar as Network Policies do Kubernetes, uma substituição do kube-proxy via eBPF para ganhos de performance e escala, e o logging fácil de usar dos resultados das network policies.
Só fique de olho nas limitações. Se você precisar dos recursos adicionais do Cilium, como o Hubble, as Cilium L7 Network Policies, o Cluster Mesh, ou estiver usando uma solução self-hosted ou outro provedor de nuvem, o melhor caminho é ir de Cilium puro mesmo.
Dataplane V2: os prós 👍
- Para começar, é fácil de instalar. Basta adicionar a flag
—enable-dataplane-v2ao criar um novo cluster GKE viagcloud container clusters create. - É baseado no projeto open-source Cilium.
- O Dataplane V2 serve como base para o Network Policy Logging no GKE. É um recurso bem útil que gera logs sempre que uma conexão é permitida ou negada por uma network policy.
- O plugin
anted, que faz parte do Dataplane V2 (baseado em Cilium), é gerenciado pelo Google e está atualmente em GA (General Availability). Ou seja, está pronto para workloads de produção, com atualizações e suporte contínuos. - É razoável supor que o Google adicione mais integrações com recursos nativos do GKE, e talvez também com recursos nativos do Cilium. Isso torna a escolha mais atrativa se você está pensando no longo prazo.
Dataplane V2: os contras 👎
- Até o momento, não consegui encontrar uma forma de usar o Hubble com o Dataplane V2. O Hubble é uma ótima ferramenta de observabilidade do Cilium, que oferece uma visibilidade importante aproveitando o eBPF do Cilium. Você pode acompanhar o tema aqui.
- Oficialmente, o Dataplane V2 não é uma solução Cilium gerenciada. Isso significa que não dá para contar com alguns recursos do Cilium que estão funcionando para você hoje no Dataplane V2. Pode haver quebras lá na frente.
- Só dá para habilitá-lo em um cluster GKE recém-criado. Ou seja, não dá para usar nos seus clusters GKE existentes.
- Há outras limitações que vale conhecer.
Como começar 🏃🏽♀️
Para começar com o Cilium no Kubernetes — clique aqui.
Para começar com o Dataplane V2 no GKE — clique aqui.
Dica de profissional: ao escrever ou planejar seus manifests de Network Policy do Kubernetes/Cilium, use o Cilium Editor para uma experiência divertida e segura.
O futuro do eBPF
Por mais revolucionária que essa tecnologia seja, dá para prever que vamos continuar vendo muitas outras soluções e desenvolvimentos interessantes baseados em eBPF.
Uma área de potencial influência é o universo de service mesh. A maioria das soluções de service mesh existentes (como Istio e Linkerd) depende de proxies sidecar acoplados aos seus pods. Isso impacta a performance, adiciona complexidade e cria pontos adicionais de falha. O eBPF tem o potencial de oferecer recursos de service mesh substituindo os proxies sidecar pela lógica do eBPF, o que pode tornar o service mesh acessível para outros casos de uso.
Fica ligado!
Obrigado pela leitura! Para se manter por dentro, siga a gente no DoiT Engineering Blog , no canal da DoiT no LinkedIn e no canal da DoiT no Twitter . Para conhecer as oportunidades de carreira, acesse https://careers.doit-intl.com .