Atualizar manualmente um cluster ou um node pool

Este documento explica como pode pedir manualmente uma atualização ou uma desatualização do plano de controlo ou dos nós de um cluster do Google Kubernetes Engine (GKE). O GKE atualiza automaticamente a versão do painel de controlo e dos nós para garantir que o cluster recebe novas funcionalidades, correções de erros e patches de segurança. No entanto, conforme explicado neste documento, também pode fazer estas atualizações manualmente.

Para mais informações sobre o funcionamento das atualizações automáticas e manuais de clusters, consulte o artigo Acerca das atualizações de clusters do GKE. Também pode controlar quando as atualizações automáticas podem e não podem ocorrer configurando janelas de manutenção e exclusões.

Pode atualizar manualmente a versão da seguinte forma:

• Clusters do Autopilot: atualize a versão do plano de controlo.
• Clusters padrão: atualize a versão do painel de controlo e a versão do node pool.

Para atualizar um cluster, o GKE atualiza a versão que o plano de controlo e os nós executam em operações separadas. Os clusters são atualizados para uma versão secundária mais recente (por exemplo, 1.33 para 1.34) ou uma versão de patch mais recente (por exemplo, 1.33.4-gke.1350000 para 1.33.5-gke.1080000). O painel de controlo e os nós de um cluster nem sempre executam a mesma versão. Para mais informações sobre as versões, consulte o artigo Versões e apoio técnico do GKE.

Para mais informações sobre como funcionam as atualizações de clusters, incluindo atualizações automáticas e manuais, consulte o artigo Acerca das atualizações de clusters do GKE.

As novas versões do GKE são anunciadas regularmente, e pode receber um aviso sobre as novas versões disponíveis para cada cluster específico com notificações de cluster. Para encontrar alvos de atualização automática específicos para clusters, obtenha informações sobre as atualizações de um cluster.

Para mais informações sobre as versões disponíveis, consulte o artigo Criação de versões. Para mais informações sobre clusters, consulte o artigo Arquitetura de clusters. Para orientações sobre a atualização de clusters, consulte o artigo Práticas recomendadas para atualizar clusters.

Antes de começar

Antes de começar, certifique-se de que realizou as seguintes tarefas:

• Ative a API Google Kubernetes Engine.
Ative a API Google Kubernetes Engine
• Se quiser usar a CLI gcloud para esta tarefa, instale-a e, em seguida, inicialize-a. Se instalou anteriormente a CLI gcloud, execute o comando gcloud components update para obter a versão mais recente. As versões anteriores da CLI gcloud podem não suportar a execução dos comandos neste documento.

• Certifique-se de que tem um cluster do Autopilot ou Standard existente. Para criar um novo cluster, consulte o artigo Crie um cluster do Autopilot.

Acerca da atualização

O painel de controlo e os nós de um cluster são atualizados separadamente. O painel de controlo e os nós do cluster não executam necessariamente a mesma versão em todos os momentos.

Os painéis de controlo e os nós do cluster são atualizados regularmente, independentemente de o cluster estar ou não inscrito num canal de lançamento.

Limitações

Não é possível atualizar os clusters alfa.

Versões suportadas

As notas de lançamento anunciam quando as novas versões ficam disponíveis e quando as versões anteriores deixam de estar disponíveis. Em qualquer altura, pode listar todas as versões de nós e clusters suportadas através do seguinte comando:

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

Substitua CONTROL_PLANE_LOCATION pela localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.

Se o seu cluster estiver inscrito num canal de lançamento, pode atualizar para uma versão de patch num canal de lançamento diferente com a mesma versão secundária do seu painel de controlo. Por exemplo, pode atualizar o cluster da versão 1.33.4-gke.1350000 no canal Regular para a versão 1.33.5-gke.1162000 no canal Rapid. Para mais informações, consulte o artigo Executar versões de patch a partir de um canal mais recente. Todos os clusters do Autopilot estão inscritos em canais de lançamento.

Acerca da alteração para um nível inferior

Pode reverter a versão do cluster para uma versão anterior em determinados cenários:

• Reversão da patch do painel de controlo: para mitigar uma atualização do painel de controlo do cluster sem êxito, pode reverter o painel de controlo para uma versão de patch anterior se a versão for uma versão de patch anterior na mesma versão secundária. Por exemplo, se o painel de controlo do cluster estiver a executar o GKE 1.33.5-gke.1080000, pode reverter o painel de controlo para a versão 1.33.4-gke.1350000, se essa versão ainda estiver disponível.
• Reversão durante uma atualização secundária do plano de controlo em dois passos (pré-visualização): só pode reverter um plano de controlo do cluster do Kubernetes para uma versão secundária anterior após a atualização binária de uma atualização secundária do plano de controlo em dois passos com segurança de reversão. Se o GKE já tiver concluído o segundo passo da atualização de dois passos, ou seja, a atualização da versão emulada, não pode reverter para a versão secundária anterior.
• Diminuição da versão do node pool: para mitigar uma atualização do node pool sem êxito, pode diminuir a versão de um node pool para uma versão de patch anterior ou uma versão secundária. Certifique-se de que não atualiza os nós para uma versão que esteja mais de duas versões secundárias atrás da versão do plano de controlo do cluster.

Além dos cenários descritos nos pontos anteriores, não pode reverter um cluster. Não pode alterar um painel de controlo do cluster para uma versão secundária anterior, incluindo após uma atualização secundária do painel de controlo de um passo. Por exemplo, se o seu plano de controlo executar o GKE versão 1.34, não pode fazer o downgrade para a versão 1.33. Se tentar fazê-lo, é apresentada a seguinte mensagem de erro:

ERROR: (gcloud.container.clusters.upgrade) ResponseError: code=400,
message=Master cannot be upgraded to "1.33.4-gke.1350000": specified version is
not newer than the current version.

Recomendamos que teste e qualifique as atualizações de versões secundárias com clusters num ambiente de teste quando uma nova versão secundária ficar disponível, mas antes de a versão se tornar o destino de atualização automática do seu cluster. Isto é especialmente recomendado se o seu cluster puder ser afetado por alterações significativas na próxima versão secundária, como a remoção de APIs ou funcionalidades descontinuadas. Para mais informações sobre a disponibilidade das versões, consulte o artigo Que versões estão disponíveis num canal.

Atualize o plano de controlo do cluster

O GKE atualiza automaticamente os painéis de controlo e os nós do cluster. Para gerir a forma como o GKE atualiza os seus clusters, consulte o artigo Controlar as atualizações de clusters.

Com os clusters do Autopilot e os clusters Standard regionais, o painel de controlo permanece disponível durante as atualizações do painel de controlo. No entanto, quando inicia uma atualização do plano de controlo para clusters zonais, não pode modificar a configuração do cluster até que o plano de controlo esteja novamente acessível dentro de alguns minutos. As atualizações do plano de controlo não afetam a disponibilidade dos nós de trabalho nos quais as suas cargas de trabalho são executadas, uma vez que permanecem disponíveis durante as atualizações do plano de controlo.

Como parte da gestão das versões do cluster, pode iniciar uma atualização manual em qualquer altura após a disponibilização de uma nova versão através de um dos seguintes métodos:

• Atualização de um passo: atualize o plano de controlo diretamente para uma versão secundária ou uma versão de patch posterior o mais rapidamente possível. Pode usar esta abordagem se já tiver validado o desempenho do cluster e da carga de trabalho na nova versão secundária.
• Atualização secundária do plano de controlo em dois passos com segurança de reversão (Pré-visualização): atualize o plano de controlo para uma versão secundária posterior através de um processo de dois passos em que pode validar a nova versão secundária durante um período de tempo de teste e reverter, se necessário. Este método de atualização só está disponível para a atualização para a versão 1.33 ou posterior, para atualizações manuais secundárias do plano de controlo.

Atualize manualmente o plano de controlo com uma atualização de um passo

Pode atualizar manualmente o plano de controlo do Autopilot ou Standard através da Cloud de Confiance consola ou da CLI Google Cloud.

gcloud container get-server-config \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
    --master \
    --location=CONTROL_PLANE_LOCATION \
    --cluster-version=VERSION

Depois de atualizar um painel de controlo Standard, pode atualizar os respetivos nós. Por predefinição, os nós padrão criados através da consola têm a atualização automática ativada, pelo que isto acontece automaticamente. Cloud de Confiance O Autopilot atualiza sempre os nós automaticamente.

Atualização secundária do plano de controlo em dois passos com segurança de reversão

Pode atualizar manualmente o plano de controlo do cluster do GKE Autopilot ou Standard para a versão secundária seguinte com uma atualização de dois passos. Neste processo de dois passos, pode testar o desempenho do seu cluster com a nova versão secundária, conhecida como versão binária, enquanto usa as funcionalidades e as APIs da versão secundária anterior, conhecida como versão emulada. Durante este período de teste, em que o plano de controlo é executado no que é conhecido como modo emulado, pode reverter para a versão secundária anterior, se necessário. Para mais informações sobre como o Kubernetes permite este tipo de atualização, consulte o artigo Versão de compatibilidade para componentes do plano de controlo do Kubernetes.

As atualizações em dois passos funcionam da seguinte forma:

1. Atualização binária: o GKE atualiza o binário do plano de controlo para a nova versão secundária, mas emula a versão secundária anterior:

   • Emula a versão anterior: o cluster executa o novo ficheiro binário, mas continua a emular o comportamento da API da versão secundária anterior. Por exemplo, pode chamar APIs que foram removidas na nova versão secundária, mas que ainda estão disponíveis na versão secundária anterior.
   • Teste o novo binário: pode testar os novos binários para regressões, correções e alterações de desempenho antes de tornar acessíveis as funcionalidades do Kubernetes disponíveis com a nova versão secundária. Monitorize as métricas da aplicação, os registos, os estados dos pods, as taxas de erro e a latência.
   • Absorva as alterações: aguarde entre seis horas e sete dias para ter tempo de testar e monitorizar. Após este período, o GKE executa a atualização da versão emulada.
   • Reverter ou concluir a atualização: pode reverter, se necessário. Em alternativa, pode avançar para a fase seguinte se tiver confiança na nova versão secundária, não quiser esperar que o período de teste seja concluído e estiver pronto para começar a usar as novas funcionalidades e alterações à API.

2. Atualização da versão emulada: o GKE atualiza a versão emulada para corresponder à nova versão binária.

   • Ativa novas funcionalidades: todas as novas funcionalidades e alterações da API da nova versão secundária são ativadas.
   • Sem reversão: após este passo, não pode reverter para a versão secundária original. A atualização foi concluída.

Durante esta operação, aplicam-se as seguintes limitações:

• Não pode iniciar uma atualização secundária do plano de controlo de um passo.
• Não pode criar nem atualizar os nós para uma versão posterior à versão emulada.
• O GKE não realiza nenhum tipo de atualizações automáticas ao painel de controlo nem aos nós.

Inicie uma atualização em dois passos

Inicie uma atualização de dois passos executando o seguinte comando:

gcloud beta container clusters upgrade CLUSTER_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION \
  --control-plane-soak-duration SOAK_DURATION \
  --master

Substitua o seguinte:

• CLUSTER_NAME: o nome do cluster.
• CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.
• VERSION: um patch específico da próxima versão secundária. Por exemplo, se o cluster executar a versão 1.33, 1.34.1-gke.1829001.
• SOAK_DURATION: o tempo de espera na fase segura de reversão. Pode definir este valor durante um mínimo de 6 horas e um máximo de 7 dias através dos formatos de duração absoluta, conforme explicado na referência para gcloud topic datetimes. Por exemplo, use 2d1h para um tempo de imersão de dois dias e uma hora.

Teste o novo ficheiro binário durante uma atualização em dois passos

Durante o tempo de teste de esforço, valide se o cluster, com o plano de controlo a executar o novo ficheiro binário, e as cargas de trabalho têm o desempenho esperado. Pode efetuar um dos seguintes passos, consoante consiga validar se as cargas de trabalho são compatíveis com o novo ficheiro binário:

• Reverter: se observar um problema com as cargas de trabalho em execução no novo ficheiro binário, pode reverter para a versão secundária anterior.
• Conclua a atualização: se tiver verificado que as suas cargas de trabalho são executadas sem problemas no novo ficheiro binário, pode concluir a atualização se quiser começar a usar as funcionalidades e as APIs da nova versão.
• Aguardar: também pode aguardar até que o tempo de preparação termine. Depois, o GKE realiza a atualização da versão emulada, em que passa a usar as funcionalidades e as APIs da nova versão secundária.

Observe a atualização em curso

Para obter informações sobre uma atualização em curso, use um dos seguintes recursos:

• Para ver detalhes sobre a atualização, siga as instruções para obter informações de atualizações ao nível do cluster.
• Use notificações de clusters. O GKE envia uma notificação UpgradeEvent quando a atualização binária é iniciada e um UpgradeInfoEvent do tipo A operação de atualização está concluída quando a atualização binária é concluída e o tempo de saturação é iniciado.
• Para ver detalhes sobre o cluster, incluindo a atualização em curso, execute o comando gcloud container clusters describe.
• Ver registos relevantes no Cloud Logging.

Reverta uma atualização de dois passos após a atualização da versão binária

Durante uma atualização de dois passos, após a atualização da versão binária, segue-se o período de teste. Durante este período, pode reverter para a versão secundária anterior, se necessário. Não pode reverter a atualização depois de o GKE executar a atualização da versão emulada.

Após a conclusão da operação de reversão, o plano de controlo executa a versão secundária anterior, tal como fazia antes de iniciar a atualização de dois passos.

Siga os passos abaixo para reverter, se possível:

1. Verifique se ainda pode reverter o plano de controlo para a versão secundária anterior executando o comando da CLI gcloud em Obter informações de atualizações ao nível do cluster. Determine se pode ou não reverter através do resultado do comando:

   • Pode reverter se existir uma secção rollbackSafeUpgradeStatus no resultado. Nessa secção, guarde o previousVersion para a variável VERSION no passo seguinte. Avançar para o passo seguinte.
   • Não pode reverter se não existir uma secção rollbackSafeUpgradeStatus. Isto indica que o GKE já efetuou a atualização da versão emulada. Não é possível realizar o passo seguinte.

2. Se o passo anterior determinou que a reversão é possível, reverta para a versão anterior:

   gcloud container clusters upgrade CLUSTER_NAME \
     --location=CONTROL_PLANE_LOCATION \
     --cluster-version VERSION
     --master
   

   O VERSION tem de ser a versão de patch exata usada anteriormente. Guardou esta versão no passo anterior.

Depois de executar este comando e reverter para a versão anterior, pode determinar por que motivo a sua carga de trabalho não foi executada corretamente no novo ficheiro binário. Se necessário, pode contactar o apoio técnico do Google Cloud, facultando registos relevantes, mensagens de erro e detalhes sobre a falha de validação que encontrou. Para mais informações, consulte Obtenha apoio técnico.

Depois de resolver o problema, pode atualizar manualmente para a nova versão secundária.

Conclua a atualização em dois passos

Durante o período de teste de estabilidade, se tiver validado que as cargas de trabalho são executadas com êxito com o novo ficheiro binário, pode ignorar o resto do tempo de teste de estabilidade:

gcloud beta container clusters clusters complete-control-plane-upgrade CLUSTER_NAME  \
  --location=CONTROL_PLANE_LOCATION

Depois de executar este comando, já não pode reverter para a versão secundária anterior.

Altere o plano de controlo para uma versão de patch anterior

1. Defina uma exclusão de manutenção antes de alterar para uma versão anterior para impedir que o GKE atualize automaticamente o plano de controlo depois de o alterar para uma versão anterior.

2. Altere o plano de controlo do cluster para uma versão de patch anterior:

    gcloud container clusters upgrade CLUSTER_NAME \
        --master \
        --location=CONTROL_PLANE_LOCATION \
        --cluster-version=VERSION
   

Desativar as atualizações automáticas de clusters

A segurança da infraestrutura é uma prioridade elevada para o GKE e, como tal, os painéis de controlo são atualizados regularmente e não podem ser desativados. No entanto, pode aplicar períodos de manutenção e exclusões para suspender temporariamente as atualizações dos painéis de controlo e dos nós.

Embora não seja recomendado, pode desativar a atualização automática dos nós para pools de nós padrão.

Verifique o histórico de atualizações recentes do plano de controlo

Para ver um resumo do histórico de atualizações automáticas recentes de um cluster, obtenha informações sobre as atualizações de um cluster.

Em alternativa, pode listar as operações recentes para ver quando o plano de controlo foi atualizado:

gcloud container operations list --filter="TYPE:UPGRADE_MASTER AND TARGET:CLUSTER_NAME" \
    --location=CONTROL_PLANE_LOCATION

Atualize node pools

Por predefinição, os conjuntos de nós padrão têm a atualização automática ativada, e todos os conjuntos de nós geridos pelo Autopilot em clusters padrão têm sempre a atualização automática ativada. As atualizações automáticas de nós garantem que a versão do painel de controlo e do nó do cluster permanecem sincronizadas e em conformidade com a política de diferença de versões do Kubernetes, o que garante que os painéis de controlo são compatíveis com nós até duas versões secundárias anteriores à do painel de controlo. Por exemplo, os planos de controlo do Kubernetes 1.34 são compatíveis com os nós do Kubernetes 1.32.

Com as atualizações do conjunto de nós Standard do GKE, pode escolher entre três estratégias de atualização configuráveis, incluindo atualizações rápidas, atualizações azul-verde> e atualizações azul-verde com ajuste de escala automático (pré-visualização). Os node pools geridos pelo Autopilot em clusters Standard usam sempre atualizações rápidas.

Para pools de nós padrão, escolha uma estratégia e use os parâmetros para ajustar a estratégia de modo a adequar-se melhor às necessidades do ambiente do cluster.

Como funcionam as atualizações de nós

Enquanto um nó está a ser atualizado, o GKE deixa de agendar novos pods no mesmo e tenta agendar os respetivos pods em execução noutros nós. Isto é semelhante a outros eventos que recriam o nó, como ativar ou desativar uma funcionalidade no conjunto de nós.

Durante as atualizações automáticas ou manuais de nós, os PodDisruptionBudgets (PDBs) e o período de tolerância de terminação de pods são respeitados durante um máximo de 1 hora. Se não for possível agendar Pods em execução no nó para novos nós após uma hora, o GKE inicia a atualização na mesma. Este comportamento aplica-se mesmo que configure os PDBs para terem sempre todas as réplicas disponíveis definindo o campo maxUnavailable como 0 ou 0%, ou definindo o campo minAvailable como 100% ou o número de réplicas. Em todos estes cenários, o GKE elimina os pods após uma hora para que a eliminação do nó possa ocorrer.

A atualização só fica concluída quando todos os nós forem recriados e o cluster estiver no novo estado. Quando um nó recém-atualizado se regista no plano de controlo, o GKE marca o nó como agendável.

As novas instâncias de nós executam a nova versão do Kubernetes, bem como o seguinte:

• A imagem do nó
• kubelet
• kube-proxy

Para que uma atualização do node pool seja considerada concluída, todos os nós no node pool têm de ser recriados. Se uma atualização tiver sido iniciada, mas não tiver sido concluída e estiver num estado parcialmente atualizado, a versão do conjunto de nós pode não refletir a versão de todos os nós. Para saber mais, consulte o artigo Algumas versões de nós não correspondem à versão do conjunto de nós após uma atualização incompleta do conjunto de nós. Para determinar que a atualização do node pool foi concluída, verifique o estado da atualização do node pool. Se a operação de atualização estiver fora do período de retenção, verifique se a versão de cada nó individual corresponde à versão do conjunto de nós.

Guarde os seus dados em discos persistentes antes de fazer a atualização

Antes de atualizar um conjunto de nós, tem de garantir que todos os dados que precisa de manter estão armazenados num pod através de volumes persistentes, que usam discos persistentes. Os discos persistentes são desmontados, em vez de apagados, durante as atualizações, e os respetivos dados são transferidos entre os pods.

As seguintes restrições aplicam-se aos discos persistentes:

• Os nós nos quais os pods estão a ser executados têm de ser VMs do Compute Engine.
• Essas VMs têm de estar no mesmo projeto e zona do Compute Engine que o disco persistente.

Para saber como adicionar um disco persistente a uma instância de nó existente, consulte o artigo Adicionar ou redimensionar discos persistentes zonais na documentação do Compute Engine.

Atualize manualmente um node pool

Pode atualizar manualmente a versão de um node pool padrão ou de um node pool gerido pelo Autopilot num cluster padrão. Pode fazer corresponder a versão do plano de controlo ou usar uma versão anterior que ainda esteja disponível e seja compatível com o plano de controlo. Pode atualizar manualmente vários conjuntos de nós em paralelo, enquanto o GKE atualiza automaticamente apenas um conjunto de nós de cada vez.

Quando atualiza manualmente um conjunto de nós, o GKE remove todas as etiquetas que adicionou a nós individuais através de kubectl. Para evitar esta situação, aplique etiquetas aos conjuntos de nós.

Antes de atualizar manualmente o conjunto de nós, considere as seguintes condições:

• A atualização de um node pool pode interromper as cargas de trabalho em execução nesse node pool. Para evitar esta situação, pode criar um novo conjunto de nós com a versão necessária e migrar a carga de trabalho. Após a migração, pode eliminar o conjunto de nós antigo.
• Se atualizar um conjunto de nós com um Ingress num estado de erro, o grupo de instâncias não é sincronizado. Para contornar este problema, verifique primeiro o estado através do comando kubectl get ing. Se o grupo de instâncias não estiver sincronizado, pode contornar o problema aplicando novamente o manifesto usado para criar a entrada.

Pode atualizar manualmente os seus conjuntos de nós para uma versão compatível com o plano de controlo:

• Para pools de nós padrão, pode usar a Cloud de Confiance consola ou a Google Cloud CLI.

• Para pools de nós geridos pelo Autopilot, só pode usar a Google Cloud CLI.

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Altere a versão dos node pools

Pode alterar para uma versão anterior de um node pool, por exemplo, para mitigar uma atualização do node pool sem êxito. Reveja as limitações antes de fazer a mudança para uma versão anterior de um conjunto de nós.

1. Defina uma exclusão de manutenção para o cluster para impedir que o pool de nós seja atualizado automaticamente pelo GKE após a reversão.
2. Para reverter um node pool, especifique uma versão anterior seguindo as instruções para atualizar manualmente um node pool.

Altere os parâmetros de atualização por picos

Para mais informações sobre como alterar os parâmetros de atualização de picos, consulte o artigo Configure atualizações de picos.

Verifique o estado da atualização do conjunto de nós

Pode verificar o estado de uma atualização através de gcloud container operations.

Veja uma lista de todas as operações em execução e concluídas no cluster dos últimos 12 dias, se houver menos de 5000 operações, ou as últimas 5000 operações:

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

A cada operação é atribuído um ID da operação e um tipo de operação, bem como horas de início e fim, cluster de destino e estado. A lista é semelhante ao seguinte exemplo:

NAME                              TYPE                ZONE           TARGET              STATUS_MESSAGE  STATUS  START_TIME                      END_TIME
operation-1505407677851-8039e369  CREATE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT16:47:57.851933021Z  20xx-xx-xxT16:50:52.898305883Z
operation-1505500805136-e7c64af4  UPGRADE_CLUSTER     us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:40:05.136739989Z  20xx-xx-xxT18:41:09.321483832Z
operation-1505500913918-5802c989  DELETE_CLUSTER      us-west1-a     my-cluster                          DONE    20xx-xx-xxT18:41:53.918825764Z  20xx-xx-xxT18:43:48.639506814Z

Para obter mais informações sobre uma operação específica, especifique o ID da operação, conforme mostrado no seguinte comando:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

Por exemplo:

gcloud container operations describe operation-1507325726639-981f0ed6
endTime: '20xx-xx-xxT21:40:05.324124385Z'
name: operation-1507325726639-981f0ed6
operationType: UPGRADE_CLUSTER
selfLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/operations/operation-1507325726639-981f0ed6
startTime: '20xx-xx-xxT21:35:26.639453776Z'
status: DONE
targetLink: https://container.googleapis.com/v1/projects/.../kubernetes-engine/docs/zones/us-central1-a/clusters/...
zone: us-central1-a

Se a atualização foi cancelada ou falhou e está parcialmente concluída, pode retomar ou reverter a atualização.

Verifique as definições de atualização do conjunto de nós

Pode ver detalhes sobre a estratégia de atualização de nós que está a ser usada para os seus conjuntos de nós com o comando gcloud container node-pools describe. Para as atualizações azul-verde, o comando também devolve a fase atual da atualização.

Execute o seguinte comando:

gcloud container node-pools describe NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Substitua o seguinte:

• NODE_POOL_NAME: o nome do node pool a descrever.
• CLUSTER_NAME: o nome do cluster do grupo de nós a descrever.
• CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.

Este comando produz as definições de atualização atuais. O exemplo seguinte mostra o resultado se estiver a usar a estratégia de atualização azul-verde.

upgradeSettings:
  blueGreenSettings:
    nodePoolSoakDuration: 1800s
    standardRolloutPolicy:
      batchNodeCount: 1
      batchSoakDuration: 10s
  strategy: BLUE_GREEN

Se estiver a usar a estratégia de atualização azul-verde, o resultado também inclui detalhes sobre as definições de atualização azul-verde e a respetiva fase intermédia atual. O exemplo seguinte mostra como pode ser apresentado:

updateInfo:
  blueGreenInfo:
    blueInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{BLUE_INSTANCE_GROUP_NAME}
    bluePoolDeletionStartTime: {BLUE_POOL_DELETION_TIME}
    greenInstanceGroupUrls:
    - https://www.googleapis.com/compute/v1/projects/{PROJECT_ID}/zones/{LOCATION}/instanceGroupManagers/{GREEN_INSTANCE_GROUP_NAME} 
    greenPoolVersion: {GREEN_POOL_VERSION}
    phase: DRAINING_BLUE_POOL

Cancele uma atualização de node pool

Pode cancelar uma atualização em qualquer altura. Para saber mais sobre o que acontece quando cancela uma atualização de pico, consulte o artigo Cancele uma atualização de pico. Para saber mais sobre o que acontece quando cancela uma atualização azul-verde, consulte o artigo Cancele uma atualização azul-verde.

1. Obtenha o ID da operação de atualização:

   gcloud container operations list \
         --location=CONTROL_PLANE_LOCATION
   

2. Cancele a atualização:

   gcloud container operations cancel OPERATION_ID \
         --location=CONTROL_PLANE_LOCATION
   

Consulte a gcloud container operations cancel documentação.

Retome uma atualização do node pool

Pode retomar uma atualização iniciando-a manualmente novamente e especificando a versão de destino da atualização original.

Por exemplo, se uma atualização falhou ou se pausou uma atualização em curso, pode retomar a atualização cancelada iniciando novamente a mesma atualização no conjunto de nós, especificando a versão de destino da operação de atualização inicial.

Para saber mais sobre o que acontece quando retoma uma atualização, consulte os artigos Retome uma atualização rápida e atualização azul/verde.

Para retomar uma atualização, use o seguinte comando:

gcloud container clusters upgrade CLUSTER_NAME \
  --node-pool=NODE_POOL_NAME \
  --location=CONTROL_PLANE_LOCATION \
  --cluster-version VERSION

Substitua o seguinte:

• NODE_POOL_NAME: o nome do node pool para o qual quer retomar a atualização do node pool.
• CLUSTER_NAME: o nome do cluster do node pool para o qual quer retomar a atualização.
• CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.
• VERSION: a versão de destino da atualização do conjunto de nós cancelada.

Para mais informações, consulte a gcloud container clusters upgrade documentação.

Reverta uma atualização de um node pool

Pode reverter um node pool para fazer o downgrade dos nós atualizados para o respetivo estado original de antes do início da atualização do node pool.

Use o comando rollback se uma atualização em curso tiver sido cancelada, a atualização tiver falhado ou a atualização estiver incompleta devido a um período de manutenção com limite de tempo excedido. Em alternativa, se quiser especificar a versão, siga as instruções para fazer o downgrade do conjunto de nós.

Para saber mais sobre o que acontece quando reverte uma atualização de um conjunto de nós, consulte os artigos Reverta uma atualização de picos ou Reverta uma atualização azul/verde.

Para reverter uma atualização, execute o seguinte comando:

gcloud container node-pools rollback NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Substitua o seguinte:

• NODE_POOL_NAME: o nome do node pool para o qual reverter a atualização do node pool.
• CLUSTER_NAME: o nome do cluster do node pool para o qual reverter a atualização.
• CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.

Consulte a gcloud container node-pools rollback documentação.

Conclua uma atualização do node pool

Se estiver a usar a estratégia de atualização azul-verde, pode concluir uma atualização do conjunto de nós durante a fase de teste de esforço, ignorando o resto do tempo de teste de esforço.

Para saber como funciona a conclusão de uma atualização de node pool, consulte o artigo Conclua uma atualização de node pool.

Para concluir uma atualização quando usar a estratégia de atualização azul/verde, execute o seguinte comando:

gcloud container node-pools complete-upgrade NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location=CONTROL_PLANE_LOCATION

Substitua o seguinte:

• NODE_POOL_NAME: o nome do node pool para o qual quer concluir a atualização.
• CLUSTER_NAME: o nome do cluster do node pool para o qual quer concluir a atualização.
• CONTROL_PLANE_LOCATION: a localização (região ou zona) do plano de controlo, como us-central1 ou us-central1-a.

Consulte a gcloud container node-pools complete-upgrade documentação.

Problemas conhecidos

Se tiver objetos PodDisruptionBudget configurados que não permitam interrupções adicionais, as atualizações de nós podem falhar ao atualizar para a versão do plano de controlo após várias tentativas. Para evitar esta falha, recomendamos que aumente a escala de Deployment ou HorizontalPodAutoscaler para permitir que o nó seja esvaziado, ao mesmo tempo que respeita a configuração de PodDisruptionBudget.

Para ver todos os objetos PodDisruptionBudget que não permitem interrupções:

kubectl get poddisruptionbudget --all-namespaces -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Embora as atualizações automáticas possam encontrar o problema, o processo de atualização automática força a atualização dos nós. No entanto, a atualização demora mais uma hora por cada nó no espaço de nomes istio-system que viole o PodDisruptionBudget.

Resolução de problemas

Para obter informações sobre a resolução de problemas, consulte o artigo Resolva problemas de atualizações de clusters.

O que se segue?

• Saiba mais sobre as estratégias de atualização de nós.
• Saiba mais sobre as atualizações de clusters.
• Saiba mais sobre as atualizações automáticas de nós.
• Leia acerca dos períodos de manutenção e das exclusões.