Aula 7: Rolling updates e rollback
Já temos um Deployment que mantém várias cópias (Pods) da aplicação. Mas o que acontece quando você quer lançar uma nova versão — por exemplo, trocar a image de nginx:1.27 para nginx:1.28? O jeito ingênuo é derrubar tudo e reconstruir, mas aí o serviço cai por alguns segundos e todo usuário sente. O
É como trocar as rodas de um carro em movimento sem parar — você troca uma roda de cada vez, então o carro continua andando. E se a roda nova estiver torta, é só recolocar a antiga.
- Rolling Update
- Uma forma de atualizar um Deployment sem tempo de inatividade: o Kubernetes substitui os Pods antigos por novos gradualmente, alguns de cada vez, de modo que sempre restam cópias ativas suficientes para atender às requisições.
- Rollback
- Retornar o Deployment para a revisão anterior que funcionava, quando a nova versão se revela com problema. O comando kubectl rollout undo faz isso em um único passo.
- Status do Rollout
- Acompanhamento ao vivo do progresso de uma atualização: quantos Pods já foram atualizados do total, até que a mensagem confirme que a atualização foi concluída com sucesso.
- maxUnavailable
- Quantos Pods podem ficar indisponíveis ao mesmo tempo durante um rolling update. Um valor baixo mantém mais cópias ativas a cada momento, mas deixa a atualização mais lenta.
- maxSurge
- Quantos Pods extras além do alvo podem ser criados temporariamente durante uma atualização, para que novas cópias já estejam prontas antes de remover as antigas.
- Revisão
- Uma versão salva do Deployment. Cada atualização cria uma nova revisão, e o Kubernetes guarda as anteriores para que seja possível voltar a elas.
