Resolva problemas com nós com o estado NotReady no GKE

Um estado NotReady no Google Kubernetes Engine (GKE) significa que o kubelet do nó não está a comunicar corretamente com o plano de controlo. Uma vez que o Kubernetes não agenda novos pods num nó NotReady, este problema pode reduzir a capacidade da aplicação e causar tempo de inatividade.

Use este documento para distinguir entre os estados NotReadyesperados e os problemas reais, diagnosticar a causa principal e encontrar resoluções para problemas comuns, como o esgotamento de recursos, problemas de rede e falhas de tempo de execução do contentor.

Estas informações destinam-se aos administradores e operadores da plataforma responsáveis pela estabilidade do cluster e aos programadores de aplicações que procuram compreender o comportamento das aplicações relacionadas com a infraestrutura. Para mais informações sobre as funções comuns e as tarefas de exemplo que referimos no conteúdo, consulte o artigo Funções de utilizador comuns do GKE e tarefas. Google Cloud

Antes de começar

  • Para receber as autorizações de que precisa para realizar as tarefas neste documento, peça ao seu administrador para lhe conceder as seguintes funções de IAM no seu Google Cloud projeto:

    Para mais informações sobre a atribuição de funções, consulte o artigo Faça a gestão do acesso a projetos, pastas e organizações.

    Também pode conseguir as autorizações necessárias através de funções personalizadas ou outras funções predefinidas.

  • Configure a ferramenta de linhas de comando kubectl para comunicar com o seu cluster do GKE:

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

    Substitua o seguinte:

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

Verifique o estado e as condições do nó

Para confirmar que um nó tem o estado NotReady e ajudar a diagnosticar a causa principal, siga estes passos para inspecionar as condições, os eventos, os registos e as métricas de recursos de um nó:

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

    kubectl get nodes -o wide

    O resultado é semelhante ao 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

    No resultado, procure nós com um valor de NotReady na coluna STATUS e tome nota dos respetivos nomes.

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

    kubectl describe node NODE_NAME

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

    No resultado, foque-se na secção Conditions para compreender o estado do nó e na secção Events para ver um histórico de problemas recentes. Por 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 secção Conditions, um estado de True para qualquer condição negativa ou Unknown para a condição Ready indica um problema. Preste muita atenção aos campos Reason e Message para estas condições, uma vez que explicam a causa do problema.

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

    • KernelDeadlock: True se o kernel do sistema operativo do nó tiver detetado um impasse, que é um erro grave que pode bloquear o nó.
    • FrequentUnregisterNetDevice: True se o nó estiver a anular frequentemente o registo dos respetivos dispositivos de rede, o que pode ser um sinal de problemas de controlador ou de hardware.
    • NetworkUnavailable: True se a rede do nó não estiver configurada corretamente.
    • OutOfDisk: True se o espaço em disco disponível estiver completamente esgotado. Esta condição é mais grave do que DiskPressure.
    • MemoryPressure: True se a memória do nó for baixa.
    • DiskPressure: True se o espaço em disco no nó for baixo.
    • PIDPressure: True se o nó estiver a sofrer esgotamento do ID do processo (PID).
    • Ready: indica se o nó está em bom estado e pronto para aceitar Pods.
      • True se o nó estiver em bom estado.
      • False se o nó não estiver em bom estado e não estiver a aceitar pods.
      • Unknown se o controlador do nó não tiver recebido informações do nó durante um período de tolerância (a predefinição é de 50 segundos) e o estado do nó for desconhecido.

    Em seguida, examine a secção Events, que fornece um registo cronológico de ações e observações sobre o nó. Esta cronologia é fundamental para compreender o que aconteceu imediatamente antes de o nó ficar NotReady. Procure mensagens específicas que possam ajudar a encontrar a causa, como avisos de despejo (que indicam pressão sobre os recursos), verificações de estado com falhas ou eventos do ciclo de vida dos nós, como isolamento para uma reparação.

  3. Para saber mais sobre o motivo pelo qual os nós têm o estado NotReady, veja os registos do nó e dos respetivos componentes.

    1. Verifique os registos kubelet para ver o estado NotReady.

      O kubelet é o agente principal que comunica o estado do nó ao plano de controlo, pelo que os respetivos registos são o local mais provável para encontrar a mensagem NotReady literal. Estes registos são a fonte autorizada para diagnosticar problemas com eventos do ciclo de vida do pod, condições de pressão de recursos (como MemoryPressure ou DiskPressure) e a conetividade do nó ao plano de controlo do Kubernetes.

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

      Aceda ao Explorador de registos

    3. No painel de consultas, introduza 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 o seguinte:

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

    4. Clique em Executar consulta e reveja os resultados.

    5. Se os registos kubelet não revelarem a causa principal, verifique os registos container-runtime e node-problem-detector. Estes componentes podem não registar o estado NotReady diretamente, mas registam frequentemente o problema subjacente (como uma falha de tempo de execução ou um pânico do kernel) que causou o problema.

    6. No painel de consultas do Explorador de registos, introduza 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 tempo de execução (containerd), responsável pelo ciclo de vida completo do contentor, incluindo a obtenção de imagens e a gestão da execução do contentor. A revisão dos registos container-runtime é essencial para resolver problemas relacionados com a instanciação de contentores, erros do serviço de tempo de execução ou problemas causados pela configuração do tempo de execução.
      • node-problem-detector: um utilitário que monitoriza proativamente e comunica uma variedade de problemas ao nível do nó ao plano de controlo. Os respetivos registos são essenciais para identificar problemas sistémicos subjacentes que podem causar instabilidade nos nós, como bloqueios do kernel, corrupção do sistema de ficheiros ou falhas de hardware, que podem não ser captados por outros componentes do Kubernetes.

    7. Clique em Executar consulta e reveja os resultados.

  4. Use o explorador de métricas para procurar esgotamento de recursos na altura em que o nó ficou NotReady:

    1. Na Google Cloud consola, aceda à página Explorador de métricas:

      Aceda ao Metrics Explorer

    2. No Explorador de métricas, verifique se a instância do Compute Engine subjacente do nó tem esgotamento de recursos. Concentre-se em métricas relacionadas com a CPU, a memória e as métricas de E/S de disco. Por exemplo:

      • Métricas de nós do GKE: comece com métricas com o prefixo kubernetes.io/node/, como kubernetes.io/node/cpu/allocatable_utilization ou kubernetes.io/node/memory/allocatable_utilization. Estas métricas mostram a quantidade de recursos disponíveis do nó que está a ser usada pelos seus pods. O valor disponível não inclui os recursos que o Kubernetes reserva para a sobrecarga do sistema.
      • Métricas do SO convidado: para uma vista a partir do sistema operativo 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 ver o desempenho da VM ao 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.

      As métricas do SO convidado e do hipervisor requerem que filtre pelo nome da instância do Compute Engine subjacente e não pelo nome do nó do Kubernetes. Pode encontrar o nome da instância de um nó executando o comando kubectl describe node NODE_NAME e procurando o campo ProviderID no resultado. O nome da instância é a última parte desse valor. Por 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.

Identifique a causa pelo sintoma

Se identificou um sintoma específico, como uma mensagem de registo, uma condição do nó ou um evento do cluster, use a tabela seguinte para encontrar sugestões de resolução de problemas:

Categoria Sintoma ou mensagem de registo Potencial causa Passos de resolução de problemas
Condições do nó NetworkUnavailable: True Problema de conetividade do nó para o plano de controlo ou falha do plugin da interface de rede de contentores (CNI). Resolva problemas de conetividade de rede
MemoryPressure: True O nó tem memória insuficiente. Resolva problemas de escassez de recursos de nós
DiskPressure: True O nó tem espaço em disco insuficiente. Resolva problemas de escassez de recursos de nós
PIDPressure: True O nó tem IDs de processos insuficientes disponíveis. Resolva problemas de escassez de recursos de nós
Eventos e mensagens de registo PLEG is not healthy O Kubelet está sobrecarregado devido a uma elevada utilização da CPU/IO ou a demasiados pods. Resolva problemas de PLEG
Out of memory: Kill process
sys oom event		 A memória do nó está completamente esgotada. Resolva eventos OOM ao nível do sistema
leases.coordination.k8s.io...is forbidden O espaço de nomes kube-node-lease está bloqueado na terminação. Resolva problemas com o espaço de nomes 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 Containerd ou Docker falhou ou está configurado incorretamente. Resolva problemas de tempo de execução do contentor
Os agrupamentos ficam bloqueados. Os registos do Terminating
Kubelet mostram DeadlineExceeded para o contentor de eliminação. Os registos do
containerd mostram mensagens Kill container repetidas		 Processos bloqueados em suspensão do disco ininterrupta (D-state), frequentemente relacionados com E/S. Resolva processos bloqueados no estado D
Sintomas ao nível do cluster Vários nós falham após uma implementação do DaemonSet. O DaemonSet está a interferir com as operações do nó. Resolva problemas causados por DaemonSets de terceiros
compute.instances.preempted nos registos de auditoria. A VM de capacidade instantânea foi anulada, o que é um comportamento esperado. Confirme a preemptividade do nó
kube-system Agrupamentos presos em Pending. O webhook de admissão está a bloquear componentes críticos. Resolva problemas causados por webhooks de admissão
exceeded quota: gcp-critical-pods A quota configurada incorretamente está a bloquear os agrupamentos do sistema. Resolva problemas causados por quotas de recursos

Verifique se existem eventos NotReady esperados

Um estado NotReady nem sempre indica um problema. Este pode ser um comportamento esperado durante operações planeadas, como uma atualização do conjunto de nós, ou se usar determinados tipos de máquinas virtuais.

Confirme as operações do ciclo de vida do nó

Sintomas:

Um nó mostra temporariamente o estado NotReady durante determinados eventos do ciclo de vida.

Causa:

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

  • Atualizações do node pool: durante uma atualização, cada nó é esvaziado e substituído. O novo nó atualizado tem o estado NotReady até terminar a inicialização e juntar-se ao cluster.
  • Reparação automática de nós: quando o GKE substitui um nó com mau funcionamento, o nó de substituição permanece NotReady enquanto está a ser aprovisionado.
  • Aumento da escala do redimensionador automático de clusters: quando são adicionados novos nós, estes começam num estado NotReady e tornam-se Ready apenas depois de serem totalmente aprovisionados e de se juntarem ao cluster.
  • Alterações manuais ao modelo de instância: o GKE recria os nós quando aplica alterações ao modelo. O novo nó tem o estado NotReady durante a fase de arranque.

Resolução:

Os nós devem ter o estado NotReady apenas brevemente. Se o estado persistir durante mais de 10 minutos, investigue outras causas.

Confirme a preemptividade do nó

Se o seu nó estiver a ser executado numa VM de instância temporária ou numa VM com capacidade de interrupção, o Compute Engine pode terminá-lo abruptamente para reclamar recursos. Este é o comportamento esperado para estes tipos de máquinas virtuais de curta duração e não é um erro.

Sintomas:

Se observar os seguintes sintomas, é provável que o estado NotReady do nó seja causado por uma remoção preventiva esperada da VM Spot:

  • Um nó entra inesperadamente num estado NotReady antes de ser eliminado e recriado pelo escalador automático do cluster.
  • Os registos de auditoria do Cloud mostram um evento compute.instances.preempted para a instância de VM subjacente.

Causa:

O nó estava a ser executado numa instância de VM do Spot ou VM preemptível e o Compute Engine recuperou esses recursos de computação para outra tarefa. As VMs de spot podem ser interrompidas em qualquer altura, embora normalmente forneçam um aviso de encerramento de 30 segundos.

Resolução:

Use VMs do Spot ou VMs preemptivas apenas para cargas de trabalho com tolerância a falhas, sem estado ou em lote concebidas para processar encerramentos frequentes de forma adequada. Para cargas de trabalho de produção ou com estado que não toleram interrupções súbitas, aprovisione os seus conjuntos de nós com VMs padrão a pedido.

Resolva problemas de escassez de recursos de nós

Um nó torna-se frequentemente 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 podem funcionar corretamente, o que leva à instabilidade da aplicação e à não resposta do nó. As secções seguintes abordam as diferentes formas como estas escassez podem aparecer, desde condições de pressão gerais a eventos mais graves ao nível do sistema.

Resolva a pressão dos recursos do nó

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

Sintomas:

Se observar as seguintes condições e registos do nó, o esgotamento de recursos é a causa provável do estado NotReady do nó:

  • No resultado do comando kubectl describe node, vê o estado True para condições como OutOfDisk, MemoryPressure, DiskPressure ou PIDPressure.
  • Os registos do kubelet podem conter eventos de falta de memória (OOM), o que indica que o OOM Killer do sistema foi invocado.

Causa:

As cargas de trabalho no nó estão a exigir coletivamente mais recursos do que o nó pode fornecer.

Resolução:

Para clusters Standard, experimente as seguintes soluções:

Para clusters do Autopilot, não controla diretamente os tipos de máquinas dos nós nem os tamanhos dos discos de arranque. A capacidade dos nós é gerida automaticamente com base nos seus pedidos de pods. Certifique-se de que os pedidos de recursos da carga de trabalho estão dentro dos limites do Autopilot e refletem com precisão as necessidades da sua aplicação. Os problemas persistentes de recursos podem indicar a necessidade de otimizar os pedidos de pods ou, em casos raros, um problema da plataforma que requer assistência do Cloud Customer Care.

Resolva eventos OOM ao nível do sistema

Um evento de falta de memória (OOM) ao nível do sistema ocorre quando a memória total de um nó se esgota, o que força o kernel do Linux a terminar processos para libertar recursos. Este evento é diferente de um evento OOM ao nível do contentor, em que um único pod excede os respetivos limites de memória.

Sintomas:

Se notar os seguintes sintomas, é provável que um evento OOM ao nível do sistema seja o motivo da instabilidade do nó:

  • Vê a mensagem Out of memory: Kill process nos registos da consola em série do nó.
  • Os registos do kubelet contêm eventos oom_watcher, que indicam que o kubelet detetou um evento OOM ao nível do sistema.
  • Encerramento inesperado de vários processos, incluindo potencialmente daemons do sistema críticos ou pods de carga de trabalho, não necessariamente os consumidores de memória mais elevados.

Causa:

A memória geral do nó está esgotada. Este problema pode dever-se a um erro num serviço do sistema, a uma carga de trabalho mal configurada que está a consumir uma quantidade excessiva de memória ou a um nó demasiado pequeno para as exigências de memória coletivas de todos os respetivos pods em execução.

Resolução:

Para resolver eventos OOM ao nível do sistema, diagnostique a causa e, em seguida, reduza a procura de memória ou aumente a capacidade do nó. Para mais informações, consulte o artigo Resolva problemas de eventos OOM.

Resolva problemas de PLEG

O gerador de eventos do ciclo de vida do pod (PLEG) é um componente no kubelet. Verifica periodicamente o estado de todos os contentores no nó e comunica quaisquer alterações ao kubelet.

Quando o PLEG tem problemas de desempenho, não consegue fornecer atualizações atempadas ao kubelet, o que pode fazer com que o nó fique instável.

Sintomas:

Se observar os seguintes sintomas, o PLEG pode não estar a funcionar corretamente:

  • Os registos do kubelet para o nó contêm uma mensagem semelhante a PLEG is not healthy.
  • O estado do nó muda frequentemente entre Ready e NotReady.

Causa:

Normalmente, os problemas de PLEG são causados por problemas de desempenho que impedem o kubelet de receber atualizações atempadas do tempo de execução do contentor. As causas comuns incluem o seguinte:

  • Carga elevada da CPU: a CPU do nó está saturada, o que impede que o kubelet e o tempo de execução do contentor tenham a capacidade de processamento de que precisam.
  • Limitação de I/O: o disco de arranque do nó está a ter operações de I/O pesadas, o que pode abrandar todas as tarefas relacionadas com o disco.
  • Pods excessivos: demasiados pods num único nó podem sobrecarregar o kubelet e o tempo de execução do contentor, o que leva a contenção de recursos.

Resolução:

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

Para clusters do Autopilot, embora não possa alterar diretamente o tamanho ou o tipo de disco de um nó existente, pode influenciar o hardware no qual as suas cargas de trabalho são executadas através de ComputeClasses personalizadas. Esta funcionalidade permite-lhe 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 a programação dos seus pods.

Se não usar ComputeClasses, ajuste as implementações de cargas de trabalho (como as quantidades de réplicas e os pedidos ou os limites de recursos) e certifique-se de que estão dentro das restrições do Autopilot. Se os problemas de PLEG persistirem após a otimização das suas cargas de trabalho, contacte o apoio ao cliente da nuvem.

Resolva processos bloqueados no estado D

Os processos bloqueados num estado de suspensão do disco ininterrupto (D-state) podem fazer com que um nó deixe de responder. Este problema impede a terminação dos pods e pode causar falhas em componentes críticos, como o containerd, o que resulta num estado NotReady.

Sintomas:

  • Os pods, especialmente os que usam armazenamento de rede, como o NFS, ficam presos no estado Terminating durante muito tempo.
  • Os registos do Kubelet mostram erros DeadlineExceeded ao tentar parar um contentor.
  • Os registos da consola série do nó podem mostrar mensagens do kernel sobre hung tasks ou tarefas bloqueadas durante mais de 120 segundos.

Causa:

Os processos entram num estado D quando estão a aguardar a conclusão de uma operação de E/S e não podem ser interrompidos. As causas comuns incluem o seguinte:

  • Sistemas de ficheiros remotos lentos ou sem resposta, como uma partilha NFS mal configurada ou sobrecarregada.
  • 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, em seguida, limpe o estado selecionando uma das seguintes opções:

Clusters padrão

  1. Encontre o processo bloqueado e determine o que está a aguardar:

    1. Ligue-se ao nó afetado através de SSH:

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

      Substitua o seguinte:

      • NODE_NAME: o nome do nó ao qual se quer ligar.
      • ZONE: a zona do Compute Engine do nó.
      • PROJECT_ID: o ID do projeto.

    2. Encontre processos num estado D:

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

      O resultado é semelhante ao seguinte:

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

      A saída não tem um cabeçalho. As colunas, por ordem, representam:

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

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

      • Se a coluna wchan incluir termos como nfs ou rpc, o processo está a aguardar uma partilha NFS.
      • Se a coluna wchan incluir termos como io_schedule, jbd2 ou ext4, o processo está a aguardar o disco de arranque local do nó.

    4. Para ver mais detalhes sobre as funções do kernel que o processo está a aguardar, verifique a pilha de chamadas do kernel do processo:

      cat /proc/PID/stack

      Substitua PID pelo ID do processo que encontrou no passo anterior.

  2. Reinicie o nó. O reinício é, muitas vezes, a forma mais eficaz de limpar um processo bloqueado num estado D.

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

  3. Depois de resolver o problema imediato, investigue o sistema de armazenamento subjacente para evitar a recorrência.

    • Para problemas de armazenamento de rede (NFS): use as ferramentas de monitorização do seu fornecedor de armazenamento para verificar se existem latências elevadas, erros do lado do servidor ou problemas de rede entre o nó do GKE e o servidor NFS.

    • Para problemas de disco local: verifique a 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 para a 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. Tem de basear-se em registos e métricas.

    1. Verifique os registos dos nós: nos Registos na nuvem, analise os registos do nó afetado. Filtre pelo nome do nó e pelo período do problema. Procure mensagens do kernel que indiquem erros de E/S, limites de tempo de armazenamento (por exemplo, para disco ou NFS) ou mensagens de controladores CSI.
    2. Verifique os registos da carga de trabalho: examine os registos dos pods em execução no nó afetado. Os registos da aplicação podem revelar erros relacionados com operações de ficheiros, chamadas de base de dados ou acesso ao armazenamento de rede.
    3. Use o Cloud Monitoring: embora não possa obter detalhes ao nível do processo, verifique se existem problemas de E/S ao nível do nó.

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

    Não pode eliminar manualmente a VM subjacente. Para acionar uma substituição, esvazie o nó. Esta ação isola o nó e despeja os pods.

    O GKE deteta automaticamente nós não íntegros e inicia reparações, normalmente substituindo a VM subjacente.

    Se o nó permanecer bloqueado após a drenagem e não for substituído automaticamente, contacte o apoio ao cliente da Google Cloud.

  3. Depois de resolver o problema imediato, investigue o sistema de armazenamento subjacente para evitar a recorrência.

    • Para problemas de disco local: verifique a 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. Pode filtrar estas métricas para o grupo de instâncias subjacente do conjunto de nós, embora as instâncias individuais sejam geridas pela Google.
    • Para problemas de armazenamento de rede (NFS): use as ferramentas de monitorização do seu fornecedor de armazenamento para verificar se existem latências elevadas, erros do lado do servidor ou problemas de rede entre o nó do GKE e o servidor NFS. Verifique os registos de quaisquer pods de controlador CSI no Cloud Logging.

Resolva problemas de falhas de componentes principais

Depois de excluir as causas esperadas e a escassez de recursos, o software do nó ou um mecanismo Kubernetes essencial pode ser a causa do problema. Um estado NotReady pode ocorrer quando um componente crítico, como o tempo de execução do contentor, falha. Também pode acontecer quando um mecanismo de verificação de funcionamento do Kubernetes principal, como o sistema de concessão de nós, avaria.

Resolva problemas de tempo de execução do contentor

Os problemas com o tempo de execução do contentor, como o containerd, podem impedir que o kubelet inicie pods num nó.

Sintomas:

Se observar as seguintes mensagens nos registos do kubelet, um problema de tempo de execução do contentor é a causa provável do estado NotReady do nó:

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

Causa:

O tempo de execução do contentor não está a funcionar corretamente, está configurado incorretamente ou está preso num ciclo de reinício.

Resolução:

Para resolver problemas de tempo de execução do contentor, faça o seguinte:

  1. Analise os registos de tempo de execução do contentor:

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

      Aceda ao Explorador de registos

    2. Para ver todos os registos de avisos e erros do tempo de execução do contentor no nó afetado, no painel de consulta, introduza o seguinte:

      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 o seguinte:

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

    3. Clique em Executar consulta e reveja o resultado para ver mensagens de erro específicas que indicam o motivo pelo qual o tempo de execução falhou. Uma mensagem como failed to load TOML nos registos do containerd Cloud Logging indica frequentemente um ficheiro com formato incorreto.

    4. Para verificar se o tempo de execução está bloqueado num ciclo de reinício, execute uma consulta que pesquise mensagens de arranque. Um número elevado destas mensagens num curto período confirma reinícios 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")

      Os reinícios frequentes apontam muitas vezes para um problema subjacente, como um ficheiro de configuração danificado ou pressão de recursos, que está a provocar falhas repetidas no serviço.

  2. Reveja a configuração do containerd para modificações: as definições incorretas podem fazer com que o tempo de execução do contentor falhe. Pode fazer alterações de configuração através de um ficheiro de configuração do sistema de nós ou através de modificações diretas feitas por cargas de trabalho com privilégios elevados.

    1. Determine se o node pool usa um ficheiro 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 o seguinte:

      • NODE_POOL_NAME: o nome do seu node pool.
      • CLUSTER_NAME: o nome do seu cluster.
      • LOCATION: a região ou a zona do Compute Engine do seu cluster.

      Se o resultado apresentar uma secção containerdConfig, significa que o GKE está a gerir estas definições personalizadas. Para modificar ou reverter as definições, siga as instruções em Personalize a configuração do containerd nos nós do GKE.

    2. Se as personalizações geridas pelo GKE não estiverem ativas ou se suspeitar de outras alterações, procure cargas de trabalho que possam estar a modificar o sistema de ficheiros do nó diretamente. Procure DaemonSets com autorizações elevadas (securityContext.privileged: true) ou volumes hostPath a montar diretórios confidenciais, como /etc.

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

      kubectl get daemonsets --all-namespaces -o yaml

      Reveja o resultado e inspecione os registos de quaisquer DaemonSets suspeitos.

    3. Para clusters padrão, inspecione o ficheiro de configuração diretamente. Não é possível o acesso SSH nem a inspeção manual de ficheiros em clusters do Autopilot, porque a Google gere a configuração de tempo de execução. Comunique problemas de tempo de execução persistentes ao apoio ao cliente do Google Cloud.

      Se usar um cluster padrão, inspecione o ficheiro:

      1. Ligue-se ao nó através de SSH:

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

        Substitua o seguinte:

        • NODE_NAME: o nome do nó ao qual se quer ligar.
        • ZONE: a zona do Compute Engine do nó.
        • PROJECT_ID: o ID do projeto.

      2. Apresente o conteúdo do ficheiro de configuração do containerd:

        sudo cat /etc/containerd/config.toml

      3. Para verificar modificações recentes, liste os detalhes dos ficheiros:

        ls -l /etc/containerd/config.toml

    4. Compare o conteúdo deste ficheiro com o resultado de containerdConfig do comando gcloud node-pools describe que executou no passo anterior. Qualquer definição em /etc/containerd/config.toml que não esteja no resultado de gcloud é uma alteração não gerida.

    5. Para corrigir qualquer configuração incorreta, remova todas as alterações que não foram aplicadas através de uma configuração do sistema de nós.

  3. Resolva problemas comuns de tempo de execução: para ver mais passos de resolução de problemas, consulte o artigo Resolução de problemas do tempo de execução do contentor.

Resolva problemas com o espaço de nomes kube-node-lease

Os recursos no espaço de nomes kube-node-lease são responsáveis por manter o estado de funcionamento do nó. Este espaço de nomes não deve ser eliminado. As tentativas de eliminar este espaço de nomes resultam na permanência do espaço de nomes no estado Terminating. Quando o espaço de nomes kube-node-lease fica bloqueado no estado Terminating, os kubelets não conseguem renovar as respetivas concessões de verificação de estado. Este problema faz com que o plano de controlo considere os nós como não estando em bom estado, o que leva a um problema ao nível do cluster em que os nós alternam entre os estados Ready e NotReady.

Sintomas:

Se observar os seguintes sintomas, é provável que um problema com o espaço de nomes kube-node-lease seja a causa da instabilidade ao nível do cluster:

  • Os registos do kubelet em todos os nós mostram erros persistentes semelhantes aos seguintes:

    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 no cluster alternam repetidamente entre os estados Ready e NotReady.

Causa:

O espaço de nomes kube-node-lease, que gere os heartbeats dos nós, está anormalmente bloqueado no estado Terminating. Este erro impede que o servidor da API Kubernetes permita a criação ou a modificação de objetos no espaço de nomes. Como resultado, os kubelets não podem renovar os respetivos objetos Lease, que são essenciais para sinalizar a respetiva atividade ao plano de controlo. Sem estas atualizações de estado, o plano de controlo não consegue confirmar que os nós estão em bom estado de funcionamento, o que faz com que os estados dos nós alternem entre Ready e NotReady.

Os motivos subjacentes pelos quais o próprio espaço de nomes kube-node-lease pode ficar bloqueado no estado Terminating incluem o seguinte:

  • Recursos com finalizadores: embora menos comuns para o espaço de nomes kube-node-lease do sistema (que contém principalmente objetos Lease), um recurso no respetivo interior pode ter um finalizador. Os finalizadores do Kubernetes são chaves que indicam que um controlador tem de realizar tarefas de limpeza antes de um recurso poder ser eliminado. Se o controlador responsável pela remoção do finalizador não estiver a funcionar corretamente, o recurso não é eliminado e o processo de eliminação do espaço de nomes é interrompido.
  • Serviços de API agregados não íntegros ou sem resposta: a terminação do espaço de nomes pode ser bloqueada se um objeto APIService, que é usado para registar um servidor de API agregado, estiver associado ao espaço de nomes e ficar não íntegro. O plano de controlo pode aguardar que o servidor da API agregada seja encerrado ou limpo corretamente, o que não ocorre se o serviço não responder.
  • Problemas com o plano de controlo ou o controlador: em casos raros, os erros ou os problemas no plano de controlo do Kubernetes, especificamente no controlador do espaço de nomes, podem impedir a recolha de lixo e a eliminação bem-sucedidas do espaço de nomes.

Resolução:

Siga as orientações em Resolva problemas de espaços de nomes bloqueados no estado de encerramento.

Resolva problemas de conetividade de rede

Os problemas de rede podem impedir que um nó comunique com o plano de controlo ou impedir que componentes críticos, como o plug-in CNI, funcionem, o que leva a um estado NotReady.

Sintomas:

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

  • A condição NetworkNotReady é True.
  • Os registos do Kubelet no nó mostram erros semelhantes aos seguintes:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • connection refused ou timeout ao tentar alcançar o endereço IP do plano de controlo.
  • Os pods, especialmente no espaço de nomes kube-system, estão bloqueados em ContainerCreating com eventos como NetworkPluginNotReady.

Causa:

Normalmente, os sintomas relacionados com a rede indicam uma falha numa das seguintes áreas:

  • Problemas de conetividade: o nó não consegue estabelecer uma ligação de rede estável ao plano de controlo do Kubernetes.
  • Falha do plug-in CNI: o plug-in CNI, que é responsável pela configuração da rede de pods, não está a ser executado corretamente ou não foi inicializado.
  • Problemas de webhook: os webhooks de admissão configurados incorretamente podem interferir com os recursos relacionados com o plug-in CNI, o que impede a configuração correta da rede.

Resolução:

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

  1. Resolva o estado NetworkNotReady transitório: nos nós criados recentemente, é normal ver um breve evento NetworkNotReady. Este estado deve ser resolvido no prazo de um ou dois minutos enquanto o plug-in CNI e outros componentes são inicializados. Se o estado persistir, avance para os passos seguintes.

  2. Verifique a conetividade do nó ao plano de controlo e as regras de firewall: certifique-se de que o caminho de rede entre o nó e o plano de controlo está aberto e a funcionar corretamente:

    1. Verifique as regras de firewall: certifique-se de que as regras de firewall da VPC permitem o tráfego necessário entre os nós do GKE e o plano de controlo. Para obter informações sobre as regras que o GKE requer para a comunicação do nó com o plano de controlo, consulte o artigo Regras da firewall criadas automaticamente.
    2. Testar conetividade: use o teste de conetividade no Network Intelligence Center para validar o caminho de rede entre o endereço IP interno do nó e o endereço IP do ponto final do plano de controlo na porta 443. Um resultado de Not Reachable ajuda frequentemente a identificar a regra de firewall ou o problema de encaminhamento que está a bloquear a comunicação.

  3. Investigue o estado e os registos do plugin CNI: se a rede do nó não estiver pronta, o problema pode estar no plugin CNI.

    1. Verifique o estado do pod CNI: identifique o plug-in CNI em utilização (por exemplo, netd ou calico-node) e verifique o estado dos respetivos pods no espaço de nomes kube-system. Pode 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 registos dos pods de CNI: se os pods não estiverem a funcionar corretamente, examine os respetivos registos no Cloud Logging para ver mensagens de erro detalhadas. Use uma consulta semelhante à seguinte para netd pods num 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. Resolva erros de CNI específicos:

      • Se os registos mostrarem Failed to allocate IP address, os seus intervalos de endereços IP de pods podem estar esgotados. Valide a utilização do endereço IP do pod e reveja os intervalos CIDR do cluster.
      • Se os registos mostrarem NetworkPluginNotReady ou cni plugin not initialized, confirme que o nó tem recursos suficientes de CPU e memória. Também pode tentar reiniciar o CNI Pod eliminando-o, o que permite que o DaemonSet o recrie.
      • Se usar o GKE Dataplane V2 e os registos mostrarem Cilium API client timeout exceeded, reinicie o pod anetd no nó.

    4. Verifique se existe interferência do webhook de admissão: os webhooks com mau funcionamento podem impedir o início dos pods de CNI, deixando o nó num estado NetworkNotReady.

    5. Verifique os registos do servidor da API: reveja os registos do servidor da API no Cloud Logging para ver se existem erros relacionados com chamadas de webhook. Para identificar se um webhook está a bloquear a criação de recursos CNI, pesquise mensagens como failed calling webhook.

      Se um webhook estiver a causar problemas, pode ter de identificar o ValidatingWebhookConfigurationproblemático MutatingWebhookConfigurationou e desativá-lo temporariamente para permitir que o nó fique pronto. Para mais informações, consulte o artigo Resolva problemas causados por webhooks de admissão.

Resolva problemas de configurações incorretas do cluster

As secções seguintes ajudam a auditar algumas configurações ao nível do cluster que podem estar a interferir com as operações normais dos nós.

Resolva problemas causados por webhooks de admissão

Um webhook de admissão configurado incorretamente, indisponível ou demasiado lento pode bloquear pedidos de API críticos, impedindo o início de componentes essenciais ou a adesão de nós ao cluster.

Sintomas:

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

  • Os pods, especialmente no espaço de nomes kube-system (como CNI ou pods de armazenamento), estão bloqueados num estado Pending ou Terminating.
  • Os novos nós não conseguem juntar-se ao cluster, muitas vezes com um tempo limite excedido com um estado NotReady.

Causa:

Os webhooks de admissão configurados incorretamente ou que não respondem podem estar a bloquear operações essenciais do cluster.

Resolução:

Reveja as configurações de webhook para garantir que são resilientes e têm o âmbito adequado. Para evitar interrupções, defina o campo failurePolicy como Ignore para webhooks não críticos. Para webhooks críticos, certifique-se de que o respetivo serviço de apoio técnico está altamente disponível e exclua o espaço de nomes kube-system da supervisão de webhooks usando um namespaceSelector para evitar impasses do plano de controlo. Para mais informações, consulte o artigo Garanta a estabilidade do plano de controlo quando usar webhooks.

Resolva problemas causados por quotas de recursos

Uma quota de recursos calculada incorretamente no espaço de nomes kube-system pode impedir que o GKE crie pods do sistema críticos. Uma vez que os componentes, como a rede (CNI) e o DNS, estão bloqueados, este problema pode impedir que novos nós se juntem com êxito ao cluster.

Sintomas:

  • Os pods críticos no espaço de nomes kube-system (por exemplo, netd, konnectivity-agent ou kube-dns) estão bloqueados num estado Pending.
  • As mensagens de erro nos registos do cluster ou a saída kubectl describe pod mostram falhas como exceeded quota: gcp-critical-pods.

Causa:

Este problema ocorre quando o controlador de quota de recursos do Kubernetes deixa 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 a utilização da quota pareça muito superior à real.

Resolução:

  1. Uma vez que um webhook problemático é a causa principal mais provável, siga as orientações na secção Resolva problemas causados por webhooks de admissão para identificar e corrigir quaisquer webhooks que possam estar a bloquear componentes do sistema. A correção do webhook resolve frequentemente o problema de quota automaticamente.

  2. Verifique se a utilização registada da quota está dessincronizada com o número real de pods em execução. Este passo confirma se a contagem do objeto ResourceQuota está incorreta:

    1. Verifique a utilização comunicada da quota:

      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 quantidade usada no ResourceQuota parecer incorreta (por exemplo, muito superior ao número real de Pods), elimine o objeto gcp-critical-pods. O plano de controlo do GKE foi concebido para recriar automaticamente este objeto com as contagens de utilização corretas e reconciliadas:

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

  4. Monitorize o espaço de nomes kube-system durante alguns minutos para garantir que o objeto é recriado e que os pods pendentes começam a ser agendados.

Resolva problemas causados por DaemonSets de terceiros

Um DaemonSet de terceiros implementado ou atualizado recentemente, que é frequentemente usado para segurança, monitorização ou registo, pode, por vezes, causar instabilidade no nó. Este problema pode ocorrer se o DaemonSet interferir com o tempo de execução do contentor ou a rede do nó, consumir recursos excessivos do sistema ou fazer modificações inesperadas no sistema.

Sintomas:

Se observar os seguintes sintomas, um DaemonSet de terceiros implementado ou modificado recentemente é uma possível causa de falhas de nós:

  • Vários nós, potencialmente em todo o cluster, entram num estado NotReady pouco depois de o DaemonSet ser implementado ou atualizado.
  • Os registos do Kubelet para os nós afetados comunicam erros como os seguintes:
    • container runtime is down
    • Failed to create pod sandbox
    • Erros ao estabelecer ligação ao socket de tempo de execução do contentor (por exemplo, /run/containerd/containerd.sock).
  • Os pods, incluindo os pods do sistema ou os próprios pods do DaemonSet, estão presos nos estados PodInitializing ou ContainerCreating.
  • Os registos do contentor para aplicações mostram erros invulgares, como exec format error.
  • O Node Problem Detector pode comunicar condições relacionadas com o estado de funcionamento do tempo de execução ou a pressão dos recursos.

Causa:

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

  • Consumir CPU, memória ou I/O do disco excessivos, o que afeta o desempenho dos componentes de nós críticos.
  • Interferir com o funcionamento do tempo de execução do contentor.
  • Causar conflitos com a configuração de rede do nó ou o plug-in da interface de rede do contentor (CNI).
  • Alterar as configurações do sistema ou as políticas de segurança de uma forma não intencional.

Resolução:

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

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

    kubectl get daemonsets --all-namespaces

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

    Normalmente, pode identificar estes DaemonSets revendo o seguinte:

    • Namespace: normalmente, os componentes do GKE predefinidos são executados no namespace kube-system. Os DaemonSets noutros espaços de nomes são provavelmente de terceiros ou personalizados.
    • Nomenclatura: os DaemonSets predefinidos têm frequentemente nomes como gke-metrics-agent, netd ou calico-node. Os agentes externos têm frequentemente nomes que refletem o produto.

  2. Correlacionar a hora de implementação: verifique se a apresentação de nós NotReadycoincide com a implementação ou a atualização de um DaemonSet específico de terceiros.

  3. Teste num único nó:

    1. Escolha um nó afetado.
    2. Isolar e esvaziar o nó.
    3. Impedir temporariamente o agendamento do DaemonSet neste nó:
      • Aplique uma etiqueta de nó temporária e configure a afinidade ou a antiafinidade do nó no manifesto do DaemonSet.
      • Elimine o pod do DaemonSet nesse nó específico.
    4. Reinicie a instância da máquina virtual do nó.
    5. Verifique se o nó fica Ready e permanece estável enquanto o DaemonSet não está em execução no mesmo. Se os problemas reaparecerem depois de reintroduzir o DaemonSet, é provável que seja um fator que contribui para o problema.

  4. Consulte o fornecedor: se suspeitar que um agente de terceiros é a causa, reveja a documentação do fornecedor para ver problemas de compatibilidade conhecidos ou práticas recomendadas para executar o agente no GKE. Se precisar de mais apoio técnico, contacte o fornecedor do software.

Verifique se o nó foi recuperado

Depois de aplicar uma potencial solução, siga estes passos para verificar se o nó foi recuperado com êxito e está estável:

  1. Verifique o estado do nó:

    kubectl get nodes -o wide

    Procure o nó afetado no resultado. A coluna Status deve agora mostrar um valor de Ready. O estado pode demorar alguns minutos a ser atualizado após a aplicação da correção. Se o estado continuar a mostrar NotReady ou estiver a alternar entre estados, o problema não está totalmente resolvido.

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

    kubectl describe node NODE_NAME

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

    • A condição Ready tem o estado True.
    • As condições negativas que tinham anteriormente o estado True (por exemplo, MemoryPressure ou NetworkUnavailable) têm agora o estado False. Os campos Reason e Message para estas condições devem indicar que o problema está resolvido.

  3. Agendamento de agrupamentos de teste. Se o nó não conseguia executar cargas de trabalho anteriormente, verifique se estão a ser agendados novos pods no mesmo e se os pods existentes estão a ser executados sem problemas:

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

    Os agrupamentos no nó devem ter um estado Running ou Completed. Não deve ver pods bloqueados no estado Pending ou noutros estados de erro.

O que se segue?