Atualizações de clusters padrão

Este documento aborda o funcionamento das atualizações automáticas e manuais para 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 clusters do 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 plano 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. Estas informações são relevantes para os conjuntos de nós padrão e os conjuntos de nós geridos pelo Autopilot.

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 pool de nós padrão do GKE, pode escolher entre as seguintes estratégias de atualização de nós:

  • Atualizações de aumentos
  • Atualizações azul-verde
  • Atualizações azul-verde com dimensionamento automático (Pré-visualização)

Para cada uma destas estratégias de atualização de nós, pode ajustar o processo de atualização com base nas necessidades do ambiente do cluster. Os conjuntos de nós geridos pelo Autopilot nos clusters Standard usam sempre atualizações rápidas e não pode modificar a configuração da estratégia nem as respetivas definições.

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 janelas de manutenção e as exclusões configuradas.

Como os nós são atualizados

Durante uma atualização de 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, se possível. 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 mais informações sobre os tipos de alterações que usam uma estratégia de atualização de nós, consulte o seguinte:

Atualizações de aumentos

Por predefinição, a estratégia de atualização rápida é usada para atualizações de node pools. Esta estratégia é sempre usada para conjuntos de nós geridos pelo Autopilot. 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. Para pools de nós padrão, pode alterar definições como o número de nós que podem ser atualizados em simultâneo e o nível de perturbação das atualizações, encontrando o equilíbrio ideal entre velocidade e perturbação para as necessidades do seu ambiente.

Atualizações azul-verde

Uma abordagem alternativa para os conjuntos de nós padrão 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 torna o reverter o mais simples possível. A implementação azul/verde requer mais 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 preparação para validação com a nova configuração. Se necessário, as cargas de trabalho podem ser rapidamente revertidas para o ambiente "azul" existente.

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

Atualizações azul-verde com dimensionamento automático

As atualizações azul-verde com escalamento automático (pré-visualização) são uma estratégia de atualização de nós em que as cargas de trabalho podem ser executadas durante mais tempo, enquanto minimiza o custo dos nós inativos ou subutilizados.

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 reserva. Se o pool de nós não tiver recursos suficientes, as atualizações podem demorar mais tempo ou falhar.

Para mais informações sobre 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 desativar 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 discrepância de versões do GKE.

Para ter mais controlo sobre quando uma atualização automática pode ocorrer (ou não deve ocorrer), 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 acumula 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 anteriores. 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 período 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, épocas festivas importantes) 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 painel de controlo do cluster ou os respetivos conjuntos de nós para uma versão disponível e compatível em qualquer altura. Nos clusters padrão, pode atualizar manualmente os node pools padrão e os node pools geridos pelo Autopilot. As atualizações manuais ignoram todas as janelas de manutenção configuradas e as exclusões de manutenção.

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: uma atualização para a versão do plano de controlo do Kubernetes.
  • UPDATE_CLUSTER: 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 mais informações, 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.
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 suporta 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 são disponibilizadas novas funcionalidades ou correções 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?