Atualizações de clusters do Autopilot

Esta página aborda o funcionamento das atualizações automáticas em clusters do Google Kubernetes Engine (GKE) no modo piloto automático, incluindo links para mais informações sobre tarefas e definições relacionadas. Pode usar estas informações para manter os seus clusters atualizados para estabilidade e segurança com interrupções mínimas nas suas cargas de trabalho.

Para uma vista geral das atualizações de clusters, consulte o artigo Acerca das atualizações de clusters do GKE. Para informações sobre como as atualizações de clusters funcionam especificamente para o Standard, consulte o artigo Atualizações de clusters Standard.

Atualizações automáticas do painel de controlo e dos nós

As atualizações automáticas estão ativadas em todos os clusters do Autopilot. O GKE inicia atualizações automáticas quando as versões do GKE são selecionadas para atualização automática, observa as atualizações automáticas em todos os clusters e intervém se ocorrerem problemas, como nós não íntegros. Não pode desativar as atualizações automáticas. No entanto, pode controlar a respetiva calendarização com janelas de manutenção e exclusões.

Para atualizar um cluster, o GKE atualiza a versão em que o painel de controlo e os nós estão a ser executados. Os clusters são atualizados para uma versão secundária mais recente (por exemplo, 1.24 para 1.25) ou uma versão de patch mais recente (por exemplo, 1.24.2-gke.100 para 1.24.5-gke.200). Para mais informações, consulte o artigo Versões e apoio técnico do GKE.

Todos os clusters do Autopilot estão inscritos num canal de lançamento, pelo que o GKE atualiza automaticamente o painel de controlo e os nós para executar a mesma versão do GKE.

O GKE atualiza o painel de controlo de um cluster antes de atualizar os nós.

Atualizações automáticas do plano de controlo

Todos os clusters do Autopilot são clusters regionais. Os clusters regionais têm várias réplicas do plano de controlo e apenas uma réplica é atualizada de cada vez, numa ordem indefinida. Isto garante que o cluster permanece altamente disponível durante as atualizações automáticas. Cada réplica do plano de controlo só fica indisponível enquanto a atualização está em curso.

Se configurar uma janela de manutenção ou uma exclusão, o GKE respeita a configuração, se possível.

O GKE não pode criar novos nós quando uma atualização do plano de controlo está em curso. Se implementar pods que requerem novos tipos de nós enquanto uma atualização do plano de controlo estiver em curso, pode haver atrasos até que a atualização do plano de controlo seja concluída.

Atualizações automáticas de nós

Depois de o GKE atualizar o painel de controlo do cluster do Autopilot, o GKE atualiza os nós para a mesma versão do GKE.

No Autopilot, o GKE agrupa nós que partilham características semelhantes. O GKE usa atualizações rápidas para nós do Autopilot, atualizando até 20 nós num grupo em simultâneo. O número exato de nós atualizados em simultâneo varia para garantir a continuação da elevada disponibilidade de nós e cargas de trabalho.

As atualizações de nós podem demorar várias horas, consoante o número de nós e a configuração das cargas de trabalho em execução nos nós. Por exemplo, as seguintes configurações podem contribuir para atualizações mais longas:

Se configurar uma janela de manutenção ou uma exclusão, o GKE respeita a configuração, se possível.

Quando o GKE atualiza um nó, ocorrem os seguintes passos:

  1. O GKE cria um novo nó de pico com a nova versão do GKE e aguarda que o nó de pico se registe no plano de controlo.
  2. O GKE seleciona um nó existente, o nó de destino, para atualizar.
  3. O GKE isola o nó de destino, impedindo que novos pods sejam colocados no nó de destino.
  4. O GKE drena o nó de destino, desalojando os pods existentes do nó de destino.

  5. O GKE reagenda os pods geridos por um controlador de carga de trabalho para outros nós disponíveis. Os pods que não podem ser reagendados permanecem no estado PENDING até que o GKE os possa reagendar.

  6. O GKE elimina o nó de destino.

Se um número significativo de atualizações automáticas para uma versão específica do GKE resultar em nós não íntegros na frota do GKE, o GKE interrompe as atualizações para essa versão enquanto investigamos o problema.

Como são selecionadas as versões para a atualização automática

O GKE lança novas versões secundárias regularmente, mas uma versão lançada não é selecionada imediatamente para atualizações automáticas. Para se qualificar como um destino de atualização automática, a versão do GKE tem de acumular utilização suficiente para comprovar a estabilidade ao longo do tempo.

Google Cloud Em seguida, seleciona essa versão como um destino de atualização automática para clusters que executam um subconjunto específico de versões mais antigas do GKE. Por exemplo, pouco depois de uma nova versão secundária ficar disponível, a versão secundária mais antiga disponível deixa normalmente de ser suportada. O GKE atualiza os clusters que executam versões secundárias não suportadas para a versão de destino da atualização automática.

O GKE anuncia novas versões de destino da atualização automática nas notas de lançamento. Ocasionalmente, é selecionada uma versão para atualizações automáticas do painel de controlo e atualizações automáticas dos nós durante semanas diferentes. O GKE é atualizado automaticamente para novas versões de patch numa versão secundária (como v1.21.x). Para obter alvos de atualização automática para um cluster específico, consulte o artigo Obtenha informações sobre as atualizações de um cluster.

Para obter informações sobre o ciclo de vida das versões e o esquema de controlo de versões, consulte o artigo Controlo de versões e apoio técnico do GKE.

Fatores que afetam o momento da implementação da versão

Para garantir a estabilidade e a fiabilidade dos clusters em novas versões, o GKE segue determinadas práticas durante as implementações de versões.

Estas práticas incluem, entre outras:

  • O GKE implementa gradualmente as alterações em Google Cloud regiões e zonas.
  • O GKE implementa gradualmente versões de patch nos canais de lançamento. É dado tempo de teste de esforço a um patch no canal de lançamento rápido e, em seguida, no canal de lançamento normal, antes de ser promovido ao canal de lançamento estável assim que tiver acumulado utilização e continuado a demonstrar estabilidade. Se for encontrado um problema com uma versão de patch durante o tempo de teste num canal de lançamento, essa versão não é promovida para o canal seguinte e o problema é corrigido numa versão de patch mais recente.
  • O GKE implementa gradualmente versões secundárias, seguindo um processo de teste semelhante ao das versões de patch. As versões secundárias têm períodos de teste mais longos, uma vez que introduzem alterações mais significativas.
  • O GKE pode atrasar as atualizações automáticas quando uma nova versão afeta um grupo de clusters. Por exemplo, o GKE pausa as atualizações automáticas para clusters que deteta estarem expostos a uma API ou uma funcionalidade descontinuada que vai ser removida na próxima versão secundária.
  • O GKE pode atrasar a implementação de novas versões durante as horas de ponta (por exemplo, grandes épocas festivas) para garantir a continuidade da empresa.

Configurar quando as atualizações automáticas podem ocorrer

Por predefinição, as atualizações automáticas podem ocorrer em qualquer altura. As atualizações automáticas são minimamente destrutivas, especialmente para clusters do Autopilot. No entanto, algumas cargas de trabalho podem exigir um controlo mais detalhado. Pode configurar janelas de manutenção e exclusões para gerir quando as atualizações automáticas podem e não podem ocorrer.

Se configurar períodos de manutenção e exclusões, a atualização não ocorre até que a hora atual esteja dentro de um período de manutenção. Se um período de manutenção expirar antes da conclusão da atualização, o GKE tenta pausar a atualização. O GKE retoma a atualização durante o próximo período de manutenção disponível.

Atualize manualmente um cluster do Autopilot

Pode atualizar manualmente a versão do GKE do painel de controlo do cluster do Autopilot. O GKE atualiza automaticamente os seus nós para corresponderem à versão do plano de controlo assim que possível, sujeito à disponibilidade de manutenção. Para ver instruções, consulte o artigo Atualizar manualmente o plano de controlo. Não pode gerir manualmente a versão do nó para clusters do Autopilot.

Pode atualizar a versão do plano de controlo para uma versão secundária ou de patch suportada no mesmo canal de lançamento ou para uma versão de patch da mesma versão secundária que o seu cluster num canal de lançamento diferente.

Por exemplo, considere um cluster do Autopilot que executa a versão 1.22.8-gke.202 do GKE no canal de lançamento regular. Aplica-se o seguinte comportamento:

  • Pode atualizar para qualquer versão no modo Regular.
  • Pode atualizar para qualquer versão de patch da versão 1.22 no canal Rápido.

Para mais informações sobre a atualização fora do seu canal, consulte o artigo Executar versões de patch a partir de um canal mais recente.

Atualizações de aumentos

Os clusters do Autopilot usam atualizações rápidas para atualizar vários nós ao mesmo tempo. As atualizações por picos permitem que o GKE reduza o impacto das atualizações de versões nas suas cargas de trabalho em execução, mantendo capacidade de computação suficiente para as cargas de trabalho em execução. O Autopilot gere o número de nós de pico que são adicionados ao cluster durante a atualização. Este número varia consoante o tamanho total do cluster. O GKE também gere o número total de nós de destino que podem estar simultaneamente indisponíveis durante a atualização.

O número de novos nós de pico e nós de destino indisponíveis varia para garantir que o cluster tem sempre capacidade de computação suficiente para todas as cargas de trabalho em execução. Pode ocorrerem pequenas interrupções à medida que o GKE migra as cargas de trabalho dos nós de destino para os nós de pico durante a atualização.

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

Requisitos de quotas para atualizações de picos

Ao contrário da recriação de nós, as atualizações rápidas requerem recursos adicionais do Compute Engine. A atribuição de recursos depende da sua quota do Compute Engine disponível. Consoante a sua configuração, esta quota pode limitar o número de atualizações paralelas ou até fazer com que a atualização falhe. Como prática recomendada para evitar problemas de escalabilidade e para atualizações mais previsíveis, certifique-se de que a quota de instâncias do Compute Engine não excede 90%.

Para mais informações sobre a quota, consulte o artigo Garanta recursos para atualizações de nós.

Receba notificações de atualizações

O GKE publica notificações de atualizações no Pub/Sub, o que lhe dá um canal para receber informações do GKE sobre os seus clusters.

Para mais informações, consulte o artigo Receber notificações de clusters.

Atualizações de componentes

O GKE executa cargas de trabalho do sistema em nós de trabalho para suportar capacidades específicas para clusters. Por exemplo, a carga de trabalho do sistema gke-metadata-server é compatível com a federação de identidades da carga de trabalho para o GKE. O GKE é responsável pela integridade destas cargas de trabalho. Para saber mais sobre estes componentes, consulte a documentação das capacidades associadas.

Quando novas funcionalidades ou correções ficam disponíveis para um componente, o GKE indica a versão de patch em que estão incluídas. Para obter a versão mais recente de um componente, consulte a documentação associada ou as notas de lançamento para ver instruções sobre como atualizar o plano de controlo ou os nós para a versão adequada.

O que se segue?