O Kubernetes criará uma nova réplica com a imagem webapp:2.0, substituindo os pods antigos somente após todos os novos estarem prontos, garantindo zero downtime.

A estratégia RollingUpdate com maxUnavailable: 1 e maxSurge: 1 permite que, durante a atualização, no máximo um pod antigo seja encerrado e um novo seja criado além do número original de réplicas, respeitando a disponibilidade.

A readiness probe é usada apenas para reiniciar automaticamente os pods que falharem após o initialDelaySeconds, e não influencia o processo de atualização.

A estratégia RollingUpdate ignora os parâmetros maxUnavailable e maxSurge se a imagem for atualizada com a mesma tag.