Upgrades de cluster padrão

Nesta página, você verá como upgrades automáticos e manuais funcionam em clusters padrão 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.

Para mais informações sobre como os upgrades de cluster funcionam no Autopilot, consulte esta página.

Como funcionam os upgrades de pools de nós e de cluster

Nesta seção, você verá o que acontece no cluster durante upgrades automáticos ou manuais. Os upgrades automáticos são iniciados pelo GKE. Ele observa upgrades automáticos e manuais em todos os clusters do GKE e intervém em caso de problemas.

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.

Se você inscrever o cluster em um canal de lançamento, os nós vão executar a mesma versão do GKE que ele, exceto durante um breve período (normalmente alguns dias, dependendo da versão atual) entre concluir o upgrade do plano de controle do cluster e iniciar o upgrade do pool de nós, ou se o plano de controle foi atualizado manualmente. Veja as notas da versão para mais informações.

Upgrades de clusters

Nesta seção, você verá o que esperar quando o GKE fizer o upgrade automático do cluster ou quando você iniciar um upgrade manual.

  • Os clusters zonais têm apenas um único plano de controle. Durante o upgrade, as cargas de trabalho continuarão em execução, mas não será possível implantar novas cargas de trabalho, modificar as atuais nem fazer outras alterações na configuração do cluster até que o upgrade seja concluído.

  • Clusters regionais têm várias réplicas do plano de controle e apenas uma é atualizada por vez, em uma ordem indefinida. Durante o upgrade, o cluster permanece altamente disponível, e cada réplica do plano de controle fica indisponível apenas durante a atualização.

Se você configurar uma janela ou exclusão de manutenção, ela será respeitada, se possível.

Upgrades de pool de nós

Nesta seção, você verá o que esperar quando o GKE fizer o upgrade automático ou iniciar um upgrade manual do pool de nós.

O GKE faz upgrade automático de um pool de nós por vez em um cluster. Como alternativa, é possível fazer upgrade manual de um ou mais pools de nós em paralelo. Por padrão, os nós de um pool são atualizados um de cada vez em uma ordem arbitrária. Em um conjunto de nós espalhados por várias zonas, os upgrades ocorrem zona por zona. Em uma zona, os nós serão atualizados em uma ordem indefinida.

Com os upgrades de pool de nós do GKE, é possível escolher entre duas estratégias configuráveis de upgrade integrado, em que é possível ajustar o processo de upgrade com base nas necessidades do ambiente do cluster. Para saber mais sobre as estratégias de upgrade súbito e azul/verde, consulte Estratégias de upgrade.

Durante um upgrade do pool de nós, não é possível fazer alterações na configuração do cluster, a menos que você cancele o upgrade.

O GKE cumpre janelas e exclusões de manutenção durante os upgrades automáticos quando possível. Os upgrades manuais ignoram as janelas e exclusões de manutenção configuradas.

Como os nós são atualizados

Durante um upgrade do pool de nós, a maneira como os nós são atualizados depende da estratégia de upgrade do pool de nós e de como ele é configurado. No entanto, as etapas básicas continuam consistentes. Para fazer upgrade de um nó, o GKE remove os pods dele para que possam ser atualizados.

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

  1. O nó é restringido para que o Kubernetes não programe novos pods nele.
  2. Em seguida, o nó é drenado, o que significa que os pods são removidos. Para upgrades súbitos, o GKE respeita as configurações PodDisruptionBudget e GracefulTerminaPeriod do pod por até uma hora. Com upgrades azul-verde, isso pode ser estendido se você configurar um tempo de imersão mais longo.
  3. O plano de controle reprograma os pods gerenciados por controladores em outros nós. Os pods que não podem ser reprogramados permanecem na fase Pendente até serem reprogramados.

O processo de upgrade do pool de nós pode levar algumas horas, dependendo da estratégia de upgrade, do número de nós e das respectivas configurações de carga de trabalho.

Considerações que afetam a duração do upgrade de nós

As configurações que podem fazer com que o upgrade de um nó demore mais para ser concluído incluem:

Estratégias de upgrade de nós

O GKE oferece estratégias configuráveis que determinam como o pool de nós será atualizado. Para saber mais sobre os tipos de alterações que usam uma estratégia de upgrade de nós, consulte Quando o GKE usa upgrades súbitos e Quando o GKE usa upgrades azuis/verdes.

Upgrades de sobretensão

Por padrão, a estratégia de upgrade súbito é usada para upgrades de pool de nós. Os upgrades súbitos usam um método contínuo para fazer upgrade dos nós. Essa estratégia é melhor para aplicativos que processam alterações incrementais sem interrupções. Com essa estratégia, os nós são atualizados em uma janela contínua. Com as configurações, é possível alterar quantos nós podem ser atualizados de uma vez e como os upgrades podem ser prejudiciais, encontrando o equilíbrio ideal de velocidade e interrupção para as necessidades do ambiente.

Upgrades azuis-verdes

A abordagem alternativa são os upgrades azul-verde, em que dois conjuntos de ambientes (o ambiente original e o novo) são mantidos de uma só vez, facilitando a reversão. O verde-azulado exibe mais uso intensivo de recursos e melhor para aplicativos mais sensíveis a mudanças. Com essa estratégia, as cargas de trabalho são migradas gradualmente do ambiente "azul" original para o novo ambiente "verde" e têm tempo de imersão para validá-las com a nova configuração. Se necessário, as cargas de trabalho podem ser revertidas rapidamente para o ambiente "azul" atual.

Para saber mais sobre como funcionam as estratégias de upgrade de nós, consulte Estratégias de upgrade de nós.

Requisitos de recursos para estratégias de upgrade de nós

Os upgrades súbitos criam VMs extras quando maxSurge é definido como maior que 0, e os upgrades azuis/verdes dobram temporariamente o número de nós em um pool de nós. Isso requer recursos extras, que estão sujeitos à cota do Compute Engine, disponibilidade de recursos e capacidade de reserva. Se o pool de nós não tiver recursos suficientes, os upgrades poderão levar mais tempo ou falhar.

Para saber mais sobre como garantir que seu projeto tenha recursos suficientes para upgrades de nós e o que fazer se o ambiente tiver restrição de recursos, consulte Garantir recursos para upgrades de nós.

Como fazer upgrades automaticamente

Quando você cria um cluster padrão, o upgrade automático é ativado no cluster e nos pools de nós dele.

O GKE é responsável por proteger o plano de controle do cluster e fazer upgrade dos clusters quando uma nova versão do GKE é selecionada para upgrade automático. A segurança da infraestrutura é uma alta prioridade para o GKE. Por isso, os planos de controle são atualizados regularmente e não podem ser desativados. No entanto, é possível aplicar janelas de manutenção e exclusões para suspender temporariamente os upgrades de planos de controle e nós.

Como parte do modelo de responsabilidade compartilhada do GKE, você é responsável por proteger seus nós, contêineres e pods. O upgrade automático de nós é ativado por padrão. Embora não seja recomendado, é possível desativar o upgrade automático do nós. A desativação dos upgrades automáticos de nós não bloqueia o upgrade do plano de controle do cluster. Ao desativar os upgrades automáticos de nós, você é responsável por garantir que os nós do cluster executem uma versão compatível com a versão do cluster e que ela esteja em conformidade com a versão do Kubernetes e a política de suporte de diferença .

Para ter mais controle sobre o momento em que um upgrade automático poderá, ou não, ocorrer, configure janelas e exclusões de manutenção.

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

Se você inscrever o cluster em um canal de lançamento, os nós sempre executarão a mesma versão do GKE que o cluster, exceto durante um breve período (geralmente alguns dias, dependendo do versão atual) entre a conclusão do upgrade do plano de controle do cluster e o início do upgrade de um determinado pool de nós. Veja as notas da versão para mais informações.

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

Novas versões do GKE são lançadas regularmente, mas uma versão não é selecionada para upgrade automático imediatamente. Quando uma versão do GKE acumular uso de cluster suficiente para comprovar a estabilidade, o GKE a selecionará como um objetivo de upgrade automático para clusters que executam um subconjunto de versões mais antigas.

Novos destinos de upgrade automático são anunciados nAs notas de lançamento. Até que uma versão disponível seja selecionada para o upgrade automático, será possível fazer upgrade para ela manualmente. Às vezes uma versão é selecionada para upgrade automático de cluster e de nó durante semanas diferentes.

Logo depois que uma nova versão secundária for disponibilizada, a versão secundária mais antiga disponível não será mais compatível. Os clusters executando versões secundárias que se tornam incompatíveis são automaticamente atualizados para a próxima versão secundária.

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

Com os canais de lançamento, é possível controlar a versão do cluster e do pool de nós com base na estabilidade de uma versão em vez de gerenciá-la diretamente.

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.

Essas práticas incluem, mas não se limitam a:

  • 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 para preservar a segurança da infraestrutura. Eles são minimamente disruptivos especialmente para clusters regionais. 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.

Como fazer upgrade manualmente

É possível solicitar o upgrade manual do cluster ou dos respectivos pools de nós para uma versão compatível e disponível a qualquer momento. Os upgrades manuais ignoram as janelas e exclusões de manutenção configuradas.

Ao fazer upgrade de um cluster manualmente, a disponibilidade dele varia se ele for regional ou não:

  • Para clusters zonais, o plano de controle fica indisponível durante o upgrade. Na maioria das vezes, as cargas de trabalho são executadas normalmente, mas não podem ser modificadas durante o upgrade.

  • Para clusters regionais, durante o upgrade, uma réplica do plano de controle fica indisponível por vez, mas ele permanece altamente disponível.

É possível iniciar um upgrade de nó manualmente para uma versão compatível com o plano de controle.

Como o GKE responde a falhas de upgrade automático

Os upgrades automáticos do pool de nós podem falhar devido a problemas com as instâncias subjacentes do Compute Engine ou por questões com o Kubernetes. Por exemplo, os upgrades automáticos falham nas seguintes situações:

  • A configuração de maxSurge definida excede sua cota de recursos do Compute Engine.
  • Novos nós de sobretensão não foram registrados no plano de controle do cluster.
  • Os nós demoraram muito para serem drenados ou demoraram muito para serem excluídos.

Quando ocorrem problemas com upgrades de nó individuais, o GKE repete o upgrade algumas vezes, com um intervalo crescente entre as novas tentativas. Se os nós no pool de nós não forem atualizados, o GKE não reverterá os nós atualizados. Em vez disso, o GKE tentará o upgrade automático do pool de nós novamente até que todos os nós sejam atualizados com sucesso.

Se os upgrades de nó falharem porque as solicitações de nó de sobretensão excedem a cota do Compute Engine, o GKE reduz o número de nós de sobretensão simultâneos para tentar atingir a cota e continuar o upgrade.

Como receber notificações de upgrade

O GKE publica notificações sobre eventos relevantes para o cluster, como upgrades de versão e boletins de segurança, no Pub/Sub, fornecendo um canal para receber informações do GKE sobre os clusters.

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

Verificar os registros de upgrade

Por padrão, o GKE registra os eventos do upgrade do plano de controle e do pool de nós no Cloud Logging. O registro de eventos de upgrade mostra o processo de upgrade e inclui informações valiosas para a solução de problemas, se necessário.

Registros de upgrade do plano de controle

Os eventos de upgrade de clusters podem ser consultados usando o seguinte filtro:

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

Esses registros são gravados como formatos de geração de registros estruturados. Use os campos a seguir para ver os detalhes dos eventos de upgrade:



Campo Descrição
protoPayload.metadata.operationType Há dois tipos de eventos de upgrade de cluster: UPGRADE_MASTER e UPDATE_CLUSTER.
UPGRADE_MASTER muda a versão do plano de controle do Kubernetes.
UPDATE_CLUSTER significa uma atualização que não muda a versão do plano de controle do Kubernetes.
Os dois tipos de upgrade de cluster podem causar a perda da disponibilidade do plano de controle para clusters zonais. Para saber mais, consulte Como funcionam os upgrades de cluster e de pool de nós.
protoPayload.methodName Esse campo mostra qual API acionou o upgrade do cluster.
google.container.v1.ClusterManager.UpdateCluster: upgrade manual do plano de controle
google.container.internal.ClusterManagerInternal.UpdateClusterInternal: upgrade automático do plano de controle
google.container.v1.ClusterManager.PatchCluster: alteração de 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 anterior do plano de controle usada antes do upgrade.
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 controle usado após o upgrade.

Registros de upgrade do pool de nós

Use a consulta a seguir para ver os eventos de upgrade do pool de nós: 

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

Use o campo a seguir para ver detalhes sobre o evento de upgrade:

O campo protoPayload.methodName mostra se o upgrade foi acionado manualmente ou automaticamente, da seguinte maneira.

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