Cluster API 1.12 entrega atualizações in-place e upgrades encadeados — menos downtime, mais controle

Em um ciclo de lançamento que mira diretamente nos pontos de dor de times de plataforma, o Cluster API chegou à versão 1.12 trazendo duas armas novas para operar Kubernetes em escala: atualizações in-place e upgrades encadeados. O efeito prático? Menos janelas de manutenção, menos orquestração manual e uma rota mais segura para manter clusters atualizados em 2025 e além.

O que muda com o v1.12

• In-place updates: extensões de atualização que permitem modificar Máquinas existentes sem recriá-las quando a mudança não exige dreno do nó;
• Chained upgrades: defina uma versão-alvo de Kubernetes e deixe o Cluster API planejar e executar os passos intermediários com segurança;
• Integração com práticas modernas: respeita políticas de version skew do Kubernetes, automatiza ordem de upgrade entre control plane e workers e mantém a extensibilidade como primeira classe.

Para quem administra dezenas (ou centenas) de clusters, o recado é claro: menos trabalho artesanal, mais governança via declaratividade.

Atualizações in-place: quando a imutabilidade dá espaço ao pragmatismo

O modelo clássico do Cluster API segue firme: ao mudar a especificação de uma Machine, ele costuma trocar a instância (cria nova, drena, deleta antiga). É simples, previsível e alinhado ao conceito de infraestrutura imutável. Mas nem toda alteração justifica girar um nó inteiro.

Com o v1.12, o projeto adiciona extensões de atualização capazes de aplicar mudanças in-place quando isso é seguro e faz sentido operacional. Em outras palavras, ao ajustar o estado desejado, o Cluster API agora escolhe a melhor ferramenta: rollout imutável ou atualização in-place.

O que é seguro atualizar in-place?

• Credenciais e metadados que não exigem reinicialização de kubelet ou dreno;
• Ajustes de configuração que não tocam no kernel/OS nem em componentes críticos;
• Correções de política que impactam apenas recursos Kubernetes, já suportadas sem rollouts desnecessários.

Se a alteração vai interromper cargas de trabalho de qualquer forma, o próprio Cluster API tende a optar pelo rollout imutável. Além disso, melhorias já conhecidas — como taints PreferNoSchedule em nós desatualizados e a estratégia delete-first para ambientes com pouco recurso — continuam disponíveis para controlar o impacto.

Por dentro das extensões

As update extensions permitem que plataformas definam quando e como executar atualizações in-place, preservando a natureza extensível do projeto. KubeadmControlPlane e MachineDeployments já suportam esse fluxo, o que abre espaço para políticas de mudança mais refinadas por ambiente, região ou classe de máquina.

Impacto real para times de plataforma

• Menos churn de pods, janelas menores e SLOs operacionais mais estáveis;
• Economia em ambientes bare metal e edge, onde capacidade ociosa é cara;
• Rastreabilidade melhor: mudanças pequenas ficam pequenas, sem esconder reimplantações completas atrás de cada ajuste.

Resumo: imutabilidade segue como padrão seguro, mas agora há um meio-termo pragmático — com controles — para reduzir atrito no dia a dia.

Upgrades encadeados: do n-3 ao n sem passeio turístico

Com ClusterClass e topologias gerenciadas, o Cluster API já oferecia uma base sólida para quem entrega Kubernetes como serviço interno. A partir do v1.12, chega o chained upgrade: você informa a versão-alvo (por exemplo, v1.35.0) e o sistema calcula e executa o plano, respeitando as regras de compatibilidade entre versões.

Como funciona na prática

• O Cluster API cria um plano de upgrade e executa em ordem estrita: control plane primeiro, depois workers;
• Para workers, o processo pula versões intermediárias quando permitido pela política de version skew do Kubernetes;
• Hooks de tempo de execução permitem automatizar tarefas relacionadas, como atualizar um add-on logo após o control plane concluir.

Para organizações que fazem apenas um upgrade por ano, essa abordagem reduz etapas manuais e risco de erro entre saltos de versão. Vale lembrar: facilidade para avançar mais de uma minor não substitui a necessidade de aplicar patches de segurança com frequência.

Riscos e limites (o checklist que salva madrugadas)

• Compatibilidade de CNIs, CSIs e ingress controllers pode exigir sequências específicas;
• Valide add-ons e políticas de admission control antes de encadear versões;
• Mantenha backups do etcd e testes de restauração prontos;
• Automatize pré-checks e post-checks via hooks e pipelines GitOps (Argo CD/Flux);
• Defina critérios de abort/fallback quando sinais vitais saírem do esperado.

Leitura de futuro: Kubernetes como produto interno

O v1.12 é mais um passo na virada de chave que vem desde 2024: times de plataforma tratam Kubernetes como um produto interno, com ciclos previsíveis, SLAs de upgrade e governança por políticas. In-place updates e chained upgrades compõem a caixa de ferramentas para:

• Padronizar upgrades em múltiplas nuvens e regiões;
• Reduzir downtime sem perder a segurança da imutabilidade;
• Escalar operação com previsibilidade, especialmente em edge e bare metal.

Se você estiver em Amsterdã para a KubeCon EU 2026, vale ficar de olho nas sessões que detalham o equilíbrio entre infraestrutura imutável e mutável com o Cluster API — o assunto rende e a prática conta.

Como começar (e não virar cobaia do próprio ambiente)

• Atualize suas dependências para o Cluster API v1.12 e valide pré-requisitos;
• Habilite as extensões de atualização e defina políticas claras para quando usar in-place;
• Modele um upgrade encadeado em ambiente de staging com telemetria e rollback testados;
• Automatize pós-passos (add-ons, CRDs, validações) via hooks;
• Audite sua estratégia: SLO de upgrade, janela máxima e critérios de sucesso;
• Observe indicadores de saúde (control plane, etcd, latência de API) durante e após cada etapa.

No balanço, o v1.12 acelera a rotina de mudanças sem abrir mão de controles. Para quem vive entre janelas de manutenção e pressão por compliance, é uma atualização que merece lugar no roteiro de 2026.

Fonte original: Kubernetes.io