Resolver problemas no registro do nó


Neste documento, descrevemos como resolver problemas encontrados ao adicionar nós ao cluster padrão do Google Kubernetes Engine (GKE). Alguns dos cenários em que esses problemas ocorrem incluem a criação de clusters e o pool de nós, bem como durante os eventos de escalonamento vertical.

Para resolver problemas com clusters do Autopilot do GKE, consulte Como solucionar problemas de clusters do Autopilot.

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

Sobre o registro 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, ele precisa ser registrado no plano de controle do cluster. Esse processo, chamado de registro de nó ou inicialização de nó, ocorre quando um nó é criado.

Quando ocorre o registro do nó

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

O processo de registro de nós segue estas etapas:

  1. A contagem de nós definida para o pool de nós é replicada para os grupos gerenciados de instâncias (MIGs, na sigla em inglês).
  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 da VM é inicializada.
    2. A instância de VM configura e instala os pacotes necessários para execução como um nó do Kubernetes.
    3. O kubelet em execução na instância da VM se comunica com o servidor da API do plano de controle para se registrar como um nó.

Mensagem de erro de registro de nó

Quando o GKE tenta adicionar nós ao cluster, o seguinte erro aparece no Console do Google Cloud em caso de falha no registro do nó:

  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.

Essa mensagem de erro indica que os nós não foram registrados com êxito no cluster. As seções a seguir descrevem algumas das possíveis causas desse erro.

Pré-requisitos para o registro do nó

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

  • Conectividade de rede
  • Disponibilidade de recursos
  • Permissões da conta de serviço

Pré-requisitos para a criação da instância

Quando o GKE cria um nó para o cluster, a primeira etapa é criar uma nova instância de VM do Compute Engine.

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

Falha na criação da instância significa que, no intervalo de tempo em que o GKE tentou criar a instância para se registrar como um nó do GKE, há registros ausentes para criação de instância, já que as instâncias nunca foram criadas. Para verificar se há registros ausentes, consulte as instruções para encontrar uma instância que falhou no registro do nó.

Permissões da conta de serviço

Os nós do GKE têm uma conta de serviço do IAM associada a eles. Por padrão, essa conta de serviço é a conta de serviço padrão do Compute Engine. Recomendamos aumentar a proteção do cluster usando uma conta de serviço personalizada do IAM com as permissões mínimas necessárias.

Essa conta de serviço precisa ter as permissões corretas para que as instâncias de VM sejam inicializadas como nós do GKE. Se você excluir a conta de serviço, desativá-la ou não conceder as permissões corretas a ela, o registro do nó poderá falhar.

Pré-requisitos para conexão de rede com APIs e serviços do Google

A instância de VM faz o download de pacotes para se preparar para ser executado como um nó do GKE, e um tempo limite de conexão pode significar que seu cluster não atendeu aos requisitos de rede necessários para se conectar a APIs e serviços do Google, como storage.googleapis.com. Se uma instância não puder se conectar a esses serviços, ela não poderá fazer o download da distribuição do Kubernetes e concluir o processo de registro de nó.

Dependendo da sua conexão de rede, permitir essa conexão pode significar configurar o Acesso privado do Google ou ter regras de firewall e rotas em a rede de nuvem privada virtual (VPC) do cluster que permita a conexão.

Pré-requisitos para conexão de rede com o plano de controle

A conectividade entre o plano de controle e os nós é fundamental para o registro do nó e para a função normal. Essa comunicação é permitida por padrão. Ao estabelecer regras de firewall da VPC, garanta que a comunicação ainda seja permitida entre os nós e o plano de controle.

Para mais informações, consulte Permitir conectividade do plano de controle.

Usar o Verificador de registro do nó para resolver problemas de registro de nós

Para os pools de nós criados no GKE versão 1.24.0-gke.100 ou posterior, um utilitário chamado Verificador de registro de nós é executado em instâncias recém-criadas e verifica se a instância concluiu as etapas de registro do nó.

Quando o registro do nó falha, o utilitário gera um relatório de resumo em que é possível ver quais pré-requisitos não foram atendidos com base no local do processo em que a instância falhou.

Use as instruções na seção a seguir para encontrar uma instância com falha no registro do nó e use o resumo do Verificador de registro do nó para saber por que houve falha.

Se não for possível usar o Verificador de registro do nó no seu pool de nós, consulte Resolver problemas de registro de nó sem o Verificador de registro do nó.

Encontrar uma instância que falhou no registro do nó

Quando uma ou mais instâncias falham ao se registrar como nós no plano de controle do cluster do GKE, é possível ver o número de instâncias que falharam na mensagem de erro mostrada na Página "Detalhes do cluster" do console do Google Cloud. Quando várias instâncias não são registradas de uma vez, pode ser pelo mesmo motivo. Por isso, é possível usar uma das instâncias com falha para investigar por que todas elas falharam.

No entanto, como as instâncias não foram registradas como nós do GKE, use as instruções a seguir para encontrar os nomes das VMs subjacentes do Compute Engine que não foram registradas.

  1. No console do Google Cloud, acesse a página do Explorador de registros.

    Acessar o Explorador de registros

  2. Use o seguinte filtro para encontrar os registros de criação da instância de 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 cluster.

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

  4. Clique em um dos registros que aparecem em Resultados da consulta e em Expandir campos aninhados para ver mais detalhes.

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

    gke-cluster-1-default-pool-b0ac62d3-9g1v é uma instância do pool de nós default-pool em gke-cluster-1.

  6. No console do Google Cloud, acesse a página Instâncias de VM do Compute Engine.

    Acessar instâncias de VM

    Encontre o nome da instância de VM usando o filtro. Clique para ver mais detalhes.

Resolver problemas de uma instância com o Verificador de registro do nó

Depois de encontrar o nome da instância que não foi registrada, é possível investigar o motivo da falha usando o Verificador de registro do nó.

Na guia Detalhes da instância de VM, na seção Registros, clique em Porta serial 1 (console).

Para os pools de nós criados no GKE versão 1.24.0-gke.100 ou posterior, a saída para instâncias recém-criadas inclui o seguinte, indicando que o Verificador de registro do nó foi iniciado:

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

Se o registro do nó for bem-sucedido, a saída incluirá as seguintes mensagens:

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

Quando essas mensagens não são exibidas, isso significa que ocorreu uma falha no registro do nó, e o verificador de registros de nó gerou um relatório resumindo o motivo da falha no registro. Procure a seguinte mensagem adicional para ver o resumo:

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

Abaixo dessa mensagem, procure uma tabela semelhante a esta:

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

Se LOGGING, GCR ou GCS estiverem listados como inacessíveis, verifique as permissões da conta de serviço para registro de nós e a conexão de rede para APIs e serviços do Google para registro de nós.

Se Master estiver listado como não acessível, verifique os pré-requisitos para Conexão de rede com plano de controle para registro de nós.

Depois de resolver todos os problemas que impedem o registro do nó, consulte Concluir o registro do nó após corrigir a causa raiz.

Se as etapas anteriores não informarem o motivo da falha no registro do nó, consulte Coletar informações para mais investigações.

Resolver problemas no registro do nó sem o Verificador de registro do nó

Se o registro do nó falhar em um pool de nós criado em uma versão do GKE anterior à 1.24.0-gke.100, você só poderá solucionar problemas de registro de nó manualmente. Se o pool de nós tiver sido criado no GKE versão 1.24.0-gke.100 ou posterior, siga as instruções para Usar o Verificador de registro de nós para solucionar problemas de registro de nó.

Depois de resolver todos os problemas que impedem o registro do nó, use as instruções abaixo para concluir o registro do nó após corrigir a causa raiz.

Se nenhuma das etapas de investigação nesta página disser por que o registro do nó falhou, consulte Coletar informações para uma investigação mais detalhada.

Verificar as permissões da conta de serviço para o registro do nó

A conta de serviço usada pelos nós precisa ter as permissões de pré-requisito para o registro de nós. Use as instruções a seguir para verificar se você cumpriu esses pré-requisitos:

  1. Encontre uma instância que falhou no registro do nó.

  2. Na guia Detalhes da instância de VM, na seção API e gerenciamento de identidade, localize o nome da conta de serviço na Conta de serviço. . Se o nó tiver usado a conta de serviço padrão do Compute Engine, o nome seguirá o formato PROJECT_NUMBER-compute@developer.gserviceaccount.com. Essa conta de serviço precisa ter as permissões mínimas necessárias.

  3. Verifique se há indicadores de registro bem-sucedido na saída do console serial. Na guia Detalhes da instância de VM, na seção Registros, clique em Porta serial 1 (console).

    Se a instância tiver usado uma conta de serviço com as permissões corretas, a saída incluirá o seguinte:

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

    Essas mensagens serão encontradas em lugares diferentes nesta saída. Eles também podem ter carimbos de data/hora ou outros artefatos que os interrompam, como Starting [0;1;39mConfigure kubernetes node: Se você vir todas essas mensagens, significa que os pré-requisitos da conta de serviço foram atendidos.

    Quando essas mensagens não são exibidas, isso significa que a conta de serviço atribuída à instância de VM pode ter sido excluída, desativada ou não ter as permissões corretas.

Verificar a conexão da rede com as APIs e os serviços do Google para registro de nós

Verificar a conexão com o acesso SSH

Se você tiver acesso SSH a instâncias de VM no seu projeto, também poderá verificar se a instância da VM tem uma conexão de rede com APIs e serviços do Google.

  1. Encontre uma instância que falhou no registro do nó.

  2. Na guia Detalhes da instância de VM, clique em SSH.

  3. Depois de se conectar à linha de comando da instância de VM, execute o seguinte comando para verificar a conexão com as APIs e os serviços do Google:

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

    Se a operação for bem-sucedida, a saída será semelhante a esta:

    *   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 conexão não funcionar, a saída será semelhante a esta:

    *   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 conexão expirar e o endereço IP retornado estiver dentro do intervalo de endereços IP 199.36.153.0/24, verifique se o cluster atende aos requisitos de rede para se conectar ao Google APIs e serviços Se o tempo limite da conexão se esgotar e o endereço IP retornado não estiver dentro do intervalo de endereços IP mencionado, verifique se há regras de firewall que bloqueiam o tráfego de saída ou rotas configuradas incorretamente na rede VPC do cluster.

    Mantenha a conexão SSH com a instância de VM aberta e avance para a próxima seção.

Verificar a conexão sem acesso SSH usando o Testes de conectividade

Se você não tiver acesso SSH às instâncias de VM, use os Testes de conectividade para verificar se elas têm conexão com as APIs e os serviços do Google.

  1. Encontre uma instância que falhou no registro do nó.

  2. Crie e execute testes de conectividade 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.

Verificar a conexão da rede com o plano de controle para registro de nós

Se você tiver acesso SSH a instâncias de VM no seu projeto, será possível verificar se a instância da VM tem uma conexão de rede com o plano de controle do cluster.

  1. Encontre uma instância que falhou no registro do nó.

  2. Na guia Detalhes da instância de VM, clique em SSH.

  3. Depois de se conectar à linha de comando da instância de VM, salve o endpoint do plano de controle do cluster como uma variável de ambiente:

    source <(sudo grep KUBERNETES_MASTER_NAME /home/kubernetes/kube-env)
    
  4. Envie uma solicitação GET para o endpoint do plano de controle:

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

    Se a saída for semelhante a esta, a instância de VM poderá estabelecer uma conexão com o plano de controle:

    {
    "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 a esta, a instância de VM não poderá estabelecer uma conexão com o plano de controle:

    curl: (28) Connection timed out after 5000 milliseconds
    

Se a instância da VM não puder estabelecer uma conexão com o plano de controle, consulte a seção sobre como permitir a conectividade do plano de controle nas práticas recomendadas da rede do GKE.

Conclua o registro do nó após corrigir a causa raiz

Depois de resolver o problema que está bloqueando o registro do nó, a forma de prosseguir depende do contexto da falha:

  • Se o registro do nó falhar na criação do cluster, exclua o cluster e tente novamente.
  • Se o registro do nó falhar durante o escalonamento vertical com o escalonador automático de clusters, aguarde que as instâncias de VM tentem se registrar novamente.
  • Se o registro do nó falhar na criação do pool de nós:
    • Se as instâncias de VM foram criadas, aguarde as instâncias de VM tentarem o registro novamente.
    • Se as instâncias de VM não foram criadas, exclua o pool de nós e tente novamente.
  • Se o registro do nó falhar ao redimensionar o cluster, execute novamente o comando para aumentar o tamanho do cluster.
  • Se o registro do nó falhar fora do escopo de uma operação, como durante uma operação de reparo, aguarde as instâncias de VM tentarem o registro novamente.

Coletar informações para investigação mais detalhada

Se você não conseguir resolver o problema do registro de nós, colete mais informações para ajudar na investigação do Cloud Customer Care com as instruções a seguir. Estas etapas exigem acesso SSH a instâncias de VM no projeto e usam o utilitário sosreport, incluído nas imagens do COS.

  1. Encontre uma instância que falhou no registro do nó.

  2. Coletar informações de depuração usando o sosreport.

    Como alternativa, se o utilitário sosreport não tiver sido transferido por download para os nós e não for possível instalá-lo, colete informações de depuração manualmente executando os seguintes comandos:

    sudo journalctl -u cloud-init-local
    sudo journalctl -u cloud-init
    sudo journalctl -u cloud-final
    sudo journalctl -u cloud-config
    systemctl status kubelet
    journalctl -u kubelet
    systemctl status kube-node-installation.service
    systemctl status kube-node-configuration.service
    journalctl -u kube-node-installation.service --no-pager
    journalctl -u kube-node-configuration.service --no-pager
    journalctl -u kubelet.service --no-pager
    
  3. Empacote essas informações em um arquivo ZIP e inclua-as ao enviar um caso de suporte para o Cloud Customer Care.

A seguir

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