Entenda por que evitar o Flux em GitOps pull-based. Uma opção melhor é o GitOps push-based com pipeline CICD — mas a melhor é o ArgoCD.
ArgoCD é a melhor opção para GitOps pull-based
Quem mexe com Kubernetes mais cedo ou mais tarde percebe o valor do GitOps. Aí vem a pergunta sobre boas práticas: vamos de ArgoCD ou FluxCD v2? Existem outras opções? Se essas dúvidas soam familiares, você está no lugar certo.
Neste artigo, vou explicar por que o Flux deve ser evitado e por que o ArgoCD é a melhor escolha para fazer GitOps pull-based. Outra alternativa que vale considerar é o GitOps push-based usando um pipeline CICD.
O que a gente esperava ganhar com o GitOps?
Para começar, ele é uma boa solução para um problema criado por uma solução anterior: Infrastructure as Code (IaC) ajuda a alcançar deployments reproduzíveis, e uma fonte de verdade garante que times grandes fiquem em sincronia, com o mínimo de comunicação extra. Só que esses benefícios da IaC dependem de o estado real da sua infraestrutura bater com o estado desejado definido no Git. O GitOps resolve esse novo problema de config drift – em que a realidade precisa ser mantida em sincronia com o git.
Usar GitOps para resolver o problema de config drift também facilita seguir o princípio do menor privilégio e simplificar o controle de acesso baseado em papéis (RBAC). Dá para abrir mão de dar acesso kubectl somente leitura para pessoas e, no lugar disso, conceder acesso somente leitura ao repositório git. O acesso kubectl direto pode ser reduzido ao mínimo, dando lugar à aplicação de RBAC em service accounts do GitOps e em repositórios git.
O GitOps também herda os controles de segurança que já existem no git. Exigir merges revisados por pares vira, na prática, exigir deployments revisados por pares. O histórico do Git pode se tornar uma trilha de auditoria de quem mudou o quê, quando a mudança aconteceu e quem aprovou.
Por que recomendo o ArgoCD em vez do FluxCD para GitOps pull-based
Resposta curta: o ArgoCD é um produto bem mais maduro e oferece uma experiência de uso superior à do Flux v2.
Primeiro, se você der push em uma config ruim com o Argo, basta fazer login SSO numa GUI: você recebe feedback visual de que há um erro, descobre onde ele está e ainda ganha uma mensagem de erro útil. Já com o Flux, é difícil até perceber que existe um erro. Para a mensagem aparecer, você precisa rodar o comando certo contra o objeto certo, no namespace certo, usando a ferramenta de CLI certa. Alguns erros aparecem no kubectl, outros no fluxctl.
Segundo, só o ArgoCD faz GitOps pull-based de verdade e entrega os benefícios citados acima. Com o Argo, dá para resolver problemas sem acesso ao kubectl. Você dá push de uma mudança no git. O Argo reconcilia o cluster com base no git de forma contínua e devolve o feedback na GUI.
Com o Flux, não dá para resolver problemas sem acesso ao kubectl. Vamos supor que você investiu o tempo necessário para montar pipelines de logging perfeitas, com alertas para expor os erros. O Flux não usa um loop de reconciliação infinito no estilo KISS como o Argo. O Flux usa um loop de reconciliação frágil, baseado em eventos, que trava com frequência em um estado ruim (mais comum com helm).
Em um trabalho anterior, treinei centenas de pessoas em GitOps com Flux. Em cada sessão de treinamento, o Flux travava para pelo menos 5 dos 20 participantes. A reconciliação para até alguém arrumar o estado confuso. Mudanças no repositório git ficam temporariamente ignoradas, então a intervenção manual é obrigatória.
A única forma de corrigir é com vários comandos fluxctl. E mais: o fluxctl depende do kubectl e, como precisamos corrigir estado, acesso somente leitura não basta. Um exemplo comum são os erros "install retries exhausted". Mesmo que você já tenha corrigido o problema no git, paciência: o Flux desistiu depois de ficar "esgotado". São necessários vários comandos fluxctl para forçar um redeploy. Dá para mudar a config padrão para retries = -1 (infinito), mas isso não resolve o problema; só faz ele travar com menos frequência. O Flux tenta executar a lógica de deployment apenas quando detecta mudanças. Existem casos extremos em que ele não consegue reconciliar porque não detectou uma mudança relacionada ao helm.
Existem casos em que o Flux é melhor que o Argo?
O ArgoCD evita de propósito algumas funcionalidades avançadas e pouco usadas do helm. Em vez disso, ele foca em estabilidade absoluta para os casos de uso mais comuns. Se você usa um helm chart muito avançado, com coisas como helm hooks, o ArgoCD pode não dar suporte. O Flux suporta melhor as funcionalidades do helm.
Que outras opções existem?
Já vi muitas vezes o seguinte padrão em times decidindo como implementar GitOps:
ArgoCD vs FluxCD vs uma quantidade exagerada de outras ferramentas que seguiram o operator pattern. Desconfio que sejam justamente essas as ferramentas que aparecem nos buscadores quando se pesquisa "GitOps".
Uma alternativa que talvez esteja passando despercebida é apontar um pipeline CICD genérico para a IaC e a lógica de scripts guardadas em um repositório git. Eu chamo essa abordagem de GitOps push-based. Sou fã dela porque permite misturar com facilidade lógica de deployment imperativa e declarativa, o que é ótimo para lidar com situações como atualizações que envolvem breaking changes. Esses casos são difíceis de resolver com uma solução de GitOps puramente declarativa e pull-based.
Para fechar
Quem está adotando GitOps pela primeira vez deveria riscar o Flux da lista de opções. ArgoCD ou um pipeline CICD são escolhas bem melhores na hora de implementar GitOps.