O Google Cloud anunciou que seu serviço GKE agora oferece atualizações de plano de controle em duas etapas em disponibilidade geral, permitindo que os clientes separem a atualização do binário do software da migração do formato de dados e mantenham uma janela de rollback aberta durante mudanças de versões minor.

Por que o GKE precisava de um caminho mais seguro

Atualizar um plano de controle do Kubernetes de uma versão minor para a próxima sempre envolveu riscos. Uma mudança da 1.33 para a 1.34 não apenas substitui os binários, mas também reescreve as estruturas de dados subjacentes. Se a nova versão contiver um bug, o cluster não pode ser simplesmente revertido; os administradores devem restaurar snapshots antigos do banco de dados ou reconstruir todo o cluster, um processo demorado e propenso a erros.

Como funciona a atualização em duas etapas

O novo fluxo divide a atualização em duas fases distintas:

  • Etapa 1 – Atualização de binários (modo emulado). O GKE substitui os binários do plano de controle pela versão de destino, preservando o formato de dados antigo. Como nenhuma nova estrutura de dados é escrita, o cluster permanece seguro para rollback durante toda esta fase.
  • Etapa 2 – Finalização. Após um período de espera configurável, o GKE converte os dados armazenados para o novo formato. Assim que esta conversão termina, realizar um rollback exigiria o mesmo esforço de restauração de snapshot que o processo de duas etapas foi projetado para evitar.

A separação cria uma "janela de observação" (soak window) onde os operadores podem observar os binários atualizados em produção sem se comprometer com a migração de dados irreversível.

A janela de observação na prática

O GKE monitora automaticamente métricas de saúde essenciais durante o período de observação — latência de API, taxas de erro e saúde dos pods. Se o serviço detectar anomalias, ele interrompe o rollout, deixando o cluster no estado de apenas binários, onde um rollback ainda é possível. O Google cita uma taxa de sucesso de 99,999% para atualizações que seguem esse padrão.

Para clusters que utilizam o recurso de auto-upgrade do GKE, a plataforma orquestra toda a sequência de duas etapas sem intervenção manual. Usuários que preferem controle total podem invocar o processo por meio da Cloud CLI ou Terraform.

Executando uma atualização manual em duas etapas

Uma atualização manual típica com uma janela de segurança de 48 horas é assim:

gcloud beta container clusters upgrade my-cluster \
  --location=us-central1 \
  --cluster-version=1.34.1-gke.1829001 \
  --control-plane-soak-duration=48h \
  --master

Para inspecionar o status atual:

gcloud container clusters describe my-cluster \
  --location=us-central1 \
  --format="yaml(rollbackSafeUpgradeStatus)"

Se um defeito surgir durante a observação, o administrador pode emitir um comando de rollback e reverter para a versão anterior sem perda de dados. Quando o cluster se mostrar estável, a atualização pode ser concluída antecipadamente com o comando complete-control-plane-upgrade.

Limites e requisitos

  • O recurso se aplica a clusters GKE executando a versão 1.33 ou posterior.
  • Apenas uma versão minor pode ser atualizada por vez; pular versões não é suportado.
  • Tanto os clusters Autopilot quanto os regionais permanecem disponíveis durante todo o processo de duas etapas.

Possíveis desvantagens

Separar as atualizações de binários e de dados adiciona uma etapa extra ao cronograma de atualização, o que pode estender a janela geral para organizações que precisam de mudanças rápidas de versão. O período de observação também depende de verificações de saúde automatizadas; equipes que executam cargas de trabalho altamente customizadas podem precisar complementar o monitoramento do GKE com suas próprias ferramentas de observabilidade para detectar regressões em casos extremos.

O que observar a seguir

O Google não divulgou um roadmap para estender o modelo de duas etapas para atualizações de versões major, que ainda exigem a recriação completa do cluster em muitos casos. Observadores estarão atentos a anúncios sobre redes de segurança semelhantes para atualizações de node-pools e para qualquer integração com pipelines de CI/CD de terceiros que possa automatizar as verificações da janela de observação.

Resumo: Ao desacoplar as atualizações de binários das migrações de dados, o GKE oferece aos engenheiros de plataforma uma janela de rollback prática para mudanças de versões minor, reduzindo o custo operacional da manutenção do cluster e mantendo o tempo de inatividade no mínimo.