Implantações rolling, blue-green e canary: comparação

O que é

Atualização rolling: a documentação de Deployment do Kubernetes (citada) descreve a estratégia padrão como a criação de novos Pods e a remoção dos antigos dentro de dois limites, maxUnavailable e maxSurge (ambos com 25 por cento por padrão). Os Pods antigos só são removidos depois que um número suficiente de novos Pods estiver em execução, e progressDeadlineSeconds marca um rollout que travou. Durante o rollout, as duas versões atendem tráfego.

Blue-green: existem duas stacks completas, e o tráfego é trocado da stack ativa para a nova em um único passo. A documentação do Argo Rollouts (citada) implementa isso apontando um Service ativo e um Service de preview opcional para ReplicaSets diferentes. Quando o novo ReplicaSet fica disponível, o Service ativo é alterado para apontar para ele, e o conjunto antigo é reduzido depois de um intervalo.

Canary: a nova versão recebe uma pequena porcentagem do tráfego de produção, que é aumentada por etapas. A estratégia canary do Argo (citada) expressa isso como uma lista de etapas setWeight e pause, opcionalmente condicionadas por uma análise automatizada de métricas.

Por que importa

As estratégias trocam capacidade por risco. A rolling exige pouca capacidade adicional, mas obriga a aplicação a tolerar versões mistas durante minutos. A blue-green exige capacidade dobrada por um curto período, mas oferece troca e rollback instantâneos enquanto a stack antiga ainda está em execução. A canary limita o número de usuários expostos a um defeito, mas requer divisão de tráfego e uma métrica que distinga de forma confiável o bom do ruim dentro da janela de observação.

Como aplicar

• Antes de tudo, crie as condições para qualquer estratégia: verificações de readiness que falhem enquanto o processo não estiver pronto, encerramento gracioso em SIGTERM, e alterações de banco de dados e respostas de API retrocompatíveis, para que versões antigas e novas possam coexistir.
• Use rolling em serviços stateless com versões compatíveis; configure maxUnavailable: 0 quando a capacidade não puder diminuir.
• Use blue-green quando uma mistura de versões for inaceitável (conexões de longa duração, caches incompatíveis) ou quando se quiser um ensaio na infraestrutura real antes da troca.
• Use canary quando um defeito só apareceria sob tráfego real e existir um sinal mensurável (taxa de erros, latência, métrica de negócio); defina o limite de aborto antes de começar.
• Combine com feature toggles: a estratégia de implantação controla qual binário está em execução, e o toggle controla qual comportamento está ativo.

Armadilhas

Session stickiness, caches de clientes e TTLs de DNS fazem a "troca do tráfego de uma só vez" ser mais lenta do que o esperado. Uma canary que recebe uma pequena parcela do tráfego só vê erros raros raramente; por isso, sua janela precisa ser longa o bastante para ser conclusiva. As migrações de banco de dados não sofrem rollback junto com o binário.

Blue-green não isola o estado compartilhado

Blue e green compartilham o banco de dados, a fila e todos os demais serviços de apoio. Assim, desde o momento em que a nova stack inicia (health checks, aquecimento, tráfego de ensaio), as duas versões leem e gravam os mesmos dados, e, após a troca, a stack antiga continua conectada durante a janela de rollback. A mistura de versões que a blue-green elimina é, portanto, apenas a de natureza local ao processo: caches em memória, sessões sticky, conexões de longa duração, formatos incompatíveis em disco dentro da instância. Mudanças de esquema e de formato de mensagens exigem a mesma disciplina de expand-and-contract de uma atualização rolling, e o rollback instantâneo só vale até que a nova versão grave algo que a antiga não consiga ler. Escolha blue-green para incompatibilidades locais ao processo ou para um ensaio na infraestrutura real; não a escolha para evitar alterações de dados retrocompatíveis.