O kubernetes nos fornece um recurso fantástico para atualizar os pods de nossa aplicação de forma controlada sem que a mesma saia do ar. O componente do kubernetes que nos fornece esse recurso é o Deployment.

Agora, vamos imaginar um cenário em que um dado conjunto de pods é atualizado e a atualização que subiu esteja errada e seja preciso retornar imediatamente para a versão anterior do nosso código. O kubernetes controla o histórico de cada um de seus componentes sendo possível subir qualquer uma das versões anteriores à atual.

A figura abaixo representa o histórico de versões de um determinado pod:

A versão NGINX-POD-V4 na imagem é a versão atual do projeto, a que acabamos de publicar. Agora, em nosso caso hipotético precisamos voltar para a versão anterior, NGINX-POD-V3. Em teoria o kubernetes apontaria para a versão selecionada e a publicaria no lugar da atual. Mas na prática não é isso que vai acontecer.

Ao voltar uma versão do histórico do kubernetes uma nova versão será criada com base na versão selecionada, como ilustra a figura abaixo:

Seguindo essa lógica, caso precise voltar para o NGINX-POD-V4 o kubernetes vai gerar um NGINX-POD-V6 e assim por diante mantendo todo o histórico de versões da sua aplicação.