Resolva problemas de registo de nós

Este documento descreve como resolver problemas ao adicionar nós ao seu cluster Standard do Google Kubernetes Engine (GKE). Alguns dos cenários em que estes problemas ocorrem incluem a criação de clusters e a criação de conjuntos de nós, bem como durante eventos de expansão.

Para resolver problemas com clusters do GKE Autopilot, consulte o artigo Resolução de problemas de clusters do Autopilot.

Acerca do registo de nós

Os nós são instâncias de VM do Compute Engine que o GKE cria em seu nome. Quando um novo nó é adicionado a um cluster do GKE, tem de ser registado no plano de controlo do cluster. Este processo, denominado registo de nós ou inicialização de nós, ocorre quando um nó é criado.

Quando ocorre o registo de nós

O registo de nós ocorre sempre que são criados nós, incluindo os seguintes cenários:

O processo de registo de nós segue estes passos:

  1. A contagem de nós definida para o node pool é replicada para os grupos de instâncias geridas (MIGs).
  2. Os MIGs criam o número necessário de instâncias de VM.

  3. Para cada instância de VM criada:

    1. A instância de VM é iniciada.
    2. A configuração da instância de VM configura e instala os pacotes necessários para ser executada como um nó do Kubernetes.
    3. O kubelet que está agora em execução na instância de VM comunica com o servidor da API do plano de controlo para se registar como um nó.

Mensagem de erro de registo do nó

Quando o GKE tenta adicionar nós ao cluster, é apresentado o seguinte erro na consola se o registo de nós falhar: Google Cloud 

  All cluster resources were brought up, but: only 0 nodes out of * have
  registered; this is likely due to the Nodes failing to start correctly; try
  re-creating the cluster or contact support if that doesn't work.

Esta mensagem de erro indica que os nós não foram registados com êxito no cluster. As secções seguintes descrevem algumas das potenciais causas deste erro.

Pré-requisitos para um registo de nó bem-sucedido

O registo bem-sucedido de um nó num cluster do GKE depende de fatores como os seguintes:

  • Conetividade de rede.
  • Disponibilidade de recursos.
  • Autorizações da conta de serviço.

Pré-requisitos para a criação de instâncias

Quando o GKE cria um nó para o seu cluster, o primeiro passo é criar uma nova instância de VM do Compute Engine.

A criação da instância pode falhar por um dos seguintes motivos:

A falha na criação de instâncias significa que, no intervalo de tempo durante o qual o GKE tentou criar a instância para registar como um nó do GKE, faltam registos para a criação de instâncias, uma vez que as instâncias nunca foram criadas. Para verificar se existem registos em falta, consulte as instruções para encontrar uma instância que não tenha conseguido registar o nó.

Autorizações da conta de serviço

Os nós do GKE têm uma conta de serviço do IAM associada. Por predefinição, esta conta de serviço é a conta de serviço predefinida do Compute Engine. Recomendamos que, para proteger o cluster, use uma conta de serviço do IAM personalizada com as autorizações mínimas necessárias.

Esta conta de serviço tem de ter as autorizações corretas para que as instâncias de VM sejam inicializadas como nós do GKE. Se eliminar a conta de serviço, a desativar ou não lhe conceder as autorizações corretas, o registo de nós pode falhar.

Pré-requisitos para a ligação de rede às APIs e aos serviços Google

A instância de MV transfere pacotes para se preparar para ser executada como um nó do GKE e um limite de tempo de ligação pode significar que o seu cluster não cumpriu os requisitos de rede necessários para estabelecer ligação às APIs e aos serviços Google, como o storage.googleapis.com. Se uma instância não conseguir estabelecer ligação a estes serviços, não pode transferir a distribuição do Kubernetes nem concluir o processo de registo do nó.

Consoante a sua ligação de rede, permitir esta ligação pode significar configurar o acesso privado à Google, ou ter regras de firewall e rotas na rede de nuvem virtual privada (VPC) do seu cluster que permitem a ligação.

Pré-requisitos para a ligação de rede com o plano de controlo

A conetividade entre o plano de controlo e os nós é fundamental para o registo dos nós e o funcionamento normal. Esta comunicação é permitida por predefinição. Certifique-se de que, ao implementar regras de firewall da VPC, a comunicação continua a ser permitida entre os nós e o plano de controlo.

Para mais informações, consulte o artigo Permita a conetividade do plano de controlo.

Use o verificador de registo de nós para resolver problemas de registo de nós

O utilitário Node Registration Checker é executado em instâncias recém-criadas e verifica se a instância concluiu com êxito os passos de registo do nó.

Quando o registo do nó falha, o utilitário gera um relatório de resumo onde pode ver que pré-requisitos não foram cumpridos com base no ponto do processo em que a instância falhou.

Use as instruções na secção seguinte para encontrar uma instância cujo registo do nó falhou e use o resumo do verificador de registo do nó para saber por que motivo falhou.

Encontre uma instância cujo registo de nós falhou

Quando uma ou mais instâncias não conseguem registar-se como nós com o plano de controlo do cluster do GKE, pode ver o número de instâncias que falharam na mensagem de erro apresentada na página Detalhes do cluster da Google Cloud consola. Quando várias instâncias não conseguem registar-se em simultâneo, pode dever-se ao mesmo motivo subjacente. Por este motivo, pode usar uma das instâncias com falhas para investigar o motivo pelo qual todas as instâncias falharam.

No entanto, uma vez que as instâncias não foram registadas como nós do GKE, tem de usar as seguintes instruções para encontrar os nomes das VMs do Compute Engine subjacentes que não foram registadas.

  1. Na Google Cloud consola, aceda à página Explorador de registos:

    Aceda ao Explorador de registos

  2. Use o seguinte filtro de registo para encontrar os registos de criação de instâncias da VM:

    resource.type="gce_instance"
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Factivity"
protoPayload.requestMetadata.callerSuppliedUserAgent="GCE Managed Instance Group for GKE"
protoPayload.response.status="RUNNING"

    Substitua PROJECT_ID pelo ID do projeto do seu cluster.

  3. Use o histograma abaixo do filtro de registo para restringir o intervalo de tempo ao momento em que a criação do nó deveria ter ocorrido.

  4. Clique num dos registos apresentados em Resultados da consulta e, de seguida, clique em Expandir campos aninhados para mostrar mais detalhes.

  5. Encontre o campo protoPayload.resourceName. A parte final do caminho indicado é o nome da instância. Os nomes das instâncias seguem um formato que começa com o nome do cluster e o nome do conjunto de nós, por exemplo:

    gke-cluster-1-default-pool-b0ac62d3-9g1v é uma instância para o node pool default-pool em gke-cluster-1.

  6. Na Google Cloud consola, aceda à página de instâncias de VM do Compute Engine:

    Aceder às instâncias de VM

    Encontre o nome da instância de VM através do filtro. Clique para ver mais detalhes.

Resolva problemas de uma instância com o verificador de registo de nós

Depois de encontrar o nome da instância que não foi registada, pode investigar o motivo da falha através do verificador de registo de nós.

No separador Detalhes da instância de VM, na secção Registos, clique em Porta série 1 (consola).

A saída para instâncias criadas recentemente inclui o seguinte, o que indica que o verificador de registo de nós foi iniciado:

** Starting Node Registration Checker **
** Loading variables from kube-env **
** Sleeping for 7m to allow registration to complete  **

Se o registo do nó for bem-sucedido, a saída inclui as seguintes mensagens:

** Node ready and registered. **
** Completed running Node Registration Checker **

Se não vir estas mensagens, o registo do nó falhou e o verificador de registo do nó gerou um relatório que resume o motivo da falha do registo. Procure a seguinte mensagem adicional para ver o resumo:

** Here is a summary of the checks performed: **

Abaixo desta mensagem, procure uma tabela semelhante à seguinte:

------------------------------
Service    DNS      Reachable
------------------------------
LOGGING    true     true
GCR        true     true
GCS        true     true
Master     N/A      false
------------------------------

Se o LOGGING, o GCR ou o GCS estiverem indicados como não acessíveis, verifique as Autorizações da conta de serviço para o registo de nós e a Ligação de rede às APIs e aos serviços Google para o registo de nós.

Se Master estiver listado como não acessível, verifique os pré-requisitos para a Ligação de rede com o plano de controlo para o registo de nós.

Depois de resolver todos os problemas que impedem o registo bem-sucedido do nó, consulte o artigo Conclua o registo do nó depois de corrigir a causa principal.

Se os passos anteriores não indicarem o motivo da falha do registo do nó, consulte a secção Recolha informações para uma investigação mais detalhada.

Resolva problemas de registo de nós sem o verificador de registo de nós

Use estes passos apenas como último recurso se já tiver verificado os pré-requisitos para o registo bem-sucedido de nós e experimentado o verificador de registo de nós.

Depois de resolver todos os problemas que impedem o registo bem-sucedido do nó, conclua o registo do nó após corrigir a causa principal.

Se nenhum dos passos de investigação nesta página lhe indicar o motivo da falha no registo do nó, consulte o artigo Recolha informações para uma investigação mais detalhada.

Verifique as autorizações da conta de serviço para o registo de nós

A conta de serviço que os seus nós usam tem de ter as autorizações pré-requisitos para o registo de nós. Siga as instruções abaixo para verificar se cumpriu estes pré-requisitos:

  1. Encontre uma instância cujo registo do nó falhou.

  2. No separador Detalhes da instância de VM, na secção API e gestão de identidade, encontre o nome da conta de serviço no campo Conta de serviço. Se o nó usou a conta de serviço predefinida do Compute Engine, o nome segue o formato PROJECT_NUMBER-compute@developer.gserviceaccount.com. Esta conta de serviço tem de ter as autorizações mínimas necessárias.

  3. Procure indicadores de registo bem-sucedido na saída da consola de série. No separador Detalhes da instância de VM, na secção Registos, clique em Porta série 1 (consola).

    Se a instância tiver usado uma conta de serviço com as autorizações corretas, o resultado inclui o seguinte:

    • Started Download and install k8s binaries and configurations
    • Started Docker Application Container Engine.
    • Started Configure kubernetes node.
    • Reached target Kubernetes.

    Estas mensagens encontram-se em locais diferentes neste resultado. Também podem ter indicações de tempo ou outros artefactos que os interrompam, como este: Starting [0;1;39mConfigure kubernetes node. Se vir todas estas mensagens, significa que os pré-requisitos da conta de serviço foram cumpridos.

    Se não vir estas mensagens, a conta de serviço atribuída à instância de VM pode ter sido eliminada, estar desativada ou não ter as autorizações corretas.

Verifique a ligação de rede às APIs e aos serviços Google para o registo de nós

Verifique a ligação com acesso SSH

Se tiver acesso SSH a instâncias de VM no seu projeto, também pode verificar se a instância de VM tem uma ligação de rede às APIs e aos serviços Google.

  1. Encontre uma instância cujo registo do nó falhou.

  2. No separador Detalhes da instância de VM, clique em SSH.

  3. Depois de se ligar à linha de comandos da instância de VM, execute o seguinte comando para verificar a ligação às APIs e aos serviços Google:

    curl -m 5 -v https://storage.googleapis.com/generate_204

    Se a ligação for bem-sucedida, a saída é semelhante à seguinte:

    *   Trying 142.250.148.128:443...
* Connected to storage.googleapis.com (142.250.148.128) port 443 (#0)

...

< HTTP/1.1 204 No Content
< Content-Length: 0
< Cross-Origin-Resource-Policy: cross-origin
< Date: Wed, 04 Jan 2023 00:58:41 GMT
<
* Connection #0 to host storage.googleapis.com left intact

    Se a ligação não for bem-sucedida, o resultado é semelhante ao seguinte:

    *   Trying 142.250.148.128:443...
* Connection timed out after 5000 milliseconds
* Closing connection 0
curl: (28) Connection timed out after 5000 milliseconds

    Se a ligação expirar e o endereço IP devolvido estiver dentro do intervalo de endereços IP 199.36.153.0/24, verifique se o cluster cumpriu os requisitos de rede para estabelecer ligação às APIs e aos serviços Google. Se o tempo limite da ligação expirar e o endereço IP devolvido não estiver dentro do intervalo de endereços IP mencionado, verifique se existem regras de firewall a bloquear o tráfego de saída ou rotas mal configuradas na rede VPC do cluster.

    Mantenha a ligação SSH à instância da VM aberta e avance para a secção seguinte.

Verifique a ligação sem acesso SSH através dos testes de conetividade

Se não tiver acesso SSH a instâncias de VMs, use os testes de conetividade para verificar se a instância de VM tem uma ligação às APIs e aos serviços Google.

  1. Encontre uma instância cujo registo do nó falhou.

  2. Crie e execute testes de conetividade com a instância de VM como origem e storage.googleapis.com TCP/443 como destino.

    Use os resultados do teste para verificar a configuração de rede do cluster.

Verifique a ligação de rede com o plano de controlo para o registo de nós

Se tiver acesso SSH a instâncias de VM no seu projeto, pode verificar se a instância de VM tem uma ligação de rede ao plano de controlo do cluster.

  1. Encontre uma instância cujo registo do nó falhou.

  2. No separador Detalhes da instância de VM, clique em SSH.

  3. Depois de se ligar à linha de comandos da instância de VM, guarde o ponto final do plano de controlo do cluster como uma variável de ambiente:

    source <(sudo grep KUBERNETES_MASTER_NAME /home/kubernetes/kube-env)

  4. Envie um pedido GET para o ponto final do plano de controlo:

    curl -k -m 5  https://${KUBERNETES_MASTER_NAME}/version

    Se o resultado for semelhante ao seguinte, significa que a instância de VM pode estabelecer uma ligação com o plano de controlo:

    {
"major": "1",
"minor": "24",
"gitVersion": "v1.24.7-gke.900",
"gitCommit": "e35c4457f66187eff006dda6d2c0fe12144ef2ec",
"gitTreeState": "clean",
"buildDate": "2022-10-26T09:25:34Z",
"goVersion": "go1.18.7b7",
"compiler": "gc",
"platform": "linux/amd64"
}

    Se a saída for semelhante à seguinte, significa que a instância de VM não consegue estabelecer uma ligação com o plano de controlo:

    curl: (28) Connection timed out after 5000 milliseconds

Se a instância de VM não conseguir estabelecer uma ligação com o plano de controlo, consulte a secção sobre como permitir a conetividade do plano de controlo nas práticas recomendadas de rede do GKE.

Conclua o registo do nó após corrigir a causa principal

Depois de resolver o problema que está a bloquear o registo do nó, a forma como prossegue depende do contexto da falha:

  • Se o registo do nó falhar na criação do cluster, elimine o cluster e tente novamente.
  • Se o registo do nó falhou durante o aumento da escala com o escalador automático de clusters, aguarde que as instâncias de VM tentem registar-se novamente.
  • Se o registo do nó falhou na criação do node pool:
    • Se as instâncias de VM foram criadas, aguarde que as instâncias de VM tentem registar-se novamente.
    • Se as instâncias de VM não foram criadas, elimine o conjunto de nós e tente novamente.
  • Se o registo do nó falhar ao redimensionar o cluster, volte a executar o comando para aumentar o tamanho do cluster.
  • Se o registo do nó falhou fora do âmbito de uma operação, como durante uma operação de reparação, aguarde que as instâncias de VM tentem registar-se novamente.

Recolha informações para uma investigação mais aprofundada

Se não conseguir resolver o problema de registo do nó, pode recolher informações adicionais para ajudar na investigação do apoio técnico ao cliente da Google Cloud com as seguintes instruções. Estes passos requerem acesso SSH a instâncias de VM no seu projeto e usam o utilitário sosreport, que está incluído nas imagens do COS.

  1. Encontre uma instância cujo registo do nó falhou.

  2. Recolha informações de depuração com o sosreport.

    Em alternativa, se os seus nós não tiverem a utilidade sosreport transferida e não for possível instalá-la, recolha manualmente as informações de depuração executando os seguintes comandos:

     # Check cloud-init logs for issues during early VM boot
 sudo journalctl -u cloud-init-local --no-pager
 sudo journalctl -u cloud-init --no-pager
 sudo journalctl -u cloud-final --no-pager
 sudo journalctl -u cloud-config --no-pager

 # Check kubelet status and logs
 sudo systemctl status kubelet
 sudo journalctl -u kubelet --no-pager

 # Check GKE node installation service status and logs
 sudo systemctl status kube-node-installation.service
 sudo journalctl -u kube-node-installation.service --no-pager

 # Check GKE node configuration service status and logs
 sudo systemctl status kube-node-configuration.service
 sudo journalctl -u kube-node-configuration.service --no-pager

  3. Empacote estas informações num ficheiro ZIP e inclua-o quando enviar um registo de apoio ao cliente para o Cloud Customer Care.

O que se segue?