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:
- Crie um cluster.
- Crie um pool de nós.
- O GKE cria um pool de nós com provisionamento automático de nós.
- O escalonador automático de clusters faz o escalonamento vertical do cluster.
- Você redimensiona o cluster.
- O reparo automático de nós cria um novo nó.
O processo de registro de nós segue estas etapas:
- 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).
- Os MIGs criam o número necessário de instâncias de VM.
Para cada instância de VM criada:
- A instância da VM é inicializada.
- A instância de VM configura e instala os pacotes necessários para execução como um nó do Kubernetes.
- 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.
No console do Google Cloud, acesse a página do Explorador de registros.
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_IDpelo ID do projeto do cluster.Use o histograma abaixo do filtro de registro para restringir o intervalo de tempo em que a criação do nó deveria ter ocorrido.
Clique em um dos registros que aparecem em Resultados da consulta e em Expandir campos aninhados para ver mais detalhes.
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ósdefault-poolemgke-cluster-1.No console do Google Cloud, acesse a página Instâncias de VM do Compute Engine.
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:
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.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 configurationsStarted 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.
Na guia Detalhes da instância de VM, clique em SSH.
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_204Se 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 intactSe 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.
Crie e execute testes de conectividade com a instância de VM como Origem e
storage.googleapis.com TCP/443como 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.
Na guia Detalhes da instância de VM, clique em SSH.
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)Envie uma solicitação
GETpara o endpoint do plano de controle:curl -k -m 5 https://${KUBERNETES_MASTER_NAME}/versionSe 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.
Coletar informações de depuração usando o sosreport.
Como alternativa, se o utilitário
sosreportnã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-pagerEmpacote essas informações em um arquivo ZIP e inclua-as ao enviar um caso de suporte para o Cloud Customer Care.