Resolver problemas de criação ou upgrade de clusters

Nesta página, mostramos como resolver problemas relacionados à instalação ou ao upgrade de clusters do Google Distributed Cloud.

Se precisar de mais ajuda, entre em contato com o Cloud Customer Care.

Problemas de instalação

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

Mensagens de erro temporárias

O processo de instalação do Google Distributed Cloud é um loop de reconciliação contínuo. Como resultado, podem aparecer mensagens de erro transitórias no registro durante a instalação.

Desde que a instalação seja concluída com êxito, esses erros podem ser ignorados com segurança. Veja abaixo uma lista de mensagens de erros transitórias e comuns:

  Internal error occurred: failed calling webhook "webhook.cert-manager.io": Post
  https://cert-manager-webhook.cert-manager.svc:443/mutate?timeout=10s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Internal error occurred: failed calling webhook "vcluster.kb.io": Post
  https://webhook-service.kube-system.svc:443/validate-baremetal-cluster-gke-io-v1-cluster?timeout=30s:
  dial tcp IP_ADDRESS:443: connect: connection refused

  Failed to register cluster with GKE Hub; gcloud output: error running command
  'gcloud container fleet memberships register CLUSTER_NAME  --verbosity=error --quiet':
  error: exit status 1, stderr: 'ERROR: (gcloud.container.hub.memberships.register)
  Failed to check if the user is a cluster-admin: Unable to connect to the server: EOF

  Get
  https://127.0.0.1:34483/apis/infrastructure.baremetal.cluster.gke.io/v1/namespaces/cluster-
  cluster1/baremetalmachines: dial tcp 127.0.0.1:34483: connect: connection refused"

  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout088683152\": no matches for kind \"NetworkLogging\" in version \"networking.gke.io/v1alpha1\""
  Create Kind Cluster "msg"="apply run failed" "error"="unable to recognize \"/tmp/kout869681888\": no matches for kind \"Provider\" in version \"clusterctl.cluster.x-k8s.io/v1alpha3\""

Se a chave da conta de serviço do Google Cloud tiver expirado, você verá as seguintes mensagens de erro de bmctl:

Error validating cluster config: 3 errors occurred:
        * GKEConnect check failed: Get https://gkehub.googleapis.com/v1beta1/projects/project/locations/global/memberships/admin: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * ClusterOperations check failed: Post https://cloudresourcemanager.googleapis.com/v1/projects/project:testIamPermissions?alt=json&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}
        * GCR pull permission for bucket: artifacts.anthos-baremetal-release.appspot.com failed: Get https://storage.googleapis.com/storage/v1/b/artifacts.anthos-baremetal-release.appspot.com/iam/testPermissions?alt=json&permissions=storage.objects.get&permissions=storage.objects.list&prettyPrint=false: oauth2: cannot fetch token: 400 Bad Request
Response: {"error":"invalid_grant","error_description":"Invalid JWT Signature."}

É necessário gerar uma nova chave da conta de serviço.

Usar o cluster de inicialização para depurar problemas

Quando o Google Distributed Cloud cria clusters autogerenciados (de administrador, híbridos ou independentes), ele implanta um cluster (tipo) do Kubernetes no Docker para hospedar temporariamente os controladores do Kubernetes necessários para criar clusters. Esse cluster transitório é chamado de cluster de inicialização. Os clusters de usuário são criados e atualizados pelo cluster de administrador ou híbrido de gerenciamento sem o uso de um cluster de inicialização.

Se um cluster de tipo já existir na implantação quando você tentar instalar, o Google Distributed Cloud excluirá o cluster de tipo atual. A exclusão só ocorre depois que a instalação ou o upgrade são bem-sucedidos. Para preservar o cluster de tipo atual mesmo após o sucesso, use a sinalização --keep-bootstrap-cluster de bmctl.

O Google Distributed Cloud cria um arquivo de configuração para o cluster de inicialização em WORKSPACE_DIR/.kindkubeconfig. Só é possível se conectar ao cluster de inicialização durante a criação e o upgrade dele.

O cluster de inicialização precisa acessar um repositório do Docker para extrair imagens. O registro é o padrão para o Container Registry, a menos que você esteja usando um registro particular. Durante a criação do cluster, bmctl cria os seguintes arquivos:

  • bmctl-workspace/config.json: contém as credenciais da conta de serviço do Google Cloud para o acesso ao registro. As credenciais são recebidas do campo gcrKeyPath no arquivo de configuração do cluster.

  • bmctl-workspace/config.toml: contém a configuração do containerd no cluster de tipo.

Examinar os registros do cluster de inicialização

Para depurar o cluster de inicialização, siga estas etapas:

  • Conecte-se ao cluster de inicialização durante a criação e o upgrade do cluster.
  • Receba os registros do cluster de inicialização.

É possível encontrar os registros na máquina que você usa para executar bmctl nas seguintes pastas:

  • bmctl-workspace/CLUSTER_NAME/log/create-cluster-TIMESTAMP/bootstrap-cluster/
  • bmctl-workspace/CLUSTER_NAME/log/upgrade-cluster-TIMESTAMP/bootstrap-cluster/

Substitua CLUSTER_NAME e TIMESTAMP pelo nome do cluster e o horário do sistema correspondente.

Para acessar os registros do cluster de inicialização diretamente, execute o seguinte comando durante a criação e o upgrade do cluster:

docker exec -it bmctl-control-plane bash

O comando abre um terminal dentro do contêiner do plano de controle bmctl que é executado no cluster de inicialização.

Para inspecionar os registros kubelet e containerd, use os seguintes comandos e procure erros ou avisos na saída:

journalctl -u kubelet
journalctl -u containerd

Problemas de upgrade de cluster

Ao fazer upgrade dos clusters do Google Distributed Cloud, é possível monitorar o progresso e verificar o status dos seus clusters e nós.

As orientações a seguir podem ajudar a determinar se o upgrade continua normalmente ou se há um problema.

Monitorar o progresso do upgrade

Use o comando kubectl describe cluster para ver o status de um cluster durante o processo de upgrade:

kubectl describe cluster CLUSTER_NAME \
    --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAME: o nome do cluster.
  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Por padrão, os clusters de administrador, híbrido e autônomo usam um upgrade no local. Se você usar a sinalização --use-bootstrap=true com o comando bmctl upgrade, a operação de upgrade usará um cluster de inicialização. Para monitorar o progresso do upgrade quando um cluster de inicialização for usado, especifique o caminho para o arquivo kubeconfig do cluster de inicialização, .kindkubeconfig. Esse arquivo está localizado no diretório do espaço de trabalho.

Observe a seção Status da saída, que mostra uma agregação do status de upgrade do cluster. Se o cluster relatar um erro, use as seções a seguir para solucionar o problema.

Verificar se os nós estão prontos

Use o comando kubectl get nodes para ver o status dos nós em um cluster durante o processo de upgrade:

kubectl get nodes --kubeconfig KUBECONFIG

Para verificar se um nó concluiu o processo de upgrade, observe as colunas VERSION e AGE na resposta do comando. O VERSION é a versão do Kubernetes do cluster. Para saber qual é a versão do Kubernetes de uma determinada versão do Google Distributed Cloud, consulte Histórico de versões.

Se o nó mostrar NOT READY, tente o conectar e verificar o status do kubelet:

systemctl status kubelet

Você também pode analisar os registros do kubelet:

journalctl -u kubelet

Analise a saída do status do kubelet e os registros das mensagens que indicam por que o nó tem um problema.

Verificar qual nó está sendo atualizado

Para verificar qual nó do cluster está em processo de upgrade, use o comando kubectl get baremetalmachines:

kubectl get baremetalmachines --namespace CLUSTER_NAMESPACE \
    --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização (bmctl-workspace/.kindkubeconfig).

O exemplo de saída a seguir mostra que o nó que está sendo atualizado tem um ABM VERSION diferente de DESIRED ABM VERSION:

NAME         CLUSTER    READY   INSTANCEID               MACHINE      ABM VERSION   DESIRED ABM VERSION
10.200.0.2   cluster1   true    baremetal://10.200.0.2   10.200.0.2   1.13.0        1.14.0
10.200.0.3   cluster1   true    baremetal://10.200.0.3   10.200.0.3   1.13.0        1.13.0

Verificar quais nós estão no processo de drenagem

Durante o processo de upgrade, os nós são esvaziados dos pods, e a programação fica desativada até que o upgrade do nó seja concluído. Para ver quais nós estão sendo drenados, use o comando kubectl get nodes:

kubectl get nodes --kubeconfig USER_CLUSTER_KUBECONFIG | grep "SchedulingDisabled"

Substitua USER_CLUSTER_KUBECONFIG pelo caminho para o arquivo Kubeconfig do cluster de usuário.

A coluna STATUS é filtrada usando grep para mostrar apenas os nós que informam SchedulingDisabled. Esse status indica que os nós estão sendo drenados.

Também é possível verificar o status do nó do cluster de administrador:

kubectl get baremetalmachines -n CLUSTER_NAMESPACE \
  --kubeconfig ADMIN_KUBECONFIG

Substitua os seguintes valores:

  • CLUSTER_NAMESPACE: o namespace do cluster.
  • ADMIN_KUBECONFIG: o arquivo kubeconfig do administrador.
    • Se um cluster de inicialização for usado para um upgrade híbrido, de administrador ou separado, especifique o arquivo kubeconfig do cluster de inicialização (bmctl-workspace/.kindkubeconfig).

O nó que está sendo drenado mostra o status na coluna MAINTENANCE.

Verifique por que um nó está no status de drenagem há muito tempo

Use um dos métodos na seção anterior para identificar o nó que está sendo drenado usando o comando kubectl get nodes. Use o comando kubectl get pods e filtre o nome desse nó para ver mais detalhes:

kubectl get pods --all-namespaces -o wide --field-selector spec.nodeName=NODE_NAME

Substitua NODE_NAME pelo nome do nó que está sendo drenado. A saída retorna uma lista de pods que estão travados ou são drenados com lentidão. O upgrade continua, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.

A partir da versão 1.29, o processo de drenagem de nó usa a API Eviction, que respeita PodDisruptionBudgets (PDBs).

As seguintes configurações de PDB podem causar problemas de drenagem de nós:

  • Pods gerenciados por vários PDBs

  • Configurações estáticas do PDB, como as seguintes:

    • maxUnavailable == 0
    • minUnavailable >= total de réplicas

    A contagem total de réplicas é difícil de determinar no recurso PDB, porque está definida em um recurso de nível superior, como Deployment, ReplicaSet ou StatefulSet. Os PDBs fazem a correspondência com pods com base no seletor somente na configuração. Uma boa abordagem para diagnosticar se uma configuração estática do PDB está causando um problema é verificar se pdb.Status.ExpectPods <= pdb.Status.DesiredHealthy primeiro e verificar se uma das configurações estáticas mencionadas permite que isso aconteça.

Violações no ambiente de execução, como o valor DisruptionsAllowed calculado para um recurso PDB como 0, também podem bloquear a drenagem de nós. Se você tiver objetos PodDisruptionBudget configurados que não permitam outras interrupções, talvez os upgrades de nó não consigam fazer upgrade para a versão do plano de controle após várias tentativas. Para evitar essa falha, recomendamos que você escalonar verticalmente Deployment ou HorizontalPodAutoscaler para permitir que o nó seja drenado, respeitando a configuração PodDisruptionBudget.

Para conferir todos os objetos PodDisruptionBudget que não permitem interrupções, use o seguinte comando:

kubectl get poddisruptionbudget --all-namespaces \
    -o jsonpath='{range .items[?(@.status.disruptionsAllowed==0)]}{.metadata.name}/{.metadata.namespace}{"\n"}{end}'

Verificar por que os pods não estão íntegros

Os upgrades poderão falhar se um pod contiver endereços IP do plano de controle upgrade-first-node ou upgrade-node. Esse comportamento geralmente ocorre porque os pods estáticos não estão íntegros.

  1. Verifique os pods estáticos com o comando crictl ps -a e procure os pods do Kubernetes ou etcd com falha. Se você tiver pods com falha, revise os registros dos pods para ver por que eles estão falhando.

    Veja algumas possibilidades de comportamento de loop de falhas:

    • As permissões ou o proprietário de arquivos montados em pods estáticos não estão corretos.
    • A conectividade com o endereço IP virtual não funciona.
    • Problemas com etcd

  2. Se o comando crictl ps não funcionar ou não retornar nada, verifique o status de kubelet e containerd. Use os comandos systemctl status SERVICE e journalctl -u SERVICE para analisar os registros.

A seguir