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 Cloud de Confiance by S3NS , consulta Ruoli utente GKE comuni e attività.

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 Cloud de Confiance by S3NS :

  • Per accedere ai cluster GKE: Visualizzatore cluster Kubernetes Engine (roles/container.viewer).
  • Per visualizzare i log: Visualizzatore log (roles/logging.viewer).
  • Per visualizzare le metriche: Monitoring Viewer (roles/monitoring.viewer).

  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 tuo 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 Cloud de Confiance by S3NS .

Controllare lo stato e le condizioni del nodo

Per verificare che un nodo abbia 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 gli indirizzi IP e le versioni 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 NotReady nella colonna STATUS e prendi nota dei loro 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 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 molta attenzione ai campi Reason e Message per queste condizioni, poiché spiegano la causa del problema.

   Ecco il significato di ogni 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 su disco disponibile è completamente esaurito. Questa condizione è più grave di DiskPressure.
   • MemoryPressure: True se la memoria del nodo è insufficiente.
   • DiskPressure: True se lo spazio su disco sul nodo è ridotto.
   • PIDPressure: True se il nodo sta esaurendo gli ID di 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 riceve 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, come 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 suoi componenti.

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

      kubelet è l'agente principale che segnala lo stato del nodo al control plane, quindi i suoi log sono il luogo più probabile in cui trovare il messaggio NotReady letterale. 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 di Kubernetes.

   2. Nella Cloud de Confiance 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) del 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 (come 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 del ciclo di vita completo del container, tra cui il pull delle immagini e la gestione dell'esecuzione del container. L'esame dei log di container-runtime è essenziale per risolvere i problemi relativi alla creazione di istanze dei 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, ad esempio blocchi 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 Esplora metriche per cercare l'esaurimento delle risorse nel momento in cui il nodo è diventato NotReady:

   1. Nella console Cloud de Confiance , 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. La quantità 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 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 dal livello dell'hypervisor, utilizza le metriche con prefisso compute.googleapis.com/instance/, ad esempio compute.googleapis.com/instance/cpu/utilization o metriche di 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 seguente tabella per trovare consigli per la risoluzione dei problemi:

Categoria	Sintomo o messaggio di log	Possibile causa	Procedura per la risoluzione dei problemi
Condizioni dei nodi	NetworkUnavailable: True	Problema di connettività dal nodo al piano di controllo o errore del plug-in Container Network Interface (CNI).	Risolvere i problemi di connettività di rete
	MemoryPressure: True	Il nodo non ha memoria sufficiente.	Risolvere i problemi di carenza di risorse dei nodi
	DiskPressure: True	Il nodo ha spazio su disco insufficiente.	Risolvi i problemi relativi alla carenza di risorse dei nodi
	PIDPressure: True	Il nodo non dispone di ID di processo sufficienti.	Risolvere i problemi di carenza di risorse dei nodi
Eventi e messaggi di log	PLEG is not healthy	Kubelet è sovraccarico a causa di un utilizzo elevato di CPU/IO o di un numero eccessivo di pod.	Risolvi 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 il container di interruzione I log di containerd mostrano messaggi Kill container ripetuti	Processi bloccati in stato di sospensione del disco non interrompibile (stato D), spesso correlati all'I/O.	Risolvi 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 dei 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 l'interruzione del nodo
	kube-system pod bloccati in Pending.	Webhook di ammissione sta bloccando i componenti critici.	Risolvi 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

Verifica la presenza di eventi NotReady previsti

Lo stato NotReady non indica sempre un problema. Può essere un comportamento previsto durante operazioni pianificate come l'upgrade di un 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 un nodo viene creato o ricreato, ad esempio nei seguenti scenari:

• Upgrade dei node pool: durante un upgrade, ogni nodo viene svuotato e sostituito. Il nuovo nodo di cui è stato eseguito l'upgrade ha lo stato NotReady finché non termina l'inizializzazione e non si unisce al 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 essere stati completamente sottoposti al provisioning e aver eseguito l'accesso al cluster.
• Modifiche manuali al template di istanza: GKE ricrea i nodi quando applichi le modifiche al template. Il nuovo nodo ha uno 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, indaga su altre cause.

Conferma il prerilascio del nodo

Se il nodo è in esecuzione su una VM spot o una VM preemptible, 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 dei cluster.
• Cloud Audit Logs mostra un evento compute.instances.preempted per l'istanza VM sottostante.

Causa:

Il nodo era in esecuzione su un'istanza VM spot o VM preemptible e Compute Engine ha recuperato le risorse di computing per un'altra attività. Le VM spot possono essere interrotte in qualsiasi momento, anche se in genere forniscono un preavviso di terminazione di 30 secondi.

Risoluzione:

Utilizza le VM spot o le VM preemptible 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 relativi alla carenza di risorse dei nodi

Un nodo diventa spesso 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 generale a eventi più gravi a livello di sistema.

Risolvi la pressione delle risorse sui nodi

L'esaurimento delle risorse si verifica quando un nodo non dispone di CPU, memoria, spazio su disco o ID di processo (PID) sufficienti per eseguire i propri 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 causa probabile 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 di kubelet potrebbero contenere eventi di out of memory (OOM), che indicano che è stato richiamato il killer OOM 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:

• Riduci la domanda del workload:
  • Riduci il numero di pod in esecuzione sul nodo interessato facendo lo scale down del numero di repliche dei tuoi deployment. Per ulteriori informazioni, consulta Scalabilità di un'applicazione.
  • Esamina e ottimizza le tue applicazioni per consumare meno risorse.
• Aumenta la capacità dei nodi:
  • Aumenta la CPU e la memoria allocate del nodo. Per saperne di più, consulta Scalare verticalmente modificando gli attributi della macchina nodo.
  • Se il problema riguarda il disco, aumenta le dimensioni del disco di avvio del nodo. Valuta la possibilità di utilizzare un disco di avvio SSD per migliorare le prestazioni.

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 workload rientrino nei limiti di Autopilot e riflettano con precisione le esigenze della tua applicazione. I problemi persistenti relativi alle risorse potrebbero indicare la necessità di ottimizzare le richieste dei pod o, in rari casi, un problema della piattaforma che richiede l'assistenza clienti Google Cloud.

Risolvere gli eventi OOM a livello di sistema

Un evento di memoria esaurita (OOM) a livello di sistema si verifica quando la memoria totale di un nodo è esaurita, costringendo 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 è il probabile motivo dell'instabilità del nodo:

• Vedi il messaggio Out of memory: Kill process nei log della console seriale del nodo.
• 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à del nodo. Per saperne di più, vedi Risoluzione dei problemi relativi agli eventi OOM.

Risolvi 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 riscontri 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. Alcune cause comuni sono:

• Carico 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:

• Riduci il carico dei nodi: diminuisci il workload complessivo sul nodo ridimensionando le implementazioni. Puoi anche distribuire i pod in modo più uniforme tra gli altri nodi del cluster utilizzando taint e tolleranze, affinità nodo o vincoli di distribuzione della topologia dei pod per influire sulla pianificazione.
• Imposta limiti CPU: per impedire a un singolo workload di consumare tutte le risorse CPU disponibili, applica limiti CPU ai pod. Per saperne di più, consulta la sezione Gestione delle risorse per pod e container nella documentazione di Kubernetes.
• Aumenta la capacità dei nodi: valuta la possibilità di utilizzare nodi più grandi con più CPU e memoria per gestire il workload. Per saperne di più, consulta Scala verticalmente modificando gli attributi della macchina nodo.
• Migliora le prestazioni del disco: se il problema è correlato alla limitazione I/O, utilizza un disco di avvio più grande o esegui l'upgrade a un disco di avvio SSD. Questa modifica può migliorare notevolmente le prestazioni del disco. Per saperne di più, consulta Risoluzione dei problemi relativi alle prestazioni del disco.

Per i cluster Autopilot, anche se non puoi modificare direttamente le dimensioni o il tipo di disco di un nodo esistente, puoi influenzare l'hardware su cui vengono eseguiti i workload utilizzando ComputeClasses 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 carichi di lavoro (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.

Risolvi 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 ad attività bloccate per più di 120 secondi.

Causa:

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

• File system remoti lenti o non reattivi, ad esempio una condivisione NFS configurata in modo errato o sovraccarica.
• Grave peggioramento delle prestazioni del disco o errori di 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:

Risolvere i problemi relativi ai guasti 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. Lo 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à di base di Kubernetes, come il sistema di lease dei nodi, si interrompe.

Risolvere i problemi di runtime del 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 relativi al runtime del container, segui questi passaggi:

1. Analizza i log di runtime dei container:

   1. Nella console Cloud de Confiance , 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 delle 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) del cluster.

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

   4. Per verificare se il runtime è bloccato in un loop di riavvio, esegui una query che cerca 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 di fondo, come un file di configurazione danneggiato o una pressione sulle risorse, che causa l'arresto anomalo ripetuto del servizio.

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

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

      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 pool di nodi.
      • CLUSTER_NAME: il nome del tuo cluster.
      • LOCATION: la regione o la zona Compute Engine del tuo cluster.

      Se nell'output viene visualizzata una sezione containerdConfig, GKE gestisce queste impostazioni personalizzate. Per modificare o ripristinare le impostazioni, segui le istruzioni riportate 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 si trova nell'output di gcloud è una modifica non gestita.

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

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

Risolvi 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 di integrità. Questo problema fa sì che il piano di controllo 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 fa sì che lo stato dei nodi alterni Ready e NotReady.

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

• Risorse con finalizzatori: sebbene meno comune per lo spazio dei nomi di sistema kube-node-lease (che contiene principalmente oggetti Lease), una risorsa al suo interno potrebbe avere un finalizzatore. I finalizer di Kubernetes sono chiavi che indicano 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 la procedura di eliminazione dello spazio dei nomi viene interrotta.
• 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 control plane potrebbe attendere che il server API aggregato venga arrestato o pulito correttamente, il che non si verifica se il servizio non risponde.
• Problemi del control plane o del 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
  • Messaggi 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 di 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 agli webhook: gli 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 NetworkNotReady dell'indirizzo: 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 seguenti passaggi.

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 la connettività: utilizza i Connectivity Tests 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 il 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 in base al 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. Risolvi gli errori CNI specifici:

      • 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 controlla 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 il 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 con i webhook di ammissione: i webhook con un funzionamento non corretto 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 individuare 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 sta causando problemi, potresti dover 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.

Risolvi 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 ammissione configurato in modo errato, non disponibile o troppo lento può bloccare richieste API critiche, impedendo l'avvio di componenti essenziali o l'unione dei nodi al cluster.

Sintomi:

Se riscontri 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 in uno stato Pending o Terminating.
• I nuovi nodi non riescono a unirsi al cluster, spesso con timeout con stato NotReady.

Causa:

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

Risoluzione:

Esamina le configurazioni dei webhook per assicurarti che siano resilienti e con un ambito corretto. Per evitare interruzioni, imposta il campo failurePolicy su Ignore per i webhook non critici. Per i webhook critici, assicurati che il servizio di supporto sia ad alta affidabilità 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 Garantisci la stabilità del control plane quando utilizzi i webhook.

Risolvere i problemi causati dalle quote delle risorse

Una quota 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 in uno stato Pending.
• I messaggi di errore nei log del cluster o nell'output kubectl describe pod mostrano errori come exceeded quota: gcp-critical-pods.

Causa:

Questo problema si verifica quando il controller delle quote delle 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ù alto di quanto non sia in realtà.

Risoluzione:

1. Poiché un webhook problematico è la causa principale più probabile, 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 relativo alla 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 non è corretto:

   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 utilizzato 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.

Risolvi i problemi causati da 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 il seguente:
  • 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 relative 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.
• Interferenza 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 delle policy 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 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 hanno spesso nomi come gke-metrics-agent, netd o calico-node. Gli agenti di terze parti spesso hanno nomi che riflettono il prodotto.

2. Correlare il momento del deployment: verifica se la comparsa dei nodi NotReady coincide con il deployment o l'aggiornamento di un DaemonSet di terze parti specifico.

3. Esegui il test su un singolo nodo:

   1. Scegli un nodo interessato.
   2. Contrassegna come non pianificabile e svuota il nodo.
   3. Impedisci temporaneamente al DaemonSet di pianificare 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 su quel nodo specifico.
   4. Riavvia l'istanza di macchina virtuale del nodo.
   5. Osserva se il nodo diventa Ready e rimane stabile mentre il DaemonSet non è in esecuzione. Se i problemi si ripresentano dopo la reintroduzione del DaemonSet, è probabile che questo 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 mostra ancora NotReady o passa da uno stato all'altro, il problema non è stato 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 i workload, controlla se vengono pianificati nuovi pod e se i pod esistenti vengono eseguiti 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 in altri stati di errore.

Passaggi successivi

• Se non riesci a trovare una soluzione al tuo problema nella documentazione, consulta Assistenza per ulteriore aiuto, inclusi consigli sui seguenti argomenti:

  • Aprire una richiesta di assistenza contattando l'assistenza clienti Google Cloud.
  • Ricevere assistenza dalla community facendo domande su StackOverflow e utilizzando il tag google-kubernetes-engine per cercare problemi simili. Puoi anche unirti al canale Slack #kubernetes-engine per assistenza dalla community.
  • Apertura di problemi o richieste di funzionalità utilizzando l'Issue Tracker pubblico.