Versão 1.1. Esta versão não é mais compatível, conforme descrito na Política de suporte da versão do Anthos. Para ver os patches e as atualizações mais recentes sobre vulnerabilidades de segurança, exposições e problemas que afetam os clusters do Anthos no VMware (GKE On-Prem), faça o upgrade para uma versão compatível. Você pode encontrar a versão mais recente neste link.

Versões disponíveis

Como fazer upgrade do GKE On-Prem

Neste tópico, explicamos como fazer upgrade do GKE On-Prem.

Para fazer upgrade do GKE On-Prem, faça upgrade da estação de trabalho do administrador. Em seguida, faça upgrade dos clusters.

Antes de começar

Siga estas instruções na estação de trabalho ou no laptop local. Não siga estas instruções da estação de trabalho do administrador atual.
Verifique a versão atual dos clusters.
Leia as Notas de lançamento.
Veja as versões.

Além disso, leia as seguintes considerações:

Sobre a inatividade durante upgrades

Recurso	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 On-Prem 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.

Upgrade sequencial

O GKE On-Prem é compatível com upgrades sequenciais. Para fazer upgrade de um cluster para uma nova versão, ele precisa estar na versão imediatamente anterior.

Não é possível fazer upgrade dos clusters diretamente para a versão mais recente de versões muito atrasadas. Se o cluster tiver mais de uma versão atrasada, será necessário fazer upgrade do cluster sequencialmente.

Exemplo

Suponha que as seguintes versões estejam disponíveis e que a estação de trabalho e os clusters de administrador estejam executando a versão mais antiga:

1.0.1 (versão mais antiga)
1.0.2
1.1 (versão mais recente)

Nesse caso, a versão 1.1 é a mais recente. Para fazer upgrade da 1.0.1 para a 1.1, siga estas etapas:

Faça upgrade da estação de trabalho do administrador da 1.0.1 para a 1.0.2.
Faça upgrade dos clusters de 1.0.1 para 1.0.2.
Faça upgrade da estação de trabalho do administrador da 1.0.2 para a 1.1.
Faça upgrade dos clusters da 1.0.2 para a 1.1.

Fazer backup do arquivo de configuração do GKE On-Prem e dos arquivos kubeconfig

Quando você faz upgrade da estação de trabalho do administrador, o Terraform exclui a VM dessa estação de trabalho e a substitui por uma estação de trabalho do administrador atualizada. Antes de fazer upgrade da estação de trabalho do administrador, faça backup do arquivo de configuração do GKE On-Prem e dos arquivos kubeconfig dos clusters. Na sequência, copie os arquivos para a estação de trabalho do administrador atualizada.

Como fazer upgrade da estação de trabalho do administrador

Quando você faz upgrade da estação de trabalho do administrador, ele inclui as seguintes entidades na mesma versão do arquivo Open Virtualization Appliance (OVA) da estação de trabalho do administrador:

gkectl
full bundle

Depois de fazer upgrade da estação de trabalho do administrador, faça upgrade dos clusters.

Como fazer o download do OVA

Em Downloads, faça o download do arquivo OVA da estação de trabalho do administrador da versão para qual você estiver fazendo upgrade.

Para fazer o download do OVA mais recente, execute o seguinte comando:

gsutil cp gs://gke-on-prem-release/admin-appliance/1.1.2-gke.0/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.{ova,ova.sig} ~/

Como importar o OVA para o vSphere e marcá-lo como um modelo de VM

Nas seções a seguir, faça as seguintes ações:

Crie algumas variáveis que declaram elementos do servidor vCenter e do ambiente do vSphere.
Importe o OVA da estação de trabalho de administrador para o vSphere e marque-o como um modelo de VM.

Como criar variáveis para `govc`

Antes de importar o OVA da estação de trabalho de administrador para o vSphere, é preciso fornecer ao govc algumas variáveis que declaram elementos do seu servidor vCenter e do ambiente do vSphere:

export GOVC_URL=https://[VCENTER_SERVER_ADDRESS]/sdk
export GOVC_USERNAME=[VCENTER_SERVER_USERNAME]
export GOVC_PASSWORD=[VCENTER_SERVER_PASSWORD]
export GOVC_DATASTORE=[VSPHERE_DATASTORE]
export GOVC_DATACENTER=[VSPHERE_DATACENTER]
export GOVC_INSECURE=true

Use o pool de recursos padrão do vSphere ou crie seu próprio pool de recursos:

# If you want to use a resource pool you've configured yourself, export this variable:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources/[VSPHERE_RESOURCE_POOL]

# If you want to use vSphere's default resource pool, export this variable instead:
export GOVC_RESOURCE_POOL=[VSPHERE_CLUSTER]/Resources

em que:

[VCENTER_SERVER_ADDRESS] é o endereço IP ou nome do host do servidor vCenter.
[VCENTER_SERVER_USERNAME] é o nome de usuário de uma conta que tem o papel de Administrador ou privilégios equivalentes no servidor vCenter.
[VCENTER_SERVER_PASSWORD] é a senha da conta do servidor vCenter.
[VSPHERE_DATASTORE] é o nome do armazenamento de dados que você configurou no ambiente do vSphere.
[VSPHERE_DATACENTER] é o nome do data center configurado no ambiente do vSphere.
[VSPHERE_CLUSTER] é o nome do cluster que você configurou no ambiente do vSphere.
[VSPHERE_RESOURCE_POOL] é o nome do pool de recursos que você configurou para seu ambiente vSphere.

Como importar o OVA para o vSphere: chave padrão

Se você estiver usando uma chave padrão do vSphere, importe o OVA para o vSphere usando este comando:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true
}
EOF

Como importar o OVA para o vSphere: chave distribuída

Se você estiver usando uma chave distribuída do vSphere, importe o OVA para o vSphere usando este comando, em que [YOUR_DISTRIBUTED_PORT_GROUP_NAME] é o nome do grupo de portas distribuído:

govc import.ova -options - ~/gke-on-prem-admin-appliance-vsphere-1.1.2-gke.0.ova <<EOF
{
  "DiskProvisioning": "thin",
  "MarkAsTemplate": true,
  "NetworkMapping": [
      {
          "Name": "VM Network",
          "Network": "[YOUR_DISTRIBUTED_PORT_GROUP_NAME]"
      }
  ]
}
EOF

Como configurar a variável de modelo do Terraform para a nova VM da estação de trabalho do administrador

No arquivo TFVARS da estação de trabalho do administrador, defina vm_template como a versão do upgrade. O valor de vm_template tem esta aparência, em que [VERSION] é a versão do OVA:

gke-on-prem-admin-appliance-vsphere-[VERSION]

Como usar o Terraform para fazer o upgrade da estação de trabalho do administrador

Para fazer upgrade da estação de trabalho do administrador, execute o comando a seguir. Esse comando exclui a VM atual da estação de trabalho do administrador e a substitui por uma VM atualizada:

terraform init && terraform apply -auto-approve -input=false

Como se conectar à estação de trabalho do administrador

Conectar-se por SSH à sua estação de trabalho do administrador:
```
ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
```
Se você estiver usando um proxy, precisará configurar a Google Cloud CLI para o proxy se quiser executar os comandos gcloud e gsutil. Para mais instruções, consulte Como configurar a CLI gcloud para que seja usada com um proxy/firewall.
Faça login no Google Cloud usando as credenciais da sua conta:
```
gcloud auth login
```
Registre gcloud como um auxiliar de credenciais do Docker (mais informações sobre este comando):
```
gcloud auth configure-docker
```
Crie uma chave privada para sua conta de serviço permitida na lista.

Copie o endereço de e-mail da conta de serviço.
```
gcloud iam service-accounts list
```
Crie a chave privada da conta de serviço, em que [KEY_FILE] é o nome escolhido para o arquivo. Este comando salva o arquivo no diretório de trabalho atual:
```
gcloud iam service-accounts keys create key.json \
--project [PROJECT_ID] --iam-account [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL]
```
em que:
- [PROJECT_ID] é o ID do projeto.
- [KEY_FILE] é um nome e um caminho para salvar a chave privada da conta de serviço, como /home/ubuntu/key.json.
- [ALLOWLISTED_SERVICE_ACCOUNT_EMAIL] é o endereço de e-mail da conta de serviço permitida.

Ative sua conta de serviço permitida na lista:

gcloud auth activate-service-account --project [PROJECT_ID] \
--key-file [KEY_FILE]

Copiar os arquivos de configuração e kubeconfig armazenados em backup

Antes, você fez backup do arquivo de configuração do GKE On-Prem e dos arquivos kubeconfig dos clusters. Agora, copie esses arquivos de volta para a estação de trabalho do administrador atualizada.

Como fazer upgrade de clusters

Depois de fazer upgrade da estação de trabalho do administrador e se conectar a ela, execute as seguintes etapas:

Verificar se há endereços IP suficientes disponíveis

Antes de fazer upgrade, verifique se você tem endereços IP suficientes disponíveis para os clusters.

DHCP

Se os endereços IP do cluster forem atribuídos por um servidor DHCP, verifique se o servidor DHCP na rede em que os nós foram criados tem endereços IP suficientes. Haverá mais endereços IP do que nós em execução no cluster de usuário.

IPs estáticos

Se o cluster tiver endereços IP estáticos, verifique se você alocou endereços IP suficientes no cluster:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME] -o yaml

em que:

[ADMIN_CLUSTER_KUBECONFIG] informa ao kubectl para usar o kubeconfig do cluster de administrador, que é usado para visualizar e/ou alterar as configurações do cluster de usuário.
-n [USER_CLUSTER_NAME] informa ao kubectl para procurar um namespace com o mesmo nome do cluster de usuário.
[USER_CLUSTER_NAME] -o yaml informa ao kubectl em qual cluster de usuário você está executando o comando. -o yaml exibe a configuração do cluster de usuário.

Na saída do comando, procure o campo reservedAddresses. É preciso haver mais endereços IP no campo do que nós em execução no cluster de usuário.

Se você precisar adicionar mais endereços ao campo reservedAddresses, siga estas etapas:

Abra o arquivo de configuração do cluster de usuário para edição:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] edit cluster [USER_CLUSTER_NAME] \
-n [USER_CLUSTER_NAME] --validate=false
```
A configuração do cluster é aberta no editor padrão do shell.
Adicione quantos blocos de IPs estáticos forem necessários. Um bloco de IPs é composto dos campos gateway, hostname, ip e netmask.

Observação: é sempre seguro adicionar mais blocos de IPs ao campo reservedAddresses, mas não é seguro remover endereços IP que estão em uso.

Veja a seguir um campo reservedAddresses de exemplo com os quatro blocos de IPs estáticos destacados:

...
networkSpec:
  dns:
  - 172.x.x.x
  ntp: 129.x.x.x
  reservedAddresses:
  - gateway: 100.x.x.x
    hostname: host-1
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-2
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-3
    ip: 100.x.x.x
    netmask: x
  - gateway: 100.x.x.x
    hostname: host-4
    ip: 100.x.x.x
    netmask: x
...

Como modificar o arquivo de configuração

Na VM da estação de trabalho do administrador, edite o arquivo de configuração. Defina o valor de bundlepath, em que [VERSION] é a versão do GKE On-Prem para o upgrade dos clusters:

bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz

Sobre os recursos ativados automaticamente

Uma nova versão do GKE On-prem pode incluir novos recursos ou suporte a recursos específicos do VMware vSphere. Às vezes, o upgrade para uma versão do GKE On-Prem ativa esses recursos automaticamente. Saiba mais sobre os novos recursos nas Notas de lançamento do GKE On-Prem. Às vezes, novos recursos aparecem no arquivo de configuração do GKE On-prem.

Como desativar novos recursos por meio do arquivo de configuração

Se você precisar desativar um novo recurso ativado automaticamente em uma nova versão do GKE On-Prem e acionado pelo arquivo de configuração, execute as etapas a seguir antes de fazer upgrade do cluster:

Na estação de trabalho do administrador atualizada, crie um novo arquivo de configuração com um nome diferente do arquivo de configuração atual:
```
gkectl create-config --config [CONFIG_NAME]
```
Abra o novo arquivo de configuração e o campo do recurso. Feche o arquivo.
Abra o arquivo de configuração atual e adicione o campo do novo recurso na especificação apropriada.
Preencha o campo com um valor false ou equivalente.
Salve o arquivo de configuração. Prossiga com o upgrade dos clusters.

Revise sempre as Notas de lançamento antes de fazer upgrade dos clusters. Não é possível alterar declarativamente a configuração de um cluster existente depois de atualizá-la.

Como executar `gkectl prepare`

Execute este comando:

gkectl prepare --config [CONFIG_FILE]

O comando gkectl prepare executa as seguintes tarefas:

Se necessário, copie uma nova imagem do SO do nó para o ambiente vSphere e marque a imagem do SO como um modelo.
Envie imagens atualizadas do Docker, especificadas no novo pacote, para seu registro particular do Docker, se você tiver configurado um.

Como fazer upgrade do cluster de administrador

Execute este comando:

gkectl upgrade admin \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE]

em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador e [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para fazer upgrade.

Como fazer upgrade do cluster de usuário

Para fazer upgrade de um cluster de usuário, seu cluster de administrador precisa ter uma versão no mínimo equivalente à versão de destino do upgrade do cluster de usuário. Se a versão do seu cluster de administrador não for equivalente, faça upgrade dela antes.

gkectl

Na estação de trabalho de administrador, execute o seguinte comando:

gkectl upgrade cluster \
--kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
--config [CONFIG_FILE] \
--cluster-name [CLUSTER_NAME]

em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador, [CLUSTER_NAME] é o nome do cluster de usuário que você está atualizando e [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para fazer upgrade.

Console

É possível registrar seus clusters de usuário com o Console do Cloud durante a instalação ou depois de criá-los. É possível visualizar e fazer login nos clusters registrados do GKE On-Prem e nos clusters do Google Kubernetes Engine no menu do GKE do Console do Cloud.

Quando um upgrade fica disponível para clusters de usuário do GKE On-Prem, uma notificação é exibida no Console do Cloud. Clique na notificação para exibir uma lista de versões disponíveis e um comando gkectl que pode ser executado para fazer upgrade do cluster:

Acesse o menu do GKE no Console do Google Cloud.

Acessar o menu do GKE On-Prem
Na coluna Notificações do cluster de usuário, clique em Upgrade disponível, se houver.
Copie o comando gkectl upgrade cluster.
Na estação de trabalho do administrador, execute o comando gkectl upgrade cluster, em que [ADMIN_CLUSTER_KUBECONFIG] é o arquivo kubeconfig do cluster de administrador, [CLUSTER_NAME] é o nome do cluster de usuário que você está atualizando e [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para fazer upgrade.

Como retomar um upgrade

Se um upgrade de cluster de usuário foi interrompido, mas o upgrade do cluster de administrador foi totalmente feito, é possível retomar o upgrade executando gkectl upgrade cluster novamente com o mesmo arquivo de configuração do GKE On-Prem e kubeconfig do cluster de administrador.

Sobre como retomar um upgrade de cluster de administrador

Não interrompa um upgrade do cluster de administrador. Atualmente, os upgrades do cluster de administrador nem sempre podem ser retomados. Se um upgrade do cluster de administrador for interrompido por qualquer motivo, entre em contato com o suporte para receber ajuda.

Problemas conhecidos

Os seguintes problemas conhecidos afetam o upgrade de clusters.

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).

Versão 1.1.1-gke.2: o disco de dados da pasta de armazenamento de dados vSAN pode ser excluído

Se você usa um armazenamento de dados vSAN, é preciso criar uma pasta para salvar o VMDK. Atualmente, um problema conhecido exige que você forneça o caminho do identificador universal exclusivo (UUID, na sigla em inglês) da pasta, em vez do caminho do arquivo, para vcenter.datadisk. Essa incompatibilidade pode causar falhas nos upgrades.

Uma correção foi gerada para a versão 1.1.2. Antes de fazer upgrade, execute estas etapas para o nó do plano de controle de administrador como uma solução alternativa:

Na interface do vCenter, encontre o UUID da pasta no seu armazenamento de dados vSAN.
Liste os recursos de máquina nos clusters. Essas máquinas correspondem aos nós nos clusters:
```
kubectl get machines -n all
```
Para a máquina do plano de controle de administrador (gke-admin-master), abra a configuração para edição:
```
kubectl edit machine [MACHINE_NAME]
```

Altere o campo spec.providerSpec.value.machineVariables.data_disk_path. Substitua o caminho para o arquivo VMDK pelo UUID. Por exemplo:

spec:
providerSpec:
 value:
   apiVersion: vsphereproviderconfig.k8s.io/v1alpha1
   kind: VsphereMachineProviderConfig
   machineVariables:
     data_disk_path: 14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk
     datacenter: datacenter
     datastore: datastore

Salve o arquivo.
Abra o arquivo de configuração do GKE On-Prem.
Em vcenter.datadisk, substitua a pasta no caminho do arquivo pelo UUID da pasta. Por exemplo:
```
vcenter:
 ...
 datadisk: "14159b5d-4265-a2ba-386b-246e9690c588/my-disk.vmdk"
```
Prossiga com o upgrade dos clusters.

Como fazer upgrade da versão 1.0.2-gke.3 para a versão 1.1.0-gke.6: problema do OIDC

Os clusters da versão 1.0.11, 1.0.1-gke.5 e 1.0.2-gke.3 com o OpenID Connect (OIDC) configurado não podem ser atualizados para a versão 1.1.0-gke.6. Esse problema foi corrigido na versão 1.1.1-gke.2.

Se você tiver configurado um cluster da versão 1.0.11, 1.0.1-gke.5 ou 1.0.2-gke.3 com OIDC durante a instalação, não será possível fazer upgrade dele. Em vez disso, crie novos clusters.

Como fazer upgrade da versão 1.0.2-gke.3 para a versão 1.0.11

A versão 1.0.2-gke.3 introduz os campos OIDC (usercluster.oidc) a seguir. Esses campos permitem fazer login em um cluster do Console do Cloud:

usercluster.oidc.kubectlredirecturl
usercluster.oidc.clientsecret
usercluster.oidc.usehttpproxy

Se você quiser usar o OIDC, o campo clientsecret será obrigatório mesmo se você não quiser fazer login em um cluster do console do Cloud. Para usar o OIDC, talvez seja necessário fornecer um valor do marcador para clientsecret:

oidc:
  clientsecret: "secret"

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 On-Prem cria automaticamente regras de 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.
A conta de usuário do vSphere fornecida no campo vcenter tem a permissão Host.Inventory.EditCluster.
Há pelo menos três hosts físicos disponíveis.

Como desativar o VMware DRS antes de fazer upgrade para 1.1.0-gke.6

Se você não quiser ativar esse recurso nos clusters de usuário atuais, por exemplo, se não tiver hosts suficientes para acomodar o recurso, execute as etapas a seguir antes de fazer upgrade dos clusters de usuário:

Abra o arquivo de configuração atual do GKE On-Prem.
Na especificação usercluster, adicione o campo antiaffinitygroups conforme descrito na documentação de antiaffinitygroups:
```
usercluster:
      ...
      antiaffinitygroups:
        enabled: false
```
Salve o arquivo.
Use o arquivo de configuração para fazer upgrade. Seus clusters estão atualizados, mas o recurso não está ativado.

Cenário de upgrade alternativo

Neste tópico, descrevemos a maneira mais simples de fazer upgrade do GKE On-Prem. Na tabela abaixo, descrevemos um cenário de upgrade alternativo. Nesse cenário, você só faz upgrade do gkectl e dos seus clusters, e não da estação de trabalho do administrador:

Cenário	Etapas
A versão não tem atualizações de segurança para a estação de trabalho do administrador.	Download `gkectl`. Faça o download do pacote. Siga as instruções nesta página.

Solução de problemas

Para mais informações, consulte Solução de problemas.

Novos nós criados, mas não íntegros

Sintomas

Novos nós não se registram no plano de controle do cluster de usuário ao usar o modo de balanceamento de carga manual.

Causas possíveis

A validação da entrada no nó pode estar ativada para bloquear o processo de inicialização dos nós.

Resolução

Para desativar a validação, execute:

kubectl patch machinedeployment [MACHINE_DEPLOYMENT_NAME] -p '{"spec":{"template":{"spec":{"providerSpec":{"value":{"machineVariables":{"net_validation_ports": null}}}}}}}' --type=merge

Como diagnosticar problemas de cluster usando `gkectl`

Use os comandos gkectl diagnose para identificar problemas de cluster e compartilhar informações do cluster com o Google. Consulte Como diagnosticar problemas de cluster.

Comportamento de geração de registros padrão

Para gkectl e gkeadm, basta usar as configurações de geração de registros padrão:

Por padrão, as entradas de registro são salvas da seguinte maneira:
- Para gkectl, o arquivo de registros padrão é /home/ubuntu/.config/gke-on-prem/logs/gkectl-$(date).log e está vinculado ao arquivo logs/gkectl-$(date).log no diretório local em que você executa gkectl.
- Para gkeadm, o arquivo de registros padrão é logs/gkeadm-$(date).log no diretório local em que você executa gkeadm.
Todas as entradas de registro são salvas no arquivo de registros, mesmo que não sejam impressas no terminal (quando --alsologtostderr é false).
O nível de detalhamento -v5 (padrão) abrange todas as entradas de registro exigidas pela equipe de suporte.
O arquivo de registros também contém o comando executado e a mensagem de erro.

Recomendamos que você envie o arquivo de registros para a equipe de suporte quando precisar de ajuda.

Como especificar um local não padrão para o arquivo de registros

Se quiser especificar um local não padrão para o arquivo de registros gkectl, use a sinalização --log_file. O arquivo de registro que você especificar não será vinculado ao diretório local.

Se quiser especificar um local não padrão para o arquivo de registros gkeadm, use a sinalização --log_file.

Como localizar registros da API Cluster no cluster de administrador

Se uma VM não for iniciada após o início do plano de controle do administrador, tente depurar isso inspecionando os registros dos controladores da API Cluster no cluster de administrador:

Encontre o nome do pod de controladores da API Cluster no namespace kube-system, em que [ADMIN_CLUSTER_KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster de administrador:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system get pods | grep clusterapi-controllers
```
Abra os registros do pod, em que [POD_NAME] é o nome do pod. Opcionalmente, use grep ou uma ferramenta semelhante para pesquisar erros:
```
kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -n kube-system logs [POD_NAME] vsphere-controller-manager
```