Progressive Delivery com Argo Rollouts: Canary que se Promove (e se Reverte) Sozinho

Existe uma diferença enorme entre "colocar código novo em produção" e "expor código novo aos usuários". Durante muito tempo tratamos as duas coisas como uma só: fazer deploy era liberar. O rolling update do Kubernetes, que substitui os Pods antigos pelos novos aos poucos, é um avanço real sobre o big bang — mas ele tem um ponto cego perigoso. Ele decide se a nova versão está saudável olhando apenas o readiness probe: o Pod respondeu na porta? Então promova. O problema é que um Pod pode subir perfeitamente, passar no health check, e mesmo assim estar servindo erro 500 para uma fração dos usuários, ou dobrando a latência, ou quebrando uma jornada de compra específica. O rolling update não sabe disso. Ele mede se o processo está vivo, não se a versão está boa.

Progressive delivery é a resposta para esse ponto cego. A ideia é expor a nova versão de forma gradual e controlada, medir o comportamento real dela com métricas de negócio e de saúde, e só avançar se os números confirmarem que ela é tão boa quanto — ou melhor que — a versão atual. Se os números pioram, o sistema recua sozinho, antes que o estrago alcance todo mundo. O Argo Rollouts é a ferramenta que traz essa disciplina para o Kubernetes de forma declarativa, e este guia mostra como ela funciona por dentro, como conectar a análise de métricas, e onde o processo costuma trair quem confia nele cegamente.

Fazer canary "na mão" não escala#

Antes do ferramental, vale entender por que você não quer implementar isso artesanalmente. A abordagem manual clássica é manter dois Deployments — app-stable e app-canary — e brincar com o número de réplicas de cada um para controlar a proporção de tráfego. Funciona para uma demonstração. Em produção, vira um pesadelo operacional: você ajusta pesos na unha, precisa lembrar de sincronizar labels e Services, o "avançar de 10% para 25%" depende de alguém acordado olhando um dashboard, e o rollback é um procedimento manual sujeito a erro justo no pior momento. Pior: a decisão de avançar fica na intuição de quem está olhando, não numa regra objetiva. Você quer que essa lógica toda — os passos, as pausas, a leitura das métricas, a promoção, o recuo — seja declarativa, versionada e automática. É exatamente isso que um controlador dedicado entrega.

O Rollout substitui o Deployment#

O Argo Rollouts introduz um novo tipo de recurso, o Rollout, que é um substituto quase drop-in do Deployment. Você troca kind: Deployment por kind: Rollout e ganha um campo novo, strategy, onde a mágica acontece. O controlador do Argo Rollouts gerencia os ReplicaSets por baixo, cria a versão canary, orquestra os passos e coordena o roteamento de tráfego. O template do Pod, os selector, os replicas — tudo continua familiar.

```yaml apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: checkout spec: replicas: 10 selector: matchLabels: { app: checkout } template: metadata: labels: { app: checkout } spec: containers:

• name: checkout

image: registry.exemplo.io/checkout:1.8.0 strategy: canary: steps:

• setWeight: 5
• pause: { duration: 5m }
• setWeight: 25
• pause: {} # pausa indefinida: exige promoção manual
• setWeight: 50
• pause: { duration: 10m }
• setWeight: 100

```

Leia os steps de cima para baixo, como uma receita. Mande 5% do tráfego para a nova versão. Espere 5 minutos. Suba para 25%. Pause indefinidamente — esse pause: {} sem duração é um portão manual: o rollout congela até alguém dar kubectl argo rollouts promote checkout. Depois vá para 50%, espere 10 minutos, e finalize em 100%. Já com isso você tem um canary declarativo com portões automáticos e manuais. Mas ainda falta o essencial: a decisão de avançar continua baseada só no tempo, não na saúde real.

AnalysisTemplate: a decisão vira dados#

O que transforma um canary temporizado num canary inteligente é a análise de métricas. O Argo Rollouts define dois objetos: o AnalysisTemplate, um molde reutilizável que descreve o que medir e qual o critério de aprovação, e o AnalysisRun, uma execução concreta desse molde durante um rollout. Você pluga a análise nos steps, e o controlador passa a consultar a sua fonte de métricas — tipicamente o Prometheus — para decidir se cada fase passou ou reprovou.

```yaml apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: taxa-de-sucesso spec: args:

• name: service-name

metrics:

• name: success-rate

interval: 1m count: 5 # 5 amostras, uma por minuto successCondition: result[0] >= 0.99 failureLimit: 2 # 2 amostras ruins abortam o rollout provider: prometheus: address: http://prometheus.monitoring:9090 query: | sum(rate(http_requests_total{service="{{args.service-name}}",code!~"5.."}[2m])) / sum(rate(http_requests_total{service="{{args.service-name}}"}[2m])) ```

Essa análise mede a taxa de requisições que não deram erro 5xx, a cada minuto, cinco vezes. A successCondition exige pelo menos 99% de sucesso; o failureLimit de 2 diz que se duas medições ficarem abaixo disso, a análise falha. E análise que falha, no Argo Rollouts, significa uma coisa só: aborte e reverta. O tráfego volta imediatamente para a versão estável, sem intervenção humana, sem alguém precisar perceber o incêndio. Para usar isso, você referencia o template dentro dos steps:

```yaml strategy: canary: steps:

• setWeight: 20
• analysis:

templates:

• templateName: taxa-de-sucesso

args:

• name: service-name

value: checkout

• setWeight: 50
• pause: { duration: 10m }
• setWeight: 100

```

Agora o rollout envia 20% do tráfego, roda a análise, e só avança para 50% se a taxa de sucesso se sustentar. Se degradar, ele recua. A decisão de promover deixou de ser opinião e virou consulta a uma métrica objetiva. Além da taxa de erro, é comum medir latência (p95, p99), taxa de saturação, ou até uma métrica de negócio direta — pedidos concluídos por minuto, por exemplo, que às vezes flagra um problema que o erro HTTP sozinho esconde.

Traffic shaping: split fino de verdade#

Há uma sutileza que separa um canary de brinquedo de um de produção: como exatamente você manda "5% do tráfego" para a nova versão? Se você depender apenas de contagem de réplicas — 1 canary contra 19 estáveis para aproximar 5% —, o controle é grosseiro e amarrado ao número de Pods. Para um split fino e independente da contagem de réplicas, o Argo Rollouts integra com a camada de rede: um Ingress controller como o NGINX, a Gateway API, ou um service mesh capaz de dividir tráfego por peso. Nessas integrações, o controlador ajusta o roteamento no próprio proxy — "encaminhe 5% para o subset canary" — sem depender de quantas réplicas existem. Isso permite começar com pesos realmente pequenos e granulares, o que é o ponto inteiro de um canary: limitar o blast radius enquanto os dados chegam.

Experiments e preview: testar antes de expor#

Além da estratégia canary, o Argo Rollouts oferece o Experiment, que sobe uma ou mais versões efêmeras lado a lado, sem lhes dar tráfego de produção, para você comparar comportamento — útil para testes A/B de infraestrutura ou para bakear uma versão sob carga sintética antes de deixá-la ver usuários reais. Há também o serviço de preview, que expõe a versão nova por um endpoint separado, permitindo que o time valide manualmente antes do primeiro setWeight. São ferramentas para os casos em que você quer olhar a versão nova de perto antes de arriscar qualquer fração de tráfego real.

kubectl argo rollouts: a visão operacional#

O dia a dia de quem opera um Rollout passa pelo plugin de linha de comando, que dá visibilidade e controle que o kubectl puro não oferece:

```bash # acompanha o progresso do rollout em tempo real, com barras por step kubectl argo rollouts get rollout checkout --watch

# libera um portão manual (pause: {}) kubectl argo rollouts promote checkout

# aborta e volta para a versão estável imediatamente kubectl argo rollouts abort checkout

# desfaz para a revisão anterior kubectl argo rollouts undo checkout ```

Esse ferramental é o que torna o processo auditável: você vê em que step está, qual o peso atual, o resultado de cada AnalysisRun, e tem os botões de emergência à mão.

As armadilhas — onde o processo trai você#

A primeira e mais grave: métrica ruim é promoção cega. Todo o valor do Argo Rollouts vem da análise, e a análise só vale o que valem as métricas que a alimentam. Se a sua query mede a coisa errada, ou se a instrumentação da aplicação está incompleta, o controlador vai promover com confiança uma versão quebrada — porque o número que ele olha diz que está tudo bem. Progressive delivery exige observabilidade confiável como pré-requisito. Não é algo que você liga por cima de um sistema mal instrumentado; é a camada que colhe o fruto de uma instrumentação madura.

A segunda: janela de análise curta demais. Se você mede por apenas um ou dois minutos com pouco tráfego, o ruído estatístico domina e a decisão vira sorte. Uma versão ruim pode passar por acaso; uma boa pode ser reprovada por uma oscilação irrelevante. Calibre o count, o interval e o failureLimit para o volume de tráfego real do serviço. Serviços de baixo volume são especialmente traiçoeiros, porque a taxa de erro calculada sobre poucas requisições balança demais.

A terceira: ignorar o warm-up. Muitas aplicações têm um comportamento pior nos primeiros segundos após subir — JIT aquecendo, cache frio, pool de conexões enchendo. Se a análise começa a medir no instante em que o canary recebe tráfego, ela captura esse transiente e pode reprovar uma versão perfeitamente boa. Um pause curto antes da análise, ou uma janela de métrica que ignore o arranque, evita esse falso negativo.

A quarta: não considerar tráfego baixo e horários mortos. Rodar um rollout às três da manhã, quando o serviço quase não recebe requisições, significa que a análise mal tem dados para julgar. O canary pode "passar" simplesmente porque ninguém exercitou o caminho quebrado ainda. Faça deploys sensíveis em janelas com tráfego representativo, ou aceite que a proteção da análise é fraca fora delas.

A quinta: confiar só na taxa de erro HTTP. Nem todo problema aparece como 5xx. Uma versão pode retornar 200 com o corpo errado, corromper dados silenciosamente, ou degradar uma métrica de negócio sem disparar erro nenhum. Combine sinais — erro, latência e pelo menos uma métrica que represente o resultado real do usuário — para fechar esses vãos.

Fechando o ciclo#

Progressive delivery com Argo Rollouts é, no fundo, a institucionalização de uma humildade saudável: a de assumir que você não sabe se a versão nova é boa até medir em produção, com tráfego real, em pequena escala. O Rollout te dá os passos declarativos; o AnalysisTemplate transforma a decisão de avançar de opinião em consulta a métricas; a integração de tráfego permite um canary fino de verdade; e o rollback automático garante que um erro seja contido em minutos e em uma fração dos usuários, não em uma madrugada inteira de firefighting. Nada disso substitui testes antes do deploy — substitui a fé cega de que passar no CI é o mesmo que estar bom para todo mundo. Configure a análise com métricas que você confia, calibre as janelas para o tráfego real, respeite o warm-up, e você terá transformado o ato mais arriscado da operação — liberar mudança — num processo que se vigia e se corrige sozinho.