Upgrades de cluster padrão

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 Google. Ele observa upgrades automáticos e manuais em todos os clusters do GKE e intervém se forem apresentados 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 cluster

Nesta seção, você verá o que esperar quando o Google 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 Google fizer o upgrade automático ou iniciar um upgrade manual do pool de nós.

Os pools de nós são atualizados um de cada vez. Por padrão, os nós em um pool de nós também são atualizados um de cada vez, em uma ordem indefinida. 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 ou 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.

Durante esse processo, a maneira como os nós são atualizados depende da estratégia de upgrade do pool de nós e de como configurá-lo. 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 do pool de nós

O GKE oferece estratégias configuráveis que determinam como o pool de nós será atualizado.

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 do pool de nós, consulte Estratégias de upgrade do pool 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 Google é responsável por proteger o plano de controle do cluster e fazer upgrade dos clusters quando uma nova versão do GKE for selecionada para upgrade automático. A segurança da infraestrutura é alta prioridade para o GKE e, como tal, planos de controle são atualizados regularmente e não pode ser desativada. No entanto, é possível aplicar janelas de manutenção e exclusõespara suspender temporariamente os upgrades de planos de controle e nós.

No modelo de responsabilidade compartilhada, você é responsável pela proteção dos 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 Google 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.

Relação com a cota

Os upgrades súbitos e azuis-verdes podem exigir outros recursos de computação. Os upgrades de sobretensão criam VMs extras (se maxSurge for definido como maior que 0) e os upgrades azul-verde dobram temporariamente o número de nós em um pool de nós.

Se você quiser minimizar os recursos de computação adicionais necessários para upgrades, use upgrades súbitos e defina maxSurge como 0. Com essa configuração, é possível evitar que o GKE crie outros nós para alterações de configuração que exigem que os nós sejam recriados. Para saber mais sobre os tipos de alterações que usam uma estratégia de upgrade de pool de nós, consulte Quando os upgrades de sobrecarga são usados e Quando os upgrades azul-verde são usados.

A alocação de recursos está sujeita à cota do Compute Engine. Dependendo da configuração, essa cota pode limitar o número de upgrades paralelos ou causar falha no upgrade.

Para saber mais sobre como garantir que seu projeto tenha recursos suficientes para upgrades de sobrecarga, consulte Como verificar upgrades e cota de nós. Para upgrades azul-verde, seu projeto requer o dobro do número de recursos usados pelo pool de nós.

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: MASTER_UPGRADE e CLUSTER_UPDATE.
MASTER_UPGRADE é um upgrade que muda a versão do plano de controle do Kubernetes.
CLUSTER_UPDATE 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.

A seguir