O advento das arquiteturas Cloud Native gerou grande complexidade quando pensamos na sustentação do nosso ambiente. Estamos falando de arquiteturas distribuídas, microsserviços, alta disponibilidade, APIs, entre outros tópicos. Garantir a segurança nos ambientes e a capacidade de compreender problemas e fornecer soluções de maneira ágil tornou-se um desafio ainda maior ao nos depararmos com um ambiente distribuído e em nuvem. Tendo ciência desse problema, falaremos hoje sobre o Cilium, uma solução open source que surgiu para remodelar a forma como pensamos na observabilidade e segurança dos nossos ambientes.

O que é Cilium?

Falamos brevemente na introdução do artigo sobre o que de fato podemos esperar do Cilium, porém antes de nos aprofundarmos na solução, é importante comentar sobre a tecnologia que habilitou sua construção e que vem revolucionando como nós estruturamos soluções de observabilidade e segurança, o eBPF.

eBPF (extended Berkeley Packet Filter) - foi lançado em 2014 como uma atualização do BPF, utilizado em hosts Linux. O eBPF foi criado com o intuito de fornecer uma maneira de ampliarmos as capacidades do kernel Linux sem a necessidade de recompilarmos todo o sistema. Com programas eBPF podemos interceptar e visualizar chamadas ao nível do kernel, possibilitando a utilização dessas informações capturadas para construirmos aplicações que levam em consideração o mais baixo nível de funcionamento do sistema.

Utilizando as capacidades fornecidas pelo eBPF, a Isovalent construiu uma solução que revolucionou a forma como enxergamos e protegemos nossos clusters e a maneira como desenvolvemos capacidades adicionais para os ambientes.

Para começarmos a falar sobre o Cilium, vamos iniciar com um desenho que mostra em alto nível as capacidades funcionais da solução e seus componentes.

Como podemos visualizar no diagrama, temos 3 pilares sobre os quais o Cilium atua:

• Service Mesh

• Observability

• Networking

As capacidades de segurança são fornecidas em parte pelo Tetragon, que falaremos em outro artigo.

Começando pela feature mais popular, o Cilium CNI é instalado nos clusters Kubernetes e serve como uma substituição (ou complemento) das interface de redes dos contêineres. Com o Cilium CNI controlando a camada de rede do ambiente, nós passamos a ter completa visibilidade (+ Hubble) das chamadas e dos processos que ali estão ocorrendo. Além das capacidades de visualização de tráfego, também temos recursos que habilitam a comunicação multi-tenant e a criptografia do tráfego das chamadas.

Indo para o segundo pilar, temos o Hubble, responsável por grande parte das capacidades de observabilidade do ecossistema do Cilium. Podendo se conectar com soluções que compõem o ecossistema de monitoramento das empresas como Prometheus e OpenTelemetry, o Hubble oferece as capacidades de compreensão de problemas para os times, fornecendo informações detalhadas do ambiente, possibilitando um troubleshooting mais efetivo.

Por último temos o Cilium Service Mesh, que vai na contramão de outras soluções de mercado, oferecendo visibilidade da mesh de maneira sidecar-less. Essa é uma das proezas do Cilium Service Mesh, falaremos mais sobre ele as próximas seções.

Para entender melhor as capacidades da solução, vamos entrar em maiores detalhes sobre cada uma das funcionalidades presentes no ecossistema!

Networking

As capacidades de networking do Cilium são expostas pelo Cilium CNI, que é o primeiro componente a ser instalado no cluster. Uma vez instalado, você terá de forma nativa uma série de funcionalidades já disponíveis para uso.

Nas capacidades de networking, o Cilium se diferencia por fornecer de maneira nativa recursos que precisariam ser implementados utilizando add-ons de outras soluções. Por termos controle de camadas mais profundas dentro do cluster, podemos executar operações em cima de protocolos como IPv4, IPv6 e BGP, suportados de forma nativa pela solução.

Além disso, visto que a responsabilidade de gerenciar a rede dos clusters é do Cilium CNI, conseguimos aplicar regras de rede nas camadas 3, 4 e 7 (com suporte à políticas de roteamento personalizadas).

Hoje em dia é difícil encontrarmos empresas que tenham só um cluster. Gerenciar um ambiente já é uma tarefa complexa, se pensarmos que cada vez mais as equipes terão autonomia de gerenciar seus próprios clusters, a nossa cluster mesh se tornará “inadministrável”. Com Cilium temos a possibilidade de gerenciar as camadas de rede dos nossos clusters de maneira centralizada, implementando políticas de acesso entre eles e controlando diversos aspectos das interfaces de rede de cada um dos ambientes.

Performance e segurança são pilares prioritários no Cilium e ao notarmos as capacidades de criptografia e balanceamento de carga isso fica ainda mais evidente. Com o wireguard e IPsec podemos configurar criptografia para a rede interna do cluster e para as comunicações na camada de rede (L3/L4).

Com as capacidades de DSR (Direct Server Return) podemos implementar uma arquitetura performática, que garantirá a resolução das chamadas e as respostas aos clients de maneira mais veloz e precisa.

Observabilidade

Com o objetivo de estender as funcionalidades de rede e fornecer visibilidade de uma série de coisas que ocorrem dentro do cluster, podemos realizar o deployment do Hubble, solução complementar ao Cilium CNI e Service Mesh que nos permite visualizar os flows existentes dentro do nosso cluster.

Para fornecer as capacidades que temos hoje, o Hubble foi separado em alguns componentes, segregando assim as responsabilidades de cada um.

• Server - responsável por fazer a interface com o Cilium para coleta dos eventos de rede, é executado dentro do container do Cilium Agent, que por sua vez é criado à partir de um DaemonSet.

• Relay - aplicação única que centraliza os endpoints dos servers que estão sendo executados no cluster.

• Hubble CLI - componente que pode ser instalado no client para recuperar informações do ambiente.

• Hubble UI - interface gráfica que interage com o relay para disponibilizar as informações coletadas.

O desenho não mostra o Hubble CLI, que é um componente que pode ser instalado no client para que possamos interagir diretamente com o Hubble Server, pois não se faz obrigatório na instalação da solução no seu cluster.

Outra capacidade importante do Hubble é a visualização de métricas capturadas por coletores como o prometheus. Com o Hubble UI nós podemos visualizar essas métricas em formato de gráficos, tornando a identificação de problemas mais simples.

Service Mesh

A sidecar-less mesh apresentada pelo Cilium é construída por uma junção dos componentes de networking, observability e por componentes padrão do Kubernetes.

Com o uso de componentes como o Kubernetes Ingress e a Kubernetes Gateway API podemos implementar diversas capacidades que antes eram atingidas apenas com a utilização de uma tecnolgia adicional no modelo sidecar.

Com o Cilium Service Mesh podemos implementar roteamento baseado em headers, teste A/B, deployment multi-version, exposição de APIs com TLS e mTLS configurados e diversas outras funcionalidades, tudo isso sem que precisemos nos preocupar com o deployment de containers distribuídos pelos nossos clusters.

Por quê utilizar?

Se você é um SRE, DevOps Engineer, SysAdmin ou se apenas gosta de tecnologia, já pode ter percebido que gerenciar um cluster não é apenas garantir que ele esteja performando conforme o esperado. Além do “básico”, nós precisamos nos preocupar com FinOps, com as aplicações que estão sendo executadas ali “dentro”, com os add-ons do cluster (que normalmente consomem muuuuuuuitos recursos de infraestrutura, consequentemente aumentando os custos), com a segurança, controle de acesso e muitos outros pontos.

Até por “limitação” do Kubernetes muitas dessas coisas precisam de recursos adicionais para serem feitas, o que em si não é um problema, porém em determinado momento você perceberá que tem em seu ambiente recursos em execução que nem sabemos para que serve.

Pela forma em que foi arquitetado, o Cilium fornece diversas capacidades (das quais comentamos na seção anterior) de forma “nativa”, não havendo a necessidade de instalarmos soluções diferentes.

Ter essas soluções de forma nativa tornará o trabalho dos times de tecnologia muito mais simples, visto que o monitoramento do ambiente e a atualização das novas versões poderá ser implementada de maneira mais rápida.

Arquitetura

De maneira bem simplificada, o deployment do Cilium se parece com o seguinte:

Possibilitando a interação com o cluster e com seus componentes, temos do lado do client o Cilium CLI instalado no laptop do usuário. O CLI é um simples executável que facilita a instalação do Cilium e seus componentes adicionais em qualquer um que seja seu cluster.

Após instalado o Cilium CNI, você poderá habilitar outros add-ons como Prometheus e o Hubble.

Aproveitando que já falamos do Hubble, na arquitetura acima temos uma referência a um “port-forwarding“ que é configurado. O intuito deste recurso é possibilitar o acesso local do laptop ao Hubble UI, que está sendo executado dentro do cluster. Quando configurado, o usuário poderá utilizar a UI com um acesso local (por padrão, o endereço é http://localhost:12000).

É importante destacar que todos os componentes do Cilium são criados de maneira a serem altamente disponíveis, garantindo que mesmo mediante a falhas nos recursos de infraestrutura que sustentam o cluster, nossa visibilidade dos recursos e proteção da plataforma seguirão intactos!

Implementando Cilium no Azure Kubernetes Service

Para “prepararmos o terreno” para os próximos artigos, vamos realizar a criação de um cluster Azure Kubernetes Service com apenas 2 nodes para iniciarmos nossos testes e não sermos surpreendidos com uma conta gigantesca no final do mês. Os 2 nodes terão baixa capacidade computacional, porém servirão perfeitamente para o propósito que desejamos cumprir.

Para conseguirmos criar o cluster de maneira simples, execute o seguinte comando em seu terminal:

az aks create \
  --resource-group <resource-group> \
  --name <aks-cluster-name> \
  --node-count 2 \
  --node-vm-size Standard_D2plds_v5 \
  --network-plugin none \
  --enable-managed-identity \
  --generate-ssh-keys

Aguarda a criação do seu cluster e recupere suas credenciais utilizando o comando:

az aks get-credentials --resource-group <resource-group> --name <aks-cluster-name>

Com o cluster no ar e o Cilium CLI instalado na sua máquina, vamos executar o seguinte comando para instalar o Cilium CNI e deixar nosso ambiente pronto para as próximas etapas:

cilium install --version <cilium-version> --set azure.resourceGroup="<resource-group>"

Para garantir que tudo foi instalado corretamente, podemos abrir uma nova instância do terminal e executar o seguinte comando, que acompanhará a instalação fornecendo detalhes visuais do status dos componentes criados:

cilium status --wait

Na primeira instalação, apenas o Cilium e o Operator serão criados, portanto não se assuste caso veja os outros componentes marcados com “disabled“.

Por hoje é só. Espero que tenha gostado do texto e te aguardo para falarmos mais sobre essa solução nas próximas semanas.

Caso tenha alguma dúvida, não deixe de me contatar no Linkedin.

Até logo!