Como fazer upgrade do GKE On-Prem

Nesta página, 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 upgrade sequencial, o que significa que o cluster que você quer atualizar precisa estar na versão anterior do patch anterior.

Não é possível fazer upgrade dos clusters diretamente para a versão mais recente de uma versão com mais de uma versão de patch. Se o cluster tiver mais de uma versão de patch, será preciso fazer upgrade sequencialmente desse cluster por cada versão de patch.

Exemplo

Se você quiser fazer upgrade para a versão 1.1.0, e a estação de trabalho do administrador e os clusters de usuário estiverem executando a versão mais antiga do 1.0.1:

• 1.0.1 (versão mais antiga)
• 1.0.2
• 1.1.0 (versão mais recente)

Em seguida, faça upgrade da versão sequencial para a versão 1.0.2 e depois a versão 1.1.0, executando as seguintes etapas:

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

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 da estação de trabalho do administrador e a substitui por uma estação de trabalho do administrador atualizada.

Antes de realizar o upgrade da estação de trabalho de administrador, primeiro faça o backup do arquivo de configuração do GKE On-Prem e dos seus arquivos kubeconfig do cluster. O comando gkectl create cluster cria os arquivos kubeconfig para seu cluster de administrador ([ADMIN_CLUSTER_KUBECONFIG]) e para o cluster de usuário ([USER_CLUSTER_KUBECONFIG]). Veja um exemplo na instalação básica. Depois do upgrade da estação de trabalho de administrador, copie os mesmos arquivos para a estação de trabalho de administrador atualizada.

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

Você usa o Terraform para fazer upgrade da estação de trabalho de administrador.

Importante: primeiro é necessário fazer backup dos arquivos da estação de trabalho do administrador porque o Terraform exclui a VM da estação de trabalho do administrador atual e a substitui por uma nova.

A estação de trabalho do administrador atualizada inclui as seguintes entidades na mesma versão do arquivo Open Virtualization Appliance (OVA) da estação de trabalho do administrador:

• gkectl
• Pacote completo

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.3.2-gke.1/gke-on-prem-admin-appliance-vsphere-1.3.2-gke.1.{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.3.2-gke.1.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.3.2-gke.1.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

Conecte-se à sua estação de trabalho de administrador usando o seguinte comando:

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

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 de administrador, edite o arquivo de configuração que você usou para criar os clusters de administrador e de usuário. 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

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

Para executar as tarefas anteriores, execute o seguinte comando:

gkectl prepare --config [CONFIG_FILE] [FLAGS]

em que:

• [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para realizar o upgrade;

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

Como fazer upgrade do cluster de administrador

Execute este comando:

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

em que:

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

• [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para realizar o upgrade;

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

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] \
[FLAGS]

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;

• [CONFIG_FILE] é o arquivo de configuração do GKE On-Prem que você está usando para realizar o upgrade;

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

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.

   Acesse o menu do GKE

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 de cluster de administrador nem sempre são recuperáveis. Se um upgrade de 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.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"

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

Se os patches de segurança, como Vulnerabilidades e exposições comuns (CVEs, na sigla em inglês), não existirem na sua versão da estação de trabalho de administrador, use o método alternativo para atualizar o GKE On-Prem. O método alternativo atualiza apenas gkectl e os clusters de usuário. Você não atualiza a estação de trabalho do administrador nesse cenário. Portanto, você só precisa usar esse método alternativo depois que todas as atualizações de segurança forem aplicadas à estação de trabalho do administrador existente.

Importante: há um problema conhecido com esse método de upgrade alternativo ao fazer upgrade dos clusters de usuário da versão 1.2.2 para a 1.3.0 usando o download do pacote. Durante o processo de upgrade, pode ocorrer um tempo limite que causa falha no upgrade do cluster de usuários. Para evitar esse problema, execute o processo de upgrade completo que inclui o upgrade da estação de trabalho do administrador usando o arquivo OVA.

1. Atualize os componentes da Google Cloud CLI: gcloud components update.
2. Faça o download e instale a ferramenta gkectl mais recente.
3. Faça o download do pacote.
4. Faça upgrade dos clusters de usuário.

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.

Como executar comandos gkectl de maneira detalhada

-v5

Como registrar erros gkectl em stderr

--alsologtostderr

Como localizar registros gkectl na estação de trabalho do administrador

Mesmo que você não transmita as sinalizações de depuração, é possível visualizar os registros gkectl no seguinte diretório da estação de trabalho do administrador:

/home/ubuntu/.config/gke-on-prem/logs

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