GitOps com Argo CD: implementando progressive delivery em Kubernetes

O modelo tradicional de deploy em Kubernetes, aquele em que alguém roda kubectl apply ou aciona um job de CI que escreve direto no cluster, funciona até certo ponto. Quando o número de clusters e times cresce, surgem perguntas difíceis de responder: o que está rodando agora corresponde ao que está no repositório? Quem mudou aquela configuração de recursos ontem à noite? Como reverter sem risco?

GitOps é a resposta para essas perguntas. A ideia central é simples: o Git contém o estado desejado do cluster, e um controlador dentro do próprio cluster é responsável por manter o estado real sincronizado com o que está no repositório. Toda mudança passa por pull request, tem histórico auditável e pode ser revertida com um git revert. O operador humano não aplica mais nada diretamente, ele escreve no Git e o controlador faz o trabalho.

O que o Argo CD faz

O Argo CD é um controlador de GitOps para Kubernetes. Ele monitora um repositório Git (ou um conjunto deles) e reconcilia continuamente os recursos do cluster com o que está definido lá. A unidade de trabalho é a Application: um objeto Kubernetes que especifica de onde buscar os manifestos (repositório, branch ou tag, caminho) e para qual cluster e namespace aplicar.

A sincronização pode ser manual, útil quando o time quer revisar antes de aplicar, ou automática, quando qualquer push na branch de destino dispara a reconciliação. Com o modo self-heal ativado, o Argo CD também corrige drift: se alguém editar um recurso diretamente no cluster, o controlador detecta a divergência e restaura o estado que está no Git dentro de instantes.

Essa detecção de drift é um dos pontos práticos mais úteis. Em ambientes com múltiplos engenheiros ou scripts de automação legados que ainda tocam o cluster, saber que qualquer desvio será visível e corrigido automaticamente reduz bastante a ansiedade em torno de "o que está realmente rodando em produção".

Organização em escala

Gerenciar dezenas ou centenas de Applications manualmente não escala. O Argo CD oferece dois padrões para isso.

O App of Apps é uma Application que aponta para um diretório com outras Applications definidas como manifestos. Ao sincronizar a raiz, todas as filhas são criadas e gerenciadas pelo Argo CD. É um padrão simples, bom para começar.

O ApplicationSet vai além: ele gera Applications dinamicamente a partir de geradores, como uma lista de clusters, diretórios de um repositório ou combinações de valores. Um único ApplicationSet pode declarar que "cada subdiretório em apps/ deve se tornar uma Application implantada no cluster de produção", sem precisar criar cada objeto manualmente. É o caminho natural quando o número de aplicações ou clusters cresce.

Por que o rolling update não é suficiente

O rolling update nativo do Kubernetes substitui pods gradualmente, o que reduz downtime, mas tem limitações. Ele não expõe a nova versão a uma fração do tráfego real enquanto mantém a anterior disponível para rollback rápido. Também não tem mecanismo para consultar métricas e decidir automaticamente se o deploy deve continuar ou abortar.

Progressive delivery é o conjunto de técnicas que preenche esse espaço. Os dois padrões mais comuns são:

• Canary: a nova versão recebe uma porcentagem pequena do tráfego (por exemplo, 5% ou 10%) enquanto a versão anterior continua atendendo o restante. O percentual aumenta em etapas, permitindo observar o comportamento da nova versão em produção com blast radius limitado.
• Blue/green: dois ambientes completos rodam em paralelo (o atual e o novo). Quando a validação termina, o tráfego é comutado integralmente para o novo. O rollback é imediato, basta comutar de volta.

Argo Rollouts

O Argo Rollouts é o complemento do Argo CD para progressive delivery. Ele substitui o Deployment padrão por um objeto Rollout, que suporta estratégias de canary e blue/green com controle fino sobre cada passo.

Um exemplo de Rollout com estratégia canary:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api-service
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10
        - pause: {duration: 5m}
        - setWeight: 30
        - pause: {duration: 10m}
        - setWeight: 60
        - pause: {duration: 10m}
      analysis:
        templates:
          - templateName: success-rate
        startingStep: 1
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
        - name: api-service
          image: registry/api-service:v2.1.0

Os passos setWeight controlam a porcentagem de tráfego direcionada à nova versão. Os passos pause pausam o avanço pelo tempo indicado, permitindo observação manual ou análise automática. O campo analysis referencia um AnalysisTemplate que define quais métricas consultar.

Análise automática com AnalysisTemplate

O AnalysisTemplate especifica as queries de métricas que o Argo Rollouts vai avaliar durante o deploy. Se os critérios forem atendidos, o rollout avança; se não forem, ele aborta e faz rollback automático para a versão anterior.

Um template simples baseado em taxa de sucesso HTTP via Prometheus:

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  metrics:
    - name: success-rate
      interval: 2m
      successCondition: result[0] >= 0.95
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(http_requests_total{
              job="api-service",
              status!~"5.."
            }[2m]))
            /
            sum(rate(http_requests_total{
              job="api-service"
            }[2m]))

O Argo Rollouts suporta outros provedores além do Prometheus: Datadog, New Relic, CloudWatch, entre outros. A lógica é a mesma: uma query retorna um valor, uma condição avalia esse valor e o resultado determina se o deploy continua.

O ponto importante aqui é que a análise automática só funciona bem se as métricas forem confiáveis. Se a cobertura de instrumentação for baixa ou os alertas já estiverem mal calibrados, o AnalysisTemplate vai ou deixar passar deploys problemáticos ou abortar deploys saudáveis. A qualidade das métricas precede a automação.

Trade-offs que merecem atenção

GitOps com Argo CD resolve problemas reais, mas traz complexidade própria.

A curva de aprendizado não é trivial. O time precisa entender o modelo de reconciliação, as diferenças entre sync manual e automático, como o self-heal interage com mudanças intencionais no cluster e como estruturar os repositórios (mono-repo versus repositórios separados para app e infra). Sem isso, o GitOps vira um obstáculo em vez de uma simplificação.

Gestão de secrets é o ponto de fricção mais comum. Não faz sentido colocar segredos em texto claro no Git, mas o controlador precisa aplicar os recursos completos no cluster. As abordagens mais usadas são o Sealed Secrets, que criptografa o secret com uma chave do cluster antes de fazer commit, e o External Secrets Operator, que busca os valores em um cofre externo (como AWS Secrets Manager ou HashiCorp Vault) em tempo de execução. Cada uma tem implicações diferentes de gestão de chaves e rotação; vale decidir antes de começar, não depois.

O Argo Rollouts adiciona uma camada de operação a mais. O objeto Rollout não é um Deployment padrão, o que pode gerar surpresas com ferramentas de observabilidade ou outros controladores que esperam o tipo canônico. É mais uma coisa para o time aprender e manter.

Como começar

A forma menos arriscada de adotar Argo CD é começar pequeno. Escolha um ou dois serviços não críticos, configure o Argo CD em modo de sync manual e passe um tempo apenas observando se o estado do cluster coincide com o que está no repositório. Essa fase revela quanto drift existe hoje e força a organização dos manifestos.

Com o padrão funcionando, mude para sync automático nos serviços onde o time se sentir confortável. O App of Apps ou ApplicationSet podem esperar até que o número de aplicações justifique o esforço.

O Argo Rollouts vale a pena quando o time já tem boas métricas de saúde dos serviços e quer reduzir o risco de deploys em produção. Introduzir Argo CD e Argo Rollouts ao mesmo tempo tende a tornar o diagnóstico de problemas mais difícil durante a fase de adoção.