Estratégias de rollout: rolling, blue-green e canary

O que é

Rolling (atualização gradual): a documentação de Deployments do Kubernetes descreve a estratégia padrão assim: novos pods são criados e os antigos são removidos, e maxUnavailable e maxSurge (25 por cento cada, por padrão) definem o piso de pods disponíveis e o teto de pods adicionais; os pods antigos só são encerrados quando há pods novos suficientes em execução. progressDeadlineSeconds marca como parado um rollout que não avança, e kubectl rollout undo volta à revisão anterior. Durante o processo, as duas versões atendem requisições.

Blue-green: existem dois ambientes completos, e o tráfego muda de um para o outro em um único passo. O Argo Rollouts implementa isso com um Service ativo e um Service de pré-visualização opcional: assim que o novo ReplicaSet fica disponível, o controlador aponta o Service ativo para ele e reduz a escala do antigo depois de scaleDownDelaySeconds. Enquanto o antigo continua em execução, a reversão consiste em apontar de volta para ele.

Canary: a nova versão recebe uma pequena porcentagem do tráfego de produção. No Argo Rollouts, isso é uma lista de passos compostos por setWeight (fração do tráfego) e pause (tempo de espera ou liberação manual), opcionalmente protegidos por uma análise automática de métricas. Sem um roteador de tráfego, o controlador aproxima a fração por meio do número de réplicas: com dez réplicas e dez por cento, isso significa um pod novo e nove antigos.

Por que importa

As três estratégias trocam capacidade por risco. O rolling quase não exige reserva, mas obriga a aplicação a tolerar versões misturadas por vários minutos. O blue-green exige, por um curto período, o dobro da capacidade e, em troca, oferece uma troca e uma reversão imediatas. O canary limita quantos usuários veem um erro, mas pressupõe uma divisão de tráfego e um sinal de medição capaz de distinguir bom de ruim dentro da janela de observação.

Como aplicar

• Primeiro o básico: readiness probes que falham até o fim da inicialização; encerramento limpo ao receber SIGTERM; alterações de banco de dados no padrão expand-contract, para que a versão antiga e a nova possam rodar lado a lado.
• Rolling para serviços sem estado com versões compatíveis entre si; maxUnavailable: 0 quando a capacidade não pode diminuir.
• Blue-green quando a mistura de versões está descartada (conexões de longa duração, caches incompatíveis) ou quando se quer um ensaio geral na infraestrutura real.
• Canary quando um erro só aparece sob tráfego real e existe um sinal mensurável; defina o limite de aborto antes de iniciar.
• Feature flags como complemento: a estratégia de rollout decide qual binário está em execução; a flag decide qual comportamento está ativo.

Armadilhas

Session stickiness, caches de clientes e tempos de vida de DNS fazem com que "trocar tudo de uma vez" seja mais lento do que o planejado. Um canary com poucos por cento do tráfego raramente enxerga erros raros; a janela precisa ser longa o bastante. Migrações de banco de dados não são revertidas junto com o binário. Em um único host, sem orquestrador, as três estratégias só podem ser reproduzidas com ferramentas auxiliares; o wiki tem uma pergunta em aberto sobre isso.

O que o blue-green não separa

A troca do ponteiro do Service separa apenas os processos. Banco de dados, caches, filas e clientes são compartilhados pelos dois ambientes: durante scaleDownDelaySeconds (30 segundos por padrão no Argo Rollouts), o azul ainda processa requisições em andamento enquanto o verde já está gravando, e navegadores e aplicativos móveis mantêm a interface antiga por muito tempo após a troca. Portanto, o blue-green não elimina a mistura de versões, apenas a desloca dos processos do servidor para a camada de dados e para os clientes. Expand-contract para mudanças de esquema e respostas de API retrocompatíveis continuam obrigatórios nas três estratégias; o blue-green compensa quando o próprio estado do processo não tolera a mistura: conexões de longa duração, caches em memória com formato alterado, uma mudança de protocolo entre componentes que só são entregues juntos. A reversão imediata só vale enquanto o ReplicaSet antigo estiver em execução; depois disso, voltar é um rollout comum.