Esta página foi traduzida pela API Cloud Translation.

Fazer upgrade de um cluster ou pool de nós

Neste documento, explicamos como fazer upgrade de clusters e pools de nós no Google Distributed Cloud. Este documento apresenta as etapas para fazer upgrade da estação de trabalho do administrador, dos clusters de usuário e dos clusters de administrador. Para clusters de usuários, este documento apresenta as etapas para fazer upgrade do plano de controle e dos pools de nós ao mesmo tempo ou separadamente.

Antes de continuar, recomendamos que você analise a seguinte documentação:

Visão geral do upgrade
Entre outras coisas, este documento descreve o desvio de versão com suporte e as regras de versão para upgrades, que foram alteradas para a versão 1.28 e mais recentes.
Práticas recomendadas de upgrade
Neste documento, você encontra listas de verificação e práticas recomendadas para o upgrade de clusters.

Revise suas regras de firewall

Na versão 1.29 e mais recentes, as verificações de simulação do lado do servidor estão ativadas por padrão. As verificações de simulação do lado do servidor exigem regras de firewall adicionais. Em Regras de firewall para clusters de administrador, procure "Verificações de simulação" e verifique se todas as regras de firewall necessárias estão configuradas.

Com as verificações de simulação do lado do servidor, quando você faz upgrade de um cluster de usuário usando gkectl, elas são executadas no cluster do administrador, e não localmente na estação de trabalho do administrador. As verificações de simulação do lado do servidor também são executadas no cluster de administrador quando você usa o console do Google Cloud, a Google Cloud CLI ou o Terraform para fazer upgrade de um cluster.

Quando você faz upgrade de um cluster de administrador, o Google Distributed Cloud implanta um cluster de Kubernetes no Docker (tipo) para hospedar temporariamente os controladores do Kubernetes necessários para fazer o upgrade do cluster de administrador. Esse cluster temporário é chamado de cluster de inicialização. As verificações de simulação do lado do servidor são executadas no cluster de inicialização quando você faz upgrade de um cluster de administrador.

Requisitos do IAM e da API do Google

Para fazer upgrade de um cluster para a versão 1.28 e mais recentes, ative kubernetesmetadata.googleapis.com e conceda o papel kubernetesmetadata.publisher do IAM à conta de serviço logging-monitoring. Essas alterações são necessárias para usar o Cloud Monitoring.

Ativar kubernetesmetadata.googleapis.com:
```
gcloud services enable --project PROJECT_ID  \
    kubernetesmetadata.googleapis.com
```
Substitua PROJECT_ID pelo ID do projeto host da frota em que o cluster de usuário é membro. Esse é o projeto especificado quando o cluster foi criado. Se você criou o cluster usando gkectl, esse será o ID do projeto no campo gkeConnect.projectID no arquivo de configuração do cluster.
Se a organização tiver configurado uma lista de permissões que permite que o tráfego das APIs do Google e outros endereços passem pelo servidor proxy, adicione kubernetesmetadata.googleapis.com à lista de permissões.
Conceda o papel kubernetesmetadata.publisher à conta de serviço logging-monitoring:
```
gcloud projects add-iam-policy-binding PROJECT_ID \
  --member "serviceAccount:SERVICE_ACCOUNT_EMAIL" \
  --role "roles/kubernetesmetadata.publisher"
```
Substitua SERVICE_ACCOUNT_EMAIL pelo endereço de e-mail da conta de serviço de monitoramento de registros.

Requisitos do IAM para fazer upgrade de clusters de usuário

Pule esta seção se você planeja usar gkectl para o upgrade do cluster de usuário.

Se você quiser usar o console do Google Cloud, a Google Cloud CLI ou o Terraform para fazer upgrade de um cluster de usuário e não for proprietário de um projeto, será necessário receber o papel do Identity and Access Management roles/gkeonprem.admin no projeto do Google Cloud em que o cluster foi criado. Para detalhes sobre as permissões incluídas nesse papel, consulte Papéis do GKE On-Prem na documentação do IAM.

Para usar o console para fazer upgrade do cluster, no mínimo, você também precisa do seguinte:

roles/container.viewer Com esse papel, os usuários podem ver a página de clusters do GKE e outros recursos do contêiner no console. Para ver detalhes sobre as permissões incluídas nesse papel ou conceder um papel com permissões de leitura/gravação, consulte Papéis do Kubernetes Engine na documentação do IAM.
roles/gkehub.viewer Esse papel permite que os usuários vejam clusters no console. Para ver detalhes sobre as permissões incluídas nesse papel ou conceder um papel com permissões de leitura/gravação, consulte Papéis do GKE Hub na documentação do IAM.

Mudar a configuração antes ou depois de um upgrade

Se você precisar alterar a configuração dos clusters, faça a atualização do cluster antes ou depois do upgrade. A única alteração na configuração do cluster para um upgrade é a versão. Dependendo da versão e do tipo do cluster, outras alterações de configuração são ignoradas silenciosamente ou causam falha no upgrade. Para mais informações, consulte Remover mudanças sem suporte para desbloquear o upgrade.

Faça upgrade da estação de trabalho do administrador

Você precisa fazer upgrade da estação de trabalho do administrador se planeja usar gkectl para fazer upgrade de um cluster de usuário.

Se você planeja usar o console, a CLI gcloud ou o Terraform para fazer upgrade de um cluster de usuário, pule o upgrade da estação de trabalho de administrador por enquanto. No entanto, você vai precisar fazer upgrade da estação de trabalho do administrador quando estiver tudo pronto para fazer upgrade do cluster de administrador, já que gkectl é compatível apenas com upgrades do cluster de administrador.

A maneira como você faz upgrade da estação de trabalho do administrador depende de como ela foi criada: gkeadm ou user-mmanaged.

gkeadm

Localizar os arquivos necessários

Antes de criar sua estação de trabalho de administrador, você preencheu um arquivo de configuração da estação de trabalho de administrador que foi gerado por gkeadm create config. O nome padrão deste arquivo é admin-ws-config.yaml.

Além disso, a estação de trabalho tem um arquivo de informações. O nome padrão desse arquivo é o mesmo nome da estação de trabalho do administrador.

Localize o arquivo de configuração da estação de trabalho de administrador e o arquivo de informações. Você precisa deles para as etapas de upgrade. Se esses arquivos estiverem no diretório atual e tiverem os nomes padrão, não será necessário especificá-los ao executar os comandos de upgrade. Se esses arquivos estiverem em outro diretório ou se você tiver alterado os nomes dos arquivos, especifique-os utilizando as sinalizações --config e --info-file.

Se o arquivo de informações de saída estiver ausente, você poderá recriá-lo. Consulte Recriar um arquivo de informações se estiver ausente.

Fazer upgrade

Para fazer upgrade da estação de trabalho do administrador:

Faça o download de gkeadm:
```
gkeadm upgrade gkeadm --target-version TARGET_VERSION
```
Substitua TARGET_VERSION pela versão de destino do seu upgrade. É necessário especificar um número de versão completo no formato X.Y.Z-gke.N.. Para conferir uma lista das versões do Google Distributed Cloud, consulte Histórico de versões.
Faça upgrade da estação de trabalho do administrador:
```
gkeadm upgrade admin-workstation --config AW_CONFIG_FILE \
    --info-file INFO_FILE
```
Substitua:
- AW_CONFIG_FILE é o caminho do arquivo de configuração da estação de trabalho do administrador. É possível omitir essa sinalização se o arquivo estiver no diretório atual e tiver o nome admin-ws-config.yaml;
- INFO_FILE é o caminho do seu arquivo de informações. Será possível omitir essa sinalização se o arquivo estiver no seu diretório atual. O nome padrão desse arquivo é o mesmo nome da estação de trabalho do administrador.

Gerenciado pelo usuário

Na estação de trabalho do administrador, navegue até um diretório em que você quer instalar uma nova versão do gkectl.

Faça o download de gkectl:

gsutil cp gs://gke-on-prem-release/gkectl/VERSION/gkectl ./
chmod +x gkectl

Substitua VERSION pela versão de destino do seu upgrade. Por exemplo: 1.29.100-gke.248.

Faça o download do pacote do Google Distributed Cloud. Verifique se a versão corresponde à que você usou para fazer o download de gkectl:

gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/VERSION/gke-onprem-vsphere-VERSION.tgz ./

Verificar as versões disponíveis para upgrades de cluster

Execute o seguinte comando para ver quais versões estão disponíveis para upgrade:

gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG

A saída mostra a versão atual e as versões disponíveis para upgrade.

Se você planeja usar o console, a CLI gcloud ou o Terraform para fazer upgrade, levará de 7 a 10 dias após o lançamento para que a versão esteja disponível na API GKE On-Prem em todas as regiões do Google Cloud. O console lista apenas as versões disponíveis para o upgrade do cluster de usuário. As etapas para fazer upgrade de um cluster de usuário usando a CLI gcloud ou o Terraform incluem uma etapa para executar gcloud container vmware clusters query-version-config e acessar as versões disponíveis para o upgrade.

Fazer upgrade de um cluster de usuários

É possível usar gkectl, o console, a CLI gcloud ou o Terraform para fazer upgrade de um cluster de usuário. Para informações sobre como decidir qual ferramenta usar, consulte Escolher uma ferramenta para fazer upgrade de clusters de usuários.

gkectl

Preparar-se para fazer upgrade de um cluster de usuário

Siga estas etapas na estação de trabalho do administrador:

Execute gkectl prepare para importar imagens do SO para o vSphere:

gkectl prepare \
  --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG

Se o cluster tiver um pool de nós do Windows, execute gkectl prepare windows e atualize o campo osImage para o pool de nós. Para instruções detalhadas, consulte Fazer upgrade do cluster de usuário com pools de nós do Windows.
No arquivo de configuração do cluster de usuário, defina gkeOnPremVersion como a versão de destino do upgrade.
Apenas pools de nós Ubuntu e COS: especifique quais pools de nós você quer atualizar. O upgrade de pools de nós separadamente do plano de controle é compatível com os pools de nós do Ubuntu e do COS, mas não para os pools de nós do Windows.

No arquivo de configuração do cluster de usuário, indique quais pools de nós você quer atualizar, da seguinte maneira:
- Para cada pool de nós que você quer atualizar, remova o campo nodePools.nodePool[i].gkeOnPremVersion ou defina-o como a string vazia.
- Para cada pool de nós que você não quer atualizar, defina nodePools.nodePool[i].gkeOnPremVersion como a versão atual.
Por exemplo, suponha que o cluster de usuário esteja na versão 1.15.5-gke.41 e tenha dois pools de nós: pool-1 e pool-2. Suponha também que você queira fazer upgrade do plano de controle e do pool-1 para 1.16.3-gke.45, mas queira que pool-2 permaneça na versão 1.15.5-gke.41. A parte a seguir de um arquivo de configuração de cluster de usuário mostra como especificar esse exemplo:
```
gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: 1.15.5-gke.41
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd
```

Executar verificações de simulação

Ao fazer upgrade para a versão 1.29 e mais recentes, é possível executar as verificações de simulação antes de fazer upgrade de um cluster de usuário:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --dry-run

Com a sinalização --dry-run, gkectl upgrade cluster executa as verificações de simulação, mas não inicia o processo de upgrade. Ainda que as versões anteriores do Google Distributed Cloud executem verificações de simulação, elas não podem ser executadas separadamente do upgrade. Ao adicionar a sinalização --dry-run, é possível encontrar e corrigir quaisquer problemas que as verificações de simulação encontrem no cluster de usuário antes do upgrade.

Executar `gkectl upgrade cluster`

Há duas variações do comando gkectl upgrade cluster:

Assíncrona: (recomendado)
Com a variação assíncrona, o comando inicia o upgrade e conclui. Você não precisa verificar a saída do comando durante todo o upgrade. Em vez disso, é possível verificar periodicamente o progresso do upgrade executando gkectl list clusters e gkectl describe clusters. Para usar a variação assíncrona, inclua a sinalização --async no comando.
Síncrona:
Com a variação síncrona, o comando gkectl upgrade cluster emite mensagens de status para a estação de trabalho do administrador conforme o upgrade avança.

Upgrade assíncrono

Pule esta etapa se você estiver fazendo upgrade para uma versão posterior à 1.16.

Se você estiver usando credenciais preparadas e um registro particular para o cluster de usuário, verifique se a credencial do registro particular está preparada antes de fazer upgrade do cluster de usuário. Para informações sobre como preparar a credencial de registro particular, consulte Configurar credenciais preparadas para clusters de usuário.
Na estação de trabalho do administrador, inicie um upgrade assíncrono:
```
gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG \
  --async
```
O comando anterior é concluído e você pode continuar usando a estação de trabalho do administrador enquanto o upgrade está em andamento.
Para ver o status do upgrade, faça o seguinte:
```
gkectl list clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
A saída mostra um valor para o cluster STATE. Se o cluster ainda estiver sendo atualizado, o valor de STATE vai ser UPGRADING. Exemplo:
```
NAMESPACE             NAME    READY   STATE       AGE   VERSION
my-uc-gkeonprem-mgmt  my-uc   False   UPGRADING   9h    1.29.0-gke.1
```
Os valores possíveis para STATE são PROVISIONING, UPGRADING, DELETING, UPDATING, RUNNING, RECONCILING, ERROR e UNKNOWN.

Para ver mais detalhes sobre o progresso do upgrade e os eventos do cluster, faça o seguinte:

gkectl describe clusters --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --cluster USER_CLUSTER_NAME -v 5

A saída mostra o recurso personalizado OnPremUserCluster para o cluster de usuário especificado, que inclui status, condições e eventos do cluster.

Registramos eventos do início e fim de cada fase crítica do upgrade, incluindo:

ControlPlaneUpgrade
MasterNodeUpgrade
AddonsUpgrade
NodePoolsUpgrade

Exemplo de saída:

Events:
Type    Reason                      Age    From                            Message
----     ------                     ----   ----                            -------
Normal  NodePoolsUpgradeStarted     22m    onprem-user-cluster-controller  Creating or updating node pools: pool-2: Creating or updating node pool
Normal  AddonsUpgradeStarted        22m    onprem-user-cluster-controller  Creating or updating addon workloads
Normal  ControlPlaneUpgradeStarted  25m    onprem-user-cluster-controller  Creating or updating cluster control plane workloads: deploying user-kube-apiserver-base, ...: 14/15 pods are ready
Normal  ControlPlaneUpgradeFinished 23m    onprem-user-cluster-controller  Control plane is running

Quando o upgrade for concluído, gkectl list clusters vai mostrar um STATUS de RUNNING:
```
NAMESPACE             NAME    READY   STATE     AGE     VERSION
my-uc-gkeonprem-mgmt  my-uc   True    RUNNING   9h      1.29.0-gke.1
```
Além disso, quando o upgrade for concluído, gkectl describe clusters vai mostrar um campo Last GKE On Prem Version em Status. Exemplo:
```
Status:
Cluster State:  RUNNING
Last GKE On Prem Version:  1.29.0-gke.1
```

Resolver problemas de upgrade assíncrono

Para fazer um upgrade assíncrono, o tempo limite é baseado no número de nós no cluster. Se o upgrade demorar mais que o tempo limite, o estado do cluster vai ser alterado de UPGRADING para ERROR, com um evento dizendo que a operação de upgrade expirou. O estado ERROR significa que o upgrade está demorando mais do que o esperado, mas não foi encerrado. O controlador continua a reconciliação e a repetir a operação.

Geralmente, uma expiração é o resultado de um impasse causado por um PodDisruptionBudget (PDB). Nesse caso, não é possível remover os pods dos nós antigos e os nós antigos não podem ser reduzidos. Se a remoção do pod demorar mais de 10 minutos, vamos gravar um evento no objeto OnPremUserCluster. É possível capturar o evento executando gkectl describe clusters. Ajuste o PDB para permitir que o nó seja reduzido. Depois disso, vai ser possível continuar e concluir o upgrade.

Evento de exemplo:

Warning  PodEvictionTooLong  96s (x2 over 4m7s)  onprem-user-cluster-controller
Waiting too long(>10m0.00000003s) for (kube-system/coredns-856d6dbfdf-dl6nz) eviction.

Além disso, quando um upgrade é bloqueado ou falha, é possível executar gkectl diagnose para verificar problemas comuns do cluster. Com base no resultado, é possível decidir se você vai realizar uma correção manual ou entrar em contato com a equipe de suporte do Anthos para receber assistência.

Upgrade síncrono

O comando gkectl upgrade executa verificações de simulação. Se as verificações de simulação falharem, o comando vai ser bloqueado. Corrija as falhas ou use a flag --skip-preflight-check-blocking. Só ignore as verificações de simulação se tiver certeza de que não há falhas críticas.

Siga estas etapas na estação de trabalho de administrador:

Pule esta etapa se você estiver fazendo upgrade para uma versão posterior à 1.16.

Se você estiver usando credenciais preparadas e um registro particular para o cluster de usuário, verifique se a credencial do registro particular está preparada antes de fazer upgrade do cluster de usuário. Para informações sobre como preparar a credencial de registro particular, consulte Configurar credenciais preparadas para clusters de usuário.

Fazer upgrade do cluster:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE

Se você estiver fazendo upgrade para a versão 1.14.0 ou mais recente, um novo arquivo kubeconfig será gerado para o cluster de usuário que substituirá qualquer arquivo existente. Para acessar os detalhes do cluster no arquivo, execute o seguinte comando:
```
kubectl config view --kubeconfig USER_CLUSTER_KUBECONFIG
```

Fazer upgrade de outros pools de nós

Se você fez upgrade apenas do plano de controle do cluster de usuário ou do plano de controle e de alguns, mas não todos os pools de nós, siga as etapas abaixo:

Edite o arquivo de configuração do cluster de usuário. Para cada pool de nós que você quer atualizar, remova o campo nodePools.nodePool[i].gkeOnPremVersion ou defina-o como a string vazia, conforme mostrado no exemplo a seguir:

gkeOnPremVersion: 1.16.3-gke.45

nodePools:
- name: pool-1
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 3
  osImageType: ubuntu_containerd
- name: pool-2
  gkeOnPremVersion: ""
  cpus: 4
  memoryMB: 8192
  replicas: 5
  osImageType: ubuntu_containerd

Execute gkectl update cluster para aplicar a alteração:
```
gkectl update cluster --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador;
- USER_CLUSTER_CONFIG: o caminho do arquivo de configuração do cluster de usuário.

Se você encontrar um problema depois de fazer upgrade de um pool de nós, poderá reverter para a versão anterior. Para mais informações, consulte Como reverter um pool de nós após um upgrade.

Retomar um upgrade

Se o upgrade de um cluster de usuário for interrompido, será possível retomar o upgrade executando o mesmo comando de upgrade com a sinalização --skip-validation-all:

gkectl upgrade cluster \
  --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
  --config USER_CLUSTER_CONFIG_FILE \
  --skip-validation-all

Console

O upgrade de um cluster de usuário exige algumas alterações no cluster de administrador. O console faz automaticamente o seguinte:

Registra o cluster de administrador na API GKE On-Prem se ele ainda não estiver registrado.
Faz o download e implanta um pacote de componentes no cluster de administrador. A versão dos componentes corresponde à versão especificada para o upgrade. Esses componentes permitem que o cluster de administrador gerencie clusters de usuário nessa versão.

Para fazer upgrade de um cluster de usuário, faça o seguinte:

No console, acesse a página de visão geral dos clusters do Google Kubernetes Engine.

Acesse os clusters do GKE
Selecione o projeto do Cloud e, em seguida, o cluster que você quer atualizar.
No painel Detalhes, clique em Mais detalhes.
Na seção Princípios básicos do cluster, clique em Fazer upgrade.
Na lista Escolher versão de destino, selecione para qual versão quer fazer upgrade. A lista selecionada contém apenas as versões de patch mais recentes.
Clique em Fazer upgrade.

Antes do upgrade do cluster, as verificações de simulação são executadas para validar o status do cluster e a integridade do nó. Se as verificações de simulação forem aprovadas, o cluster de usuário será atualizado. A atualização leva cerca de 30 minutos.

Para ver o status do upgrade, clique em Mostrar detalhes na guia Detalhes do cluster.

CLI da gcloud

O upgrade de um cluster de usuário exige algumas alterações no cluster de administrador. O comando gcloud container vmware clusters upgrade faz automaticamente o seguinte:

Registra o cluster de administrador na API GKE On-Prem se ele ainda não estiver registrado.
Faz o download e implanta um pacote de componentes no cluster de administrador. A versão dos componentes corresponde à versão especificada para o upgrade. Esses componentes permitem que o cluster de administrador gerencie clusters de usuário nessa versão.

Para fazer upgrade de um cluster de usuário, faça o seguinte:

Atualize os componentes da Google Cloud CLI:
```
gcloud components update
```
Somente pools de nós Ubuntu e COS: se você quiser fazer upgrade apenas do plano de controle do cluster de usuário e deixar todos os pools de nós na versão atual, altere a política de upgrade no cluster:
```
gcloud container vmware clusters update USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --upgrade-policy control-plane-only=True
```
Substitua:
- USER_CLUSTER_NAME: o nome do cluster de usuário que será atualizado.
- PROJECT_ID: o ID do projeto host da frota em que o cluster de usuário é membro. Esse é o projeto especificado quando o cluster foi criado. Se você criou o cluster usando gkectl, esse será o ID do projeto no campo gkeConnect.projectID no arquivo de configuração do cluster.
- REGION: a região do Google Cloud em que a API GKE On-Prem executa e armazena os metadados. Se você criou o cluster usando um cliente da API GKE On-Prem, essa é a região selecionada ao criar o cluster. Se você criou o cluster usando gkectl, essa será a região especificada quando você registrou o cluster na API GKE On-Prem.

Veja uma lista das versões disponíveis para upgrade:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

A saída deste comando é semelhante a:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Você pode ignorar a mensagem após a lista de versões. Não importa se a versão para que você está atualizando está instalada no cluster de administrador. O comando upgrade faz o download e implanta um pacote dos componentes que corresponde à versão que você especificar no comando upgrade.

Faça upgrade do cluster. Se você executou o comando update para alterar a política de upgrade para control-plane-only=True, somente o plano de controle do cluster será atualizado. Caso contrário, o plano de controle do cluster e todos os pools de nós serão atualizados.
```
gcloud container vmware clusters upgrade USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION
```
Substitua VERSION pela versão do Google Distributed Cloud para a qual você quer fazer upgrade. Especifique uma versão com base na saída do comando anterior. Recomendamos que você faça o upgrade para a versão de patch mais recente.

A saída deste comando terá esta aparência:
```
Waiting for operation [projects/example-project-12345/locations/us-west1/operations/operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179] to complete.
```
No exemplo de saída, a string operation-1679543737105-5f7893fd5bae9-942b3f97-75e59179 é o OPERATION_ID da operação de longa duração. Descubra o status da operação executando o comando a seguir em outra janela de terminal:
```
gcloud container vmware operations describe OPERATION_ID \
  --project=PROJECT_ID \
  --location=REGION
```

Fazer upgrade dos pools de nós

Se você optou por fazer upgrade apenas do plano de controle do cluster de usuário, siga estas etapas para fazer upgrade dos pools de nós depois que o plano de controle do cluster do usuário tiver sido atualizado:

Receba uma lista de pools de nós no cluster de usuário:

gcloud container vmware node-pools list
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION

Para cada pool de nós que você quer atualizar, execute o seguinte comando:

gcloud container vmware node-pools update NODE_POOL_NAME \
  --cluster=USER_CLUSTER_NAME  \
  --project=PROJECT_ID \
  --location=REGION \
  --version=VERSION

Terraform

Atualize os componentes da Google Cloud CLI:
```
gcloud components update
```
Registre o cluster de administrador na API GKE On-Prem caso ainda não tenha feito isso. Depois que o cluster for registrado na API GKE On-Prem, não será necessário realizar essa etapa novamente.

Veja uma lista das versões disponíveis para upgrade:

gcloud container vmware clusters query-version-config \
  --cluster=USER_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION

Substitua:

USER_CLUSTER_NAME: o nome do cluster do usuário.
PROJECT_ID: o ID do projeto da frota em que o cluster de usuário é membro. Esse é o projeto especificado quando o cluster foi criado. Se você criou o cluster usando gkectl, esse é o ID do projeto no campo gkeConnect.projectID no arquivo de configuração do cluster.
REGION: a região do Google Cloud em que a API GKE On-Prem executa e armazena os metadados. No arquivo main.tf usado para criar o cluster de usuário, a região está no campo location do recurso do cluster.

A saída deste comando é semelhante a:

versions:
- version: 1.16.3-gke.45
- version: 1.16.2-gke.28
- version: 1.16.1-gke.45
- version: 1.16.0-gke.669
- version: 1.15.6-gke.25
- version: 1.15.5-gke.41

An Anthos version must be made available on the admin cluster ahead of the user
cluster creation or upgrade. Versions annotated with isInstalled=true are
installed on the admin cluster for the purpose of user cluster creation or
upgrade whereas other version are released and will be available for upgrade
once dependencies are resolved.

To install the version in the admin cluster, run:
$ gcloud container vmware admin-clusters update my-admin-cluster --required-platform-version=VERSION

Faça o download da nova versão dos componentes e implante-os no cluster de administrador:
```
gcloud vmware admin-clusters update ADMIN_CLUSTER_NAME \
  --project=PROJECT_ID \
  --location=REGION \
  --required-platform-version=VERSION
```
Esse comando faz o download da versão dos componentes especificados em --required-platform-version no cluster de administrador e, em seguida, implanta os componentes. Esses componentes permitem que o cluster de administrador gerencie clusters de usuário nessa versão.
No arquivo main.tf usado para criar o cluster de usuário, altere on_prem_version no recurso do cluster para a nova versão.
Somente pools de nós Ubuntu e COS: se você quiser fazer upgrade apenas do plano de controle do cluster de usuário e deixar todos os pools de nós na versão atual, adicione o seguinte ao recurso do cluster:
```
upgrade_policy {
  control_plane_only = true
}
```
Inicialize e crie o plano do Terraform:
```
terraform init
```
O Terraform instala todas as bibliotecas necessárias, como o provedor do Google Cloud.
Revise a configuração e faça alterações, se necessário:
```
terraform plan
```
Aplique o plano do Terraform para criar o cluster de usuário:
```
terraform apply
```

Fazer upgrade dos pools de nós

Se você optou por fazer upgrade apenas do plano de controle do cluster de usuário, siga estas etapas para fazer upgrade de outros pools de nós depois que o plano de controle do cluster do usuário tiver sido atualizado:

Em main.tf no recurso de cada pool de nós que você quer atualizar, adicione o seguinte:

on_prem_version = "VERSION"

Exemplo:

resource "google_gkeonprem_vmware_node_pool" "nodepool-basic" {
name = "my-nodepool"
location = "us-west1"
vmware_cluster = google_gkeonprem_vmware_cluster.default-basic.name
config {
  replicas = 3
  image_type = "ubuntu_containerd"
  enable_load_balancer = true
}
on_prem_version = "1.16.0-gke.0"
}

Inicialize e crie o plano do Terraform:
```
terraform init
```
Revise a configuração e faça alterações, se necessário:
```
terraform plan
```
Aplique o plano do Terraform para criar o cluster de usuário:
```
terraform apply
```

Fazer upgrade do cluster de administrador

Depois de fazer upgrade dos clusters de usuário, é possível fazer upgrade do cluster de administrador.

Antes de começar:

Verifique se os certificados estão atualizados e renove-os, se necessário.
Se você estiver fazendo upgrade para a versão 1.13 ou mais recente, primeiro registre o cluster de administrador preenchendo a seção gkeConnect no arquivo de configuração do cluster de administrador. Execute o comando gkectl update cluster com as alterações no arquivo de configuração.
Verifique se o gkectl e os clusters são a versão apropriada para um upgrade e se você fez o download do pacote apropriado. A distorção de versão entre os clusters de administrador e de usuário depende da versão do Google Distributed Cloud. Para garantir que você possa fazer upgrade do cluster de administrador, consulte Desvio de versão do cluster de administrador e de usuário.
Verifique se o campo bundlepath no arquivo de configuração do cluster de administrador corresponde ao caminho do pacote que você quer fazer upgrade.

Se você fizer outras alterações nos campos do arquivo de configuração do cluster de administrador, elas serão ignoradas durante o upgrade. Para que essas alterações entrem em vigor, primeiro você precisa fazer upgrade do cluster e, em seguida, executar um comando update cluster com as alterações do arquivo de configuração para fazer outras alterações no cluster.

Executar `gkectl upgrade admin`

Siga as etapas desta seção na estação de trabalho do administrador. Há duas variações do comando gkectl upgrade admin:

Assíncrona:
Com a variação assíncrona, o comando inicia o upgrade e conclui. Você não precisa verificar a saída do comando durante todo o upgrade. Em vez disso, é possível verificar periodicamente o progresso do upgrade executando gkectl list admin e gkectl describe admin. Para usar a variação assíncrona, inclua a sinalização --async no comando.

Requisitos para o upgrade assíncrono:
- Compatível apenas com clusters de administrador de alta disponibilidade com a versão 1.29 ou mais recente.
- Todos os clusters de usuário precisam ter o Controlplane V2 ativado.
Síncrona:
Com a variação síncrona, o comando gkectl upgrade admin emite mensagens de status para a estação de trabalho do administrador conforme o upgrade avança.

Upgrade assíncrono

Na estação de trabalho do administrador, inicie um upgrade assíncrono:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    --async \
    FLAGS
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de administrador.
- ADMIN_CLUSTER_CONFIG_FILE: o caminho para o arquivo de configuração do cluster de administrador.
- FLAGS: um conjunto opcional de sinalizações. Por exemplo, inclua a sinalização --skip-validation-infra para pular a verificação da infraestrutura do vSphere.
O comando anterior é concluído e você pode continuar usando a estação de trabalho do administrador enquanto o upgrade está em andamento.
Para ver o status do upgrade, faça o seguinte:
```
gkectl list admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
A saída mostra um valor para o cluster STATE. Se o cluster ainda estiver sendo atualizado, o valor de STATE vai ser UPGRADING. Exemplo:
```
NAME              STATE         AGE    VERSION
gke-admin-test    UPGRADING     9h     1.29.100-gke.248
```
Os valores possíveis para STATE são RUNNING, UPGRADING, RECONCILING, ERROR e UNKNOWN.

Para ver mais detalhes sobre o progresso do upgrade e os eventos do cluster, faça o seguinte:

gkectl describe admin --kubeconfig ADMIN_CLUSTER_KUBECONFIG

A saída mostra o recurso personalizado OnPremAdminCluster para o cluster de administrador especificado, que inclui status, condições e eventos do cluster.

Os eventos são registrados para o início e o fim de cada fase de upgrade crítico.

Exemplo de saída:

Events:
Type    Reason                             Age   From                             Message
----       ------                                  ----     ----                                -------
Normal  ControlPlaneUpgradeStarted         40m   onprem-admin-cluster-controller  Creating or updating admin cluster API Controller
Normal  ControlPlaneMachineUpgradeStarted  40m   onprem-admin-cluster-controller  Creating or updating control plane machine
Normal  StatusChanged                      40m   onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: UPGRADING
- New Ready condition: False, CreateOrUpdateControlPlaneMachine, Creating or updating control plane machine
Normal   StatusChanged      2m                onprem-admin-cluster-controller  OnPremAdminCluster status changed:
- New ClusterState condition: RUNNING
- New Ready condition: True, ClusterRunning, Cluster is running

Quando o upgrade for concluído, gkectl list admin vai mostrar um STATUS de RUNNING:
```
NAME              STATE         AGE    VERSION
gke-admin-test    RUNNING       9h     1.29.100-gke.248
```
Além disso, quando o upgrade for concluído, gkectl describe admin vai mostrar um campo Last GKE On Prem Version em Status. Exemplo:
```
Status:
  Cluster State:  RUNNING
  Last GKE On Prem Version:  1.29.0-gke.1
```

Resolver problemas de upgrade assíncrono

Para um upgrade assíncrono, a duração do tempo limite é baseada no número de nós no cluster. Se o upgrade demorar mais do que a duração do tempo limite, o estado do cluster será alterado de UPGRADING para ERROR, com um evento informando que a operação de upgrade expirou. Observe que o estado ERROR significa que o upgrade está demorando mais do que o esperado, mas não foi encerrado. O controlador continua a reconciliação e continua tentando a operação novamente. Quando um upgrade é bloqueado ou falha, é possível executar gkectl diagnose para verificar se há problemas comuns do cluster. Com base no resultado, é possível decidir se você precisa realizar uma correção manual ou entrar em contato com o Suporte do Google Cloud para receber mais assistência.

Upgrade síncrono

Execute este comando:
```
gkectl upgrade admin \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --config ADMIN_CLUSTER_CONFIG_FILE \
    FLAGS
```
Substitua:
- ADMIN_CLUSTER_KUBECONFIG: o caminho para o arquivo kubeconfig do cluster de administrador.
- ADMIN_CLUSTER_CONFIG_FILE: o caminho até o arquivo de configuração do cluster de administrador.
- FLAGS: um conjunto opcional de sinalizações. Por exemplo, inclua a sinalização --skip-validation-infra para pular a verificação da infraestrutura do vSphere.
O comando gkectl upgrade executa verificações de simulação. Se as verificações de simulação falharem, o comando vai ser bloqueado. Corrija as falhas ou use a sinalização --skip-preflight-check-blocking com o comando para desbloqueá-la.
Se você estiver fazendo upgrade para a versão 1.14.0 ou mais recente, um novo arquivo kubeconfig será gerado para o cluster de administrador que substitui qualquer arquivo atual. Para acessar os detalhes do cluster no arquivo, execute o seguinte comando:
```
kubectl config view --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```

Remover o pacote completo

Se você fez o download de um pacote completo e executou os comandos gkectl prepare e gkectl upgrade admin, exclua o pacote completo para economizar espaço em disco na estação de trabalho do administrador. Execute o seguinte comando para excluir o pacote completo:

rm /var/lib/gke/bundles/gke-onprem-vsphere-${TARGET_VERSION}-full.tgz

Como retomar um upgrade de cluster de administrador

Se o upgrade de um cluster de administrador for interrompido ou falhar, o upgrade poderá ser retomado se o ponto de verificação do cluster de administrador contiver o estado necessário para restaurar o estado antes da interrupção.

Aviso: não repare o admin-master com gkectl repair admin-master após uma tentativa de upgrade com falha. Isso fará com que o cluster de administrador fique em um estado inadequado.

Siga estas etapas:

Verifique se o plano de controle do administrador está íntegro antes de iniciar a tentativa de upgrade inicial. Consulte Como diagnosticar problemas de cluster. Conforme discutido neste tópico, execute o comando gkectl diagnose cluster para o cluster de administrador.
Se o plano de controle do administrador não estiver íntegro antes da tentativa inicial de upgrade, repare o plano de controle do administrador com o comando gkectl repair admin-master.
Ao executar o comando de upgrade novamente depois que um upgrade for interrompido ou falhar, use o mesmo pacote e versão de destino do que você fez na tentativa anterior.

Quando você executa o comando de upgrade novamente, o upgrade retomado recria o estado do cluster de administrador do checkpoint e executa todo o upgrade novamente. A partir da versão 1.12.0, se o plano de controle do administrador não estiver íntegro, o processo de upgrade vai ser atualizado diretamente para a versão de destino sem tentar restaurar o cluster de administrador na versão de origem antes de dar continuidade ao upgrade.

O upgrade será retomado a partir do ponto em que falhou ou saiu, se o checkpoint do cluster de administrador estiver disponível. Se o checkpoint não estiver disponível, o upgrade voltará a depender do plano de controle do administrador. Portanto, o plano de controle de administrador precisa estar íntegro para prosseguir com o upgrade. Após um upgrade bem-sucedido, o checkpoint é gerado novamente.

Se o gkectl sair inesperadamente durante um upgrade de cluster de administrador, o cluster de tipo não será limpo. Antes de executar o comando de upgrade novamente para retomar o upgrade, exclua o cluster de tipo:

docker stop gkectl-control-plane && docker rm gkectl-control-plane

Depois de excluir o cluster de tipo, execute o comando de upgrade novamente.

Reverter uma estação de trabalho de administrador após um upgrade

É possível reverter a estação de trabalho do administrador para a versão usada antes do upgrade.

Durante o upgrade, gkeadm registra a versão anterior no arquivo de informações de saída. Durante a reversão, gkeadm usa a versão listada para fazer o download do arquivo mais antigo.

Para reverter a estação de trabalho do administrador para a versão anterior, faça o seguinte:

gkeadm rollback admin-workstation --config=AW_CONFIG_FILE

Será possível omitir --config=AW_CONFIG_FILE se o arquivo de configuração da estação de trabalho do administrador for o admin-ws-config.yaml padrão. Caso contrário, substitua AW_CONFIG_FILE pelo caminho do arquivo de configuração da estação de trabalho de administrador.

O comando de reversão executa as seguintes etapas:

Faz o download da versão de reversão de gkeadm.
Faz o backup do diretório inicial da estação de trabalho de administrador atual.
Cria uma nova estação de trabalho de administrador usando a versão de reversão do gkeadm.
Exclui a estação de trabalho de administrador original.

Instalar o pacote com uma versão diferente para fazer upgrade

Se você fizer upgrade da estação de trabalho, um pacote com uma versão correspondente será instalado nela para fazer o upgrade dos clusters. Se você quiser uma versão diferente, siga estas etapas para instalar um pacote para TARGET_VERSION, que é a versão para que você quer fazer upgrade.

Para verificar as versões atuais de gkectl e de cluster, execute este comando. Use a sinalização --details/-d para informações mais detalhadas.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```
A resposta mostra informações sobre as versões do cluster.
Com base no resultado, procure os seguintes problemas e corrija-os conforme necessário.
- Se a versão atual do cluster de administrador for mais recente que a versão secundária da TARGET_VERSION, faça upgrade de todos os clusters para uma versão secundária inferior à TARGET_VERSION.
- Se a versão do gkectl for anterior à 1.11 e você quiser fazer upgrade para a 1.12.x, precisará fazer vários upgrades. Faça upgrade de uma versão secundária de cada vez até chegar à versão 1.11.x e siga as instruções neste tópico.
- Se a versão gkectl for anterior à TARGET_VERSION, faça upgrade da estação de trabalho do administrador para o TARGET_VERSION.
Depois de determinar que gkectl e as versões de cluster são apropriadas para um upgrade, faça o download do pacote.

Verifique se o tarball do pacote já existe na estação de trabalho do administrador.
```
stat /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz
```
Se o pacote não estiver na estação de trabalho de administrador, faça o download dele.
```
gsutil cp gs://gke-on-prem-release/gke-onprem-bundle/TARGET_VERSION/gke-onprem-vsphere-TARGET_VERSION.tgz /var/lib/gke/bundles/
```
Instale o pacote.
```
gkectl prepare --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-TARGET_VERSION.tgz --kubeconfig ADMIN_CLUSTER_KUBECONFIG
```
Substitua ADMIN_CLUSTER_KUBECONFIG pelo caminho do arquivo kubeconfig. É possível omitir essa sinalização se o arquivo estiver no diretório atual e tiver o nome kubeconfig.

Observação:: por padrão, é feito o download do pacote normal em vez do pacote completo. O pacote completo contém todas as imagens de contêiner e de VM, enquanto o pacote normal faz o download das imagens do contêiner e da VM do Google Cloud Platform para a estação de trabalho do administrador durante a instalação. Para usar o pacote completo, defina o caminho do pacote no comando de instalação como gke-onprem-vsphere-TARGET_VERSION-full.tgz.
Liste as versões de cluster disponíveis e verifique se a versão de destino está incluída nas versões disponíveis do cluster de usuário.
```
gkectl version --kubeconfig ADMIN_CLUSTER_KUBECONFIG --details
```

Agora você pode criar um cluster de usuário na versão de destino ou fazer upgrade de um cluster de usuário para a versão de destino.

Como solucionar problemas do processo de upgrade

Se você tiver um problema ao seguir o processo de upgrade recomendado, siga estas recomendações para resolvê-los. Essas sugestões presumem que você começou com a configuração da versão 1.11.x e está seguindo o processo de upgrade recomendado.

Veja também Solução de problemas na criação e no upgrade de clusters.

Como solucionar problemas de upgrade de cluster de usuário

Suponha que você encontre um problema com a versão de upgrade ao fazer upgrade de um cluster de usuário. Você determina com o Suporte do Google que o problema será corrigido em uma próxima versão de patch. Você pode prosseguir da seguinte forma:

Continue usando a versão atual para produção.
Teste a versão do patch em um cluster que não seja de produção quando ele for lançado.
Quando você tiver certeza, faça upgrade de todos os clusters de usuário de produção para a versão de lançamento do patch.
Faça upgrade do cluster de administrador para a versão de lançamento do patch.

Como solucionar problemas de upgrade de cluster de administrador

Se você encontrar um problema ao fazer upgrade do cluster de administrador, entre em contato com o Suporte do Google para resolvê-lo.

Enquanto isso, com o novo fluxo de upgrade, você ainda pode aproveitar os novos recursos de cluster de usuário sem ser bloqueado pelo upgrade do cluster de administrador, o que permite reduzir a frequência de upgrade do cluster de administrador se quiser. O processo de upgrade pode prosseguir da seguinte maneira:

Fazer upgrade dos clusters de usuários de produção para a versão 1.12.x
Manter o cluster de administrador na versão anterior e continuar recebendo patches de segurança
Testar o upgrade do cluster de administrador de 1.11.x para 1.12.x em um ambiente de teste e informar eventuais problemas
Se o problema for resolvido por uma versão de patch 1.12.x, você poderá fazer upgrade do cluster de administrador de produção para essa versão de patch, se quiser

Problemas conhecidos das versões recentes

Os problemas conhecidos a seguir podem afetar os upgrades se você estiver fazendo upgrade da versão 1.7 ou posterior.

Consulte também Problemas conhecidos.

A atualização da estação de trabalho do administrador pode falhar se o disco de dados estiver quase cheio

Se você atualizar a estação de trabalho de administrador com o comando gkectl upgrade admin-workstation, o upgrade poderá falhar se o disco de dados estiver quase cheio, porque o sistema tentará fazer o backup da estação de trabalho de administrador atual localmente durante o upgrade para uma nova estação de trabalho de administrador. Se não for possível liberar espaço suficiente no disco de dados, use o comando gkectl upgrade admin-workstation com a sinalização adicional --backup-to-local=false para evitar fazer um backup local da estação de trabalho do administrador atual.

Interrupção de cargas de trabalho com PodDisruptionBudgets

Atualmente, o upgrade de clusters pode causar interrupção ou inatividade para cargas de trabalho que usam PodDisruptionBudgets (PDBs).

Falha no processo de upgrade dos nós

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}'

Apêndice

Sobre as regras do VMware DRS ativadas na versão 1.1.0-gke.6

A partir da versão 1.1.0-gke.6, o GKE no VMware cria automaticamente regras antiafinidade do VMware Distributed Resource Scheduler (DRS) para os nós do cluster de usuário, fazendo com que eles sejam distribuídos por pelo menos três hosts físicos no seu data center. A partir da versão 1.1.0-gke.6, esse recurso é ativado automaticamente para clusters novos e atuais.

Antes de fazer upgrade, verifique se o ambiente vSphere atende às condições a seguir:

O VMware DRS está ativado. O VMware DRS requer a edição de licença do vSphere Enterprise Plus. Para saber como ativar o DRS, consulte Como ativar o VMware DRS em um cluster.
O nome de usuário do vSphere fornecido no arquivo de confirmação de credenciais tem a permissão Host.Inventory.EditCluster.
Há pelo menos três hosts físicos disponíveis.

Caso seu ambiente do vSphere não atenda às condições anteriores, você ainda pode fazer upgrade, mas, para atualizar um cluster de usuário de 1.3.x para 1.4.x, você precisará desativar grupos antiafinidade. Para mais informações, consulte esse problema conhecido nas notas da versão do Google Distributed Cloud.

Sobre a inatividade durante upgrades

Resource	Descrição
Cluster de administrador	Quando um cluster de administrador fica inativo, os planos de controle do cluster de usuário e as cargas de trabalho em clusters de usuário continuam em execução, a menos que tenham sido afetados por uma falha que causou a inatividade.
Plano de controle do cluster de usuário	Normalmente, não há inatividade perceptível nos planos de controle do cluster de usuário. No entanto, conexões de longa duração com o servidor da API Kubernetes podem falhar e precisam ser restabelecidas. Nesses casos, o autor da chamada da API precisa tentar novamente até estabelecer uma conexão. No pior dos casos, pode haver até um minuto de inatividade durante um upgrade. Observação: se os nós do cluster de usuário não conseguirem alcançar o plano de controle do usuário durante o upgrade, novas cargas de trabalho não serão programadas para o cluster. As cargas de trabalho já existentes não são afetadas.
Nós do cluster de usuário	Se um upgrade exigir uma alteração nos nós do cluster de usuário, o GKE no VMware recriará os nós de maneira contínua e reagendará os pods em execução nesses nós. É possível evitar o impacto nas suas cargas de trabalho configurando PodDisruptionBudgets e regras antiafinidade apropriados.

Recriar um arquivo de informações se estiver ausente

Se o arquivo de informações de saída da estação de trabalho do administrador estiver ausente, recrie esse arquivo para continuar o upgrade. Esse arquivo foi criado durante a criação da estação de trabalho. Se você fez o upgrade, ele foi atualizado com novas informações.

O arquivo de informações de saída tem este formato:

Admin workstation version: GKEADM_VERSION
Created using gkeadm version: GKEADM_VERSION
VM name: ADMIN_WS_NAME
IP: ADMIN_WS_IP
SSH key used: FULL_PATH_TO_ADMIN_WS_SSH_KEY
To access your admin workstation:
ssh -i FULL-PATH-TO-ADMIN-WS-SSH-KEY ubuntu@ADMIN-WS-IP

Veja um exemplo de arquivo de informações de saída:

Admin workstation version: v1.10.3-gke.49
Created using gkeadm version: v1.10.3-gke.49
VM name: admin-ws-janedoe
IP: 172.16.91.21
SSH key used: /usr/local/google/home/janedoe/.ssh/gke-admin-workstation
Upgraded from (rollback version): v1.10.0-gke.194
To access your admin workstation:
ssh -i /usr/local/google/home/janedoe/.ssh/gke-admin-workstation ubuntu@172.16.91.21

Crie o arquivo em um editor, substituindo os parâmetros adequados. Salve o arquivo com um nome de arquivo igual ao da VM no diretório em que o gkeadm é executado. Por exemplo, se o nome da VM for admin-ws-janedoe, salve o arquivo como admin-ws-janedoe.

A seguir

documentação de referência da CLI gcloud
documentação de referência do Terraform
- google_gkeonprem_vmware_cluster
- google_gkeonprem_vmware_node_pool

Fazer upgrade de um cluster ou pool de nós

Revise suas regras de firewall

Requisitos do IAM e da API do Google

Requisitos do IAM para fazer upgrade de clusters de usuário

Mudar a configuração antes ou depois de um upgrade

Faça upgrade da estação de trabalho do administrador

gkeadm

Localizar os arquivos necessários

Fazer upgrade

Gerenciado pelo usuário

Verificar as versões disponíveis para upgrades de cluster

Fazer upgrade de um cluster de usuários

gkectl

Preparar-se para fazer upgrade de um cluster de usuário

Executar verificações de simulação

Executar gkectl upgrade cluster

Upgrade assíncrono

Resolver problemas de upgrade assíncrono

Upgrade síncrono

Fazer upgrade de outros pools de nós

Retomar um upgrade

Console

CLI da gcloud

Fazer upgrade dos pools de nós

Terraform

Fazer upgrade dos pools de nós

Fazer upgrade do cluster de administrador

Antes de começar:

Executar gkectl upgrade admin

Upgrade assíncrono

Resolver problemas de upgrade assíncrono

Upgrade síncrono

Remover o pacote completo

Como retomar um upgrade de cluster de administrador

Reverter uma estação de trabalho de administrador após um upgrade

Instalar o pacote com uma versão diferente para fazer upgrade

Como solucionar problemas do processo de upgrade

Como solucionar problemas de upgrade de cluster de usuário

Como solucionar problemas de upgrade de cluster de administrador

Problemas conhecidos das versões recentes

A atualização da estação de trabalho do administrador pode falhar se o disco de dados estiver quase cheio

Interrupção de cargas de trabalho com PodDisruptionBudgets

Falha no processo de upgrade dos nós

Apêndice

Sobre as regras do VMware DRS ativadas na versão 1.1.0-gke.6

Sobre a inatividade durante upgrades

Recriar um arquivo de informações se estiver ausente

A seguir

Executar `gkectl upgrade cluster`

Executar `gkectl upgrade admin`