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 GKE em bare metal.

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 de instalação do GKE em Bare Metal.

Mensagens de erro temporárias

O processo de instalação do Ado GKE em Bare Metal é um loop de reconciliação contínua. 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 sua 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 GKE em bare metal cria clusters autogerenciados (administrador, híbrido ou autônomo), ele implanta um cluster do Kubernetes no Docker (tipo) para hospedar temporariamente o 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 em sua implantação ao tentar instalar, o GKE em Bare Metal excluirá o cluster de tipo existente. 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 GKE em Bare Metal 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 do GKE em clusters Bare Metal, é possível monitorar o progresso e verificar o status dos 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 ver a versão do Kubernetes de um determinado GKE em versão Bare Metal, confira a tabela na Política de suporte de versão.

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á fazendo upgrade

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 independente, especifique o arquivo kubeconfig do cluster de inicialização (bmctl-workspace/.kindkubeconfig).

O exemplo de saída abaixo mostra que o nó que está sendo atualizado no momento 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 sendo drenados no momento

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 de pods, 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 independente, 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 lentos para drenagem. O upgrade prossegue, mesmo com pods travados, quando o processo de drenagem em um nó leva mais de 20 minutos.

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