Como fazer o upgrade manual de um cluster ou pool de nós

Neste documento, explicamos como solicitar manualmente um upgrade ou downgrade do plano de controle ou dos nós de um cluster do Google Kubernetes Engine (GKE). O GKE faz upgrade automático da versão do plano de controle e dos nós para garantir que o cluster receba novos recursos, correções de bugs e patches de segurança. No entanto, conforme explicado neste documento, você também pode fazer esses upgrades manualmente.

Para mais informações sobre como os upgrades de cluster automáticos e manuais funcionam, consulte Sobre os upgrades de cluster do GKE. Você também pode controlar quando os upgrades automáticos podem ou não ocorrer com a configuração de janelas e exclusões de manutenção.

É possível fazer upgrade da versão manualmente da seguinte maneira:

Para fazer upgrade de um cluster, o GKE atualiza a versão que o plano de controle e os nós executam em operações separadas. Os clusters são atualizados para uma versão secundária mais recente (por exemplo, da 1.33 para a 1.34) ou para uma versão de patch mais recente (por exemplo, da 1.33.4-gke.1350000 para a 1.33.5-gke.1080000). O plano de controle e os nós de um cluster não executam necessariamente a mesma versão o tempo todo. Para mais informações sobre versões, consulte Controle de versões e suporte do GKE.

Para mais informações sobre como os upgrades de cluster funcionam, incluindo upgrades automáticos e manuais, consulte Sobre upgrades de cluster do GKE.

Novas versões do GKE são anunciadas regularmente, e é possível receber avisos sobre as novas versões disponíveis para cada cluster específico com notificações de cluster. Para encontrar destinos específicos de upgrade automático para clusters, receba informações sobre os upgrades de um cluster.

Para mais informações sobre as versões disponíveis, consulte Controle de versões. Para mais informações sobre clusters, consulte Arquitetura de cluster. Para orientações sobre como fazer upgrade de clusters, consulte Práticas recomendadas para fazer upgrade de clusters.

Antes de começar

Antes de começar, verifique se você realizou as tarefas a seguir:

  • Ativar a API Google Kubernetes Engine.
    • Ativar a API Google Kubernetes Engine
  • Se você quiser usar a CLI do Google Cloud para essa tarefa, instale e inicialize a gcloud CLI. Se você instalou a gcloud CLI anteriormente, instale a versão mais recente executando o comando gcloud components update. Talvez as versões anteriores da gcloud CLI não sejam compatíveis com a execução dos comandos neste documento.

Sobre o upgrade

Os upgrades do plano de controle e dos nós de um cluster são feitos separadamente. O plano de controle e os nós do cluster não executam necessariamente a mesma versão o tempo todo.

Os planos de controle e nós de cluster são atualizados regularmente, independentemente de o cluster estar inscrito em um canal de lançamento ou não.

Limitações

Clusters Alpha não podem receber upgrade.

Versões compatíveis

As notas da versão anunciam quando novas versões estão disponíveis e quando versões anteriores não estão mais disponíveis. A qualquer momento, é possível listar todas as versões compatíveis de cluster e nó usando este comando:

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

Substitua CONTROL_PLANE_LOCATION pelo local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.

Se o cluster estiver inscrito em um canal de lançamento, será possível fazer upgrade para uma versão de patch em um canal de lançamento diferente com a mesma versão secundária do plano de controle. Por exemplo, é possível fazer upgrade do cluster da versão 1.33.4-gke.1350000 no canal normal para 1.33.5-gke.1162000 no canal rápido. Para mais informações, consulte Executar versões de patch de um canal mais recente. Todos os clusters do Autopilot são registrados em canais de lançamento.

Sobre o downgrade

É possível fazer downgrade da versão do cluster para uma versão anterior em determinados cenários:

Além dos cenários descritos nos pontos anteriores, não é possível fazer downgrade de um cluster. Não é possível fazer downgrade de um plano de controle de cluster para uma versão secundária anterior, mesmo após um upgrade secundário de uma etapa do plano de controle. Por exemplo, se o plano de controle executa a versão 1.34 do GKE, não é possível fazer downgrade para a versão 1.33. Se você tentar fazer isso, a seguinte mensagem de erro vai aparecer:

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 você teste e qualifique upgrades de versão secundária com clusters em um ambiente de teste quando uma nova versão secundária for disponibilizada, mas antes de ela se tornar o destino do upgrade automático para seu cluster. Isso é especialmente recomendado se o cluster for afetado por mudanças significativas na próxima versão secundária, como a remoção de recursos ou APIs descontinuadas. Para mais informações sobre a disponibilidade de versões, consulte Quais versões estão disponíveis em um canal.

Fazer upgrade do plano de controle do cluster

O GKE faz upgrade automático dos planos de controle e nós do cluster. Para gerenciar como o GKE faz upgrade dos clusters, consulte Controlar upgrades de cluster.

Com os clusters do Autopilot e os clusters padrão regionais, o plano de controle permanece disponível durante os upgrades. No entanto, ao iniciar um upgrade do plano de controle para clusters zonais, não é possível modificar a configuração do cluster até que o plano de controle fique acessível novamente em alguns minutos. Os upgrades do plano de controle não afetam a disponibilidade dos nós de trabalho em que as cargas de trabalho são executadas, já que permanecem disponíveis durante os upgrades do plano de controle.

Como parte do gerenciamento das versões do cluster, você pode iniciar um upgrade manual a qualquer momento depois que uma nova versão estiver disponível, usando um dos seguintes métodos:

  • Upgrade em uma etapa: faça upgrade do plano de controle diretamente para uma versão secundária ou de patch mais recente o mais rápido possível. Use essa abordagem se já tiver validado o desempenho do cluster e da carga de trabalho na nova versão secundária.
  • Upgrade secundário do plano de controle em duas etapas com segurança de reversão (prévia): faça upgrade do plano de controle para uma versão secundária mais recente usando um processo de duas etapas em que é possível validar a nova versão secundária por um período de tempo de absorção e reverter, se necessário. Esse método de upgrade está disponível apenas para upgrades manuais secundários do plano de controle para a versão 1.33 ou mais recente.

Fazer upgrade manual do plano de controle com um upgrade de uma etapa

É possível fazer upgrade manual do seu plano de controle do Autopilot ou Standard usando o Google Cloud console ou a Google Cloud CLI.

Console

Para atualizar manualmente o plano de controle do cluster, siga estas etapas:

  1. Acesse a página Google Kubernetes Engine no Google Cloud console.

    Acessar o Google Kubernetes Engine

  2. Clique no nome do cluster.

  3. Em Princípios básicos do cluster, clique em Upgrade disponível ao lado de Versão.

  4. Selecione a nova versão e clique em Salvar alterações.

gcloud

Para ver as versões disponíveis para o plano de controle do seu cluster, execute o seguinte comando:

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

Para fazer upgrade para a versão padrão do cluster, execute o seguinte comando:

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

Para fazer upgrade para uma versão específica que não seja a padrão, especifique a sinalização --cluster-version como no seguinte comando:

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

Substitua VERSION pela versão em que você quer fazer upgrade do cluster. Use uma versão específica, como 1.32.9-gke.1072000, ou um alias de versão, como latest. Para mais informações, consulte Como especificar a versão do cluster.

Depois de fazer upgrade de um plano de controle padrão, é possível fazer upgrade dos nós dele. Por padrão, os nós padrão criados com o console Google Cloud têm o upgrade automático ativado. Isso acontece automaticamente. O Autopilot sempre faz o upgrade automático dos nós.

Upgrade secundário do plano de controle em duas etapas com segurança de rollback

É possível fazer upgrade manual do plano de controle do cluster do GKE Autopilot ou Standard para a próxima versão secundária com um upgrade em duas etapas. Nesse processo de duas etapas, você pode testar o desempenho do cluster com a nova versão secundária, conhecida como versão binária, usando os recursos e as APIs da versão secundária anterior, conhecida como versão emulada. Durante esse período, em que o plano de controle é executado no que é conhecido como modo emulado, é possível reverter para a versão secundária anterior, se necessário. Para mais informações sobre como o Kubernetes permite esse tipo de upgrade, consulte Versão de compatibilidade para componentes do plano de controle do Kubernetes.

Os upgrades em duas etapas funcionam da seguinte maneira:

  1. Upgrade binário: o GKE faz upgrade do binário do plano de controle 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 binário, mas continua emulando o comportamento da API da versão secundária anterior. Por exemplo, é possível chamar APIs que foram removidas na nova versão secundária, mas ainda estão disponíveis na versão secundária anterior.
    • Testar novo binário: é possível testar os novos binários para regressões, correções e mudanças de desempenho antes de disponibilizar os recursos do Kubernetes com a nova versão secundária. Monitore métricas, registros, status de pods, taxas de erro e latência de aplicativos.
    • Absorva as mudanças: aguarde de seis horas a sete dias para ter tempo de testar e monitorar. Depois desse período, o GKE realiza o upgrade da versão emulada.
    • Reverter ou concluir o upgrade: é possível reverter, se necessário. Ou, avance para a próxima etapa se você tiver confiança na nova versão secundária, não quiser esperar a conclusão do período de teste e estiver pronto para começar a usar os novos recursos e as mudanças na API.

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

    • Ativa novos recursos: todos os novos recursos e mudanças na API da nova versão secundária são ativados.
    • Sem reversão: depois dessa etapa, não é possível reverter para a versão secundária original. O upgrade foi concluído.

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

  • Não é possível iniciar um upgrade secundário do plano de controle em uma etapa.
  • Não é possível criar ou fazer upgrade dos nós para uma versão posterior à versão emulada.
  • O GKE não realiza nenhum tipo de upgrade automático no plano de controle ou nos nós.

Iniciar um upgrade em duas etapas

Inicie um upgrade em duas etapas 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:

  • CLUSTER_NAME: o nome do cluster.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, 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 de reversão segura. É possível definir esse valor por um período mínimo de 6 horas e máximo de 7 dias usando os formatos de duração absoluta, conforme explicado na referência de gcloud topic datetimes. Por exemplo, use 2d1h para um tempo de imersão de dois dias e uma hora.

Teste o novo binário durante um upgrade em duas etapas

Durante o tempo de permanência, valide se o cluster (com o plano de controle executando o novo binário) e as cargas de trabalho funcionam conforme o esperado. Siga uma das etapas abaixo, dependendo se você consegue verificar se as cargas de trabalho são compatíveis com o novo binário:

  • Reverter: se você notar um problema com as cargas de trabalho em execução no novo binário, poderá reverter para a versão secundária anterior.
  • Conclua o upgrade: se você verificou que as cargas de trabalho são executadas sem problemas no novo binário, conclua o upgrade se quiser começar a usar os recursos e as APIs da nova versão.
  • Aguardar: você também pode esperar o tempo de teste expirar. Depois, o GKE realiza o upgrade da versão emulada, em que a transição para o uso dos recursos e APIs da nova versão secundária é feita.
Observar o upgrade em andamento

Para receber informações sobre um upgrade em andamento, use um dos seguintes recursos:

Reverter um upgrade em duas etapas após o upgrade da versão binária

Durante um upgrade em duas etapas, após o upgrade da versão binária, há o período de teste. Durante esse período, você pode reverter para a versão secundária anterior, se necessário. Não é possível reverter depois que o GKE realiza o upgrade da versão emulada.

Depois que a operação de rollback for concluída, seu plano de controle vai executar a versão secundária anterior, como fazia antes de você iniciar o upgrade em duas etapas.

Siga estas etapas para reverter, se possível:

  1. Verifique se ainda é possível reverter o plano de controle para a versão secundária anterior executando o comando da CLI gcloud em Receber informações de upgrades no nível do cluster. Determine se é possível fazer reverter pela saída do comando:

    • É possível fazer reverter se houver uma seção rollbackSafeUpgradeStatus na saída. Nessa seção, salve o previousVersion para a variável VERSION na próxima etapa. Siga para a próxima etapa.
    • Não é possível fazer reverter se não houver uma seção rollbackSafeUpgradeStatus. Isso indica que o GKE já fez o upgrade da versão emulada. Não é possível realizar a próxima etapa.

  2. Se a etapa anterior determinar que a reversão é possível, reverter para a versão anterior:

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

    O VERSION precisa ser a versão de patch exata usada anteriormente. Você salvou essa versão na etapa anterior.

Depois de executar esse comando e fazer downgrade para a versão anterior, você pode determinar por que a carga de trabalho não foi executada corretamente no novo binário. Se necessário, entre em contato com o Cloud Customer Care e forneça registros, mensagens de erro e detalhes relevantes sobre a falha de validação encontrada. Para mais informações, consulte Receber suporte.

Depois de resolver o problema, faça o upgrade manual novamente para a nova versão secundária.

Concluir o upgrade em duas etapas

Durante o período de teste, se você verificar que as cargas de trabalho são executadas corretamente com o novo binário, poderá pular o restante do tempo de teste:

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

Depois de executar esse comando, não será mais possível fazer downgrade para a versão secundária anterior.

Fazer downgrade do plano de controle para uma versão de patch anterior

  1. Defina uma exclusão de manutenção antes de fazer downgrade para impedir que o GKE faça upgrade do plano de controle automaticamente depois do downgrade.

  2. Faça downgrade do plano de controle do cluster para uma versão de patch anterior:

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

Como desativar os upgrades automáticos do cluster

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ões para suspender temporariamente os upgrades de planos de controle e nós.

Embora não seja recomendado, é possível desativar o upgrade automático de nós para pools de nós padrão.

Verificar o histórico recente de upgrades do plano de controle

Para conferir um resumo do histórico recente de atualizações automáticas de um cluster, receba informações sobre os upgrades de um cluster.

Como alternativa, liste as operações recentes para ver quando o plano de controle foi atualizado:

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

Upgrade dos pools de nós

Por padrão, os pools de nós do Standard têm o upgrade automático ativado, e todos os pools de nós gerenciados pelo Autopilot em clusters do Standard sempre têm o upgrade automático ativado. Os upgrades automáticos de nós garantem que o plano de controle e a versão do nó do cluster permaneçam sincronizados e em conformidade com a política de distorção de versão do Kubernetes, que garante que os planos de controle sejam compatíveis com nós de até duas versões secundárias anteriores ao plano de controle. Por exemplo, os planos de controle do Kubernetes 1.34 são compatíveis com os nós do Kubernetes 1.32.

Prática recomendada:

Evite desativar os upgrades automáticos de nós com pools de nós padrão para que seu cluster se beneficie dos upgrades listados no parágrafo anterior.

Com os upgrades de pool de nós do GKE Standard, é possível escolher entre três estratégias de upgrade configuráveis, incluindo upgrades súbitos, upgrades azul-verde e upgrades azul-verde com escalonamento automático (prévia). Os pools de nós gerenciados pelo Autopilot em clusters padrão sempre usam upgrades súbitos.

Para pools de nós padrão, escolha uma estratégia e use os parâmetros para ajustá-la de acordo com as necessidades do ambiente do cluster.

Como funcionam os upgrades de nós

Enquanto um nó está sendo atualizado, o GKE interrompe a programação de novos pods nele e tenta programar seus pods em execução em outros nós. Isso é semelhante a outros eventos que recriam o nó, como ativar ou desativar um recurso no pool de nós.

Durante os upgrades automáticos ou manuais de nós, os PodDisruptionBudgets (PDBs) e o período de carência do encerramento do pod são respeitados por 1 hora no máximo. Se os pods em execução no nó não puderem ser programados em novos nós após uma hora, o GKE inicia o upgrade mesmo assim. Esse comportamento se aplica mesmo se você configurar seus PDBs para sempre ter todas as suas réplicas disponíveis, definindo o campo maxUnavailable como 0 ou 0% ou definindo o campo minAvailable como 100% ou ao número de réplicas. Em todos esses cenários, o GKE exclui os pods após uma hora para que a exclusão do nó possa acontecer.

Prática recomendada:

Se uma carga de trabalho em execução em um pool de nós padrão exigir mais flexibilidade com encerramento otimizado, use upgrades azul-verde, que fornecem configurações para mais tempo de imersão para estender as verificações de PDB além do padrão de uma hora.

Para saber mais sobre o que esperar durante o encerramento do nó em geral, consulte o tópico sobre Pods.

O upgrade será concluído apenas quando todos os nós forem recriados e o cluster assumir o novo estado. Quando um nó recém-atualizado é registrado no plano de controle, o GKE o marca como programável.

As instâncias do novo nó executam a nova versão do Kubernetes e também:

Para que um upgrade do pool de nós seja considerado concluído, todos os nós no pool precisam ser recriados. Se um upgrade foi iniciado, mas não foi concluído e está em um estado parcialmente atualizado, a versão do pool de nós pode não refletir a versão de todos os nós. Para saber mais, consulte Algumas versões de nós não correspondem à versão do pool de nós após um upgrade incompleto do pool de nós. Para determinar se o upgrade do pool de nós foi concluído, verifique o status do upgrade do pool de nós. Se a operação de upgrade estiver além do período de armazenamento, verifique se cada versão de nó individual corresponde à versão do pool de nós.

Salve seus dados em discos permanentes antes de fazer o upgrade

Antes de fazer upgrade de um pool de nós, garanta que todos os dados que você precisa manter estejam armazenados em um pod usando volumes permanentes, que usam discos permanentes. Em vez de apagados, os discos permanentes são desconectados durante os upgrades, e os dados deles são transferidos entre os pods.

As seguintes restrições são relacionadas aos discos permanentes:

  • Os pods estão em execução nos nós que precisam ser VMs do Compute Engine.
  • Essas VMs precisam estar no mesmo projeto e zona do Compute Engine que o disco permanente.

Para saber como adicionar um disco permanente a uma instância de nó atual, consulte Como adicionar ou redimensionar discos permanentes zonais na documentação do Compute Engine.

Como fazer upgrade manual de um pool de nós

É possível fazer upgrade manual da versão de um pool de nós padrão ou gerenciado pelo Autopilot em um cluster padrão. É possível igualar a versão do plano de controle ou usar uma versão anterior que ainda esteja disponível e seja compatível com o plano de controle. É possível fazer upgrade manual de vários pools de nós em paralelo, enquanto o GKE faz upgrade automático de apenas um pool de nós por vez.

Quando você faz upgrade manual de um pool de nós, o GKE remove todos os rótulos adicionados a nós individuais usando kubectl. Para evitar isso, aplique rótulos aos pools de nós.

Antes de fazer upgrade manual do pool de nós, considere as seguintes condições:

  • O upgrade de um pool de nós pode interromper a execução das cargas de trabalho nele. Para evitar isso, crie um novo pool de nós com a versão necessária e migre a carga de trabalho. Após a migração, é possível excluir o antigo pool de nós.
  • Se você fizer upgrade de um pool de nós que tenha um Entrada com erro, o grupo de instâncias não será sincronizado. Para resolver esse problema, primeiro verifique o status usando o comando kubectl get ing. Se o grupo de instâncias não estiver sincronizado, aplique novamente o manifesto usado para criar o Ingress.

É possível fazer upgrade manual dos pools de nós para uma versão compatível com o plano de controle:

Console

Para fazer upgrade de um pool de nós padrão usando o console Google Cloud , siga estas etapas:

  1. Acesse a página Google Kubernetes Engine no Google Cloud console.

    Acessar o Google Kubernetes Engine

  2. Clique no nome do cluster.

  3. Na página Detalhes do cluster, clique na guia Nós.

  4. Na seção Pools de nós, clique no nome do pool de nós que você quer atualizar.

  5. Clique em Editar.

  6. Em Versão do nó, clique em Alterar.

  7. Selecione a versão necessária na lista suspensa Versão do nó e clique em Alterar.

Talvez leve vários minutos para que a versão do nó seja alterada.

gcloud

As variáveis a seguir são usadas nos comandos desta seção:

  • CLUSTER_NAME: o nome do cluster do pool de nós a ser atualizado.
  • NODE_POOL_NAME: o nome do pool de nós a ser atualizado.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.
  • VERSION: a versão do Kubernetes para que os nós são atualizados. Por exemplo, --cluster-version=1.34.1-gke.1293000 ou cluster-version=latest.

Fazer upgrade de um pool de nós:

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

Para especificar uma versão diferente do GKE nos nós, use a sinalização opcional --cluster-version:

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

Para mais informações sobre como especificar versões, consulte Controle de versões.

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

Fazer downgrade de pools de nós

É possível fazer downgrade de um pool de nós, por exemplo, para reduzir um upgrade mal-sucedido. Analise as limitações antes de fazer downgrade de um pool de nós.

Prática recomendada:

Use a estratégia de upgrade de nós azul-verde se você precisar otimizar para mitigação de riscos em upgrades de pool de nós que afetam suas cargas de trabalho. Com essa estratégia, é possível reverter um upgrade em andamento para os nós originais se ele não for bem-sucedido.

  1. Defina uma exclusão de manutenção para o cluster para evitar que o pool de nós seja atualizado automaticamente pelo GKE após o downgrade.
  2. Para fazer downgrade de um pool de nós, especifique uma versão anterior seguindo as instruções para Fazer upgrade manual de um pool de nós.

Mudar os parâmetros de upgrade súbito

Para mais informações sobre como mudar os parâmetros de upgrade súbito, consulte Configurar upgrades súbitos.

Verificar o status do upgrade do pool de nós

É possível verificar o status de um upgrade usando gcloud container operations.

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

gcloud container operations list \
    --location=CONTROL_PLANE_LOCATION

Cada operação recebe um código e um tipo, além de horários de início e término, cluster de destino e status. A lista é semelhante ao exemplo a seguir:

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 ver mais informações sobre uma operação específica, informe o ID da operação, conforme mostrado no comando a seguir:

gcloud container operations describe OPERATION_ID \
    --location=CONTROL_PLANE_LOCATION

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 o upgrade foi cancelado ou falhou e está parcialmente concluído, é possível retomar ou reverter o upgrade.

Verificar as configurações de upgrade do pool de nós

É possível ver detalhes sobre a estratégia de upgrade de nós que está sendo usada para os pools de nós usando o comando gcloud container node-pools describe. Para upgrades em azul-verde, o comando também retorna a fase atual do upgrade.

Execute este comando:

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

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós a ser descrito.
  • CLUSTER_NAME: o nome do cluster do pool de nós a ser descrito.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.

Este comando exibirá as configurações de upgrade atuais. No exemplo a seguir, a saída será exibida se você estiver usando a estratégia de upgrade azul-verde.

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

Se você estiver usando a estratégia de upgrade azul-verde, a saída também incluirá detalhes sobre as configurações de upgrade azul-verde e a fase intermediária atual. O exemplo a seguir mostra como isso pode ser feito:

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

Cancelar um upgrade do pool de nós

Você pode cancelar um upgrade a qualquer momento. Para saber mais sobre o que acontece quando você cancela um upgrade súbito, consulte Cancelar um upgrade súbito. Para saber mais sobre o que acontece quando você cancela um upgrade azul-verde, consulte Cancelar um upgrade azul-verde.

  1. Consiga o ID da operação de upgrade:

    gcloud container operations list \
      --location=CONTROL_PLANE_LOCATION

  2. Cancelar o upgrade:

    gcloud container operations cancel OPERATION_ID \
      --location=CONTROL_PLANE_LOCATION

Consulte a documentação gcloud container operations cancel.

Retomar um upgrade do pool de nós

É possível retomar um upgrade iniciando-o manualmente novamente, especificando a versão de destino do upgrade original.

Por exemplo, se um upgrade falhar ou se você pausar um upgrade em andamento, será possível retomar o upgrade cancelado iniciando o mesmo upgrade novamente no pool de nós, especificando a versão de destino da operação inicial de upgrade.

Para saber mais sobre o que acontece quando você retoma um upgrade, consulte Retomar um upgrade súbito e Upgrade azul-verde.

Para retomar um upgrade, use o seguinte comando:

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

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós em que você quer retomar o upgrade dele.
  • CLUSTER_NAME: o nome do cluster do pool de nós em que você quer retomar o upgrade.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.
  • VERSION: a versão de destino do upgrade do pool de nós cancelado.

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

Reverter um upgrade do pool de nós

É possível reverter um pool de nós para fazer downgrade dos nós atualizados para o estado original antes do início do upgrade.

Use o comando rollback se um upgrade em andamento tiver sido cancelado, tiver ocorrido falha no upgrade ou ele estiver incompleto devido a uma janela de manutenção tempo limite. Como alternativa, se você quiser especificar a versão, siga as instruções para fazer downgrade do pool de nós.

Para saber mais sobre o que acontece quando você reverte um upgrade de pool de nós, consulte Reverter um upgrade súbito ou Reverter um upgrade azul-verde.

Para reverter um upgrade, execute o seguinte comando:

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

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós para reverter o upgrade do pool de nós.
  • CLUSTER_NAME: o nome do cluster do pool de nós para onde reverter o upgrade.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.

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

Concluir um upgrade do pool de nós

Se você estiver usando a estratégia de upgrade azul-verde, poderá concluir um upgrade do pool de nós durante a fase de imersão, pulando o restante do tempo de imersão.

Para saber como fazer um upgrade do pool de nós, consulte Concluir um upgrade do pool de nós.

Para concluir um upgrade usando a estratégia azul-verde, execute o seguinte comando:

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

Substitua:

  • NODE_POOL_NAME: o nome do pool de nós em que você quer concluir o upgrade.
  • CLUSTER_NAME: o nome do cluster do pool de nós para o qual você quer concluir o upgrade.
  • CONTROL_PLANE_LOCATION: o local (região ou zona) do plano de controle, como us-central1 ou us-central1-a.

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

Problemas conhecidos

Se você tiver objetos PodDisruptionBudget configurados que não podem permitir outras interrupções, o upgrade dos nós poderá falhar no upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você escalone verticalmente Deployment ou HorizontalPodAutoscaler para permitir que o nó seja drenado enquanto respeita a configuração 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 os upgrades automáticos possam encontrar o problema, o processo de upgrade automático força os nós a fazer upgrade. No entanto, o upgrade leva uma hora extra para cada nó no namespace istio-system que viola o PodDisruptionBudget.

Solução de problemas

Para informações sobre solução de problemas, consulte Resolver problemas de upgrades de cluster.

A seguir