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 e os problemas conhecidos que afetam o upgrade.
• 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:

1. Faça upgrade da estação de trabalho do administrador da 1.0.1 para a 1.0.2.
2. Faça upgrade dos clusters de 1.0.1 para 1.0.2.
3. Faça upgrade da estação de trabalho do administrador da 1.0.2 para a 1.1.
4. 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

Importante: use o Terraform para fazer upgrade da estação de trabalho do administrador. Certifique-se de fazer uma cópia dos arquivos da estação de trabalho do administrador. O Terraform exclui a VM atual da estação de trabalho do administrador e a substitui por uma nova VM.

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.2.2-gke.2/gke-on-prem-admin-appliance-vsphere-1.2.2-gke.2.{ova,ova.1.sig} ~/

Observação: para verificar esse arquivo, consulte Como verificar o OVA usando openssl.

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:

1. Crie algumas variáveis que declaram elementos do servidor vCenter e do ambiente do vSphere.
2. 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:

Observação: é possível encontrar muitos desses valores fazendo login no Servidor vCenter.

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.
Para usar um pool de recursos não padrão,
• [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.2.2-gke.2.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.2.2-gke.2.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:

Observação: importe o OVA para o vSphere antes de executar este comando.

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

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

1. Conectar-se por SSH à sua estação de trabalho do administrador:

   ssh -i ~/.ssh/vsphere_workstation ubuntu@[IP_ADDRESS]
   

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

3. Faça login no Google Cloud usando as credenciais da sua conta:

   gcloud auth login

4. Registre gcloud como um auxiliar de credenciais do Docker (mais informações sobre este comando):

   gcloud auth configure-docker

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

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

Anteriormente, você fez backup do arquivo de configuração no 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

Durante um upgrade, o GKE On-prem cria um nó temporário no cluster de administrador e um nó temporário em cada cluster de usuário associado. Verifique se o servidor DHCP pode fornecer endereços IP suficientes para esses nós temporários. Para mais informações, consulte Endereços IP necessários para clusters de administrador e usuário.

IPs estáticos

Durante um upgrade, o GKE On-Prem cria um nó temporário no cluster de administrador e um nó temporário em cada cluster de usuário associado. Para o cluster de administrador e cada um dos clusters de usuário, verifique se você reservou endereços IP suficientes. Para cada cluster, você precisa ter reservado pelo menos um endereço IP a mais do que o número de nós do cluster. Para mais informações, consulte Como configurar endereços IP estáticos.

Determine o número de nós no cluster de administrador:

kubectl --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] get nodes

[ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador.

Em seguida, veja os endereços reservados para o cluster de administrador:

kubectl get cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] -o yaml

Na saída, no campo reservedAddresses, é possível ver o número de endereços IP reservados para os nós do cluster de administrador. Por exemplo, a saída a seguir mostra que há cinco endereços IP reservados para os nós do cluster de administrador:

...
reservedAddresses:
- gateway: 21.0.135.254
  hostname: admin-node-1
  ip: 21.0.133.41
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-2
  ip: 21.0.133.50
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-3
  ip: 21.0.133.56
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-4
  ip: 21.0.133.47
  netmask: 21
- gateway: 21.0.135.254
  hostname: admin-node-5
  ip: 21.0.133.44
  netmask: 21

O número de endereços IP reservados precisa ser pelo menos um a mais do que o número de nós no cluster de administrador. Se esse não for o caso, será possível reservar um endereço extra editando o objeto Cluster.

Abra o objeto Cluster para edição:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG]

Em reservedAddresses, adicione mais um bloco que tenha gateway, hostname, ip e netmask.

Siga o mesmo procedimento para cada um dos clusters de usuário.

Para determinar o número de nós em um cluster de usuário:

kubectl --kubeconfig [USER_CLUSTER_KUBECONFIG] get nodes

Em que [USER_CLUSTER_KUBECONFIG] is the path of your user cluster's kubeconfig file.

Para ver os endereços reservados para um cluster de usuário:

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

onde:

• [ADMIN_CLUSTER_KUBECONFIG] é o caminho do arquivo kubeconfig do cluster de administrador;

• [USER_CLUSTER_NAME] é o nome do cluster de usuário.

Para editar o objeto Cluster de um cluster de usuário:

kubectl edit cluster --kubeconfig [ADMIN_CLUSTER_KUBECONFIG] \
-n [USER_CLUSTER_NAME] [USER_CLUSTER_NAME]

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 para recursos específicos do VMware vSphere. Às vezes, a atualização 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:

1. Na estação de trabalho de 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]
   

2. Abra o novo arquivo de configuração e o campo do recurso. Feche o arquivo.

3. Abra o arquivo de configuração atual e adicione o campo do novo recurso na especificação apropriada.

4. Preencha o campo com um valor false ou equivalente.

5. 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, o cluster de administrador precisa ser atualizado para a versão desejada ou superior antes de fazer upgrade do cluster de usuário.

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 Google 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 Google Cloud.

Quando um upgrade fica disponível para clusters de usuário do GKE On-Prem, uma notificação é exibida no console do Google 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:

1. Acesse o menu do GKE no Console do Google Cloud.

   Acessar o menu do GKE On-Prem

2. Na coluna Notificações do cluster de usuário, clique em Upgrade disponível, se disponível.

3. Copie o comando gkectl upgrade cluster.

4. 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 o upgrade.

Como retomar um upgrade

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

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

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.

Versão 1.1.0-gke.6, 1.2.0-gke.6: campo stackdriver.proxyconfigsecretname removido

O campo stackdriver.proxyconfigsecretname foi removido na versão 1.1.0-gke.6. As verificações de simulação do GKE On-prem retornarão um erro se o campo estiver presente no arquivo de configuração.

Para contornar esse problema, antes de fazer upgrade para o 1.2.0-gke.6, exclua o campo proxyconfigsecretname do arquivo de configuração.

O Stackdriver referencia a versão antiga

Antes da versão 1.2.0-gke.6, um problema conhecido impede que o Stackdriver atualize a configuração após os upgrades do cluster. O Stackdriver ainda referencia uma versão antiga, impedindo que o Stackdriver receba os recursos mais recentes do pipeline de telemetria. Esse problema pode dificultar o Suporte do Google para solucionar problemas de clusters.

Depois de fazer upgrade dos clusters para a 1.2.0-gke.6, execute o seguinte comando nos clusters de administrador e de usuário:

kubectl --kubeconfig=[KUBECONFIG] \
-n kube-system --type=json patch stackdrivers stackdriver \
-p '[{"op":"remove","path":"/spec/version"}]'

[KUBECONFIG] é o caminho para o arquivo kubeconfig do cluster.

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.2.0-gke.6: Prometheus e Grafana desativados após o upgrade

Nos clusters do usuário, o Prometheus e o Grafana são desativados automaticamente durante o upgrade. No entanto, os dados de configuração e métricas não são perdidos. Nos clusters de administrador, o Prometheus e o Grafana permanecem ativados.

Para mais instruções, consulte as notas de lançamento do GKE On-Prem.

Versão 1.1.2-gke.0: os nós de cluster de usuário excluídos não são removidos do armazenamento de dados vSAN

Para mais instruções, consulte as notas de lançamento do GKE On-Prem.

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

Para mais instruções, consulte as notas de lançamento do GKE On-Prem.

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. Em vez disso, crie novos clusters.

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

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 Google 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 (link em inglês). A partir da versão 1.1.0-gke.6, esse recurso é ativado automaticamente para novos clusters e clusters 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 para os clusters de usuário existentes, 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:

1. Abra o arquivo de configuração existente do GKE On-Prem.
2. Na especificação usercluster, adicione o campo antiaffinitygroups:

   usercluster:
         ...
         antiaffinitygroups:
           enabled: false
   

3. Salve o arquivo.
4. Use o arquivo de configuração para fazer upgrade. Seus clusters são atualizados, mas o recurso não está ativado.

Cenário de upgrade alternativo

Neste tópico, você verá a maneira mais simples de fazer upgrade do GKE On-prem, que é fazer o upgrade da estação de trabalho de administrador e, em seguida, dos clusters atuais. 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 de upgrade. 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:

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

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