Atualizações de clusters padrão

Esta página aborda o funcionamento das atualizações automáticas e manuais nos clusters padrão do Google Kubernetes Engine (GKE), 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 o mínimo de interrupções 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 obter informações sobre como as atualizações de clusters funcionam especificamente para o Autopilot, consulte o artigo Atualizações de clusters do Autopilot.

Como funcionam as atualizações de clusters e node pools

Esta secção aborda o que acontece no seu cluster durante as atualizações automáticas ou manuais. Para atualizações automáticas, o GKE inicia a atualização automática. O GKE observa as atualizações automáticas e manuais em todos os clusters do GKE e intervém se forem detetados problemas.

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.

Se inscrever o cluster num canal de lançamento, os nós executam a mesma versão do GKE que o cluster, exceto durante um breve período (normalmente, alguns dias, consoante o lançamento atual) entre a conclusão da atualização do painel de controlo do cluster e o início da atualização do conjunto de nós, ou se o painel de controlo tiver sido atualizado manualmente. Consulte as notas de lançamento para mais informações.

Atualizações de clusters

Esta secção aborda o que esperar quando o GKE atualiza automaticamente o seu cluster ou quando inicia uma atualização manual.

  • Os clusters Zonal têm apenas um único painel de controlo. Durante a atualização, as suas cargas de trabalho continuam a ser executadas, mas não pode implementar novas cargas de trabalho, modificar as cargas de trabalho existentes nem fazer outras alterações à configuração do cluster até a atualização estar concluída.

  • Os clusters regionais têm várias réplicas do painel de controlo e apenas uma réplica é atualizada de cada vez, numa ordem indefinida. Durante a atualização, o cluster permanece altamente disponível e cada réplica do plano de controlo só fica indisponível enquanto está a ser atualizada.

Se configurar uma janela de manutenção ou uma exclusão, esta é respeitada, se possível.

Atualizações de node pools

Esta secção aborda o que esperar quando o GKE atualiza automaticamente o seu conjunto de nós ou quando inicia uma atualização manual do conjunto de nós.

O GKE atualiza automaticamente um node pool de cada vez num cluster. Em alternativa, pode atualizar manualmente um ou mais conjuntos de nós em paralelo. Por predefinição, os nós num node pool são atualizados um de cada vez numa ordem arbitrária. Num conjunto de nós distribuído por várias zonas, as atualizações são feitas zona a zona. Numa zona, os nós são atualizados numa ordem indefinida.

Com as atualizações do conjunto de nós do GKE, pode escolher entre duas estratégias de atualização configuráveis e incorporadas, onde pode ajustar o processo de atualização com base nas necessidades do ambiente do cluster. Para saber mais sobre as estratégias de atualização de picos e azul-verde, consulte o artigo Estratégias de atualização.

Durante uma atualização do conjunto de nós, não pode fazer alterações à configuração do cluster, a menos que cancele a atualização.

O GKE respeita as janelas de manutenção e as exclusões durante as atualizações automáticas, sempre que possível. As atualizações manuais ignoram as exclusões e os períodos de manutenção configurados.

Como os nós são atualizados

Durante uma atualização do node pool, a forma como os nós são atualizados depende da estratégia de atualização do node pool e de como o configura. No entanto, os passos básicos permanecem consistentes. Para atualizar um nó, o GKE remove os pods do nó para que possa ser atualizado.

Quando um nó é atualizado, ocorre o seguinte com os pods:

  1. O nó está isolado para que o Kubernetes não agende novos pods no mesmo.
  2. Em seguida, o nó é esvaziado, o que significa que os pods são removidos. Para atualizações rápidas, o GKE respeita as definições de PodDisruptionBudget e GracefulTerminationPeriod do pod durante um máximo de uma hora. Com as atualizações azul-verde, este período pode ser prolongado se configurar um tempo de preparação mais longo.
  3. O plano de controlo reprograma os pods geridos por controladores noutros nós. Os pods que não podem ser reagendados permanecem na fase Pendente até poderem ser reagendados.

O processo de atualização do conjunto de nós pode demorar até algumas horas, consoante a estratégia de atualização, o número de nós e as respetivas configurações de carga de trabalho.

Considerações que afetam a duração da atualização de nós

As configurações que podem fazer com que a atualização de um nó demore mais tempo a ser concluída incluem:

Estratégias de atualização de nós

O GKE oferece estratégias configuráveis incorporadas que determinam como o conjunto de nós é atualizado. Para saber mais sobre os tipos de alterações que usam uma estratégia de atualização de nós, consulte Quando o GKE usa atualizações rápidas e Quando o GKE usa atualizações azul-verde.

Atualizações de aumentos

Por predefinição, a estratégia de atualização por picos é usada para atualizações do conjunto de nós. As atualizações rápidas usam um método contínuo para atualizar os nós. Esta estratégia é mais adequada para aplicações que podem processar alterações incrementais e não disruptivas. Com esta estratégia, os nós são atualizados numa janela contínua. Com as definições, pode alterar o número de nós que podem ser atualizados em simultâneo e o nível de interrupção das atualizações, encontrando o equilíbrio ideal entre velocidade e interrupção para as necessidades do seu ambiente.

Atualizações azul-verde

A abordagem alternativa são as atualizações azul-verde, em que são mantidos dois conjuntos de ambientes (os ambientes originais e os novos) em simultâneo, o que facilita ao máximo a reversão. A implementação azul/verde é mais intensiva em recursos e melhor para aplicações mais sensíveis a alterações. Com esta estratégia, as cargas de trabalho são migradas gradualmente do ambiente "azul" original para o novo ambiente "verde" e recebem tempo de saturação para as validar com a nova configuração. Se necessário, as cargas de trabalho podem ser revertidas rapidamente para o ambiente "azul" existente.

Para saber mais sobre o funcionamento das estratégias de atualização de nós, consulte o artigo Estratégias de atualização de nós.

Requisitos de recursos para estratégias de atualização de nós

As atualizações de picos criam nós adicionais se maxSurge estiver definido para mais de 0 e as atualizações azul/verde duplicam temporariamente o número de nós num conjunto de nós. Isto requer recursos adicionais, que estão sujeitos à quota do Compute Engine, à disponibilidade de recursos e à capacidade de reservas. Se o pool de nós não tiver recursos suficientes, as atualizações podem demorar mais tempo ou falhar.

Para saber como garantir que o seu projeto tem recursos suficientes para as atualizações de nós e o que fazer se o seu ambiente tiver restrições de recursos, consulte o artigo Garanta recursos para as atualizações de nós.

Atualizar automaticamente

Quando cria um cluster padrão, a atualização automática está ativada por predefinição no cluster e nos respetivos conjuntos de nós.

O GKE é responsável por proteger o plano de controlo do seu cluster e atualiza os seus clusters quando uma nova versão do GKE é selecionada para atualização automática. A segurança da infraestrutura é uma prioridade elevada para o GKE e, como tal, os planos de controlo são atualizados regularmente e não podem ser desativados. No entanto, pode aplicar janelas de manutenção e exclusões para suspender temporariamente as atualizações dos painéis de controlo e dos nós.

No âmbito do modelo de responsabilidade partilhada do GKE, é responsável por proteger os seus nós, contentores e pods. A atualização automática de nós está ativada por predefinição. Embora não seja recomendado, pode desativar a atualização automática dos nós. A desativação das atualizações automáticas de nós não bloqueia a atualização do painel de controlo do cluster. Se recusar as atualizações automáticas de nós, é responsável por garantir que os nós do cluster executam uma versão compatível com a versão do cluster e que a versão cumpre a política de desvio de versão do GKE.

Para ter mais controlo sobre quando pode ocorrer (ou não deve ocorrer) uma atualização automática, pode configurar janelas de manutenção e exclusões.

Os node pools de um cluster não podem estar mais de duas versões secundárias atrás da versão do plano de controlo para manter a compatibilidade com a API do cluster. A versão do conjunto de nós também determina as versões dos pacotes de software instalados em cada nó. Recomendamos que mantenha os node pools atualizados para a versão do cluster.

Se inscrever o cluster num canal de lançamento, os nós executam sempre a mesma versão do GKE que o cluster em si, exceto durante um breve período (normalmente, alguns dias, consoante o lançamento atual) entre a conclusão da atualização do painel de controlo do cluster e o início da atualização de um determinado conjunto de nós. Consulte as notas de lançamento para mais informações.

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

As novas versões do GKE são lançadas regularmente, mas não é selecionada uma versão para atualização automática de imediato. Quando uma versão do GKE acumulou utilização suficiente do cluster para provar a estabilidade ao longo do tempo, o GKE seleciona-a como um destino de atualização automática para clusters que executam um subconjunto de versões mais antigas. 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.

Os novos alvos de atualização automática são anunciados nas notas de lançamento. Até selecionar uma versão disponível para atualização automática, pode atualizá-la manualmente. Ocasionalmente, é selecionada uma versão para a atualização automática do cluster e a atualização automática do nó durante semanas diferentes.

Pouco depois de uma nova versão secundária ficar geralmente disponível, a versão secundária mais antiga disponível torna-se normalmente não suportada. Os clusters que executam versões secundárias que ficam sem suporte técnico são atualizados automaticamente para a versão secundária seguinte.

Numa versão secundária (como a v1.14.x), os clusters podem ser atualizados automaticamente para uma nova versão de patch.

Os canais de lançamento permitem-lhe controlar a versão do cluster e do conjunto de nós com base na estabilidade de uma versão, em vez de gerir a versão diretamente.

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 para preservar a segurança da infraestrutura. As atualizações automáticas são minimamente disruptivas, especialmente para clusters regionais. 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.

Atualizar manualmente

Pode pedir para atualizar manualmente o cluster ou os respetivos conjuntos de nós para uma versão disponível e compatível em qualquer altura. As atualizações manuais ignoram todas as janelas de manutenção e exclusões de manutenção configuradas.

Quando atualiza manualmente um cluster, a respetiva disponibilidade depende de o cluster ser regional ou não:

  • Para clusters zonais, o plano de controlo não está disponível enquanto está a ser atualizado. Na maioria dos casos, os fluxos de trabalho são executados normalmente, mas não podem ser modificados durante a atualização.

  • Para clusters regionais, uma réplica do plano de controlo fica indisponível de cada vez enquanto é atualizada, mas o cluster permanece altamente disponível durante a atualização.

Pode iniciar manualmente uma atualização de nós para uma versão compatível com o plano de controlo.

Como o GKE responde à falha da atualização automática

As atualizações automáticas do node pool podem falhar devido a problemas com as instâncias subjacentes do Compute Engine ou com o Kubernetes. Por exemplo, as atualizações automáticas falham nas seguintes situações:

  • A definição maxSurge configurada excede a sua quota de recursos do Compute Engine.
  • Os novos nós de pico não foram registados no painel de controlo do cluster.
  • Os nós demoraram demasiado tempo a esvaziar ou a eliminar.

Quando ocorrem problemas com atualizações de nós individuais, o GKE tenta novamente a atualização algumas vezes, com um intervalo crescente entre as novas tentativas. Se os nós no conjunto de nós não forem atualizados, o GKE não reverte os nós atualizados. Em alternativa, o GKE tenta novamente a atualização automática do conjunto de nós até que todos os nós sejam atualizados com êxito.

Se as atualizações dos nós falharem porque os pedidos de nós de pico excedem a sua quota do Compute Engine, o GKE reduz o número de nós de pico simultâneos para tentar cumprir a quota e continuar a atualização.

Receção de notificações de atualização

O GKE publica notificações sobre eventos relevantes para o seu cluster, como atualizações de versões e boletins de segurança, 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.

Verifique os registos de atualização

Por predefinição, o GKE regista eventos de atualização do painel de controlo e do conjunto de nós no Cloud Logging. O registo de eventos de atualização oferece visibilidade do processo de atualização e inclui informações valiosas para a resolução de problemas, se necessário.

Registos de atualização do plano de controlo

Os eventos de atualização do cluster podem ser consultados através do seguinte filtro:

resource.type="gke_cluster"
protoPayload.metadata.operationType=~"(UPDATE_CLUSTER|UPGRADE_MASTER)"
resource.labels.cluster_name="CLUSTER_NAME"

Estes registos são registados como formatos de registo estruturados. Pode usar os seguintes campos para os detalhes dos eventos de atualização:



Campo Descrição
protoPayload.metadata.operationType Existem dois tipos de eventos de atualização de clusters: UPGRADE_MASTER e UPDATE_CLUSTER.
UPGRADE_MASTER altera a versão do plano de controlo do Kubernetes.
UPDATE_CLUSTER significa uma atualização que não altera a versão do plano de controlo do Kubernetes.
Ambos os tipos de atualizações de clusters podem causar a perda de disponibilidade do plano de controlo para clusters zonais. Para saber mais, consulte o artigo Como funcionam as atualizações de clusters e conjuntos de nós.
protoPayload.methodName Este campo mostra que API acionou a atualização do cluster.
google.container.v1.ClusterManager.UpdateCluster: atualização manual do plano de controlo
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: atualização automática do plano de controlo
google.container.v1.ClusterManager.PatchCluster: alteração da configuração do cluster.
protoPayload.metadata.previousMasterVersion Este campo é usado apenas para o tipo de operação MASTER_UPGRADE e contém a versão do plano de controlo anterior usada antes da atualização.
protoPayload.metadata.currentMasterVersion Este campo é usado apenas para o tipo de operação MASTER_UPGRADE e contém o novo número da versão do plano de controlo usado após a atualização.

Registos de atualização do node pool

Use a seguinte consulta para ver eventos de atualização do conjunto de nós: 

resource.type="gke_nodepool"
protoPayload.metadata.operationType="UPGRADE_NODES"
resource.labels.cluster_name="CLUSTER_NAME"

Use o seguinte campo para detalhes sobre o evento de atualização:

protoPayload.methodName mostra se a atualização foi acionada manualmente ou automaticamente, da seguinte forma.

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?