Service Configuration Question #019e3a4f

Resumo

No Kubernetes, a estratégia de implantação RollingUpdate é a abordagem nativa que suporta atualizações com zero downtime. Ela substitui gradualmente os Pods antigos por novos, garantindo que o aplicativo permaneça disponível durante todo o processo de atualização.

Como Funciona

Quando um Deployment é configurado com strategy.type: RollingUpdate, o Kubernetes atualiza os Pods de forma incremental. Ele cria novos Pods com a especificação atualizada enquanto encerra os antigos, mantendo um número configurável de Pods disponíveis em todos os momentos. Os parâmetros maxUnavailable e maxSurge controlam o ritmo da implantação. Por padrão, maxUnavailable é 25% e maxSurge é 25%, significando que no máximo 25% dos Pods desejados podem ficar indisponíveis durante a atualização, e até 25% de Pods extras podem ser criados acima da contagem desejada. Isso garante que o serviço continue atendendo ao tráfego sem interrupção.

Por que RollingUpdate é Correto

• Zero downtime: A atualização contínua garante que um número mínimo de Pods esteja sempre em execução, então o serviço permanece disponível.
• Nativo do Kubernetes: É a estratégia padrão para Deployments e está totalmente integrada com os controladores e APIs do Kubernetes.
• Configurável: Administradores podem ajustar a velocidade da implantação e as garantias de disponibilidade através de maxUnavailable e maxSurge.

Por que as Outras Opções são Incorretas

• Canary: Embora implantações canary possam alcançar zero downtime, elas não são uma estratégia de implantação nativa do Kubernetes. Elas exigem ferramentas adicionais (ex: service mesh, controladores de ingress) para rotear um subconjunto de tráfego para a nova versão. O Kubernetes não fornece suporte canary embutido para Deployments.
• Recreate: Esta estratégia encerra todos os Pods existentes antes de criar novos. Ela causa downtime porque o aplicativo fica indisponível durante a transição. É adequada para desenvolvimento ou quando o downtime é aceitável.
• BlueGreen: Implantações blue-green envolvem executar dois ambientes idênticos (blue e green) e alternar o tráfego entre eles. Embora isso possa alcançar zero downtime, não é uma estratégia nativa de Deployment do Kubernetes. Requer balanceadores de carga externos ou configurações de service mesh. O Kubernetes não possui uma estratégia BlueGreen embutida para Deployments.

Conclusão

Para atualizações nativas com zero downtime no Kubernetes, a estratégia RollingUpdate é a escolha correta e padrão. Ela está incorporada no recurso Deployment e fornece um mecanismo confiável e configurável para atualizar workloads sem interrupção de serviço.