Era 11h de sexta quando o time de plataforma percebeu que o ArgoCD estava reconciliando um estado errado. Ninguem sabia de onde veio a mudanca. Ninguem conseguia rastrear quem aprovou o PR. O cluster de producao estava num estado diferente do que o Git dizia que deveria estar, e a "fonte unica da verdade" tinha virado fonte de confusao.
Se voce usa GitOps sem entender a filosofia por tras da ferramenta que escolheu, voce esta gerenciando caos com interface bonitinha. Nesse artigo voce vai entender a diferenca real entre ArgoCD 3.3 e Flux 2.8 em 2026, quando usar cada um, e como evitar o principal erro que times de plataforma cometem na hora de adotar GitOps.
GitOps nao e so "coloca tudo no Git"
Antes de comparar as ferramentas, precisa ficar claro o que e GitOps de fato. A definicao oficial do OpenGitOps Working Group tem 4 principios:
- Declarativo: o estado desejado do sistema e expressado declarativamente
- Versionado e imutavel: o estado desejado esta armazenado de forma que faz cumprir imutabilidade, versionamento e mantem historico completo
- Puxado automaticamente: agentes de software puxam automaticamente as declaracoes do estado desejado do repositorio
- Reconciliado continuamente: agentes de software reconciliam continuamente o estado real com o estado desejado
O ponto que a maioria dos times pula e o terceiro: puxado automaticamente. GitOps nao e voce rodar um kubectl apply a partir de uma pipeline CI. Isso e CI/CD classico com manifests no Git. GitOps de verdade e o cluster que puxa as mudancas e as aplica sozinho.
E e exatamente ai que ArgoCD e Flux diferem na filosofia.
A diferenca filosofica que ninguem explica direito
ArgoCD e centralizado. Voce tem uma instancia do ArgoCD que gerencia multiplos clusters. Um painel. Uma API. Um ponto de controle. O ArgoCD vive num cluster (geralmente o de plataforma ou management) e de la ele aplica mudancas nos clusters de destino. Pensa num hub-and-spoke: ArgoCD no centro, clusters na borda.
Flux e descentralizado. Voce instala o Flux dentro de cada cluster. Cada cluster e autonomo: ele mesmo puxa o estado do Git e reconcilia. Nao tem instancia central. Nao tem dashboard nativo rico. Cada cluster cuida de si mesmo.
Essa diferenca muda tudo: governanca, blast radius em caso de falha, visibilidade, e escalabilidade. Nao e questao de qual ferramenta e "melhor" de forma absoluta. E qual modelo de operacao funciona para o seu time.
ArgoCD 3.3: o que mudou e como funciona na pratica
O ArgoCD 3.3 trouxe melhorias importantes no ApplicationSet controller e suporte melhorado a OCI registries para Helm charts. Mas a estrutura central continua a mesma.
Uma Application no ArgoCD define:
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: minha-api-producao
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/meuuniversonerd/k8s-manifests.git
targetRevision: main
path: apps/minha-api/overlays/producao
destination:
server: https://kubernetes.default.svc
namespace: minha-api
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
- CreateNamespace=true
Com selfHeal: true, se alguem rodar um kubectl edit deployment direto no cluster, o ArgoCD detecta a divergencia em ate 3 minutos e reverte para o estado do Git. Isso e reconciliacao continua de fato.
O ponto forte do ArgoCD e a visibilidade. O dashboard mostra o estado de todas as aplicacoes de todos os clusters gerenciados num lugar so. Voce ve em tempo real se uma aplicacao esta Synced, OutOfSync ou Degraded. Para um time de plataforma que gerencia 10, 20, 50 clusters, isso e o que mantem a sanidade.
O ponto fraco: o proprio ArgoCD vira um ponto critico de falha. Se o cluster onde ele roda tiver problema, voce perde visibilidade e controle de todos os outros clusters.
Flux 2.8: autonomia por cluster sem UI central
O Flux 2.8 reescreveu a image automation do zero, melhorando confiabilidade e performance de reconciliacao de imagens de container. Mas a filosofia continua igual.
No Flux, o equivalente da Application do ArgoCD e o Kustomization:
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
name: minha-api-producao
namespace: flux-system
spec:
interval: 5m
retryInterval: 1m
timeout: 5m
sourceRef:
kind: GitRepository
name: k8s-manifests
path: ./apps/minha-api/overlays/producao
prune: true
healthChecks:
- apiVersion: apps/v1
kind: Deployment
name: minha-api
namespace: minha-api
O Flux roda como um conjunto de controllers dentro do cluster. Ele precisa de um GitRepository que define de onde puxar:
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
name: k8s-manifests
namespace: flux-system
spec:
interval: 1m
url: https://github.com/meuuniversonerd/k8s-manifests.git
ref:
branch: main
secretRef:
name: github-credentials
O ponto forte do Flux e resiliencia e isolamento. Se um cluster tiver problema, os outros continuam funcionando independentemente. Nao tem single point of failure de plataforma. Para ambientes edge ou regulados onde cada cluster precisa ser autonomo, Flux e a escolha natural.
O ponto fraco: visibilidade distribuida e mais dificil. Voce precisa de Prometheus + Grafana + alertas configurados em cada cluster para ter a visao que o ArgoCD da de graca com o dashboard.
Quando usar cada ferramenta: a tabela de decisao
Na empresa em que trabalhei antes de focar no Meu Universo Nerd, operavamos 40 clusters de clientes diferentes com isolamento total entre eles. O Flux foi a escolha certa: cada cluster era autonomo, sem dependencia de infraestrutura central. Mas em outro projeto, com 15 microsservicos num cluster unico e um time de plataforma central, o ArgoCD fazia muito mais sentido pela visibilidade que ele oferecia.
| Criterio | ArgoCD 3.3 | Flux 2.8 |
|---|---|---|
| Multiplos clusters | Hub-and-spoke centralizado | Cada cluster autonomo |
| Visibilidade | Dashboard nativo rico | Precisa de Weave GitOps ou Grafana |
| Single point of failure | Sim (cluster do ArgoCD) | Nao (cada cluster independente) |
| Ambientes regulados (PCI, HIPAA) | Funciona, mas complica isolamento | Melhor por design |
| Curva de aprendizado | Menor (UI ajuda) | Maior (CLI-first) |
O erro que causou o incidente da 11h de sexta
O time tinha um ApplicationSet no ArgoCD gerando Applications dinamicamente. O problema: o generator estava usando glob de pastas, criando uma Application para qualquer pasta encontrada no repositorio.
# ApplicationSet problematico (evite isso)
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: microservicos
spec:
generators:
- git:
repoURL: https://github.com/meuuniversonerd/k8s-manifests.git
revision: main
directories:
- path: apps/* # qualquer pasta nova vira uma Application
template:
metadata:
name: '{{path.basename}}'
# ApplicationSet seguro (lista explicita)
apiVersion: argoproj.io/v1alpha1
kind: ApplicationSet
metadata:
name: microservicos
spec:
generators:
- list:
elements:
- app: minha-api
- app: outro-servico
- app: terceiro-servico
template:
metadata:
name: '{{app}}'
spec:
source:
path: 'apps/{{app}}/overlays/producao'
Com a lista explicita, pastas temporarias no repositorio nao viram Applications. A rastreabilidade fica no proprio YAML do ApplicationSet. E o PR de adicionar um novo servico precisa ser aprovado conscientemente.
FAQ: perguntas que surgem sempre sobre GitOps em 2026
ArgoCD e Flux podem coexistir no mesmo cluster?
Sim, mas nao e recomendado. Algumas empresas usam Flux para infraestrutura (cert-manager, ingress-nginx) e ArgoCD para aplicacoes de negocio. Funciona, mas adiciona duas superficies de aprendizado e manutencao.
GitOps substitui o Helm?
Nao. Helm e GitOps sao camadas diferentes. Voce pode usar ArgoCD ou Flux para fazer deploy de Helm charts. O GitOps e a estrategia de reconciliacao. O Helm e o formato de packaging.
E necessario para um cluster pequeno?
Provavelmente nao. GitOps adiciona complexidade. Para projetos com 1-2 devs, um pipeline CI que roda kubectl apply e suficiente. GitOps faz sentido quando voce tem multiplos ambientes, multiplos devs aplicando mudancas, ou compliance que exige rastreabilidade de deploys.
Qual performa melhor com muitas aplicacoes?
Flux costuma ter menor overhead por cluster. ArgoCD em versoes antigas tinha problemas com mais de 100 Applications. Na versao 3.x isso melhorou. Para mais de 200 Applications por cluster, vale fazer benchmark com carga real antes de decidir.
Takeaways e proximos passos
- GitOps nao e so CI/CD com Git: e o cluster que puxa e reconcilia o estado declarado automaticamente
- ArgoCD e hub-and-spoke: otimo para visibilidade centralizada, mas cria single point of failure de plataforma
- Flux e por cluster: mais resiliente e isolado por design, mas exige investimento em observabilidade propria
- ApplicationSet com glob: cuidado com autodiscovery por pasta, pode criar Applications indesejadas em producao
Voce ja usa GitOps na sua stack? ArgoCD ou Flux? Qual problema voce resolveu (ou criou) com isso? Conta nos comentarios, quero saber como esta sendo na pratica nos times brasileiros.
Na proxima semana vou entrar fundo em Flux Image Automation: como configurar o Flux para detectar automaticamente quando uma nova imagem esta disponivel no registry e abrir um PR no Git com a atualizacao. Para quem ainda toca no values.yaml manualmente para mudar a tag da imagem, isso vai mudar o fluxo de trabalho completamente.
Artigos relacionados no Meu Universo Nerd: