APRENDER. PRATICAR. EVOLUIR.Identificar o que realmente mudou
Começa a revisão pelo diff do Pod template. Uma annotation na metadata externa do Deployment não equivale a uma mudança do template, e escalar réplicas não cria por si só uma nova revisão da aplicação. No exercício fictício, o ticket mistura atualização de regras, aumento de capacidade e alteração de imagem. Separa a intenção de cada operação e identifica a evidência esperada. Regista versão, âmbito, responsável e condição de aceitação. Assim, a equipa pode explicar por que houve mais Pods sem atribuir ao controlador uma mudança de aplicação que não foi pedida.
Calcular as margens antes de escolher a janela
Com três réplicas e ambas as percentagens a 25%, maxSurge permite uma réplica adicional e maxUnavailable resulta em zero. O cálculo usa arredondamento para cima no primeiro e para baixo no segundo. Não interpreta estas margens como garantia contra qualquer falha. No modelo de capacidade, cada Pod novo pede 500m e existem 300m elegíveis livres: faltam 200m por CPU. O exemplo exclui init containers, sidecars e overhead, e não resolve memória ou affinity. Uma margem de réplicas autorizada não cria capacidade física para executar o próximo Pod.
Relacionar prontidão, estabilização e progresso
Um Pod Ready há dez segundos ainda pode não contar como Available se minReadySeconds exige trinta. Observa a continuidade da prontidão e os crashes relevantes antes de concluir que o controlador está atrasado. O prazo de progresso deve ser superior a esse período e coerente com o comportamento do serviço. A aula inicial já distingue deadline de rollback; aqui acrescenta a ligação entre tempos e critérios. No caso de fecho, um novo processo que responde a um endpoint simples pode continuar sem completar a operação funcional requerida. A decisão de aceitação precisa dessas duas vistas.
Pausa e terminação alteram a interpretação do estado
Enquanto um Deployment está pausado, alterações ao template não desencadeiam novos rollouts. Revê o conjunto acumulado antes de retomar, com autorização e observação adequadas. Durante a substituição, os Pods antigos podem continuar Terminating e consumir recursos. Um orçamento que ignora esse intervalo pode falhar apesar de a configuração de surge parecer suficiente. Distingue intenção, criação, disponibilidade e conclusão da terminação. Prepara a passagem de turno com timestamps, revisão em curso, alterações pendentes e capacidade observada. Não deduzas libertação de recursos apenas porque apareceu uma marca de terminação.
Reversão precisa de artefactos e dados compatíveis
O exercício configura revisionHistoryLimit=0 e estabelece que os ReplicaSets antigos já foram removidos. Nesse estado, o plano não deve prometer recuperação dessa revisão por rollout undo. Localiza uma declaração anterior aprovada e avalia o modo de a recuperar. Se a release alterou dados para um formato incompatível, reaplicar o template antigo não resolve essa dependência. Envolve aplicação e dados para decidir entre correção em frente, compatibilização ou recuperação ensaiada. Preserva resultados posteriores e identidades de operações incertas. Um comando disponível não substitui um procedimento com condições e consequências compreendidas.
Oficina: defender uma decisão de go ou no-go
Prepara uma ficha para a API fictícia de fundos: três réplicas, margens de 25%, novos Pods Pending e serviço antigo funcional. Explica a conta, apresenta os eventos da restrição e propõe opções com impacto explícito. Não baixa requests apenas para cumprir o calendário. Inclui resultado funcional, backlog e responsável pela decisão. A passagem em inglês pode dizer: “The current service remains available; the new revision is waiting for eligible capacity.” Este é um cenário documental original. O laboratório seguinte gera manifests localmente, sem executar o scheduler, o controlador ou a aplicação.
Modelo fictício: três réplicas, surge 25% → 1, unavailable 25% → 0. Um Pod de 500m com 300m elegíveis livres fica com défice de 200m pelo critério CPU; outros critérios continuam por avaliar.
Armadilhas comuns
Confundir escala com revisão; arredondar ambas as percentagens para cima; tratar Ready como Available imediato; ignorar Terminating; prometer reversão após perda de histórico e mudança de dados.
Tópicos relacionados: Workloads e estado desejado · Recursos e agendamento · Configuração e dados
O rollout precisa de margem operacional e evidência funcional. Usa a configuração para planear, observa o estado real e mantém um caminho de recuperação compatível com os dados.
Referência: Deployments · Kubernetes v1.37 concepts; current official documentation consulted 2026-09-30; cluster versions and plugin capabilities must be confirmed