Kubernetes: o fecho de cherry-picks é hoje — a mudança segura começa antes de 11 de agosto
O calendário oficial fixa 7 de agosto como prazo de cherry-pick e 11 de agosto como alvo para a edição mensal de patches. O próprio projeto avisa que as datas podem variar: hoje é o momento de fechar o ensaio, não de instalar uma versão que ainda não foi publicada.
- Natureza
- Calendário operacional e plano de mudança para Kubernetes
- Público
- SRE, plataforma, segurança, produto e responsáveis de serviço
- Publicado e verificado
- 7 de agosto de 2026
- Rever quando
- A página de patch releases publicar versões, changelogs ou alteração de datas
Em resumo
A página oficial indica próximas correções para as séries 1.36, 1.35 e 1.34, mas não transforma o target date num compromisso imutável. Também mostra que 1.34 entra em maintenance mode a 27 de agosto e termina suporte a 27 de outubro; 1.33 já terminou suporte em 28 de junho. Uma equipa preparada verifica ramo suportado, version skew, APIs removidas, capacidade de drenar, PodDisruptionBudgets, backup/restauro, canário, observação e rollback antes de tocar em produção.
- 7 de agosto é prazo do processo de release para cherry-picks; não é uma ordem universal para atualizar hoje.
- 11 de agosto é target date e pode mudar com a gravidade e maturidade das correções.
- Clusters 1.33 estão fora de suporte segundo o calendário; 1.34 aproxima-se de maintenance mode em 27 de agosto.
- O gate de produção exige compatibilidade, disponibilidade, restauro e reversão testados com a versão efetivamente publicada.
Hoje fecha a seleção; a versão candidata ainda precisa de existir e ser lida
O projeto Kubernetes publica um ciclo mensal para facilitar planeamento. Em agosto, o prazo de cherry-pick é 7 de agosto e a data-alvo é 11 de agosto. O texto diz expressamente que os prazos podem variar consoante a gravidade das correções e que podem existir releases críticas fora do ciclo. Logo, um calendário interno deve esperar pelo anúncio e changelog reais.
A mesma página indica 1.36, 1.35 e 1.34 como ramos ativos. O ramo 1.34 entra em manutenção em 27 de agosto e chega ao fim de vida em 27 de outubro. O 1.33 terminou suporte em 28 de junho. Um cluster fora de suporte não deve ser escondido dentro do mesmo ticket de patch: precisa de um plano de atualização de minor version, com risco e janela próprios.
Janela oficial e decisão interna
- 7 AGOCherry-pick deadline
O processo de release fecha a seleção planeada de correções.
- 11 AGOTarget date
Data-alvo oficial; só o anúncio final confirma versões e conteúdo.
- 27 AGO1.34 em manutenção
O ramo aproxima-se da fase de manutenção antes do fim de vida de outubro.
- 27 OUTFim de vida 1.34
Clusters restantes precisam de uma rota de upgrade concluída antes desta data.
O preflight tem seis provas; “é só patch” não é uma delas
Confirme primeiro a versão de kube-apiserver, kubelet, kube-proxy, kubectl, runtime, add-ons e ferramentas de gestão. A version skew policy define combinações suportadas; não presuma que todos os componentes podem saltar em qualquer ordem. Depois, procure APIs removidas ou depreciadas usadas por manifests e controladores.
Disponibilidade precisa de capacidade real. PodDisruptionBudgets limitam interrupções voluntárias, mas não criam recursos nem corrigem aplicações com uma única réplica. Verifique drain, afinidade, volumes, admission webhooks, DNS, ingress, CNI, CSI e observabilidade num ambiente representativo. Para kubeadm, siga a ordem e os passos documentados para control plane e workers.
Preflight antes de 11 de agosto
| Prova | Pergunta | Evidência | Bloqueio |
|---|---|---|---|
| Suporte | O minor version recebe correções? | Matriz de ramos e EOL | 1.33 ou outro ramo sem suporte |
| Compatibilidade | Componentes respeitam version skew? | Inventário por node e control plane | Versão desconhecida ou ordem inválida |
| API | Há recursos removidos/depreciados? | Scan de manifests, CRDs e controladores | API sem rota de migração |
| Disponibilidade | Drain cabe na capacidade e no PDB? | Ensaio, réplicas, capacidade e tempos | Eviction bloqueada ou saturação |
| Estado | Backup restaura dados e configuração? | Restauro isolado com tempo medido | Backup nunca restaurado |
| Reversão | Qual é o ponto sem retorno? | Runbook, snapshot, owner e critério | Rollback descrito apenas como “voltar atrás” |
Da publicação à produção: quatro gates e uma observação sem pressa
Quando a release for publicada, leia o changelog por componente e confirme artefactos oficiais. Aplique primeiro num laboratório com cópia representativa de configuração; depois num canário com carga real controlada; avance para um domínio de falha de produção; só então expanda. Entre gates, compare SLOs, erros de API, restarts, latência, filas, DNS, armazenamento e eventos.
Defina antecipadamente quanto tempo observar e que sinal interrompe. A ausência de erro imediato não prova estabilidade. Guarde comandos, versões, tempos, decisões e diferenças. Se um rollback completo de control plane não for suportado no seu método, o plano precisa de restauração e reconstrução ensaiadas, não de uma promessa.
- Não fixe o número da patch release antes do anúncio oficial.
- Mantenha um dono por gate e um decisor de rollback disponível.
- Pare se a telemetria crítica falhar durante a janela.
- Separe upgrade de minor version de aplicação de patch sempre que o risco for diferente.
Fontes consultadas
Consultadas na data de atualização indicada.
Abre numa nova janela.- 01Kubernetes patch releasesKubernetes · SYS-KUBERNETES
- 02Kubernetes release and maintenance branchesKubernetes · SYS-KUBERNETES
- 03Version skew policyKubernetes · SYS-KUBERNETES
- 04Upgrading kubeadm clustersKubernetes · SYS-KUBERNETES
- 05Specifying a disruption budget for an applicationKubernetes · SYS-KUBERNETES
- 06Deprecated API migration guideKubernetes · SYS-KUBERNETES
Participar
Partilhe a análise. Acrescente contexto.
Divulgue a matéria no seu canal ou deixe uma observação ligada ao tema.
Comentários
A carregar a conversa.