Resolva problemas de criação ou atualização de clusters

Esta página mostra-lhe como investigar problemas com a criação e a atualização de clusters no Google Distributed Cloud (apenas software) para VMware.

Problemas de instalação

As secções seguintes podem ajudar a resolver problemas com a instalação do Google Distributed Cloud.

Use o cluster de arranque para depurar problemas

Durante a instalação, o Google Distributed Cloud cria um cluster de arranque temporário. Após uma instalação bem-sucedida, o Google Distributed Cloud elimina o cluster de arranque, deixando-lhe o cluster de administrador e o cluster de utilizador. Geralmente, não deve ter motivos para interagir com o cluster de arranque. No entanto, se tiver problemas durante a instalação, pode usar os registos do cluster de arranque para ajudar a depurar o problema.

Se passar --cleanup-external-cluster=false para gkectl create cluster, o cluster de arranque não é eliminado e pode usar o cluster de arranque para depurar problemas de instalação.

Examine os registos do cluster de arranque

  1. Encontre os nomes dos pods em execução no espaço de nomes kube-system:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl get pods -n kube-system

  2. Para ver os registos de um pod:

    kubectl --kubeconfig /home/ubuntu/.kube/kind-config-gkectl -n kube-system get logs POD_NAME

    Substitua POD_NAME pelo nome do pod que quer ver.

  3. Para obter os registos do cluster de arranque diretamente, execute o seguinte comando durante a criação, a atualização e a atualização do cluster:

    docker exec -it gkectl-control-plane bash

    Este comando abre um terminal no contentor gkectl-control-plane que é executado no cluster de arranque.

  4. Para inspecionar os registos kubelet e containerd, use os seguintes comandos e procure erros ou avisos no resultado:

    systemctl status -l kubelet
journalctl --utc -u kubelet
systemctl status -l containerd
journalctl --utc -u containerd

Examine o resumo do cluster de arranque

Se tentar criar ou atualizar um cluster de administrador e essa operação falhar, o Google Distributed Cloud tira uma captura de ecrã externa do cluster de arranque. Esta captura instantânea do cluster de arranque é semelhante à captura instantânea feita através da execução do comando gkectl diagnose snapshot no cluster de administrador, mas o processo é acionado automaticamente. A captura de ecrã do cluster de arranque contém informações de depuração importantes para o processo de criação e atualização do cluster de administrador. Pode fornecer esta captura de ecrã ao Cloud Customer Care, se necessário.

O resumo externo inclui registos de pods do onprem-admin-cluster-controller que pode ver para depurar a criação de clusters ou problemas de atualização. Os registos são armazenados num ficheiro separado, por exemplo:

kubectl_logs_onprem-admin-cluster-controller-6767f6597-nws8g_ \
    --container_onprem-admin-cluster-controller_ \
    --kubeconfig_.home.ubuntu..kube.kind-config-gkectl_\
    --namespace_kube-system

A VM não é iniciada após o início do plano de controlo do administrador

Se uma VM não for iniciada após o início do painel de controlo do administrador, pode investigar o problema inspecionando os registos do pod dos controladores da API Cluster no cluster de administrador:

  1. Encontre o nome do pod dos controladores da API de clusters:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    get pods | grep clusterapi-controllers

  2. Ver registos do trabalho vsphere-controller-manager. Comece por especificar o pod, mas nenhum contentor:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME

    O resultado indica que tem de especificar um contentor e apresenta os nomes dos contentores no pod. Por exemplo:

    ... a container name must be specified ...,
choose one of: [clusterapi-controller-manager vsphere-controller-manager rbac-proxy]

  3. Escolha um contentor e veja os respetivos registos:

    kubectl --kubeconfig ADMIN_CLUSTER_KUBECONFIG --namespace kube-system \
    logs POD_NAME --container CONTAINER_NAME

Número suficiente de endereços IP atribuídos, mas a máquina não se regista no cluster

Este problema pode ocorrer se existir um conflito de endereço IP. Por exemplo, um endereço IP que especificou para uma máquina está a ser usado para um equilibrador de carga.

Para resolver este problema, atualize o ficheiro de bloco de IPs do cluster para que os endereços das máquinas não entrem em conflito com os endereços especificados no ficheiro de configuração do cluster ou no ficheiro de bloco de IPs do Seesaw

O cluster do Kind não é eliminado

Quando cria um cluster de administrador, é criado um cluster kind (também denominado cluster de arranque) como parte do processo. Quando a operação do cluster de administrador estiver concluída, o cluster kind é eliminado automaticamente.

Se vir a mensagem de erro Failed to delete the kind cluster, pode efetuar os seguintes passos na estação de trabalho do administrador para eliminar manualmente o cluster kind:

  1. Obtenha o kind ID do contentor:

    docker inspect --format="{{.Id}}" gkectl-control-plane

  2. Obtenha o ID do processo containerd-shim:

    sudo ps awx | grep containerd-shim | grep CONTAINER_ID | awk '{print $1}'

  3. Termine o processo:

    sudo kill -9 PROCESS_ID

Problemas de atualização de clusters

As secções seguintes oferecem sugestões sobre como resolver problemas que pode encontrar durante uma atualização do cluster.

Reverta um node pool após uma atualização

Se atualizar um cluster de utilizadores e, em seguida, descobrir um problema com os nós do cluster, pode reverter pools de nós selecionados para a versão anterior.

A reversão de pools de nós selecionados é suportada para pools de nós do Ubuntu e do COS, mas não para pools de nós do Windows.

A versão de um conjunto de nós pode ser igual ou uma versão secundária mais antiga do que a versão do plano de controlo do cluster de utilizadores. Por exemplo, se o plano de controlo estiver na versão 1.14, os conjuntos de nós podem estar na versão 1.14 ou 1.13.

Veja as versões do node pool disponíveis

Suponhamos que atualizou recentemente o cluster de utilizadores nós de trabalho e plano de controlo da versão 1.13.1-gke.35 para a versão 1.14.0 e descobre um problema com os nós de trabalho atualizados. Por isso, decide reverter um ou mais node pools para a versão que estava a executar anteriormente: 1.13.1-gke.35. Antes de poder iniciar a reversão, tem de verificar se a versão anterior está disponível para reversão.

Para ver as versões disponíveis, execute o seguinte comando:

gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

O resultado mostra a versão atual e a versão anterior de cada conjunto de nós. Por exemplo:

user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Reverta a versão do node pool

Pode reverter a versão de um conjunto de nós de cada vez ou reverter vários conjuntos de nós num único passo.

Para reverter a versão de um conjunto de nós, conclua os seguintes passos:

  1. No ficheiro de configuração do cluster de utilizadores, num ou mais conjuntos de nós, defina o valor de gkeOnPremVersion para a versão anterior. O exemplo seguinte mostra como reverter para a versão 1.13.1-gke.35:

    nodePools:
- name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: 1.13.1-gke.35
  ...

  2. Atualize o cluster para reverter os node pools:

    gkectl update cluster --config USER_CLUSTER_CONFIG \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

  3. Verifique se a reversão foi bem-sucedida:

    gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    A seguinte saída mostra que pool-1 foi revertido para a versão 1.13.1-gke.35.

    user cluster version: 1.14.0-gke.x

node pools:
- pool-1:
  - version: 1.13.1-gke.35
  - previous version: 1.14.0-gke.x
- pool-2:
  - version: 1.14.0-gke.x
  - previous version: 1.13.1-gke.35

available node pool versions:
- 1.13.1-gke.35
- 1.14.0-gke.x

Atualize para uma nova versão de patch

Pode atualizar todos os conjuntos de nós e o plano de controlo para uma nova versão de patch. Isto pode ser útil se reverter para uma versão anterior e quiser atualizar para uma versão que inclua uma correção.

Para atualizar para uma nova versão, conclua os seguintes passos:

  1. Faça as seguintes alterações no ficheiro de configuração do cluster de utilizadores:

    1. Defina o valor de gkeOnPremVersion para uma nova versão de patch. Este exemplo usa a versão 1.14.1-gke.x.

    2. Para cada conjunto de nós, remova o campo gkeOnPremVersion ou defina-o como a string vazia. Quando não é especificada nenhuma versão para um conjunto de nós, a versão do conjunto de nós é predefinida para a versão especificada para o cluster.

      Estas alterações têm um aspeto semelhante ao seguinte exemplo:

      gkeOnPremVersion: 1.14.1-gke.x

nodePools:
-   name: pool-1
  cpus: 4
  memoryMB: 8192
  replicas: 3
  gkeOnPremVersion: ""
-   name: pool-2
  cpus: 8
  memoryMB: 8192
  replicas: 2
  gkeOnPremVersion: ""

  2. Execute gkectl prepare e gkectl upgrade cluster conforme descrito em Atualizar o Google Distributed Cloud.

  3. Verifique a nova versão do cluster e veja as versões disponíveis para reversão:

    gkectl version --cluster-name USER_CLUSTER_NAME \
    --kubeconfig ADMIN_CLUSTER_KUBECONFIG

    O resultado é semelhante ao seguinte:

     user cluster version: 1.14.1-gke.y

 node pools:
 - pool-1:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35
 - pool-2:
   - version: 1.14.1-gke.y
   - previous version: 1.13.1-gke.35

 available node pool versions:
 - 1.13.1-gke.35
 - 1.14.0-gke.x
 - 1.14.1-gke.y
 ```

As verificações de estado são executadas automaticamente quando a atualização do cluster falha

Se tentar atualizar um cluster de administrador ou de utilizador e essa operação falhar, o Google Distributed Cloud executa automaticamente o comando gkectl diagnose cluster no cluster.

Para ignorar o diagnóstico automático, transmita a flag --skip-diagnose-cluster para gkectl upgrade.

O processo de atualização fica bloqueado

Nos bastidores, o Google Distributed Cloud usa o comando Kubernetes drain durante uma atualização. Este procedimento drain pode ser bloqueado por uma implementação com apenas uma réplica que tenha um PodDisruptionBudget (PDB) criado para ela com minAvailable: 1.

A partir da versão 1.13 do Google Distributed Cloud, pode verificar as falhas através de eventos de pods do Kubernetes.

  1. Encontre os nomes das máquinas:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG get machines --all-namespaces

  2. Verifique se existem erros através do comando kubectl describe machine:

    kubectl --kubeconfig USER_CLUSTER_KUBECONFIG describe machine MACHINE_NAME

    O resultado é semelhante ao seguinte:

    Events:
  Type     Reason              Age    From                Message
  ----     ------              ----   ----                -------
  Warning  PodEvictionTooLong  3m49s  machine-controller  Waiting too long(12m10.284294321s) for pod(default/test-deployment-669b85c4cc-z8pz7) eviction.

  3. Opcional: para uma análise mais detalhada do estado dos objetos de aprendizagem automática, execute o comando gkectl diagnose cluster.

    O resultado é semelhante ao seguinte:

    ...
Checking machineset...SUCCESS
Checking machine objects...FAILURE
    Reason: 1 machine objects error(s).
    Unhealthy Resources:
    Pod test-deployment-669b85c4cc-7zjpq: Pod cannot be evicted successfully. There is 1 related PDB.
...
Checking all poddisruptionbudgets...FAILURE
    Reason: 1 pod disruption budget error(s).
    Unhealthy Resources:
    PodDisruptionBudget test-pdb: default/test-pdb might be configured incorrectly, the total replicas(3) should be larger than spec.MinAvailable(3).
...
Some validation results were FAILURE or UNKNOWN. Check report above.

Para resolver este problema, guarde o PDB e remova-o do cluster antes de tentar a atualização. Em seguida, pode adicionar novamente o PDB após a conclusão da atualização.

Remova alterações não suportadas para desbloquear a atualização

Quando atualiza clusters para a versão 1.16 ou anterior, as alterações à maioria dos campos são ignoradas silenciosamente durante a atualização, o que significa que estas alterações não têm efeito durante nem após a atualização.

Quando atualiza clusters de utilizadores para a versão 1.28 ou posterior, validamos todas as alterações feitas no ficheiro de configuração e devolvemos um erro para alterações não suportadas, em vez de as ignorarmos. Esta funcionalidade destina-se apenas a clusters de utilizadores. Quando atualiza clusters de administrador, as alterações à maioria dos campos são ignoradas silenciosamente e não entram em vigor após a atualização.

Por exemplo, se tentar desativar a autorreparação de nós ao atualizar um cluster de utilizador para a versão 1.28, a atualização falha com a seguinte mensagem de erro:

failed to generate desired create config: failed to generate desired OnPremUserCluster from seed config: failed to apply validating webhook to OnPremUserCluster: the following changes on immutable fields are forbidden during upgrade: (diff: -before, +after):
   v1alpha1.OnPremUserClusterSpec{
    ... // 20 identical fields
    CloudAuditLogging:     &{ProjectID: "syllogi-partner-testing", ClusterLocation: "us-central1", ServiceAccountKey: &{KubernetesSecret: &{Name: "user-cluster-creds", KeyName: "cloud-audit-logging-service-account-key"}}},
-   AutoRepair:            &v1alpha1.AutoRepairConfig{Enabled: true},
+   AutoRepair:            &v1alpha1.AutoRepairConfig{},
    CARotation:            &{Generated: &{CAVersion: 1}},
    KSASigningKeyRotation: &{Generated: &{KSASigningKeyVersion: 1}},
    ... // 8 identical fields
  }

Se precisar de ignorar este erro, existem as seguintes soluções alternativas:

  • Reverta a alteração tentada e, em seguida, volte a executar a atualização. Por exemplo, no cenário anterior, reverteria as alterações feitas à configuração AutoRepair e, em seguida, executaria novamente gkectl upgrade.
  • Em alternativa, pode gerar ficheiros de configuração que correspondam ao estado atual do cluster executando gkectl get-config, atualizar os campos gkeOnPremVersion para o cluster e os conjuntos de nós no ficheiro de configuração e, em seguida, executar novamente gkectl upgrade.

Problema: imagem do SO não encontrada após gkectl prepare

Depois de executar o comando gkectl prepare e, em seguida, tentar atualizar um cluster de utilizadores com gkectl upgrade cluster, pode ocorrer um erro semelhante ao seguinte:

[FAILURE] User OS images exist: OS images [gke-on-prem-ubuntu-VERSION] don't exist, please run `gkectl prepare` to upload OS images.

Este erro pode ocorrer quando o cluster de administrador e o cluster de utilizador estão configurados para usar pastas do vSphere diferentes. Por predefinição, o comando gkectl prepare carrega a imagem do SO para a pasta do cluster de administrador. Para carregar a imagem para a pasta do cluster do utilizador, use a flag --user-cluster-config, conforme mostrado no comando seguinte:

  gkectl prepare --kubeconfig ADMIN_CLUSTER_KUBECONFIG \
    --bundle-path /var/lib/gke/bundles/gke-onprem-vsphere-VERSION-full.tgz \
    --user-cluster-config USER_CLUSTER_CONFIG

Depure problemas do F5 BIG-IP com o ficheiro kubeconfig interno

Após uma instalação, o Google Distributed Cloud gera um ficheiro kubeconfig denominado internal-cluster-kubeconfig-debug no diretório base da sua estação de trabalho de administração. Este ficheiro kubeconfig é idêntico ao ficheiro kubeconfig do cluster de administrador, exceto que aponta diretamente para o nó do plano de controlo do cluster de administrador, onde o servidor da API Kubernetes é executado. Pode usar o ficheiro internal-cluster-kubeconfig-debug para depurar problemas do F5 BIG-IP.

Resolva problemas com o vSphere

Pode usar govc para investigar problemas com o vSphere. Por exemplo, pode confirmar as autorizações e o acesso das suas contas de utilizador do vCenter, bem como recolher registos do vSphere.

Recrie o ficheiro kubeconfig do cluster de utilizadores em falta

Pode querer recriar um ficheiro de cluster de utilizadores kubeconfig nas seguintes situações:

  • Se tentar criar um cluster de utilizadores, a operação de criação falhar e quiser ter o ficheiro kubeconfig do cluster de utilizadores.
  • Se o ficheiro kubeconfig do cluster de utilizadores estiver em falta, por exemplo, após ter sido eliminado.

Para gerar um novo ficheiro kubeconfig para o cluster de utilizadores, execute os seguintes passos:

  1. Defina variáveis de ambiente:

    Comece por definir as seguintes variáveis de ambiente com os valores adequados:

    USER_CONTROLPLANEVIP=USER_CONTROLPLANEVIP
USER_CLUSTER_NAME=USER_CLUSTER_NAME
ADMIN_CLUSTER_KUBECONFIG=PATH_TO_ADMIN_KUBECONFIG
KUBECONFIG_SECRET_NAME=$(kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets -n $USER_CLUSTER_NAME | grep ^admin | cut -d' ' -f1 | head -n 1)

    Substitua o seguinte:

    • ADMIN_CLUSTER_KUBECONFIG: o caminho do ficheiro kubeconfig para o cluster de administrador.
    • USER_CONTROLPLANEVIP: o controlPlaneVIP do cluster de utilizadores. Pode ser obtido a partir do ficheiro de manifesto do cluster de utilizadores.

  2. Gere o ficheiro Kubeconfig:

    Execute o seguinte comando para criar o novo ficheiro kubeconfig:

    kubectl --kubeconfig $ADMIN_CLUSTER_KUBECONFIG get secrets $KUBECONFIG_SECRET_NAME \
 -n $USER_CLUSTER_NAME -o jsonpath='{.data.admin\.conf}'  | base64 -d | \
 sed -r "s/ kube-apiserver.*local\./${USER_CONTROLPLANEVIP}/" \
 > USER_CLUSTER_KUBECONFIG

    Substituir :

    • USER_CLUSTER_KUBECONFIG: o nome do novo ficheiro kubeconfig para o seu cluster de utilizadores.

O que se segue?

Se precisar de assistência adicional, contacte o apoio ao cliente do Google Cloud.

Também pode consultar o artigo Receber apoio técnico para mais informações sobre recursos de apoio técnico, incluindo o seguinte: