Risolvi i problemi relativi ai nodi con stato NotReady in GKE

Uno stato NotReady in Google Kubernetes Engine (GKE) indica che kubelet del nodo non comunica correttamente con il control plane. Poiché Kubernetes non pianifica nuovi pod su un nodo NotReady, questo problema può ridurre la capacità dell'applicazione e causare tempi di inattività.

Utilizza questo documento per distinguere tra gli stati NotReady previsti e i problemi effettivi, diagnosticare la causa principale e trovare soluzioni per problemi comuni come esaurimento delle risorse, problemi di rete ed errori di runtime del container.

Queste informazioni sono destinate agli amministratori e agli operatori della piattaforma responsabili della stabilità del cluster e agli sviluppatori di applicazioni che vogliono comprendere il comportamento delle applicazioni correlate all'infrastruttura. Per ulteriori informazioni sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti di Google Cloud , consulta Ruoli utente e attività comuni di GKE.

Prima di iniziare

  • Per ottenere le autorizzazioni necessarie per eseguire le attività descritte in questo documento, chiedi all'amministratore di concederti i seguenti ruoli IAM nel tuo progetto Google Cloud :

    Per saperne di più sulla concessione dei ruoli, consulta Gestisci l'accesso a progetti, cartelle e organizzazioni.

    Potresti anche riuscire a ottenere le autorizzazioni richieste tramite i ruoli personalizzati o altri ruoli predefiniti.

  • Configura lo strumento a riga di comando kubectl per comunicare con il cluster GKE:

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

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del tuo cluster.
    • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.
    • PROJECT_ID: il tuo ID progetto Google Cloud .

Controllare lo stato e le condizioni del nodo

Per confermare che un nodo ha lo stato NotReady e aiutarti a diagnosticare la causa principale, segui questi passaggi per esaminare le condizioni, gli eventi, i log e le metriche delle risorse di un nodo:

  1. Visualizza lo stato dei nodi. Per ottenere ulteriori dettagli come indirizzi IP e versioni del kernel, utili per la diagnosi, utilizza il flag -o wide:

    kubectl get nodes -o wide

    L'output è simile al seguente:

    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

    Nell'output, cerca i nodi con un valore di NotReady nella colonna STATUS e annota i relativi nomi.

  2. Visualizza ulteriori informazioni su nodi specifici con lo stato NotReady, incluse le relative condizioni ed eventuali eventi Kubernetes recenti:

    kubectl describe node NODE_NAME

    Sostituisci NODE_NAME con il nome di un nodo con lo stato NotReady.

    Nell'output, concentrati sulla sezione Conditions per comprendere lo stato del nodo e sulla sezione Events per visualizzare una cronologia dei problemi recenti. Ad esempio:

    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

    Nella sezione Conditions, lo stato True per qualsiasi condizione negativa o Unknown per la condizione Ready indica un problema. Presta particolare attenzione ai campi Reason e Message per queste condizioni, in quanto spiegano la causa del problema.

    Di seguito è riportato il significato di ciascun tipo di condizione:

    • KernelDeadlock: True se il kernel del sistema operativo del nodo ha rilevato un deadlock, ovvero un errore grave che può bloccare il nodo.
    • FrequentUnregisterNetDevice: True se il nodo annulla spesso la registrazione dei dispositivi di rete, il che può essere un segnale di problemi con i driver o l'hardware.
    • NetworkUnavailable: True se il networking per il nodo non è configurato correttamente.
    • OutOfDisk: True se lo spazio disponibile sul disco è completamente esaurito. Questa condizione è più grave di DiskPressure.
    • MemoryPressure: True se la memoria del nodo è insufficiente.
    • DiskPressure: True se lo spazio su disco del nodo è insufficiente.
    • PIDPressure: True se il nodo sta esaurendo gli ID processo (PID).
    • Ready: indica se il nodo è integro e pronto ad accettare pod.
      • True se il nodo è integro.
      • False se il nodo non è integro e non accetta pod.
      • Unknown se il controller del nodo non ha ricevuto notizie dal nodo per un periodo di tolleranza (il valore predefinito è 50 secondi) e lo stato del nodo è sconosciuto.

    Successivamente, esamina la sezione Events, che fornisce un log cronologico di azioni e osservazioni sul nodo. Questa sequenza temporale è fondamentale per capire cosa è successo immediatamente prima che il nodo diventasse NotReady. Cerca messaggi specifici che possano aiutarti a trovare la causa, ad esempio avvisi di sfratto (che segnalano la pressione delle risorse), controlli di integrità non riusciti o eventi del ciclo di vita dei nodi come l'isolamento per una riparazione.

  3. Per scoprire di più sul motivo per cui i nodi hanno lo stato NotReady, visualizza i log del nodo e dei relativi componenti.

    1. Controlla i log di kubelet per lo stato di NotReady.

      kubelet è l'agente principale che comunica lo stato del nodo al piano di controllo, quindi i suoi log sono il luogo più probabile in cui trovare il messaggio letterale NotReady. Questi log sono la fonte autorevole per diagnosticare i problemi relativi agli eventi del ciclo di vita dei pod, alle condizioni di pressione delle risorse (come MemoryPressure o DiskPressure) e alla connettività del nodo al control plane Kubernetes.

    2. Nella Google Cloud console, vai alla pagina Esplora log:

      Vai a Esplora log

    3. Nel riquadro della query, inserisci la seguente query:

      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"

      Sostituisci quanto segue:

      • NODE_NAME: il nome del nodo che stai esaminando.
      • CLUSTER_NAME: il nome del tuo cluster.
      • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.

    4. Fai clic su Esegui query ed esamina i risultati.

    5. Se i log kubelet non rivelano la causa principale, controlla i log container-runtime e node-problem-detector. Questi componenti potrebbero non registrare direttamente lo stato NotReady, ma spesso registrano il problema sottostante (ad esempio un errore di runtime o un kernel panic) che ha causato il problema.

    6. Nel riquadro della query di Esplora log, inserisci la seguente query:

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

      Sostituisci COMPONENT_NAME con uno dei seguenti valori:

      • container-runtime: il runtime (containerd), responsabile dell'intero ciclo di vita del container, incluso il pull delle immagini e la gestione dell'esecuzione del container. La revisione dei log container-runtime è essenziale per la risoluzione dei problemi relativi all'istanza del container, agli errori del servizio di runtime o ai problemi causati dalla configurazione del runtime.
      • node-problem-detector: un'utilità che monitora in modo proattivo e segnala al control plane una serie di problemi a livello di nodo. I suoi log sono fondamentali per identificare i problemi sistemici sottostanti che possono causare l'instabilità dei nodi, come deadlock del kernel, danneggiamento del file system o guasti hardware, che potrebbero non essere acquisiti da altri componenti di Kubernetes.

    7. Fai clic su Esegui query ed esamina i risultati.

  4. Utilizza Metrics Explorer per verificare l'esaurimento delle risorse nel periodo in cui il nodo è diventato NotReady:

    1. Nella console Google Cloud , vai alla pagina Esplora metriche:

      Vai a Esplora metriche

    2. In Esplora metriche, controlla l'istanza Compute Engine sottostante del nodo per verificare l'esaurimento delle risorse. Concentrati sulle metriche relative a CPU, memoria e I/O del disco. Ad esempio:

      • Metriche dei nodi GKE: inizia con le metriche con il prefisso kubernetes.io/node/, ad esempio kubernetes.io/node/cpu/allocatable_utilization o kubernetes.io/node/memory/allocatable_utilization. Queste metriche mostrano la quantità di risorse disponibili del nodo utilizzate dai tuoi pod. L'importo disponibile non include le risorse che Kubernetes riserva per l'overhead di sistema.
      • Metriche del sistema operativo guest: per una visualizzazione dall'interno del sistema operativo del nodo, utilizza le metriche con il prefisso compute.googleapis.com/guest/, ad esempio compute.googleapis.com/guest/cpu/usage o compute.googleapis.com/guest/memory/bytes_used.
      • Metriche dell'hypervisor: per visualizzare le prestazioni della VM a livello di hypervisor, utilizza le metriche con il prefisso compute.googleapis.com/instance/, ad esempio compute.googleapis.com/instance/cpu/utilization o le metriche I/O del disco come compute.googleapis.com/instance/disk/read_bytes_count.

      Le metriche del sistema operativo guest e dell'hypervisor richiedono di filtrare in base al nome dell'istanza Compute Engine sottostante, non al nome del nodo Kubernetes. Puoi trovare il nome dell'istanza di un nodo eseguendo il comando kubectl describe node NODE_NAME e cercando il campo ProviderID nell'output. Il nome dell'istanza è l'ultima parte di questo valore. Ad esempio:

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

      In questo esempio, il nome dell'istanza è gke-my-cluster-default-pool-1234abcd-5678.

Identificare la causa in base al sintomo

Se hai identificato un sintomo specifico, ad esempio un messaggio di log, una condizione del nodo o un evento del cluster, utilizza la tabella seguente per trovare consigli per la risoluzione dei problemi:

Categoria Sintomo o messaggio di log Possibile causa Passaggi per la risoluzione dei problemi
Condizioni dei nodi NetworkUnavailable: True Problema di connettività dal nodo al control plane o errore del plug-in Container Network Interface (CNI). Risolvere i problemi di connettività di rete
MemoryPressure: True Il nodo ha memoria insufficiente. Risolvere i problemi relativi alla carenza di risorse dei nodi
DiskPressure: True Il nodo ha spazio su disco insufficiente. Risolvere i problemi relativi alla carenza di risorse dei nodi
PIDPressure: True Il nodo non dispone di ID processo sufficienti. Risolvere i problemi relativi alla carenza di risorse dei nodi
Eventi e messaggi di log PLEG is not healthy Kubelet è sovraccarico a causa di un utilizzo elevato di CPU/I/O o di un numero eccessivo di pod. Risolvere i problemi relativi a PLEG
Out of memory: Kill process
sys oom event		 La memoria del nodo è completamente esaurita. Risolvere gli eventi OOM a livello di sistema
leases.coordination.k8s.io...is forbidden Lo spazio dei nomi kube-node-lease è bloccato in fase di terminazione. Risolvere i problemi relativi allo spazio dei nomi kube-node-lease
Container runtime not ready
runtime is down
Errori che fanno riferimento a /run/containerd/containerd.sock o docker.sock		 Il servizio Containerd o Docker non è riuscito o è configurato in modo errato. Risolvere i problemi di runtime del container
Pod bloccati in Terminating
I log di Kubelet mostrano DeadlineExceeded per l'eliminazione del container
I log di containerd mostrano messaggi Kill container ripetuti		 Processi bloccati in stato di sospensione del disco non interrompibile (stato D), spesso correlati a I/O. Risolvere i processi bloccati nello stato D
Sintomi a livello di cluster Più nodi non funzionano dopo l'implementazione di un DaemonSet. DaemonSet interferisce con le operazioni sui nodi. Risolvere i problemi causati dai DaemonSet di terze parti
compute.instances.preempted negli audit log. La VM spot è stata prerilasciata, il che è un comportamento previsto. Conferma il preempting del nodo
kube-system Pod bloccati in Pending. Il webhook di ammissione sta bloccando i componenti critici. Risolvere i problemi causati dai webhook di ammissione
exceeded quota: gcp-critical-pods La quota configurata in modo errato sta bloccando i pod di sistema. Risolvere i problemi causati dalle quote delle risorse

Controlla gli eventi NotReady previsti

Lo stato NotReady non indica sempre un problema. Può essere un comportamento previsto durante operazioni pianificate come un upgrade del pool di nodi o se utilizzi determinati tipi di macchine virtuali.

Conferma le operazioni del ciclo di vita dei nodi

Sintomi:

Un nodo mostra temporaneamente lo stato NotReady durante determinati eventi del ciclo di vita.

Causa:

Lo stato di un nodo diventa temporaneamente NotReady durante diversi eventi comuni del ciclo di vita. Questo comportamento è previsto ogni volta che viene creato o ricreato un nodo, ad esempio nei seguenti scenari:

  • Upgrade del node pool: durante un upgrade, ogni nodo viene svuotato e sostituito. Il nuovo nodo sottoposto ad upgrade ha lo stato NotReady finché non termina l'inizializzazione e non entra a far parte del cluster.
  • Riparazione automatica dei nodi: quando GKE sostituisce un nodo malfunzionante, il nodo sostitutivo rimane NotReady durante il provisioning.
  • Scalabilità verticale di Cluster Autoscaler: quando vengono aggiunti nuovi nodi, questi iniziano con lo stato NotReady e diventano Ready solo dopo il provisioning completo e l'aggiunta al cluster.
  • Modifiche manuali al modello di istanza: GKE ricrea i nodi quando applichi le modifiche al modello. Il nuovo nodo ha lo stato NotReady durante la fase di avvio.

Risoluzione:

I nodi devono avere lo stato NotReady solo per un breve periodo. Se lo stato persiste per più di 10 minuti, esamina altre cause.

Conferma il preempting del nodo

Se il nodo è in esecuzione su una VM spot o una VM prerilasciabile, Compute Engine potrebbe terminarlo bruscamente per recuperare risorse. Si tratta di un comportamento previsto per questi tipi di macchine virtuali di breve durata e non è un errore.

Sintomi:

Se osservi i seguenti sintomi, lo stato NotReady del nodo è probabilmente causato da un prerilascio previsto della VM spot:

  • Un nodo entra inaspettatamente in uno stato NotReady prima di essere eliminato e ricreato dal gestore della scalabilità automatica del cluster.
  • Cloud Audit Logs mostra un evento compute.instances.preempted per l'istanza VM sottostante.

Causa:

Il nodo veniva eseguito su un'istanza VM Spot o VM prerilasciabile e Compute Engine ha recuperato queste risorse di calcolo per un'altra attività. Le VM spot possono essere interrotte in qualsiasi momento, anche se in genere forniscono un avviso di terminazione di 30 secondi.

Risoluzione:

Utilizza le VM spot o le VM prerilasciabili solo per carichi di lavoro batch, stateless o a tolleranza di errore progettati per gestire correttamente le interruzioni frequenti. Per i workload di produzione o stateful che non possono tollerare interruzioni improvvise, esegui il provisioning dei pool di nodi utilizzando VM standard on demand.

Risolvi i problemi di carenza di risorse dei nodi

Un nodo spesso diventa NotReady perché non dispone di risorse essenziali come CPU, memoria o spazio su disco. Quando un nodo non dispone di risorse sufficienti, i componenti critici non possono funzionare correttamente, causando instabilità dell'applicazione e mancata risposta del nodo. Le sezioni seguenti illustrano i diversi modi in cui queste carenze possono manifestarsi, dalle condizioni di pressione generali agli eventi più gravi a livello di sistema.

Risolvi la pressione delle risorse del nodo

L'esaurimento delle risorse si verifica quando un nodo non dispone di CPU, memoria, spazio su disco o ID processo (PID) sufficienti per eseguire i suoi workload. Questo problema può portare allo stato NotReady.

Sintomi:

Se osservi le seguenti condizioni e i seguenti log dei nodi, l'esaurimento delle risorse è la probabile causa dello stato NotReady del nodo:

  • Nell'output del comando kubectl describe node, viene visualizzato lo stato True per condizioni come OutOfDisk, MemoryPressure, DiskPressure o PIDPressure.
  • I log kubelet potrebbero contenere eventi Out of Memory (OOM), che indicano che è stato richiamato OOM Killer del sistema.

Causa:

I carichi di lavoro sul nodo richiedono collettivamente più risorse di quelle che il nodo può fornire.

Risoluzione:

Per i cluster standard, prova le seguenti soluzioni:

Per i cluster Autopilot, non controlli direttamente i tipi di macchina dei nodi o le dimensioni del disco di avvio. La capacità dei nodi viene gestita automaticamente in base alle richieste dei pod. Assicurati che le richieste di risorse del tuo workload rientrino nei limiti di Autopilot e riflettano con precisione le esigenze della tua applicazione. I problemi persistenti con le risorse potrebbero indicare la necessità di ottimizzare le richieste di pod o, in rari casi, un problema della piattaforma che richiede l'assistenza di assistenza clienti Google Cloud.

Risolvere eventi OOM a livello di sistema

Un evento di esaurimento della memoria (OOM) a livello di sistema si verifica quando la memoria totale di un nodo è esaurita, il che costringe il kernel Linux a terminare i processi per liberare risorse. Questo evento è diverso da un evento OOM a livello di container, in cui un singolo pod supera i limiti di memoria.

Sintomi:

Se noti i seguenti sintomi, un evento OOM a livello di sistema è la probabile causa dell'instabilità del nodo:

  • Nel log della console seriale del nodo viene visualizzato il messaggio Out of memory: Kill process.
  • I log kubelet contengono eventi oom_watcher, che indicano che kubelet ha rilevato un evento OOM a livello di sistema.
  • Terminazione imprevista di vari processi, inclusi daemon di sistema o pod di workload potenzialmente critici, non necessariamente i consumatori di memoria più elevati.

Causa:

La memoria complessiva del nodo è esaurita. Questo problema può essere dovuto a un bug in un servizio di sistema, a un workload configurato in modo errato che consuma una quantità eccessiva di memoria o a un nodo troppo piccolo per le richieste di memoria collettive di tutti i pod in esecuzione.

Risoluzione:

Per risolvere gli eventi OOM a livello di sistema, diagnostica la causa e poi riduci la richiesta di memoria o aumenta la capacità dei nodi. Per maggiori informazioni, consulta Risoluzione dei problemi relativi agli eventi OOM.

Risolvere i problemi relativi a PLEG

Il generatore di eventi del ciclo di vita del pod (PLEG) è un componente di kubelet. Controlla periodicamente lo stato di tutti i container sul nodo e segnala eventuali modifiche a Kubelet.

Quando PLEG riscontra problemi di prestazioni, non può fornire aggiornamenti tempestivi a kubelet, il che può causare l'instabilità del nodo.

Sintomi:

Se osservi i seguenti sintomi, il PLEG potrebbe non funzionare correttamente:

  • I log kubelet per il nodo contengono un messaggio simile a PLEG is not healthy.
  • Lo stato del nodo cambia spesso tra Ready e NotReady.

Causa:

I problemi PLEG sono in genere causati da problemi di prestazioni che impediscono a kubelet di ricevere aggiornamenti tempestivi dal runtime del container. Le cause comuni includono quanto segue:

  • Carico della CPU elevato: la CPU del nodo è satura, il che impedisce a kubelet e al runtime del container di avere la potenza di elaborazione di cui hanno bisogno.
  • Limitazione I/O: il disco di avvio del nodo sta eseguendo operazioni di I/O pesanti, che possono rallentare tutte le attività correlate al disco.
  • Pod eccessivi: un numero eccessivo di pod su un singolo nodo può sovraccaricare kubelet e il runtime del container, causando contesa delle risorse.

Risoluzione:

Per i cluster standard, riduci il carico sulle risorse del nodo:

Per i cluster Autopilot, anche se non puoi modificare direttamente le dimensioni o il tipo di disco di un nodo esistente, puoi influire sull'hardware su cui vengono eseguiti i tuoi workload utilizzando ComputeClass personalizzate. Questa funzionalità consente di specificare i requisiti nel manifest del workload, ad esempio una quantità minima di CPU e memoria o una serie di macchine specifica, per guidare la pianificazione dei pod.

Se non utilizzi ComputeClass, modifica i deployment dei workload (ad esempio i conteggi delle repliche e le richieste o i limiti delle risorse) e assicurati che rientrino nei vincoli di Autopilot. Se i problemi relativi a PLEG persistono dopo l'ottimizzazione dei carichi di lavoro, contatta l'assistenza clienti Google Cloud.

Risolvere i processi bloccati nello stato D

I processi bloccati in uno stato di sospensione del disco non interrompibile (stato D) possono rendere un nodo non reattivo. Questo problema impedisce la terminazione dei pod e può causare l'errore di componenti critici come containerd, con conseguente stato NotReady.

Sintomi:

  • I pod, in particolare quelli che utilizzano l'archiviazione di rete come NFS, rimangono a lungo nello stato Terminating.
  • I log di Kubelet mostrano errori DeadlineExceeded durante il tentativo di arrestare un container.
  • I log della console seriale del nodo potrebbero mostrare messaggi del kernel relativi a hung tasks o attività bloccate per più di 120 secondi.

Causa:

I processi entrano in uno stato D quando sono in attesa del completamento di un'operazione I/O e non possono essere interrotti. Le cause comuni includono:

  • File system remoti lenti o che non rispondono, ad esempio una condivisione NFS configurata in modo errato o sovraccarica.
  • Grave degrado delle prestazioni del disco o errori I/O hardware sui dischi locali del nodo.

Risoluzione:

Per risolvere i problemi relativi ai processi in stato D, identifica l'origine I/O e poi cancella lo stato selezionando una delle seguenti opzioni:

Cluster standard

  1. Trova il processo bloccato e determina cosa sta aspettando:

    1. Connettiti al nodo interessato utilizzando SSH:

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

      Sostituisci quanto segue:

      • NODE_NAME: il nome del nodo a cui connettersi.
      • ZONE: la zona Compute Engine del nodo.
      • PROJECT_ID: il tuo ID progetto.

    2. Trova eventuali processi in stato D:

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

      L'output è simile al seguente:

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

      L'output non avrà un'intestazione. Le colonne, in ordine, rappresentano:

      • Stato
      • ID processo (PID)
      • Comando
      • Canale di attesa (wchan)

    3. Esamina la colonna wchan per identificare l'origine I/O:

      • Se la colonna wchan include termini come nfs o rpc, il processo è in attesa di una condivisione NFS.
      • Se la colonna wchan include termini come io_schedule, jbd2 o ext4, il processo è in attesa del disco di avvio locale del nodo.

    4. Per ulteriori dettagli sulle funzioni del kernel su cui è in attesa il processo, controlla lo stack di chiamate del kernel del processo:

      cat /proc/PID/stack

      Sostituisci PID con l'ID processo che hai trovato nel passaggio precedente.

  2. Riavvia il nodo. Il riavvio è spesso il modo più efficace per eliminare un processo bloccato in stato D.

    1. Svuota il nodo.
    2. Elimina l'istanza VM sottostante. In genere GKE crea una nuova VM per sostituirla.

  3. Dopo aver risolto il problema immediato, esamina il sistema di archiviazione sottostante per evitare che si ripresenti.

    • Per problemi di archiviazione di rete (NFS): utilizza gli strumenti di monitoraggio del tuo provider di archiviazione per verificare la presenza di latenza elevata, errori lato server o problemi di rete tra il nodo GKE e il server NFS.

    • Per problemi relativi al disco locale: verifica la limitazione I/O in Cloud Monitoring visualizzando le metriche compute.googleapis.com/instance/disk/throttled_read_ops_count e compute.googleapis.com/instance/disk/throttled_write_ops_count per l'istanza Compute Engine.

Cluster Autopilot

  1. Prova a identificare l'origine del blocco:

    L'accesso SSH diretto ai nodi e l'esecuzione di comandi come ps o cat /proc non sono disponibili nei cluster Autopilot. Devi fare affidamento a log e metriche.

    1. Controlla i log dei nodi: in Cloud Logging, analizza i log del nodo interessato. Filtra per nome del nodo e intervallo di tempo del problema. Cerca messaggi del kernel che indicano errori di I/O, timeout di archiviazione (ad esempio su disco o NFS) o messaggi dei driver CSI.
    2. Controlla i log del workload: esamina i log dei pod in esecuzione sul nodo interessato. I log delle applicazioni potrebbero rivelare errori relativi a operazioni sui file, chiamate di database o accesso allo spazio di archiviazione di rete.
    3. Utilizza Cloud Monitoring: anche se non puoi ottenere dettagli a livello di processo, verifica la presenza di problemi di I/O a livello di nodo.

  2. Attiva la sostituzione di un nodo per cancellare lo stato.

    Non puoi eliminare manualmente la VM sottostante. Per attivare una sostituzione, svuota il nodo. Questa azione isola il nodo ed espelle i pod.

    GKE rileva automaticamente i nodi non integri e avvia le riparazioni, in genere sostituendo la VM sottostante.

    Se il nodo rimane bloccato dopo lo svuotamento e non viene sostituito automaticamente, contatta l'assistenza clienti Google Cloud.

  3. Dopo aver risolto il problema immediato, esamina il sistema di archiviazione sottostante per evitare che si ripresenti.

    • Per i problemi relativi al disco locale: verifica la limitazione I/O in Cloud Monitoring visualizzando le metriche compute.googleapis.com/instance/disk/throttled_read_ops_count e compute.googleapis.com/instance/disk/throttled_write_ops_count. Puoi filtrare queste metriche per il gruppo di istanze sottostante del pool di nodi, anche se le singole istanze sono gestite da Google.
    • Per problemi di archiviazione di rete (NFS): utilizza gli strumenti di monitoraggio del tuo provider di archiviazione per verificare la presenza di latenza elevata, errori lato server o problemi di rete tra il nodo GKE e il server NFS. Controlla i log di tutti i pod dei driver CSI in Cloud Logging.

Risolvere i problemi relativi agli errori dei componenti principali

Dopo aver escluso le cause previste e la carenza di risorse, il software del nodo o un meccanismo Kubernetes di base potrebbe essere la causa del problema. Uno stato NotReady può verificarsi quando un componente critico, come il runtime del container, non funziona. Può verificarsi anche quando un meccanismo di controllo di integrità principale di Kubernetes, come il sistema di lease dei nodi, si interrompe.

Risolvere i problemi del runtime container

I problemi con il runtime del container, ad esempio containerd, possono impedire a kubelet di avviare i pod su un nodo.

Sintomi:

Se nei log di kubelet vengono visualizzati i seguenti messaggi, un problema di runtime del container è la causa probabile dello stato NotReady del nodo:

  • Container runtime not ready
  • Container runtime docker failed!
  • docker daemon exited
  • Errori di connessione al socket di runtime (ad esempio, unix:///var/run/docker.sock o unix:///run/containerd/containerd.sock).

Causa:

Il runtime del container non funziona correttamente, è configurato in modo errato o è bloccato in un ciclo di riavvio.

Risoluzione:

Per risolvere i problemi del runtime del container:

  1. Analizza i log di runtime dei container:

    1. Nella console Google Cloud , vai alla pagina Esplora log.

      Vai a Esplora log

    2. Per visualizzare tutti i log di avviso ed errore del runtime del container sul nodo interessato, inserisci quanto segue nel riquadro della query:

      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

      Sostituisci quanto segue:

      • NODE_NAME: il nome del nodo che stai esaminando.
      • CLUSTER_NAME: il nome del tuo cluster.
      • LOCATION: la regione o la zona di Compute Engine (ad esempio us-central1 o us-central1-a) per il cluster.

    3. Fai clic su Esegui query ed esamina l'output per individuare messaggi di errore specifici che indicano il motivo per cui l'esecuzione non è riuscita. Un messaggio come failed to load TOML nei log containerd in Cloud Logging spesso indica un file danneggiato.

    4. Per verificare se il runtime è bloccato in un ciclo di riavvio, esegui una query che cerchi i messaggi di avvio. Un numero elevato di questi messaggi in un breve periodo conferma i riavvii frequenti.

      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")

      I riavvii frequenti spesso indicano un problema sottostante, ad esempio un file di configurazione danneggiato o una pressione delle risorse, che causa l'arresto anomalo ripetuto del servizio.

  2. Rivedi la configurazione di containerd per le modifiche: impostazioni errate possono causare l'errore del runtime del container. Puoi apportare modifiche alla configurazione tramite un file di configurazione del sistema dei nodi o tramite modifiche dirette apportate dai workload con privilegi elevati.

    1. Determina se il pool di nodi utilizza un file di configurazione del sistema di nodi:

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

      Sostituisci quanto segue:

      • NODE_POOL_NAME: il nome del tuo pool di nodi.
      • CLUSTER_NAME: il nome del tuo cluster.
      • LOCATION: la regione o la zona Compute Engine del tuo cluster.

      Se l'output mostra una sezione containerdConfig, GKE gestisce queste impostazioni personalizzate. Per modificare o ripristinare le impostazioni, segui le istruzioni in Personalizza la configurazione di containerd nei nodi GKE.

    2. Se le personalizzazioni gestite da GKE non sono attive o se sospetti altre modifiche, cerca i carichi di lavoro che potrebbero modificare direttamente il file system del nodo. Cerca DaemonSet con privilegi elevati (securityContext.privileged: true) o volumi hostPath che montano directory sensibili come /etc.

      Per esaminare la configurazione, elenca tutti i DaemonSet in formato YAML:

      kubectl get daemonsets --all-namespaces -o yaml

      Esamina l'output e controlla i log di eventuali DaemonSet sospetti.

    3. Per i cluster Standard, esamina direttamente il file di configurazione. L'accesso SSH e l'ispezione manuale dei file non sono possibili nei cluster Autopilot, perché Google gestisce la configurazione del runtime. Segnala problemi di runtime persistenti all'assistenza clienti Google Cloud.

      Se utilizzi un cluster Standard, esamina il file:

      1. Connettiti al nodo utilizzando SSH:

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

        Sostituisci quanto segue:

        • NODE_NAME: il nome del nodo a cui connettersi.
        • ZONE: la zona Compute Engine del nodo.
        • PROJECT_ID: il tuo ID progetto.

      2. Visualizza i contenuti del file di configurazione di containerd:

        sudo cat /etc/containerd/config.toml

      3. Per verificare le modifiche recenti, elenca i dettagli del file:

        ls -l /etc/containerd/config.toml

    4. Confronta i contenuti di questo file con l'output di containerdConfig del comando gcloud node-pools describe eseguito nel passaggio precedente. Qualsiasi impostazione in /etc/containerd/config.toml che non è presente nell'output di gcloud è una modifica non gestita.

    5. Per correggere eventuali errori di configurazione, rimuovi le modifiche che non sono state applicate tramite una configurazione di sistema dei nodi.

  3. Risolvi i problemi comuni di runtime: per ulteriori passaggi per la risoluzione dei problemi, vedi Risoluzione dei problemi relativi al runtime del container.

Risolvere i problemi relativi allo spazio dei nomi kube-node-lease

Le risorse nello spazio dei nomi kube-node-lease sono responsabili del mantenimento dell'integrità dei nodi. Questo spazio dei nomi non deve essere eliminato. I tentativi di eliminazione di questo spazio dei nomi comportano il blocco dello spazio dei nomi nello stato Terminating. Quando lo spazio dei nomi kube-node-lease si blocca nello stato Terminating, i kubelet non possono rinnovare i lease di controllo dell'integrità. Questo problema fa sì che il control plane consideri i nodi non integri, il che porta a un problema a livello di cluster in cui i nodi alternano gli stati Ready e NotReady.

Sintomi:

Se osservi i seguenti sintomi, è probabile che un problema con lo spazio dei nomi kube-node-lease sia la causa dell'instabilità a livello di cluster:

  • I log di kubelet su ogni nodo mostrano errori persistenti simili ai seguenti:

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

  • I nodi del cluster alternano ripetutamente gli stati Ready e NotReady.

Causa:

Lo spazio dei nomi kube-node-lease, che gestisce i heartbeat dei nodi, è bloccato in modo anomalo nello stato Terminating. Questo errore impedisce al server API Kubernetes di consentire la creazione o la modifica di oggetti all'interno dello spazio dei nomi. Di conseguenza, i kubelet non possono rinnovare i propri oggetti Lease, che sono essenziali per segnalare la loro attività al control plane. Senza questi aggiornamenti di stato, il control plane non può confermare che i nodi sono integri, il che comporta l'alternarsi degli stati dei nodi tra Ready e NotReady.

I motivi di fondo per cui lo spazio dei nomi kube-node-lease potrebbe bloccarsi nello stato Terminating includono:

  • Risorse con finalizzatori: sebbene meno comuni per lo spazio dei nomi kube-node-lease del sistema (che contiene principalmente oggetti Lease), una risorsa al suo interno potrebbe avere un finalizzatore. I finalizer di Kubernetes sono chiavi che segnalano a un controller di eseguire attività di pulizia prima che una risorsa possa essere eliminata. Se il controller responsabile della rimozione del finalizer non funziona correttamente, la risorsa non viene eliminata e il processo di eliminazione dello spazio dei nomi viene interrotto.
  • Servizi API aggregati non integri o che non rispondono: la terminazione dello spazio dei nomi può essere bloccata se un oggetto APIService, utilizzato per registrare un server API aggregato, è collegato allo spazio dei nomi e diventa non integro. Il piano di controllo potrebbe attendere che il server API aggregato venga arrestato o pulito correttamente, il che non avverrà se il servizio non risponde.
  • Problemi con il control plane o il controller: in rari casi, bug o problemi all'interno del control plane Kubernetes, in particolare del controller dello spazio dei nomi, potrebbero impedire la garbage collection e l'eliminazione dello spazio dei nomi.

Risoluzione:

Segui le indicazioni riportate in Risolvere i problemi relativi agli spazi dei nomi bloccati nello stato Terminating.

Risoluzione dei problemi di connettività di rete

I problemi di rete possono impedire a un nodo di comunicare con il control plane o impedire il funzionamento di componenti critici come il plug-in CNI, con conseguente stato NotReady.

Sintomi:

Se osservi i seguenti sintomi, i problemi di rete potrebbero essere la causa dello stato NotReady dei tuoi nodi:

  • La condizione NetworkNotReady è True.
  • I log di Kubelet sul nodo mostrano errori simili ai seguenti:
    • connection timeout to the control plane IP address
    • network plugin not ready
    • CNI plugin not initialized
    • connection refused o timeout quando tenti di raggiungere l'indirizzo IP del control plane.
  • I pod, in particolare nello spazio dei nomi kube-system, sono bloccati in ContainerCreating con eventi come NetworkPluginNotReady.

Causa:

I sintomi correlati alla rete in genere indicano un errore in una delle seguenti aree:

  • Problemi di connettività: il nodo non riesce a stabilire una connessione di rete stabile al control plane Kubernetes.
  • Errore del plug-in CNI: il plug-in CNI, responsabile della configurazione del networking dei pod, non è in esecuzione correttamente o non è stato inizializzato.
  • Problemi relativi ai webhook: i webhook di controllo dell'ammissione configurati in modo errato possono interferire con le risorse correlate al plug-in CNI, impedendo la corretta configurazione della rete.

Risoluzione:

Per risolvere i problemi di rete:

  1. Stato temporaneo dell'indirizzo NetworkNotReady: sui nodi appena creati, è normale visualizzare un breve evento NetworkNotReady. Questo stato dovrebbe risolversi entro un minuto o due durante l'inizializzazione del plug-in CNI e di altri componenti. Se lo stato persiste, procedi con i passaggi successivi.

  2. Verifica la connettività dal nodo al control plane e le regole firewall: assicurati che il percorso di rete tra il nodo e il control plane sia aperto e funzioni correttamente:

    1. Controlla le regole firewall: assicurati che le regole firewall VPC consentano il traffico necessario tra i nodi GKE e il control plane. Per informazioni sulle regole richieste da GKE per la comunicazione tra i nodi e il control plane, consulta Regole firewall create automaticamente.
    2. Verifica della connettività: utilizza il test di connettività in Network Intelligence Center per verificare il percorso di rete tra l'indirizzo IP interno del nodo e l'indirizzo IP dell'endpoint del control plane sulla porta 443. Un risultato di Not Reachable spesso ti aiuta a identificare la regola firewall o il problema di routing che blocca la comunicazione.

  3. Esamina lo stato e i log del plug-in CNI: se la rete del nodo non è pronta, il problema potrebbe essere dovuto al plug-in CNI.

    1. Controlla lo stato del pod CNI: identifica il plug-in CNI in uso (ad esempio, netd o calico-node) e controlla lo stato dei relativi pod nello spazio dei nomi kube-system. Puoi filtrare il nodo specifico con il seguente comando:

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

    2. Esamina i log dei pod CNI: se i pod non funzionano correttamente, esamina i relativi log in Cloud Logging per visualizzare messaggi di errore dettagliati. Utilizza una query simile alla seguente per i pod netd su un nodo specifico:

      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. Errori CNI specifici per l'indirizzo:

      • Se i log mostrano Failed to allocate IP address, gli intervalli di indirizzi IP dei pod potrebbero essere esauriti. Verifica l'utilizzo degli indirizzi IP dei pod e rivedi gli intervalli CIDR del cluster.
      • Se i log mostrano NetworkPluginNotReady o cni plugin not initialized, verifica che il nodo disponga di risorse di CPU e memoria sufficienti. Puoi anche provare a riavviare il pod CNI eliminandolo, in modo che DaemonSet lo ricrei.
      • Se utilizzi GKE Dataplane V2 e i log mostrano Cilium API client timeout exceeded, riavvia il pod anetd sul nodo.

    4. Verifica la presenza di interferenze del webhook di ammissione: i webhook malfunzionanti possono impedire l'avvio dei pod CNI, lasciando il nodo in uno stato NetworkNotReady.

    5. Controlla i log del server API: esamina i log del server API in Cloud Logging per gli errori relativi alle chiamate webhook. Per identificare se un webhook blocca la creazione di risorse CNI, cerca messaggi come failed calling webhook.

      Se un webhook causa problemi, potrebbe essere necessario identificare il ValidatingWebhookConfiguration o MutatingWebhookConfiguration problematico e disattivarlo temporaneamente per consentire al nodo di diventare pronto. Per saperne di più, consulta Risolvere i problemi causati dai webhook di ammissione.

Risolvere i problemi di configurazione errata del cluster

Le sezioni seguenti ti aiutano a controllare alcune configurazioni a livello di cluster che potrebbero interferire con le normali operazioni dei nodi.

Risolvere i problemi causati dagli webhook di ammissione

Un webhook di controllo degli accessi configurato in modo errato, non disponibile o troppo lento può bloccare richieste API critiche, impedendo l'avvio di componenti essenziali o l'unione di nodi al cluster.

Sintomi:

Se osservi i seguenti sintomi, è probabile che un webhook di controllo dell'ammissione non configurato correttamente o non disponibile stia bloccando le operazioni essenziali del cluster:

  • I pod, in particolare nello spazio dei nomi kube-system (come i pod CNI o di archiviazione), sono bloccati nello stato Pending o Terminating.
  • I nuovi nodi non riescono a unirsi al cluster, spesso con timeout con stato NotReady.

Causa:

I webhook di controllo dell'ammissione configurati in modo errato o che non rispondono potrebbero bloccare operazioni essenziali del cluster.

Risoluzione:

Rivedi le configurazioni dei webhook per assicurarti che siano resilienti e con un ambito definito correttamente. Per evitare interruzioni, imposta il campo failurePolicy su Ignore per i webhook non critici. Per i webhook critici, assicurati che il servizio di backend sia a disponibilità elevata ed escludi lo spazio dei nomi kube-system dalla supervisione dei webhook utilizzando un namespaceSelector per evitare deadlock del control plane. Per saperne di più, consulta Garantire la stabilità del control plane quando si utilizzano webhook.

Risolvere i problemi causati dalle quote delle risorse

Una quota di risorse calcolata in modo errato nello spazio dei nomi kube-system può impedire a GKE di creare pod di sistema critici. Poiché componenti come il networking (CNI) e il DNS sono bloccati, questo problema può impedire ai nuovi nodi di unirsi correttamente al cluster.

Sintomi:

  • I pod critici nello spazio dei nomi kube-system (ad esempio netd, konnectivity-agent o kube-dns) sono bloccati nello stato Pending.
  • I messaggi di errore nei log del cluster o nell'output di kubectl describe pod mostrano errori come exceeded quota: gcp-critical-pods.

Causa:

Questo problema si verifica quando il controller della quota di risorse Kubernetes smette di aggiornare con precisione il conteggio utilizzato negli oggetti ResourceQuota. Una causa comune è un webhook di ammissione di terze parti malfunzionante che blocca gli aggiornamenti del controller, facendo sembrare l'utilizzo della quota molto più elevato di quanto non sia in realtà.

Risoluzione:

  1. Poiché la causa principale più probabile è un webhook problematico, segui le indicazioni nella sezione Risolvere i problemi causati dai webhook di ammissione per identificare e correggere eventuali webhook che potrebbero bloccare i componenti del sistema. La correzione del webhook spesso risolve automaticamente il problema della quota.

  2. Verifica che l'utilizzo registrato della quota non sia sincronizzato con il numero effettivo di pod in esecuzione. Questo passaggio conferma se il conteggio dell'oggetto ResourceQuota è errato:

    1. Controlla l'utilizzo segnalato della quota:

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

    2. Controlla il numero effettivo di pod:

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

  3. Se il conteggio di utilizzo in ResourceQuota sembra errato (ad esempio, molto superiore al numero effettivo di pod), elimina l'oggetto gcp-critical-pods. Il control plane GKE è progettato per ricreare automaticamente questo oggetto con i conteggi di utilizzo corretti e riconciliati:

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

  4. Monitora lo spazio dei nomi kube-system per alcuni minuti per assicurarti che l'oggetto venga ricreato e che la pianificazione dei pod in attesa inizi.

Risolvere i problemi causati dai DaemonSet di terze parti

Un DaemonSet di terze parti appena implementato o aggiornato, spesso utilizzato per la sicurezza, il monitoraggio o la registrazione, a volte può causare l'instabilità dei nodi. Questo problema può verificarsi se DaemonSet interferisce con il runtime del container o con il networking del nodo, consuma risorse di sistema eccessive o apporta modifiche inattese al sistema.

Sintomi:

Se osservi i seguenti sintomi, un DaemonSet di terze parti recentemente implementato o modificato è una possibile causa di errori del nodo:

  • Più nodi, potenzialmente in tutto il cluster, entrano in uno stato NotReady poco dopo il deployment o l'aggiornamento di DaemonSet.
  • I log di Kubelet per i nodi interessati segnalano errori come i seguenti:
    • container runtime is down
    • Failed to create pod sandbox
    • Errori di connessione al socket del runtime del container (ad esempio, /run/containerd/containerd.sock).
  • I pod, inclusi i pod di sistema o i pod di DaemonSet, sono bloccati negli stati PodInitializing o ContainerCreating.
  • I log dei container per le applicazioni mostrano errori insoliti, come exec format error.
  • Node Problem Detector potrebbe segnalare condizioni correlate all'integrità del runtime o alla pressione delle risorse.

Causa:

Il DaemonSet di terze parti potrebbe influire sulla stabilità dei nodi per i seguenti motivi:

  • Consumare CPU, memoria o I/O del disco eccessivi, il che influisce sulle prestazioni dei componenti critici del nodo.
  • Interferire con il funzionamento del runtime del container.
  • Causando conflitti con la configurazione di rete del nodo o con il plug-in Container Network Interface (CNI).
  • Modifica delle configurazioni di sistema o dei criteri di sicurezza in modo non intenzionale.

Risoluzione:

Per determinare se la causa è un DaemonSet, isolalo e testalo:

  1. Identifica i DaemonSet: elenca tutti i DaemonSet in esecuzione nel tuo cluster:

    kubectl get daemonsets --all-namespaces

    Presta particolare attenzione ai DaemonSet che non fanno parte dell'installazione GKE predefinita.

    Spesso puoi identificare questi DaemonSet esaminando quanto segue:

    • Spazio dei nomi: i componenti GKE predefiniti vengono in genere eseguiti nello spazio dei nomi kube-system. I DaemonSet in altri spazi dei nomi sono probabilmente di terze parti o personalizzati.
    • Denominazione: i DaemonSet predefiniti spesso hanno nomi come gke-metrics-agent, netd o calico-node. Gli agenti di terze parti spesso hanno nomi che riflettono il prodotto.

  2. Correlare il tempo di deployment: verifica se la visualizzazione di NotReady nodi coincide con il deployment o l'aggiornamento di un DaemonSet di terze parti specifico.

  3. Test su un singolo nodo:

    1. Scegli un nodo interessato.
    2. Contrassegna il nodo come non pianificabile e svuotalo.
    3. Impedisci temporaneamente la pianificazione del DaemonSet su questo nodo:
      • Applica un'etichetta di nodo temporanea e configura l'affinità o l'anti-affinità dei nodi nel manifest di DaemonSet.
      • Elimina il pod di DaemonSet sul nodo specifico.
    4. Riavvia l'istanza della macchina virtuale del nodo.
    5. Osserva se il nodo diventa Ready e rimane stabile mentre DaemonSet non è in esecuzione. Se i problemi si ripresentano dopo la reintroduzione del DaemonSet, è probabile che sia un fattore che contribuisce al problema.

  4. Consulta il fornitore: se sospetti che la causa sia un agente di terze parti, consulta la documentazione del fornitore per problemi di compatibilità noti o best practice per l'esecuzione dell'agente su GKE. Se hai bisogno di ulteriore assistenza, contatta il fornitore del software.

Verifica che il nodo sia stato ripristinato

Dopo aver applicato una potenziale soluzione, segui questi passaggi per verificare che il nodo sia stato recuperato correttamente e sia stabile:

  1. Controlla lo stato del nodo:

    kubectl get nodes -o wide

    Cerca il nodo interessato nell'output. Ora la colonna Status dovrebbe mostrare un valore di Ready. L'aggiornamento dello stato potrebbe richiedere alcuni minuti dopo l'applicazione della correzione. Se lo stato continua a mostrare NotReady o alterna gli stati, il problema non è completamente risolto.

  2. Esamina la sezione Conditions del nodo:

    kubectl describe node NODE_NAME

    Nella sezione Conditions, verifica i seguenti valori:

    • La condizione Ready ha lo stato True.
    • Le condizioni negative che in precedenza avevano lo stato True (ad esempio, MemoryPressure o NetworkUnavailable) ora hanno lo stato False. I campi Reason e Message per queste condizioni devono indicare che il problema è stato risolto.

  3. Testa la pianificazione dei pod. Se in precedenza il nodo non era in grado di eseguire carichi di lavoro, controlla se sono stati pianificati nuovi pod e se i pod esistenti sono in esecuzione senza problemi:

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

    I pod sul nodo devono avere lo stato Running o Completed. Non dovresti vedere pod bloccati in Pending o altri stati di errore.

Passaggi successivi