Upgrades de cluster de Autopilot

Nesta página, você verá como os upgrades automáticos funcionam nos clusters de Autopilot do Google Kubernetes Engine (GKE), incluindo links para mais informações sobre tarefas e configurações relacionadas. Use essas informações para manter seus clusters atualizados e ter estabilidade e segurança com interrupções mínimas nas cargas de trabalho.

Upgrades automáticos de nós e planos de controle

Os upgrades automáticos estão ativados em todos os clusters do Autopilot. O GKE inicia upgrades automáticos quando as versões do GKE são selecionadas para upgrade automático, observa upgrades automáticos em todos os clusters e intervém em caso de problemas, como nós não íntegros. Não é possível desativar os upgrades automáticos. No entanto, é possível controlar o tempo deles com janelas de manutenção e exclusões.

Para fazer upgrade de um cluster, o GKE atualiza a versão que o plano de controle e os nós estão executando. Os clusters são atualizados para uma versão secundária mais recente (por exemplo, da 1.24 para a 1.25) ou para uma versão de patch mais recente (por exemplo, da 1.24.2-gke.100 para a 1.24.5-gke.200). Para mais informações, consulte Controle de versão e suporte do GKE.

Todos os clusters do Autopilot são inscritos em um canal de lançamento. Portanto, o GKE faz o upgrade automático do plano de controle e dos nós para executar a mesma versão do GKE.

O GKE faz upgrade do plano de controle de um cluster antes de fazer upgrade de nodes.

Upgrades automáticos do plano de controle

Todos os clusters do Autopilot são clusters regionais. Clusters regionais têm várias réplicas do plano de controle e apenas uma é atualizada por vez, em uma ordem indefinida. Isso garante que o cluster permaneça altamente disponível durante os upgrades automáticos. As réplicas do plano de controle não estarão disponíveis enquanto o upgrade estiver em andamento.

Se você definir uma janela ou exclusão de manutenção, o GKE respeitará a configuração, se possível.

O GKE não pode criar novos nós quando um upgrade do plano de controle está em andamento. Se você implantar pods que exigem novos tipos de nó enquanto um upgrade do plano de controle estiver em andamento, poderá haver atrasos até que o upgrade do plano de controle seja concluído.

Upgrades automáticos de nós

Depois que o GKE faz upgrade do plano de controle do cluster do Autopilot,- o GKE faz upgrade dos nós para a mesma versão do GKE.

No piloto automático, o GKE agrupa nós que compartilham características semelhantes. O GKE usa upgrades súbitos em nós do Autopilot, fazendo upgrade de até 20 nós em um grupo ao mesmo tempo. O número exato de nós atualizados ao mesmo tempo varia para garantir a alta disponibilidade contínua de nós e cargas de trabalho.

Os upgrades de nó podem levar várias horas, dependendo do número de nós e da configuração das cargas de trabalho em execução nos nós. Por exemplo, as configurações a seguir podem contribuir para upgrades mais longos:

Se você definir uma janela ou exclusão de manutenção, o GKE respeitará a configuração, se possível.

Quando o GKE faz upgrade de um nó, estas etapas ocorrem:

  1. O GKE cria um novo nó súbito com a nova versão do GKE e aguarda o registro do nó súbito no plano de controle.
  2. O GKE seleciona um nó atual, o nó de destino, para fazer o upgrade.
  3. O GKE limita o nó de destino, impedindo que novos pods sejam colocados nele.
  4. O GKE arrasta o nó de destino, removendo pods atuais dele.

  5. O GKE reprograma os pods gerenciados por um controlador de carga de trabalho em outros nós disponíveis. Os pods que não podem ser reprogramados permanecem no estado PENDING até que o GKE possa reprogramá-los.

  6. O GKE exclui o nó de destino.

Se um número significativo de upgrades automáticos para uma versão específica do GKE resultar em nós não íntegros na frota do GKE, o GKE interromperá os upgrades para essa versão enquanto investigamos o problema.

Como as versões são selecionadas para o upgrade automático

O GKE lança novas versões secundárias regularmente, mas uma versão lançada não é selecionada imediatamente para upgrades automáticos. Para se qualificar como um destino de upgrade automático, a versão do GKE precisa acumular uso suficiente para comprovar a estabilidade ao longo do tempo.

Em seguida, o Google Cloud seleciona essa versão como um destino de upgrade automático para clusters que executam um subconjunto específico de versões mais antigas do GKE. Por exemplo, assim que uma nova versão secundária é disponibilizada, a versão secundária mais antiga disponível geralmente fica sem suporte. O GKE faz upgrade dos clusters que executam versões secundárias sem suporte para a versão de destino do upgrade automático.

O GKE anuncia novas versões de destino do upgrade automático nas notas de lançamento. Às vezes, uma versão é selecionada para upgrades automáticos do plano de controle e de nós durante semanas diferentes. O GKE faz upgrade automaticamente para novas versões de patch em uma versão secundária (como v1.21.x).

Para informações sobre o ciclo de vida e o esquema de controle de versão, consulte Controle de versão e suporte do GKE.

Fatores que afetam o tempo de lançamento da versão

Para garantir a estabilidade e a confiabilidade dos clusters em novas versões, o GKE segue algumas práticas durante os lançamentos das versões.

Alguns exemplos dessas práticas incluem:

  • O GKE lança gradualmente as alterações nas regiões e zonas do Google Cloud.
  • O GKE lança gradualmente as versões de patch nos canais de lançamento. Um patch recebe tempo de imersão no canal de lançamento rápido e, em seguida, no canal de lançamento regular, antes de ser promovido para o canal de lançamento Stable assim que acumular o uso e continuar demonstrando estabilidade. Se um problema for encontrado com uma versão do patch durante o tempo de imersão em um canal de lançamento, essa versão não será promovida para o próximo canal e o problema será corrigido em uma versão mais recente do patch.
  • O GKE lança gradualmente as versões secundárias, seguindo um processo de imersão semelhante para corrigir versões. As versões secundárias têm períodos de imersão mais longos, já que apresentam mudanças mais significativas.
  • O GKE pode atrasar upgrades automáticos quando uma nova versão afeta um grupo de clusters. Por exemplo, o GKE pausa os upgrades automáticos dos clusters detectados que estão expostos a uma API ou recurso descontinuado que será removido na próxima versão secundária.
  • O GKE pode atrasar o lançamento de novas versões durante os horários de pico (por exemplo, feriados) para garantir a continuidade dos negócios.

Como configurar o momento em que os upgrades automáticos podem ocorrer

Por padrão, os upgrades automáticos podem ocorrer a qualquer momento. Eles são minimamente disruptivos especialmente para clusters do Autopilot. Porém, algumas cargas de trabalho podem exigir um controle mais preciso. É possível configurar janelas e exclusões de manutenção para gerenciar o momento em que os upgrades automáticos podem, ou não, ocorrer.

Se você configurar janelas e exclusões de manutenção, o upgrade não ocorrerá até que a hora atual esteja dentro de uma janela de manutenção. Se uma janela de manutenção expirar antes da conclusão do upgrade, o GKE tentará pausar o upgrade. O GKE retoma o upgrade durante a próxima janela de manutenção disponível.

Fazer upgrade manual de um cluster do Autopilot

É possível fazer upgrade manual da versão do GKE do seu plano de controle do cluster do Autopilot. O GKE faz o upgrade automático dos seus nós para que correspondam à versão do plano de controle o mais rápido possível, sujeito à disponibilidade da manutenção. Para instruções, consulte Como fazer upgrade manual do plano de controle. Não é possível gerenciar manualmente a versão do nó para clusters do Autopilot.

É possível fazer upgrade da versão do plano de controle para uma versão secundária ou de patch compatível no mesmo canal de lançamento ou para uma versão patch da mesma versão secundária que o cluster em um canal de lançamento diferente.

Por exemplo, pense em um cluster do Autopilot executando a versão 1.22.8-gke.202 do GKE no canal de lançamento Normal. O comportamento a seguir se aplica:

  • É possível fazer upgrade para qualquer versão no lançamento Normal.
  • É possível fazer upgrade para qualquer versão de patch 1.22 no Canal rápido.

Para saber mais sobre como fazer upgrade para fora do seu canal, consulte Executar versões de patch de um canal mais recente.

Upgrades de sobretensão

Os clusters do Autopilot usam upgrades súbitos para fazer upgrade de vários nós ao mesmo tempo. Os upgrades de sobretensão permitem que o GKE reduza os upgrades que causam interrupções nas cargas de trabalho em execução, mantendo uma capacidade de computação suficiente para essas cargas. O Autopilot gerencia o número de nós de sobretensão adicionados ao cluster durante o upgrade. Esse número varia de acordo com o tamanho total do cluster. O GKE também gerencia o número total de nós de destino que podem estar indisponíveis simultaneamente durante o upgrade.

O número de novos nós de sobretensão e os nós de destino indisponíveis variam para garantir que o cluster sempre tenha capacidade de computação suficiente para todas as cargas de trabalho em execução. Podem ocorrer pequenas interrupções à medida que o GKE migra cargas de trabalho de nós de destino para nós de sobrecarga durante o upgrade.

Para uma descrição de como ocorrem upgrades de sobrecarga, consulte Upgrades automáticos de nós.

Requisitos de cota para upgrades súbitos

Ao contrário da recriação de nós, os upgrades súbitos exigem recursos adicionais do Compute Engine. A alocação de recursos depende da cota do Compute Engine disponível. Dependendo da configuração, essa cota pode limitar o número de upgrades paralelos ou causar falha no upgrade. Como prática recomendada para evitar problemas de escalonamento e upgrades mais previsíveis, garanta que sua cota de instâncias do Compute Engine não exceda 90%.

Para mais informações sobre cotas, consulte Garantir recursos para upgrades de nó.

Receber notificações de upgrade

O GKE publica notificações de upgrade no Pub/Sub, fornecendo um canal para receber informações do GKE sobre seus clusters.

Para mais informações, consulte Como receber notificações de cluster.

Upgrades de componentes

O GKE executa cargas de trabalho do sistema em nós de trabalho para oferecer suporte a recursos específicos de clusters. Por exemplo, a carga de trabalho do sistema gke-metadata-server é compatível com a federação de identidade da carga de trabalho do GKE. O GKE é responsável pela integridade dessas cargas de trabalho. Para saber mais sobre esses componentes, consulte a documentação das funcionalidades associadas.

Quando novos recursos ou correções são disponibilizados para um componente, o GKE indica a versão do patch em que eles estão incluídos. Para conseguir a versão mais recente de um componente, consulte a documentação associada ou as Notas de lançamento para conferir instruções sobre como fazer upgrade do plano de controle ou dos nós para a versão adequada.

A seguir