Como fazer upgrade de clusters

Nesta página, explicamos como fazer upgrade dos clusters de administrador e usuário de uma versão de patch do GKE On-Prem para a próxima versão de patch superior. Para saber mais sobre as versões disponíveis, consulte Versões.

Consulte também:

• Downloads
• Notas de lançamento
• Como fazer upgrade da estação de trabalho do administrador

Visão geral

O GKE On-Prem é compatível com upgrades sequenciais. Por exemplo, imagine que estas são as únicas versões que existem:

• 1.0.10
• 1.0.X, em que X veio depois de .10
• 1.0.Y, em que Y veio depois de X

Nesse caso, 1.0.Y é a versão mais recente. Para fazer upgrade de um cluster da versão 1.0.10 para a 1.0.Y, siga estas etapas:

1. Atualize o cluster de 1.0.10 para 1.0.X.
2. Em seguida, faça upgrade do cluster de 1.0.X para 1.0.Y.

Antes de começar

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

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

2. Autorize o gcloud a acessar o Google Cloud:

   gcloud auth login

3. Ative sua conta de serviço de acesso:

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

   onde:

   • [PROJECT_ID] é o ID do projeto.
   • [ACCESS_KEY_FILE] é o caminho para o arquivo de chave JSON da sua conta de serviço de acesso, como /home/ubuntu/access.json.

Como atualizar para a versão 1.0.2

Na versão 1.0.2-gke.3, os seguintes campos OIDC obrigatórios (usercluster.oidc) foram adicionados. Estes campos permitem fazer login em um cluster do console do Cloud:

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

Se você não quer fazer login em um cluster pelo Console do Cloud, mas quer usar o OIDC, pode inserir valores do marcador nesses campos:

oidc:
  kubectlredirecturl: "redirect.invalid"
  clientsecret: "secret"
  usehttpproxy: "false"

Como determinar o cenário de upgrade de cluster

Antes de fazer upgrade do cluster, decida qual destes cenários é relevante para a versão para a qual você está fazendo upgrade:

Cenário	Ação necessária	Observações
A versão não tem atualizações de segurança.	Faça o download do gkectl mais recente. Faça o download do pacote mais recente. Siga as instruções nesta página.
A versão tem atualizações de segurança.	Faça o download da versão mais recente da OVA da estação de trabalho do administrador. Faça upgrade da estação de trabalho do administrador. Siga as instruções nesta página.	Você só precisará fazer upgrade da estação de trabalho do administrador se a nova versão tiver atualizações de segurança. Quando você faz upgrade da estação de trabalho do administrador, ele inclui o gkectl e o pacote mais recentes.

Como determinar a versão da plataforma

Para fazer upgrade dos clusters, determine a versão da plataforma dos clusters:

Da documentação

Consulte Versões.

Do pacote

Execute o seguinte comando para extrair o pacote para um diretório temporário:

tar -xvzf /var/lib/gke/bundles/gke-onprem-vsphere-[VERSION].tgz -C [TEMP_DIR]

Analise os arquivos YAML extraídos para ter uma noção geral do que está no pacote.

Em particular, abra gke-onprem-vsphere-[VERSION]-images.yaml. Veja o campo osimages. É possível ver a versão da plataforma GKE no nome do arquivo de imagem do SO. Por exemplo, na imagem do SO a seguir, é possível ver que a versão da plataforma do GKE é 1.12.7-gke.19.

osImages:
  admin: "gs://gke-on-prem-os-ubuntu-release/gke-on-prem-osimage-1.12.7-gke.19-20190516-905ef43658.ova"

Como modificar o arquivo de configuração

Na VM da estação de trabalho do administrador, edite o arquivo de configuração. Defina os valores de gkeplatformversion e bundlepath. Por exemplo:

gkeplatformversion: 1.12.7-gke.19
bundlepath: /var/lib/gke/bundles/gke-onprem-vsphere-1.0.10.tgz

Como executar o 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 dos clusters

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.

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.

Cluster de usuário

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

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.

Problemas conhecidos

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

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