Como acelerar a configuração do cluster do Kubernetes usando o FluxCD – Parte 1

Já teve que criar um novo cluster de Kubernetes e pensou: “Ah não, cadê o HelmChart que eu usei para instalar o operador X no cluster atual?”. No mundo corporativo, ter que provisionar novos clusters de Kubernetes pode ser uma tarefa recorrente e dolorosa. Seja para testes de Recuperação ao Desastre, segregação de departamentos, testes de novas funcionalidades/operadores/versões, existe sempre configuração mínima necessária a ser feita antes do solicitante começar a rodar workloads no cluster.

É verdade que a parte de “criação dos recursos” é facilmente resolvida com Infraestrutura como código (com ferramentas como Terraform ou CloudFormation), mas depois disso, ainda existe uma etapa de “configuração do cluster” onde temos que instalar e configurar uma série de componentes para garantir uma boa experiência para os usuários do cluster.

A maior parte das empresas fazem estas configurações com uma série de scripts e automações que estão frequentemente desatualizadas se comparados ao estado atual do cluster, seja por atualização de versões, mudança de funcionalidades e etc. É ai que o framework de GitOps e o FluxCD entram! A ideia do post de hoje é mostrar como usar GitOps para além do tradicional cenário de “configurações de workload” e demonstrar como acelerar o processo de configuração do cluster com FluxCD.

O operador FluxCD

FluxCD é uma ferramenta para gerir automaticamente aplicações em Kubernetes utilizando os princípios de GitOps. O operador monitora continuamente os repositórios do Git em busca de alterações para aplicar ao cluster, permitindo assim um gerenciamento declarativo e automatizado da infraestrutura. Para cumprir esta tarefa, o FluxCD utiliza dois recursos principais:

1. GitRepository: Este recurso é responsável por monitorar o repositório Git em que os manifestos de infraestrutura estão armazenados e garante que o FluxCD tem sempre a última versão dos arquivos.
2. Kustomization: Este recurso permite que você customize os manifestos durante o processo de implementação no cluster.

O operator também adiciona suporte para instalações baseadas em HelmCharts com os recursos HelmRepository e HelmRelease, que, neste caso, serão essenciais para aplicarmos os conceitos de GitOps para além do básico e automatizar a configuração do nosso cluster de Kubernetes de maneira declarativa, sem ter que executar comandos da Helm CLI.

Organizando os componentes em manifestos

A primeira etapa será criar um repositório Git e adicionar os manifestos que iremos aplicar no cluster de Kubernetes. Para este laboratório, criei o repositório k8s-base-config no GitHub com duas pastas principais:

1. global-config: os manifestos incluídos nessa pasta serão aplicados automaticamente durante a instalação do FluxCD.
2. extra-capabilities: Os manifestos incluídos nesta pasta só serão aplicados se forem declarados explícitamente.

Como exemplo, vamos considerar que o KEDA é um operador que deve ser ativado em todos os clusters por padrão quando o FluxCD for instalado. Para isso, uma pasta chamada “keda-operator” foi criada dentro da pasta global-config com os arquivos a seguir:

#### helmrepository.yml
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: HelmRepository
metadata:
  ## Nome do repositório
  ## Mesmo valor utilizado no comando "helm repo add [NAME]"
  name: keda-operator 
  namespace: flux-system 
spec:
  ## Intervalo que o flux irá procurar por novas versões.
  interval: 5m0s
  ## Link do repositório Helm do operador que você deseja instalar.
  ## Mesmo valor utilizado no comando "helm repo add [NAME] [URL]".
  url: https://kedacore.github.io/charts 
  
#### helmrelease.yml
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  ## Nome da instalação Helm
  ## Mesmo valor utilizado no comando "helm install [NAME]".
  name: keda-operator 
  namespace: flux-system
spec:
  ## Intervalo para aplicar a última configuração em caso de nova versão disponível. 
  interval: 5m0s 
  chart:
    spec:
      ## Chart field must be the name of the helmchart. 
      ## O nome do HelmChart que será aplicado.
      ## Mesmo valor utilizado no comando "helm install [NAME] [CHART]".
      chart: keda 
      ## Versão que será instalada.
      ## Mesmo valor utilizado no parâmetro "--version".
      version: '2.*'
      ## SourceRef deve conter o mesmo nome utilizado no arquivo helmrepository.yml.
      sourceRef:
        kind: HelmRepository
        name: keda-operator
    install:
      createNamespace: true
  targetNamespace: keda

### kustomization.yml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- helmrepository.yml
- helmrelease.yml

Se você deseja adicionar outros componentes, basta adicionar mais pastas e manifestos ao seguindo o exemplo acima.

Instalando o KEDA e os componentes globais

O FluxCD deve ser instalado no cluster de Kubernetes utilizando o FluxCLI. Para instalar a CLI, execute o comando a seguir:

brew install fluxcd/tap/flux

Caso você não utilize homebrew, você pode encontrar mais opções de instalação aqui: Install the FluxCLI

Com a CLI instalada, o comando flux bootstrap será utilizado para instalar o operador. Já que estamos utilizando GitHub, vamos executar o comando a seguir para iniciar a instalação:

### Um Personal Access Token (PAT) com acesso de leitura e escrita no repositório deve ser fornecido.
export GITHUB_TOKEN=<myPAT> 

flux bootstrap github \
  --token-auth \
  --owner=diego7marques \
  --repository=k8s-base-config \
  --branch=main \
  --path=global-config \
  --personal

E pronto! O FluxCD e os componentes declarados na pasta global-config serão instalados. Você pode ver o quão rápido isto acontece no nosso exemplo:

Conclusão

O FluxCD prova ser uma ferramenta poderosa para nos ajudar a acelerar o processo de inicialização de novos clusters do Kubernetes, garantindo consistência e conformidade contínua na configuração e no gerenciamento do cluster. Com todos os componentes declarados em um repositório, é possível garantir o estado do cluster e gerenciar todo o ciclo de vida das configurações de uma forma muito mais simples e transparente.

Para evitar uma postagem longa e tediosa, decidi dividi-la em duas partes. Na segunda seção, abordaremos como gerenciar e ativar recursos específicos com um controle mais refinado. Aguarde 🙂