Resolver problemas de nós com o status "NotReady" no GKE

Um status NotReady no Google Kubernetes Engine (GKE) significa que o kubelet do nó não está se comunicando corretamente com o plano de controle. Como o Kubernetes não agenda novos pods em um nó NotReady, esse problema pode reduzir a capacidade do aplicativo e causar tempo de inatividade.

Use este documento para distinguir entre os status NotReady esperados e os problemas reais, diagnosticar a causa raiz e encontrar soluções para problemas comuns, como esgotamento de recursos, problemas de rede e falhas de tempo de execução do contêiner.

Estas informações são destinadas a administradores e operadores de plataforma responsáveis pela estabilidade do cluster e a desenvolvedores de aplicativos que querem entender o comportamento do aplicativo relacionado à infraestrutura. Para mais informações sobre as funções comuns e exemplos de tarefas que mencionamos no conteúdo do Google Cloud , consulte Funções e tarefas comuns do usuário do GKE.

Antes de começar

  • Para receber as permissões necessárias para realizar as tarefas neste documento, peça ao administrador para conceder a você os seguintes papéis do IAM no seu projeto Google Cloud :

    Para mais informações sobre a concessão de papéis, consulte Gerenciar o acesso a projetos, pastas e organizações.

    Também é possível conseguir as permissões necessárias usando papéis personalizados ou outros papéis predefinidos.

  • Configure a ferramenta de linha de comando kubectl para se comunicar com o cluster do GKE:

    gcloud container clusters get-credentials CLUSTER_NAME \
    --location LOCATION \
    --project PROJECT_ID

    Substitua:

    • CLUSTER_NAME: o nome do cluster.
    • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.
    • PROJECT_ID: o ID do projeto Google Cloud .

Verificar o status e as condições do nó

Para confirmar se um nó tem um status NotReady e ajudar a diagnosticar a causa raiz, siga estas etapas para inspecionar as condições, os eventos, os registros e as métricas de recursos de um nó:

  1. Confira o status dos seus nós. Para mais detalhes, como endereços IP e versões do kernel, que são úteis para diagnóstico, use a flag -o wide:

    kubectl get nodes -o wide

    O resultado será o seguinte:

    NAME                                STATUS     ROLES    AGE   VERSION               INTERNAL-IP  EXTERNAL-IP  OS-IMAGE                             KERNEL-VERSION   CONTAINER-RUNTIME
gke-cluster-pool-1-node-abc1        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.1   1.2.3.4      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-def2        Ready      <none>   94d   v1.32.3-gke.1785003   10.128.0.2   5.6.7.8      Container-Optimized OS from Google   6.6.72+          containerd://1.7.24
gke-cluster-pool-1-node-ghi3        NotReady   <none>   94d   v1.32.3-gke.1785003   10.128.0.3   9.10.11.12   Container-Optimized OS from Google   6.6.72+          containerd://1.7.24

    Na saída, procure nós com um valor de NotReady na coluna STATUS e anote os nomes deles.

  2. Confira mais informações sobre nós específicos com o status NotReady, incluindo as condições e os eventos recentes do Kubernetes:

    kubectl describe node NODE_NAME

    Substitua NODE_NAME pelo nome de um nó com o status NotReady.

    Na saída, concentre-se na seção Conditions para entender a integridade do nó e na seção Events para conferir um histórico de problemas recentes. Exemplo:

    Name:                   gke-cluster-pool-1-node-ghi3
...
Conditions:
Type                          Status    LastHeartbeatTime                 LastTransitionTime                Reason                   Message
----                          ------    -----------------                 ------------------                ------                   -------
NetworkUnavailable            False     Wed, 01 Oct 2025 10:29:19 +0100   Wed, 01 Oct 2025 10:29:19 +0100   RouteCreated             RouteController created a route
MemoryPressure                Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
DiskPressure                  Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
PIDPressure                   False     Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:29:00 +0100   KubeletHasSufficientPID  kubelet has sufficient PID available
Ready                         Unknown   Wed, 01 Oct 2025 10:31:06 +0100   Wed, 01 Oct 2025 10:31:51 +0100   NodeStatusUnknown        Kubelet stopped posting node status.
Events:
Type     Reason                   Age                  From                                   Message
----     ------                   ----                 ----                                   -------
Normal   Starting                 32m                  kubelet, gke-cluster-pool-1-node-ghi3  Starting kubelet.
Warning  PLEGIsNotHealthy         5m1s (x15 over 29m)  kubelet, gke-cluster-pool-1-node-ghi3  PLEG is not healthy: pleg was last seen active 5m1.123456789s ago; threshold is 3m0s
Normal   NodeHasSufficientMemory  5m1s (x16 over 31m)  kubelet, gke-cluster-pool-1-node-ghi3  Node gke-cluster-pool-1-node-ghi3 status is now: NodeHasSufficientMemory

    Na seção Conditions, um status True para qualquer condição negativa ou Unknown para a condição Ready indica um problema. Preste atenção aos campos Reason e Message dessas condições, porque eles explicam a causa do problema.

    Confira o que cada tipo de condição significa:

    • KernelDeadlock: True se o kernel do sistema operacional do nó tiver detectado um deadlock, que é um erro grave que pode congelar o nó.
    • FrequentUnregisterNetDevice: True se o nó estiver cancelando o registro dos dispositivos de rede com frequência, o que pode ser um sinal de problemas de driver ou hardware.
    • NetworkUnavailable: True se a rede do nó não estiver configurada corretamente.
    • OutOfDisk: True se o espaço disponível em disco estiver completamente esgotado. Essa condição é mais grave do que DiskPressure.
    • MemoryPressure: True se a memória do nó estiver baixa.
    • DiskPressure: True se o espaço em disco no nó estiver baixo.
    • PIDPressure: True se o nó estiver com exaustão de ID do processo (PID).
    • Ready: indica se o nó está íntegro e pronto para aceitar pods.
      • True se o nó estiver íntegro.
      • False se o nó não estiver íntegro e não aceitar pods.
      • Unknown se o controlador de nós não receber informações do nó por um período de carência (o padrão é de 50 segundos) e o status do nó for desconhecido.

    Em seguida, examine a seção Events, que fornece um registro cronológico de ações e observações sobre o nó. Essa linha do tempo é crucial para entender o que aconteceu imediatamente antes de o nó se tornar NotReady. Procure mensagens específicas que possam ajudar a encontrar a causa, como avisos de remoção (indicando pressão de recursos), falhas nas verificações de integridade ou eventos do ciclo de vida do nó, como isolamento para um reparo.

  3. Para saber por que os nós têm o status NotReady, consulte os registros do nó e dos componentes dele.

    1. Verifique os registros de kubelet para o status NotReady.

      O kubelet é o principal agente que informa o status do nó ao plano de controle. Portanto, os registros dele são o lugar mais provável para encontrar a mensagem literal NotReady. Esses registros são a fonte oficial para diagnosticar problemas com eventos do ciclo de vida do pod, condições de pressão de recursos (como MemoryPressure ou DiskPressure) e a conectividade do nó com o plano de controle do Kubernetes.

    2. No console do Google Cloud , acesse a página Análise de registros:

      Acessar a Análise de registros

    3. No painel de consulta, digite a seguinte consulta:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("kubelet")
textPayload=~"(?i)NotReady"

      Substitua:

      • NODE_NAME: o nome do nó que você está investigando.
      • CLUSTER_NAME: o nome do cluster.
      • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.

    4. Clique em Executar consulta e analise os resultados.

    5. Se os registros kubelet não revelarem a causa raiz, verifique os registros container-runtime e node-problem-detector. Esses componentes podem não registrar o status NotReady diretamente, mas geralmente registram o problema subjacente (como uma falha de tempo de execução ou um kernel panic) que causou o problema.

    6. No painel de consulta da Análise de registros, insira a seguinte consulta:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("COMPONENT_NAME")

      Substitua COMPONENT_NAME por um dos seguintes valores:

      • container-runtime: o ambiente de execução (containerd), responsável pelo ciclo de vida completo do contêiner, incluindo o pull de imagens e o gerenciamento da execução do contêiner. A análise dos registros do container-runtime é essencial para resolver falhas relacionadas à instanciação de contêineres, erros de serviço de execução ou problemas causados pela configuração do ambiente de execução.
      • node-problem-detector: um utilitário que monitora proativamente e informa vários problemas no nível do nó ao plano de controle. Os registros são essenciais para identificar problemas sistêmicos que podem causar instabilidade no nó, como deadlocks do kernel, corrupção do sistema de arquivos ou falhas de hardware, que podem não ser capturadas por outros componentes do Kubernetes.

    7. Clique em Executar consulta e analise os resultados.

  4. Use o Metrics Explorer para procurar exaustão de recursos por volta do momento em que o nó se tornou NotReady:

    1. No console Google Cloud , acesse a página do Metrics Explorer:

      Acessar o Metrics Explorer

    2. No Metrics Explorer, verifique se a instância do Compute Engine subjacente ao nó está com recursos esgotados. Concentre-se nas métricas relacionadas à CPU, à memória e à E/S do disco. Exemplo:

      • Métricas de nós do GKE: comece com métricas prefixadas com kubernetes.io/node/, como kubernetes.io/node/cpu/allocatable_utilization ou kubernetes.io/node/memory/allocatable_utilization. Essas métricas mostram quanto dos recursos disponíveis do nó está sendo usado pelos seus pods. O valor disponível não inclui os recursos que o Kubernetes reserva para sobrecarga do sistema.
      • Métricas do SO convidado: para uma visão de dentro do sistema operacional do nó, use métricas com o prefixo compute.googleapis.com/guest/, como compute.googleapis.com/guest/cpu/usage ou compute.googleapis.com/guest/memory/bytes_used.
      • Métricas do hipervisor: para conferir o desempenho da VM no nível do hipervisor, use métricas com o prefixo compute.googleapis.com/instance/, como compute.googleapis.com/instance/cpu/utilization ou métricas de E/S de disco, como compute.googleapis.com/instance/disk/read_bytes_count.

      Para as métricas do SO convidado e do hipervisor, é necessário filtrar pelo nome da instância do Compute Engine subjacente, não pelo nome do nó do Kubernetes. Para encontrar o nome da instância de um nó, execute o comando kubectl describe node NODE_NAME e procure o campo ProviderID na saída. O nome da instância é a última parte desse valor. Exemplo:

      ...
Spec:
ProviderID: gce://my-gcp-project-123/us-central1-a/gke-my-cluster-default-pool-1234abcd-5678
...

      Neste exemplo, o nome da instância é gke-my-cluster-default-pool-1234abcd-5678.

Identificar a causa por sintoma

Se você identificou um sintoma específico, como uma mensagem de log, uma condição de nó ou um evento de cluster, use a tabela a seguir para encontrar dicas de solução de problemas:

Categoria Sintoma ou mensagem de registro Possível causa Etapas da solução de problemas
Condições do nó NetworkUnavailable: True Problema de conectividade do nó com o plano de controle ou falha no plug-in da interface de rede de contêiner (CNI). Como solucionar problemas de conectividade de rede
MemoryPressure: True O nó não tem memória suficiente. Resolver problemas de falta de recursos do nó
DiskPressure: True O nó não tem espaço em disco suficiente. Resolver problemas de falta de recursos do nó
PIDPressure: True O nó não tem IDs de processo suficientes disponíveis. Resolver problemas de falta de recursos do nó
Eventos e mensagens de registro PLEG is not healthy O Kubelet está sobrecarregado devido ao alto uso de CPU/E/S ou ao grande número de pods. Resolver problemas do PLEG
Out of memory: Kill process
sys oom event		 A memória do nó está completamente esgotada. Resolver eventos de falta de memória no nível do sistema
leases.coordination.k8s.io...is forbidden O namespace kube-node-lease está travado no encerramento. Resolver problemas com o namespace kube-node-lease
Container runtime not ready
runtime is down
Erros que fazem referência a /run/containerd/containerd.sock ou docker.sock		 O serviço do Containerd ou do Docker falhou ou está configurado incorretamente. Resolver problemas do ambiente de execução do contêiner
Pods presos em Terminating
Os registros do kubelet mostram DeadlineExceeded para o contêiner de encerramento
Os registros do containerd mostram mensagens Kill container repetidas		 Processos presos em espera de disco não interrompível (estado D), geralmente relacionados a E/S. Resolver processos presos no estado D
Sintomas no nível do cluster Vários nós falham após um lançamento do DaemonSet. O DaemonSet está interferindo nas operações do nó. Resolver problemas causados por DaemonSets de terceiros
compute.instances.preempted nos registros de auditoria. A VM spot foi interrompida, o que é o comportamento esperado. Confirmar remoção forçada de nós
kube-system Pods travados em Pending. O webhook de admissão está bloqueando componentes críticos. Resolver problemas causados por webhooks de admissão
exceeded quota: gcp-critical-pods A cota mal configurada está bloqueando os pods do sistema. Resolver problemas causados por cotas de recursos

Verificar os eventos NotReady esperados

Um status NotReady nem sempre indica um problema. Esse é um comportamento esperado durante operações planejadas, como um upgrade de pool de nós, ou se você usa determinados tipos de máquinas virtuais.

Confirmar operações do ciclo de vida do nó

Sintomas:

Um nó mostra temporariamente um status NotReady durante determinados eventos do ciclo de vida.

Causa:

O status de um nó se torna NotReady temporariamente durante vários eventos comuns do ciclo de vida. Esse comportamento é esperado sempre que um nó é criado ou recriado, como nos seguintes cenários:

  • Upgrades do pool de nós: durante um upgrade, cada nó é esvaziado e substituído. O novo nó atualizado tem o status NotReady até que ele termine a inicialização e entre no cluster.
  • Reparo automático de nós: quando o GKE substitui um nó com falha, o nó de substituição permanece NotReady enquanto está sendo provisionado.
  • Aumento de escala do escalonador automático de cluster: quando novos nós são adicionados, eles começam em um status NotReady e se tornam Ready somente depois de serem totalmente provisionados e entrarem no cluster.
  • Mudanças manuais no modelo de instância: o GKE recria os nós quando você aplica mudanças no modelo. O novo nó tem um status NotReady durante a fase de inicialização.

Resolução:

Os nós só devem ter o status NotReady por um breve período. Se o status persistir por mais de 10 minutos, investigue outras causas.

Confirmar a remoção forçada do nó

Se o nó estiver sendo executado em uma VM do Spot ou em uma VM preemptiva, o Compute Engine poderá encerrá-lo abruptamente para recuperar recursos. Esse é o comportamento esperado para esses tipos de máquinas virtuais de curta duração e não é um erro.

Sintomas:

Se você observar os seguintes sintomas, é provável que o status NotReady do nó seja causado por uma preempção esperada da VM spot:

  • Um nó entra inesperadamente em um status NotReady antes de ser excluído e recriado pelo escalonador automático de cluster.
  • Os Registros de auditoria do Cloud mostram um evento compute.instances.preempted para a instância de VM subjacente.

Causa:

O nó estava sendo executado em uma instância de VM spot ou preemptiva, e o Compute Engine recuperou esses recursos de computação para outra tarefa. As VMs spot podem ser interrompidas a qualquer momento, mas geralmente fornecem um aviso de encerramento de 30 segundos.

Resolução:

Use VMs do Spot ou preemptivas apenas para cargas de trabalho tolerantes a falhas, sem estado ou em lote projetadas para lidar com encerramentos frequentes de maneira adequada. Para cargas de trabalho de produção ou com estado que não podem tolerar interrupções repentinas, provisione seus pools de nós usando VMs padrão sob demanda.

Resolver problemas de falta de recursos do nó

Um nó geralmente fica NotReady porque não tem recursos essenciais, como CPU, memória ou espaço em disco. Quando um nó não tem recursos suficientes, os componentes críticos não funcionam corretamente, o que causa instabilidade no aplicativo e falta de resposta do nó. As seções a seguir abordam as diferentes maneiras como essas escassez pode aparecer, desde condições gerais de pressão até eventos mais graves em todo o sistema.

Resolver a pressão de recursos do nó

O esgotamento de recursos ocorre quando um nó não tem CPU, memória, espaço em disco ou IDs de processo (PIDs) suficientes para executar as cargas de trabalho. Esse problema pode levar ao status NotReady.

Sintomas:

Se você observar as seguintes condições e registros de nós, o esgotamento de recursos será a causa provável do status NotReady do nó:

  • Na saída do comando kubectl describe node, você vai encontrar um status de True para condições como OutOfDisk, MemoryPressure, DiskPressure ou PIDPressure.
  • Os registros do kubelet podem conter eventos de falta de memória (OOM), indicando que o OOM Killer do sistema foi invocado.

Causa:

As cargas de trabalho no nó exigem coletivamente mais recursos do que o nó pode fornecer.

Resolução:

Para clusters padrão, tente as seguintes soluções:

Para clusters do Autopilot, não é possível controlar diretamente os tipos de máquinas de nós ou os tamanhos dos discos de inicialização. A capacidade do nó é gerenciada automaticamente com base nas solicitações do pod. Verifique se as solicitações de recursos da carga de trabalho estão dentro dos limites do Autopilot e refletem com precisão as necessidades do aplicativo. Problemas persistentes de recursos podem indicar a necessidade de otimizar as solicitações de pods ou, em casos raros, um problema na plataforma que exige assistência do Cloud Customer Care.

Resolver eventos de falta de memória no nível do sistema

Um evento de falta de memória (OOM) no nível do sistema ocorre quando a memória total de um nó é esgotada, forçando o kernel do Linux a encerrar processos para liberar recursos. Esse evento é diferente de um evento OOM no nível do contêiner, em que um único pod excede os limites de memória.

Sintomas:

Se você notar os seguintes sintomas, um evento OOM no nível do sistema é o provável motivo da instabilidade do nó:

  • Você vai notar a mensagem Out of memory: Kill process nos registros do console serial do nó.
  • Os registros do kubelet contêm eventos oom_watcher, que indicam que o kubelet detectou um evento OOM no nível do sistema.
  • Encerramento inesperado de vários processos, incluindo daemons do sistema ou pods de carga de trabalho potencialmente críticos, não necessariamente os maiores consumidores de memória.

Causa:

A memória geral do nó está esgotada. Esse problema pode ser causado por um bug em um serviço do sistema, uma carga de trabalho mal configurada que está consumindo uma quantidade excessiva de memória ou um nó muito pequeno para as demandas coletivas de memória de todos os pods em execução.

Resolução:

Para resolver eventos OOM no nível do sistema, diagnostique a causa e reduza a demanda de memória ou aumente a capacidade do nó. Para mais informações, consulte Resolver problemas de eventos de falta de memória.

Resolver problemas de PLEG

O gerador de eventos de ciclo de vida do pod (PLEG) é um componente do kubelet. Ele verifica periodicamente o estado de todos os contêineres no nó e informa quaisquer mudanças de volta ao kubelet.

Quando o PLEG tem problemas de desempenho, ele não consegue fornecer atualizações oportunas para o kubelet, o que pode causar instabilidade no nó.

Sintomas:

Se você observar os seguintes sintomas, talvez o PLEG não esteja funcionando corretamente:

  • Os registros do kubelet para o nó contêm uma mensagem semelhante a PLEG is not healthy.
  • O status do nó muda com frequência entre Ready e NotReady.

Causa:

Normalmente, os problemas do PLEG são causados por problemas de desempenho que impedem o kubelet de receber atualizações oportunas do tempo de execução do contêiner. Confira algumas causas comuns:

  • Carga alta da CPU: a CPU do nó está saturada, o que impede que o kubelet e o tempo de execução do contêiner tenham a capacidade de processamento necessária.
  • Limitação de E/S: o disco de inicialização do nó está passando por operações de E/S intensas, o que pode diminuir a velocidade de todas as tarefas relacionadas ao disco.
  • Excesso de pods: muitos pods em um único nó podem sobrecarregar o kubelet e o ambiente de execução do contêiner, causando disputa de recursos.

Resolução:

Para clusters padrão, reduza a pressão sobre os recursos do nó:

Para clusters do Autopilot, embora não seja possível mudar diretamente o tamanho ou o tipo de disco de um nó, é possível influenciar o hardware em que as cargas de trabalho são executadas usando ComputeClasses personalizadas. Com esse recurso, é possível especificar requisitos no manifesto da carga de trabalho, como uma quantidade mínima de CPU e memória ou uma série de máquinas específica, para orientar onde os pods são programados.

Se você não usar ComputeClasses, ajuste as implantações de carga de trabalho (como contagens de réplicas e solicitações ou limites de recursos) e verifique se elas estão dentro das restrições do Autopilot. Se os problemas do PLEG persistirem após a otimização das suas cargas de trabalho, entre em contato com Cloud Customer Care.

Resolver processos travados no estado D

Processos presos em um estado de espera ininterrupta do disco (D) podem fazer com que um nó pare de responder. Esse problema impede que os pods sejam encerrados e pode causar falhas em componentes críticos, como o containerd, resultando em um status NotReady.

Sintomas:

  • Os pods, especialmente aqueles que usam armazenamento de rede como NFS, ficam presos no status Terminating por muito tempo.
  • Os registros do Kubelet mostram erros DeadlineExceeded ao tentar interromper um contêiner.
  • Os registros do console serial do nó podem mostrar mensagens do kernel sobre hung tasks ou tarefas bloqueadas por mais de 120 segundos.

Causa:

Os processos entram em um estado D quando estão aguardando a conclusão de uma operação de E/S e não podem ser interrompidos. Algumas causas comuns:

  • Sistemas de arquivos remotos lentos ou sem resposta, como um compartilhamento NFS mal configurado ou sobrecarregado.
  • Degradação grave do desempenho do disco ou erros de E/S de hardware nos discos locais do nó.

Resolução:

Para resolver problemas com processos no estado D, identifique a origem de E/S e limpe o estado selecionando uma das seguintes opções:

Clusters padrão

  1. Encontre o processo travado e determine o que ele está aguardando:

    1. Conecte-se ao nó afetado usando SSH:

      gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

      Substitua:

      • NODE_NAME: o nome do nó a ser conectado.
      • ZONE: a zona do Compute Engine do nó.
      • PROJECT_ID: o ID do projeto.

    2. Encontre processos no estado D:

      ps -eo state,pid,comm,wchan | grep '^D'

      O resultado será o seguinte:

      D  12345  my-app      nfs_wait
D  54321  data-writer io_schedule

      A saída não terá um cabeçalho. As colunas, em ordem, representam:

      • Estado
      • ID do processo (PID)
      • Comando
      • Canal de espera (wchan)

    3. Analise a coluna wchan para identificar a origem de E/S:

      • Se a coluna wchan incluir termos como nfs ou rpc, o processo estará aguardando um compartilhamento NFS.
      • Se a coluna wchan incluir termos como io_schedule, jbd2 ou ext4, o processo estará aguardando o disco de inicialização local do nó.

    4. Para mais detalhes sobre quais funções do kernel o processo está aguardando, verifique a pilha de chamadas do kernel do processo:

      cat /proc/PID/stack

      Substitua PID pelo ID do processo que você encontrou na etapa anterior.

  2. Reinicie o nó. A reinicialização costuma ser a maneira mais eficaz de limpar um processo preso em um estado D.

    1. Drene o nó.
    2. Exclua a instância de VM subjacente. Normalmente, o GKE cria uma nova VM para substituir a anterior.

  3. Depois de resolver o problema imediato, investigue o sistema de armazenamento para evitar que ele aconteça de novo.

    • Para problemas de armazenamento em rede (NFS): use as ferramentas de monitoramento do provedor de armazenamento para verificar alta latência, erros do lado do servidor ou problemas de rede entre o nó do GKE e o servidor NFS.

    • Para problemas com disco local: verifique se há limitação de E/S no Cloud Monitoring. Para isso, consulte as métricas compute.googleapis.com/instance/disk/throttled_read_ops_count e compute.googleapis.com/instance/disk/throttled_write_ops_count da instância do Compute Engine.

Clusters do Autopilot

  1. Tente identificar a origem do bloqueio:

    O acesso SSH direto aos nós e a execução de comandos como ps ou cat /proc não estão disponíveis em clusters do Autopilot. É preciso usar registros e métricas.

    1. Verifique os registros do nó: no Cloud Logging, analise os registros do nó afetado. Filtre pelo nome do nó e pelo período do problema. Procure mensagens do kernel que indiquem erros de E/S, tempos limite de armazenamento (por exemplo, para disco ou NFS) ou mensagens de drivers CSI.
    2. Verifique os registros da carga de trabalho: examine os registros dos pods em execução no nó afetado. Os registros de aplicativos podem revelar erros relacionados a operações de arquivos, chamadas de banco de dados ou acesso ao armazenamento de rede.
    3. Use o Cloud Monitoring: embora não seja possível receber detalhes no nível do processo, verifique se há problemas de E/S no nível do nó.

  2. Acione uma substituição de nó para limpar o estado.

    Não é possível excluir manualmente a VM subjacente. Para acionar uma substituição, drene o nó. Essa ação isola o nó e remove os pods.

    O GKE detecta automaticamente nós não íntegros e inicia reparos, geralmente substituindo a VM subjacente.

    Se o nó continuar preso após o esgotamento e não for substituído automaticamente, entre em contato com o Cloud Customer Care.

  3. Depois de resolver o problema imediato, investigue o sistema de armazenamento para evitar que ele aconteça de novo.

    • Para problemas de disco local: verifique se há limitação de E/S no Cloud Monitoring visualizando as métricas compute.googleapis.com/instance/disk/throttled_read_ops_count e compute.googleapis.com/instance/disk/throttled_write_ops_count. É possível filtrar essas métricas para o grupo de instâncias subjacente do pool de nós, embora as instâncias individuais sejam gerenciadas pelo Google.
    • Para problemas de armazenamento em rede (NFS): use as ferramentas de monitoramento do provedor de armazenamento para verificar alta latência, erros do lado do servidor ou problemas de rede entre o nó do GKE e o servidor NFS. Verifique os registros de todos os pods de driver CSI no Cloud Logging.

Resolver problemas de falhas de componentes principais

Depois de descartar causas esperadas e falta de recursos, o software do nó ou um mecanismo principal do Kubernetes pode ser a causa do problema. Um status NotReady pode ocorrer quando um componente crítico, como o ambiente de execução de contêiner, falha. Isso também pode acontecer quando um mecanismo principal de verificação de integridade do Kubernetes, como o sistema de concessão de nós, falha.

Resolver problemas do ambiente de execução do contêiner

Problemas com o ambiente de execução do contêiner, como o containerd, podem impedir que o kubelet inicie pods em um nó.

Sintomas:

Se você observar as seguintes mensagens nos registros do kubelet, um problema de runtime de contêiner será a causa provável do status NotReady do nó:

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Erros ao se conectar ao soquete de tempo de execução (por exemplo, unix:///var/run/docker.sock ou unix:///run/containerd/containerd.sock).

Causa:

O ambiente de execução do contêiner não está funcionando corretamente, está mal configurado ou preso em um loop de reinicialização.

Resolução:

Para resolver problemas de tempo de execução do contêiner, faça o seguinte:

  1. Analisar registros de ambiente de execução de contêineres:

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

      Acessar a Análise de registros

    2. Para conferir todos os registros de aviso e erro do tempo de execução do contêiner no nó afetado, insira o seguinte no painel de consultas:

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
severity>=WARNING

      Substitua:

      • NODE_NAME: o nome do nó que você está investigando.
      • CLUSTER_NAME: o nome do cluster.
      • LOCATION: a região ou zona do Compute Engine (por exemplo, us-central1 ou us-central1-a) do cluster.

    3. Clique em Executar consulta e analise a saída para encontrar mensagens de erro específicas que indicam por que o tempo de execução falhou. Uma mensagem como failed to load TOML nos registros containerd do Cloud Logging geralmente indica um arquivo malformado.

    4. Para verificar se o ambiente de execução está preso em um loop de reinicialização, execute uma consulta que pesquise mensagens de inicialização. Um grande número dessas mensagens em um curto período confirma reinicializações frequentes.

      resource.type="k8s_node"
resource.labels.node_name="NODE_NAME"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
log_id("container-runtime")
("starting containerd" OR "Containerd cri plugin version" OR "serving..."
OR "loading plugin" OR "containerd successfully booted")

      Reinicializações frequentes geralmente indicam um problema subjacente, como um arquivo de configuração corrompido ou pressão de recursos, que está causando falhas repetidas no serviço.

  2. Revise a configuração containerd para modificações: configurações incorretas podem causar falha no tempo de execução do contêiner. É possível fazer mudanças de configuração usando um arquivo de configuração do sistema de nós ou modificações diretas feitas por cargas de trabalho com privilégios elevados.

    1. Determine se o pool de nós usa um arquivo de configuração do sistema de nós:

      gcloud container node-pools describe NODE_POOL_NAME \
    --cluster CLUSTER_NAME \
    --location LOCATION \
    --format="yaml(config.containerdConfig)"

      Substitua:

      • NODE_POOL_NAME: o nome do pool de nós.
      • CLUSTER_NAME: o nome do cluster.
      • LOCATION: a região ou zona do Compute Engine do cluster.

      Se a saída mostrar uma seção containerdConfig, o GKE estará gerenciando essas configurações personalizadas. Para modificar ou reverter as configurações, siga as instruções em Personalizar a configuração do containerd em nós do GKE.

    2. Se as personalizações gerenciadas pelo GKE não estiverem ativas ou se você suspeitar de outras mudanças, procure cargas de trabalho que possam estar modificando o sistema de arquivos do nó diretamente. Procure DaemonSets com permissões elevadas (securityContext.privileged: true) ou volumes hostPath que montam diretórios sensíveis, como /etc.

      Para inspecionar a configuração deles, liste todos os DaemonSets no formato YAML:

      kubectl get daemonsets --all-namespaces -o yaml

      Analise a saída e inspecione os registros de DaemonSets suspeitos.

    3. Para clusters padrão, inspecione o arquivo de configuração diretamente. O acesso SSH e a inspeção manual de arquivos não são possíveis em clusters do Autopilot porque o Google gerencia a configuração de tempo de execução. Informe problemas de execução persistentes ao Google Cloud Customer Care.

      Se você usa um cluster Standard, inspecione o arquivo:

      1. Conecte-se ao nó usando SSH:

        gcloud compute ssh NODE_NAME \
    --zone ZONE \
    --project PROJECT_ID

        Substitua:

        • NODE_NAME: o nome do nó a ser conectado.
        • ZONE: a zona do Compute Engine do nó.
        • PROJECT_ID: o ID do projeto.

      2. Mostre o conteúdo do arquivo de configuração do containerd:

        sudo cat /etc/containerd/config.toml

      3. Para verificar modificações recentes, liste os detalhes do arquivo:

        ls -l /etc/containerd/config.toml

    4. Compare o conteúdo desse arquivo com a saída do containerdConfig do comando gcloud node-pools describe executado na etapa anterior. Qualquer configuração em /etc/containerd/config.toml que não esteja na saída de gcloud é uma mudança não gerenciada.

    5. Para corrigir qualquer configuração incorreta, remova as mudanças que não foram aplicadas por uma configuração do sistema de nós.

  3. Solucionar problemas comuns de ambiente de execução: para mais etapas de solução de problemas, consulte Solução de problemas do ambiente de execução do contêiner.

Resolver problemas com o namespace kube-node-lease

Os recursos no namespace kube-node-lease são responsáveis por manter a integridade do nó. Esse namespace não deve ser excluído. As tentativas de excluir esse namespace resultam em um namespace travado no status Terminating. Quando o namespace kube-node-lease fica preso em um status Terminating, os kubelets não podem renovar os contratos de locação de verificação de integridade. Esse problema faz com que o plano de controle considere os nós como não íntegros, levando a um problema em todo o cluster em que os nós alternam entre os status Ready e NotReady.

Sintomas:

Se você observar os seguintes sintomas, um problema com o namespace kube-node-lease é a causa provável da instabilidade em todo o cluster:

  • Os registros do kubelet em todos os nós mostram erros persistentes semelhantes a estes:

    leases.coordination.k8s.io NODE_NAME is forbidden: unable to create new content in namespace kube-node-lease because it is being terminated

  • Os nós do cluster alternam repetidamente entre os status Ready e NotReady.

Causa:

O namespace kube-node-lease, que gerencia heartbeats de nós, está travado de forma anormal no status Terminating. Esse erro impede que o servidor da API Kubernetes permita a criação ou modificação de objetos no namespace. Como resultado, os kubelets não podem renovar os objetos Lease, que são essenciais para sinalizar a atividade deles ao plano de controle. Sem essas atualizações de status, o plano de controle não pode confirmar se os nós estão íntegros, o que faz com que os status dos nós alternem entre Ready e NotReady.

Os motivos para o namespace kube-node-lease ficar preso no status Terminating incluem:

  • Recursos com finalizadores: embora menos comum para o namespace kube-node-lease do sistema (que contém principalmente objetos Lease), um recurso nele pode ter um finalizador. Os finalizadores do Kubernetes são chaves que indicam que um controlador precisa realizar tarefas de limpeza antes que um recurso possa ser excluído. Se o controlador responsável por remover o finalizador não estiver funcionando corretamente, o recurso não será excluído, e o processo de exclusão do namespace será interrompido.
  • Serviços de API agregados não íntegros ou sem resposta: o encerramento do namespace pode ser bloqueado se um objeto APIService, usado para registrar um servidor de API agregada, estiver vinculado ao namespace e ficar não íntegro. O plano de controle pode esperar que o servidor de API agregado seja desligado ou limpo corretamente, o que não vai acontecer se o serviço não responder.
  • Problemas no plano de controle ou no controlador: em casos raros, bugs ou problemas no plano de controle do Kubernetes, especificamente no controlador de namespace, podem impedir a coleta de lixo e a exclusão do namespace.

Resolução:

Siga as orientações em Resolver problemas de namespaces travados no estado de encerramento.

como resolver problemas de conectividade de rede

Problemas de rede podem impedir que um nó se comunique com o plano de controle ou impedir que componentes críticos, como o plug-in CNI, funcionem, resultando em um status NotReady.

Sintomas:

Se você observar os seguintes sintomas, os problemas de rede podem ser a causa do status NotReady dos nós:

  • A condição NetworkNotReady é True.
  • Os registros do kubelet no nó mostram erros semelhantes a estes:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • Mensagens connection refused ou timeout ao tentar acessar o endereço IP do plano de controle.
  • Os pods, principalmente no namespace kube-system, ficam presos em ContainerCreating com eventos como NetworkPluginNotReady.

Causa:

Os sintomas relacionados à rede geralmente indicam uma falha em uma das seguintes áreas:

  • Problemas de conectividade: o nó não consegue estabelecer uma conexão de rede estável com o plano de controle do Kubernetes.
  • Falha no plug-in CNI: o plug-in CNI, responsável por configurar a rede de pods, não está sendo executado corretamente ou não foi inicializado.
  • Problemas de webhook: webhooks de admissão configurados incorretamente podem interferir nos recursos relacionados ao plug-in CNI, impedindo que a rede seja configurada corretamente.

Resolução:

Para resolver problemas de rede, faça o seguinte:

  1. Resolver o status NetworkNotReady temporário: em nós recém-criados, é normal ver um evento NetworkNotReady breve. Esse status deve ser resolvido em um ou dois minutos enquanto o plug-in da CNI e outros componentes são inicializados. Se o status persistir, siga as etapas abaixo.

  2. Verifique a conectividade entre o nó e o plano de controle e as regras de firewall: confira se o caminho de rede entre o nó e o plano de controle está aberto e funcionando corretamente:

    1. Verifique as regras de firewall: confira se as regras de firewall da VPC permitem o tráfego necessário entre os nós do GKE e o plano de controle. Para informações sobre as regras que o GKE exige para a comunicação do nó com o plano de controle, consulte Regras de firewall criadas automaticamente.
    2. Testar a conectividade: use o Teste de conectividade no Network Intelligence Center para verificar o caminho de rede entre o endereço IP interno do nó e o endereço IP do endpoint do plano de controle na porta 443. Um resultado de Not Reachable geralmente ajuda a identificar a regra de firewall ou o problema de roteamento que está bloqueando a comunicação.

  3. Investigue o status e os registros do plug-in CNI: se a rede do nó não estiver pronta, o problema pode estar no plug-in CNI.

    1. Verifique o status do pod da CNI: identifique o plug-in da CNI em uso (por exemplo, netd ou calico-node) e verifique o status dos pods no namespace kube-system. É possível filtrar o nó específico com o seguinte comando:

      kubectl get pods \
    -n kube-system \
    -o wide \
    --field-selector spec.nodeName=NODE_NAME \
    | grep -E "netd|calico|anetd"

    2. Examine os registros do pod da CNI: se os pods não estiverem funcionando corretamente, examine os registros deles no Cloud Logging para ver mensagens de erro detalhadas. Use uma consulta semelhante à seguinte para pods netd em um nó específico:

      resource.type="k8s_container"
resource.labels.cluster_name="CLUSTER_NAME"
resource.labels.location="LOCATION"
resource.labels.namespace_name="kube-system"
labels."k8s-pod/app"="netd"
resource.labels.node_name="NODE_NAME"
severity>=WARNING

    3. Resolver erros específicos da CNI:

      • Se os registros mostrarem Failed to allocate IP address, os intervalos de endereços IP do pod poderão estar esgotados. Verifique a utilização de endereços IP do pod e analise os intervalos CIDR do cluster.
      • Se os registros mostrarem NetworkPluginNotReady ou cni plugin not initialized, confirme se o nó tem recursos suficientes de CPU e memória. Você também pode tentar reiniciar o pod da CNI excluindo-o, o que permite que o DaemonSet o recrie.
      • Se você usa o GKE Dataplane V2 e os registros mostram Cilium API client timeout exceeded, reinicie o pod anetd no nó.

    4. Verifique se há interferência do webhook de admissão: webhooks com falhas podem impedir que os pods da CNI sejam iniciados, deixando o nó em um status NetworkNotReady.

    5. Verifique os registros do servidor da API: analise os registros do servidor da API no Cloud Logging para encontrar erros relacionados a chamadas de webhook. Para identificar se um webhook está bloqueando a criação de recursos da CNI, pesquise mensagens como failed calling webhook.

      Se um webhook estiver causando problemas, talvez seja necessário identificar o ValidatingWebhookConfiguration ou MutatingWebhookConfiguration problemático e desativá-lo temporariamente para que o nó fique pronto. Para mais informações, consulte Resolver problemas causados por webhooks de admissão.

Resolver problemas de configurações incorretas do cluster

As seções a seguir ajudam você a auditar algumas configurações em todo o cluster que podem estar interferindo nas operações normais do nó.

Resolver problemas causados por webhooks de admissão

Um webhook de admissão mal configurado, indisponível ou muito lento pode bloquear solicitações de API críticas, impedindo que componentes essenciais sejam iniciados ou que nós entrem no cluster.

Sintomas:

Se você observar os seguintes sintomas, é provável que um webhook de admissão mal configurado ou indisponível esteja bloqueando operações essenciais do cluster:

  • Os pods, especialmente no namespace kube-system (como pods de CNI ou de armazenamento), estão presos em um status Pending ou Terminating.
  • Novos nós não conseguem entrar no cluster, geralmente excedendo o tempo limite com um status NotReady.

Causa:

Webhooks de admissão mal configurados ou sem resposta podem estar bloqueando operações essenciais do cluster.

Resolução:

Revise as configurações de webhook para garantir que elas sejam resilientes e tenham o escopo adequado. Para evitar interrupções, defina o campo failurePolicy como Ignore para webhooks não críticos. Para webhooks críticos, verifique se o serviço de suporte tem alta disponibilidade e exclua o namespace kube-system da supervisão de webhook usando um namespaceSelector para evitar impasses no plano de controle. Para mais informações, consulte Garantir a estabilidade do plano de controle ao usar webhooks.

Resolver problemas causados por cotas de recursos

Uma cota de recursos calculada incorretamente no namespace kube-system pode impedir que o GKE crie pods de sistema críticos. Como componentes como rede (CNI) e DNS são bloqueados, esse problema pode impedir que novos nós entrem no cluster.

Sintomas:

  • Os pods críticos no namespace kube-system (por exemplo, netd, konnectivity-agent ou kube-dns) estão presos em um status Pending.
  • As mensagens de erro nos registros do cluster ou na saída kubectl describe pod mostram falhas como exceeded quota: gcp-critical-pods.

Causa:

Esse problema ocorre quando o controlador de cota de recursos do Kubernetes para de atualizar com precisão a contagem usada em objetos ResourceQuota. Uma causa comum é um webhook de admissão de terceiros com mau funcionamento que bloqueia as atualizações do controlador, fazendo com que o uso da cota pareça muito maior do que realmente é.

Resolução:

  1. Como um webhook problemático é a causa raiz mais provável, siga as orientações na seção Resolver problemas causados por webhooks de admissão para identificar e corrigir os webhooks que podem estar bloqueando componentes do sistema. A correção do webhook geralmente resolve o problema de cota automaticamente.

  2. Verifique se o uso registrado da cota está dessincronizado com o número real de pods em execução. Esta etapa confirma se a contagem do objeto ResourceQuota está incorreta:

    1. Verifique o uso informado da cota:

      kubectl get resourcequota gcp-critical-pods -n kube-system -o yaml

    2. Verifique o número real de pods:

      kubectl get pods -n kube-system --no-headers | wc -l

  3. Se a contagem usada em ResourceQuota parecer incorreta (por exemplo, muito maior do que o número real de pods), exclua o objeto gcp-critical-pods. O plano de controle do GKE foi projetado para recriar automaticamente esse objeto com as contagens de uso corretas e reconciliadas:

    kubectl delete resourcequota gcp-critical-pods -n kube-system

  4. Monitore o namespace kube-system por alguns minutos para garantir que o objeto seja recriado e que os pods pendentes comecem a ser programados.

Resolver problemas causados por DaemonSets de terceiros

Um DaemonSet de terceiros recém-implantado ou atualizado, que geralmente é usado para segurança, monitoramento ou registro, às vezes pode causar instabilidade no nó. Esse problema pode ocorrer se o DaemonSet interferir no tempo de execução do contêiner ou na rede do nó, consumir recursos excessivos do sistema ou fazer modificações inesperadas no sistema.

Sintomas:

Se você observar os seguintes sintomas, um DaemonSet de terceiros implantado ou modificado recentemente pode ser a causa das falhas de nós:

  • Vários nós, possivelmente em todo o cluster, entram em um status NotReady logo após a implantação ou atualização do DaemonSet.
  • Os registros do kubelet para nós afetados informam erros como estes:
    • container runtime is down
    • Failed to create pod sandbox
    • Erros ao se conectar ao soquete do ambiente de execução do contêiner (por exemplo, /run/containerd/containerd.sock).
  • Os pods, incluindo pods do sistema ou os próprios pods do DaemonSet, estão parados nos estados PodInitializing ou ContainerCreating.
  • Os registros de contêineres para aplicativos mostram erros incomuns, como exec format error.
  • O detector de problemas do nó pode informar condições relacionadas à integridade do tempo de execução ou à pressão de recursos.

Causa:

O DaemonSet de terceiros pode afetar a estabilidade do nó pelos seguintes motivos:

  • Consumir CPU, memória ou E/S de disco em excesso, o que afeta o desempenho de componentes críticos do nó.
  • Interferir na operação do ambiente de execução do contêiner.
  • Causando conflitos com a configuração de rede do nó ou o plug-in da interface de rede de contêiner (CNI).
  • Alterar configurações do sistema ou políticas de segurança de maneira não intencional.

Resolução:

Para determinar se um DaemonSet é a causa, isole e teste:

  1. Identifique os DaemonSets: liste todos os DaemonSets em execução no cluster:

    kubectl get daemonsets --all-namespaces

    Preste atenção aos DaemonSets que não fazem parte da instalação padrão do GKE.

    Muitas vezes, é possível identificar esses DaemonSets revisando o seguinte:

    • Namespace: os componentes padrão do GKE geralmente são executados no namespace kube-system. DaemonSets em outros namespaces provavelmente são de terceiros ou personalizados.
    • Nomenclatura: os DaemonSets padrão geralmente têm nomes como gke-metrics-agent, netd ou calico-node. Os agentes de terceiros geralmente têm nomes que refletem o produto.

  2. Correlacionar o tempo de implantação: verifique se o aparecimento de nós NotReady coincide com a implantação ou atualização de um DaemonSet específico de terceiros.

  3. Teste em um único nó:

    1. Escolha um nó afetado.
    2. Restrinja e drene o nó.
    3. Impeça temporariamente que o DaemonSet seja programado nesse nó:
      • Aplique um rótulo de nó temporário e configure a afinidade ou antiafinidade de nó no manifesto do DaemonSet.
      • Exclua o pod do DaemonSet nesse nó específico.
    4. Reinicie a instância de máquina virtual do nó.
    5. Observe se o nó fica Ready e permanece estável enquanto o DaemonSet não está em execução nele. Se os problemas reaparecerem depois que o DaemonSet for reintroduzido, é provável que ele seja um fator contribuinte.

  4. Consulte o fornecedor: se você suspeitar que um agente de terceiros é a causa, consulte a documentação do fornecedor para problemas de compatibilidade conhecidos ou práticas recomendadas para executar o agente no GKE. Se precisar de mais ajuda, entre em contato com o fornecedor do software.

Verificar se o nó foi recuperado

Depois de aplicar uma possível solução, siga estas etapas para verificar se o nó foi recuperado e está estável:

  1. Verifique o status do nó:

    kubectl get nodes -o wide

    Procure o nó afetado na saída. A coluna Status agora vai mostrar um valor de Ready. O status pode levar alguns minutos para ser atualizado depois que a correção for aplicada. Se o status ainda mostrar NotReady ou estiver alternando entre status, o problema não foi totalmente resolvido.

  2. Inspecione a seção Conditions do nó:

    kubectl describe node NODE_NAME

    Na seção Conditions, verifique os seguintes valores:

    • A condição Ready tem um status de True.
    • As condições negativas que antes tinham o status True (por exemplo, MemoryPressure ou NetworkUnavailable) agora têm o status False. Os campos Reason e Message para essas condições precisam indicar que o problema foi resolvido.

  3. Teste o agendamento de pods. Se o nó não conseguia executar cargas de trabalho antes, verifique se novos pods estão sendo programados nele e se os pods atuais estão sendo executados sem problemas:

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

    Os pods no nó precisam ter um status Running ou Completed. Não é recomendável que os pods fiquem presos no status Pending ou em outros estados de erro.

A seguir

  • Se você não encontrar uma solução para seu problema na documentação, consulte Receber suporte para mais ajuda, incluindo conselhos sobre os seguintes tópicos: