No começo do Kubernetes, cuidar de um único cluster já consumia o dia todo. Hoje, os platform engineers de grandes organizações vão muito além disso: gerenciam frotas inteiras, com dezenas ou até centenas de clusters espalhados por diferentes ambientes, regiões e unidades de negócio.
Como o Kubernetes evolui rápido, o Google Kubernetes Engine (GKE) lança com frequência novas versões com correções de segurança, melhorias de desempenho, mudanças de API e descontinuação de recursos. Esses upgrades são fundamentais para manter a plataforma segura e suportada, mas também trazem risco operacional caso a nova versão tenha incompatibilidades com seus workloads. Por outro lado, adiar upgrades por tempo indeterminado acumula dívida de segurança.
O GKE Rollout Sequencing resolve esse impasse com um pipeline de upgrade declarativo e automatizado para os seus clusters. Ele permite que as organizações tratem os upgrades de cluster com o mesmo rigor aplicado aos deploys de aplicação, avançando por etapas, aplicando períodos de soak (pausa) e garantindo que cada nova versão seja testada a fundo nos ambientes de teste antes de chegar à Produção.
Desafios dos upgrades padrão no GKE
Mesmo com um serviço totalmente gerenciado como o GKE, os upgrades padrão trazem alguns obstáculos operacionais capazes de travar uma equipe de DevOps/Platform:
- O risco do "tudo de uma vez": sem sequenciamento, todos os clusters de um Release Channel ficam elegíveis ao upgrade assim que uma nova versão vira o padrão. O resultado é que ambientes de Dev e Prod podem ser atualizados na mesma janela, se estiverem no mesmo release channel, sem tempo hábil para identificar bugs nos ambientes inferiores antes que cheguem aos clientes.
- Controle manual: muitas equipes recorrem a Maintenance Windows ou Exclusions para bloquear manualmente os upgrades em Produção enquanto testam em Desenvolvimento. Isso exige intervenção e acompanhamento constantes, sobrecarregando o time de SRE.
- Dependências e descontinuação de APIs: o Kubernetes não para. A cada versão menor (por exemplo, 1.33 para 1.34) é possível que versões específicas de APIs sejam descontinuadas. Se o upgrade atinge um cluster com Helm chart ou operator incompatível, serviços podem não subir e a indisponibilidade se prolonga.
- Version drift: na tentativa de jogar pelo seguro, as equipes acabam atualizando os clusters um a um. O efeito colateral é o version drift: cada ambiente roda uma versão de patch ligeiramente diferente, e fica impossível garantir que um bug encontrado em Produção possa ser reproduzido em um ambiente inferior.
Por que o Rollout Sequencing importa
O Rollout sequencing ataca esses desafios trazendo estrutura, previsibilidade e automação ao processo de upgrade. Veja por que ele vem se firmando como padrão na gestão corporativa do GKE:
- Ciclo de vida declarativo da infraestrutura: da mesma forma que você usa Terraform para os seus recursos, o Rollout Sequencing permite definir a política de upgrade como código. Você define a relação upstream e downstream entre os clusters, e o control plane do Google cuida da execução.
- "Soak periods" garantidos: dá para impor programaticamente um soak time (de até 30 dias). Por exemplo, exigir que uma versão rode sem erros na Staging Fleet por 7 dias antes que a Production Fleet fique elegível para ela.
- Promoção condicional: cria uma lógica de Promoção. Uma versão só avança para a próxima etapa se todos os clusters da etapa anterior tiverem sido atualizados com sucesso. É uma barreira de segurança que protege os ambientes mais críticos.
- Sincronização em escala de frota: é construído sobre o conceito de fleets, agrupamentos lógicos de clusters GKE. Em vez de configurar 100 clusters um por um, você define uma ou mais rollout sequences que regem toda a estrutura organizacional.
Estratégias de Rollout: padrão vs. personalizada
O Google oferece duas abordagens para arquitetar o pipeline de upgrade dos seus clusters, conforme a estrutura do time e a tolerância a risco.
Estratégia 1: Sequência baseada em Fleet
Essa estratégia se apoia no conceito de promoção por ambiente. Você organiza os clusters em Fleets de acordo com o ambiente (por exemplo, dev-fleet, test-fleet, prod-fleet). Todos os clusters de todos os grupos da rollout sequence precisam estar no mesmo release channel.
- Como funciona: você define uma sequência formada por fleets e configura o soak time entre cada grupo. Quando o GKE seleciona uma nova versão para upgrades automáticos no release channel, os grupos de clusters são atualizados na sequência definida, e você valida se os workloads rodam como esperado na nova versão antes que o upgrade chegue aos clusters do próximo grupo da cadeia.
Uma rollout sequence baseada em fleets
- Ideal para: organizações com agrupamentos de clusters claros e baseados em ambiente.
Estratégia 2: Rollout Sequencing com Custom Stages (Preview)
Para organizações maiores ou com necessidade de Canary, os Custom Stages oferecem uma abordagem mais cirúrgica. Em vez de movimentar uma fleet inteira de uma só vez, você usa Cluster Selectors baseados em labels.
- Como funciona: você pode criar um Canary Stage dentro da sua Production Fleet. Por exemplo, marcar 5% dos clusters de produção com
canary: true. A rollout sequence atualiza esses clusters primeiro. Se eles seguirem estáveis, a sequência avança para os clusters das demais etapas da mesma production fleet.
Uma rollout sequence com custom stages
- Ideal para: footprints globais massivos, em que até a Produção precisa ser atualizada em ondas para evitar indisponibilidade.
Como o Rollout Sequencing se integra a outros recursos de upgrade?
O Rollout sequencing é um dos vários recursos que dão a você controle sobre os upgrades no ciclo de vida do cluster.
O GKE respeita as maintenance windows e as maintenance exclusions configuradas ao atualizar clusters com rollout sequencing. O GKE só inicia o upgrade de um cluster dentro da maintenance window dele. Você pode usar uma maintenance exclusion para impedir temporariamente que um cluster seja atualizado. Se o GKE não conseguir atualizar um cluster por conta de uma maintenance window ou exclusion, isso pode impedir que os upgrades de cluster sejam concluídos no grupo.
O GKE também pausa os upgrades automáticos dos clusters de um grupo de uma rollout sequence quando detecta uso de determinadas APIs e recursos descontinuados.
O GKE Rollout Sequencing entrega um framework robusto para gerenciar upgrades de Kubernetes em escala. Com rollouts em etapas, soak periods e agrupamentos personalizáveis, as organizações reduzem bastante o risco dos upgrades sem abrir mão da velocidade.
Se você já está avaliando o Rollout Sequencing em uma prova de conceito ou quer entender melhor o recurso, a DoiT pode ajudar. Nosso time, com mais de 100 especialistas, atua em soluções de nuvem sob medida e está pronto para guiar você no processo e otimizar sua infraestrutura para compliance e demandas futuras.
Vamos conversar sobre qual estratégia de rollout faz mais sentido para a sua empresa, garantindo uma infraestrutura de nuvem robusta, em conformidade e otimizada para o sucesso. Fale com a gente hoje mesmo.