Personalizzazione della configurazione del sistema di nodi

Standard

Questo documento mostra come personalizzare la configurazione dei nodi di Google Kubernetes Engine (GKE) utilizzando un file di configurazione chiamato configurazione di sistema dei nodi.

Una configurazione di sistema del nodo è un file di configurazione che consente di regolare un insieme limitato di impostazioni di sistema. Nel tuo pool di nodi, puoi utilizzare una configurazione di sistema dei nodi per specificare impostazioni personalizzate per l'agente nodo Kubernetes kubelet e per le configurazioni del kernel Linux di basso livello sysctl.

Attenzione: la modifica delle impostazioni kubelet o sysctl può causare un comportamento imprevisto che potrebbe influire negativamente sull'integrità dei workload e dei nodi. Testa in modo approfondito tutte le modifiche a kubelet o sysctl prima di eseguirne il deployment sui workload di produzione.

Questo documento descrive le configurazioni disponibili per un sistema di nodi e come applicarle ai pool di nodi GKE Standard. Tieni presente che, poiché i cluster GKE Autopilot hanno un ambiente dei nodi più gestito, le opzioni di configurazione diretta del sistema dei nodi sono limitate rispetto ai pool di nodi GKE Standard.

Perché utilizzare le configurazioni di sistema dei nodi

Le configurazioni di sistema dei nodi offrono i seguenti vantaggi:

• Ottimizzazione delle prestazioni: ottimizza le prestazioni dello stack di rete, la gestione della memoria, la pianificazione della CPU o il comportamento di I/O per applicazioni impegnative come l'addestramento o l'erogazione dell'AI, i database, i server web con traffico elevato o i servizi sensibili alla latenza.
• Rafforzamento della sicurezza: applica impostazioni di sicurezza specifiche a livello di kernel o limita determinati comportamenti del sistema per ridurre la superficie di attacco.
• Gestione delle risorse: ottimizza il modo in cui kubelet gestisce i PID, lo spazio su disco, la garbage collection delle immagini o le risorse di CPU e memoria.
• Compatibilità dei workload: contribuiscono a garantire che l'ambiente dei nodi soddisfi prerequisiti specifici per software specializzati o applicazioni meno recenti che richiedono impostazioni del kernel particolari.

Altre opzioni per la personalizzazione delle configurazioni dei nodi

Puoi anche personalizzare la configurazione dei nodi utilizzando altri metodi:

• File di configurazione del runtime: per personalizzare un runtime container containerd sui nodi GKE, puoi utilizzare un file diverso, chiamato file di configurazione del runtime. Per saperne di più, consulta Personalizza la configurazione di containerd nei nodi GKE.
• ComputeClass: puoi specificare gli attributi dei nodi nella specifica ComputeClass di GKE. Puoi utilizzare le classi di calcolo sia in modalità GKE Autopilot che in modalità Standard, in GKE versione 1.32.1-gke.1729000 e successive. Per saperne di più, consulta Personalizza la configurazione di sistema del nodo.
• DaemonSets: puoi utilizzare i DaemonSet anche per personalizzare i nodi. Per saperne di più, consulta Bootstrapping automatico dei nodi GKE con DaemonSet.

Le configurazioni di sistema dei nodi non sono supportate nei nodi Windows Server.

Prima di iniziare

Prima di iniziare, assicurati di:

• Installa gli strumenti a riga di comando:
  • Se utilizzi gli esempi di gcloud CLI in questo documento, assicurati di installare e configurare Google Cloud CLI.
  • Se utilizzi gli esempi di Terraform, assicurati di installare e configurare Terraform.
• Concedi le autorizzazioni: devi disporre delle autorizzazioni IAM appropriate per creare e aggiornare i cluster GKE e i node pool, ad esempio container.clusterAdmin o un altro ruolo con autorizzazioni equivalenti.
• Pianifica potenziali interruzioni del workload: le configurazioni dei nodi personalizzate vengono applicate a livello di pool di nodi. In genere, le modifiche attivano un aggiornamento in sequenza dei nodi nel pool, che comporta la ricreazione dei nodi. Pianifica potenziali interruzioni dei workload e utilizza i budget di interruzione dei pod (PDB) dove appropriato.
• Esegui il backup e testa tutte le modifiche: testa sempre le modifiche alla configurazione in un ambiente di gestione temporanea o di sviluppo prima di applicarle alla produzione. Impostazioni errate possono causare instabilità dei nodi o errori dei workload.
• Esamina le impostazioni predefinite di GKE: le immagini dei nodi GKE vengono fornite con configurazioni predefinite ottimizzate. Personalizza i parametri solo se hai un'esigenza specifica e comprendi l'impatto delle modifiche.

Aggiungi una configurazione di sistema dei nodi

Puoi personalizzare la configurazione del sistema dei nodi utilizzando una classe ComputeClass o un file di configurazione.

Utilizza una classe ComputeClass per la configurazione del sistema dei nodi

Puoi utilizzare una ComputeClass personalizzata per personalizzare determinati parametri in kubelet e nel kernel Linux. Questo metodo è disponibile in GKE versione 1.32.1-gke.1729000 e successive.

Per utilizzare una classe ComputeClass per personalizzare la configurazione del sistema dei nodi, segui questi passaggi:

1. Crea una classe ComputeClass che includa la coppia campo-valore spec.nodePoolAutoCreation.enabled: true e specifica le configurazioni di sistema nel campo priorityDefaults.
2. Esegui il deployment di un workload che seleziona la classe ComputeClass.

Crea la classe ComputeClass

Scrivi la configurazione di ComputeClass in YAML. Utilizza il campo nodeSystemConfig all'interno della specifica priorityDefaults per impostare le configurazioni di sistema per tutte le priorità.

L'esempio ComputeClass seguente configura la policy del gestore della CPU statico e i parametri del kernel personalizzati:

apiVersion: cloud.google.com/v1
kind: ComputeClass
metadata:
  name: custom-sysconfig
spec:
  nodePoolAutoCreation:
    enabled: true
  priorityDefaults:
    nodeSystemConfig:
      kubeletConfig:
        cpuManagerPolicy: static
      linuxNodeConfig:
        sysctls:
          net.core.somaxconn: 2048
  priorities:
  - machineFamily: n4

Applica la classe ComputeClass:

kubectl apply -f custom-sysconfig.yaml

Esegui il deployment di un workload che seleziona la classe di computing

Nella specifica del pod, aggiungi un selettore di nodi per il nome della classe di computing:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      nodeSelector:
        cloud.google.com/compute-class: custom-sysconfig
      containers:
      - name: app-container
        image: nginx

Applica il workload:

kubectl apply -f my-app.yaml

Per saperne di più, consulta Personalizza la configurazione di sistema del nodo.

Utilizza un file di configurazione per la configurazione del sistema dei nodi

Quando utilizzi un file di configurazione del sistema del nodo, utilizzi un file YAML che contiene i parametri di configurazione per kubelet e il kernel Linux. Sebbene le configurazioni di sistema dei nodi siano disponibili anche in modalità GKE Autopilot, i passaggi descritti in questo documento mostrano come creare e utilizzare un file di configurazione per la modalità GKE Standard.

Per utilizzare un file di configurazione del sistema dei nodi in modalità GKE Standard, segui questi passaggi:

1. Crea un file di configurazione. Questo file contiene le configurazioni di kubelet e sysctl.
2. Aggiungi la configurazione quando crei un cluster o un pool di nodi oppure aggiorna un node pool esistente.

Creare un file di configurazione

Scrivi la configurazione del sistema del nodo in YAML. L'esempio seguente aggiunge le configurazioni per le opzioni kubelet e sysctl:

kubeletConfig:
  cpuManagerPolicy: static
  allowedUnsafeSysctls:
    - 'kernel.shm*'
    - 'kernel.msg*'
    - 'kernel.sem'
    - 'fs.mqueue.*'
    - 'net.*'
linuxConfig:
  sysctl:
    net.core.somaxconn: '2048'
    net.ipv4.tcp_rmem: '4096 87380 6291456'
  kernelOverrides:
    kernelCommandlineOverrides:
      specRstackOverflow: 'SPEC_RSTACK_OVERFLOW_OFF'
      initOnAlloc: 'INIT_ON_ALLOC_OFF'

In questo esempio, si applica quanto segue:

• Il campo cpuManagerPolicy: static configura kubelet in modo che utilizzi la policy di gestione della CPU statica.
• Il campo net.core.somaxconn: '2048' limita il backlog socket listen() a 2048 byte.
• Il campo net.ipv4.tcp_rmem: '4096 87380 6291456' imposta i valori minimo, predefinito e massimo del buffer di ricezione del socket TCP rispettivamente su 4096 byte, 87.380 byte e 6.291.456 byte.
• Il blocco kernelCommandlineOverrides disattiva la mitigazione dello stack overflow di ritorno speculativo (SRSO) e il parametro del kernel init_on_alloc.

Se vuoi aggiungere configurazioni solo per kubelet o sysctl, includi solo quella sezione nella configurazione del sistema del nodo. Ad esempio, per aggiungere una configurazione kubelet, crea il seguente file:

kubeletConfig:
  cpuManagerPolicy: static

Per un elenco completo dei campi che puoi aggiungere alla configurazione di sistema del nodo, consulta le sezioni Opzioni di configurazione di Kubelet e Opzioni di configurazione di Sysctl.

Aggiungi la configurazione a un pool di nodi Standard

Dopo aver creato la configurazione di sistema del nodo, aggiungi il flag --system-config-from-file utilizzando Google Cloud CLI. Puoi aggiungere questo flag quando crei un cluster o un pool di nodi oppure quando aggiorni un node pool esistente. Non puoi aggiungere una configurazione di sistema del nodo utilizzando la console Google Cloud .

Crea un cluster con la configurazione di sistema del nodo

Puoi aggiungere una configurazione di sistema dei nodi durante la creazione del cluster utilizzando gcloud CLI o Terraform. Le seguenti istruzioni applicano la configurazione di sistema del nodo al pool di nodi predefinito:

gcloud CLI

gcloud container clusters create CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Sostituisci quanto segue:

• CLUSTER_NAME: il nome del cluster
• LOCATION: la zona o la regione di computing del cluster
• SYSTEM_CONFIG_PATH: il percorso del file che contiene le configurazioni kubelet e sysctl

Dopo aver applicato una configurazione di sistema dei nodi, il pool di nodi predefinito del cluster utilizza le impostazioni che hai definito.

Terraform

Per creare un cluster a livello di regione con una configurazione del sistema dei nodi personalizzata utilizzando Terraform, consulta l'esempio seguente:

resource "google_container_cluster" "default" {
  name     = "gke-standard-regional-cluster"
  location = "us-central1"

  initial_node_count = 1

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Per ulteriori informazioni sull'utilizzo di Terraform, consulta Supporto di Terraform per GKE.

Crea un nuovo pool di nodi con la configurazione di sistema del nodo

Puoi aggiungere una configurazione di sistema del nodo quando utilizzi gcloud CLI o Terraform per creare un nuovo pool di nodi.

Le seguenti istruzioni applicano la configurazione di sistema del nodo a un nuovo pool di nodi:

gcloud CLI

gcloud container node-pools create POOL_NAME \
     --cluster CLUSTER_NAME \
     --location=LOCATION \
     --system-config-from-file=SYSTEM_CONFIG_PATH

Sostituisci quanto segue:

• POOL_NAME: il nome del pool di nodi
• CLUSTER_NAME: il nome del cluster a cui vuoi aggiungere un pool di nodi
• LOCATION: la zona o la regione di computing del cluster
• SYSTEM_CONFIG_PATH: il percorso del file che contiene le configurazioni kubelet e sysctl

Terraform

Per creare un pool di nodi con una configurazione di sistema dei nodi personalizzata utilizzando Terraform, consulta l'esempio seguente:

resource "google_container_node_pool" "default" {
  name    = "gke-standard-regional-node-pool"
  cluster = google_container_cluster.default.name

  node_config {
    # Kubelet configuration
    kubelet_config {
      cpu_manager_policy = "static"
    }

    linux_node_config {
      # Sysctl configuration
      sysctls = {
        "net.core.netdev_max_backlog" = "10000"
      }

      # Linux cgroup mode configuration
      cgroup_mode = "CGROUP_MODE_V2"

      # Linux huge page configuration
      hugepages_config {
        hugepage_size_2m = "1024"
      }
    }
  }
}

Per ulteriori informazioni sull'utilizzo di Terraform, consulta Supporto di Terraform per GKE.

Aggiorna la configurazione di sistema dei nodi per un pool di nodi esistente

Se utilizzi un file di configurazione per gestire la configurazione del sistema dei nodi, puoi aggiornare un pool di nodi esistente in uno dei seguenti modi:

• Aggiornamento in tempo reale non invasivo: applica le impostazioni sysctl e kubelet aggiornate direttamente ai nodi in esecuzione senza ricreare le VM o espellere i pod. Utilizza questo metodo quando modifichi solo le impostazioni di sysctl o kubelet e vuoi ridurre al minimo le interruzioni.
• Strategia di upgrade standard: ricrea i nodi con la nuova configurazione. Utilizza questo metodo quando modifichi impostazioni che non supportano gli aggiornamenti in tempo reale, quando il cluster o il pool di nodi esegue una versione di GKE precedente alla 1.37.1-gke.1954000 o quando vuoi che GKE svuoti e ripianifichi i pod su nuovi nodi.

Per modificare la configurazione dei nodi che utilizzano una classe ComputeClass, consulta Modifica una configurazione di sistema dei nodi per le classi ComputeClass.

Attenzione: con entrambi i metodi, l'inclusione della sezione kubeletConfig o linuxConfig nel file sostituisce l'intera sezione della configurazione esistente del pool di nodi. Qualsiasi parametro omesso da una sezione inclusa viene reimpostato sul valore predefinito. Durante un aggiornamento in tempo reale, l'omissione di un parametro precedentemente configurato che non supporta gli aggiornamenti in tempo reale (come cpuManagerPolicy o cgroupMode) comporta il rifiuto dell'aggiornamento da parte di GKE. Prima di eseguire l'aggiornamento, recupera la configurazione di sistema dei nodi esistente e includi ogni impostazione che vuoi mantenere.

Esegui l'aggiornamento utilizzando un aggiornamento in tempo reale non invasivo

Anteprima

Questo prodotto o questa funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Puoi applicare le impostazioni sysctl e kubelet aggiornate dal file di configurazione direttamente ai nodi in esecuzione. Poiché questo processo aggiorna i parametri senza ricreare o riavviare le VM sottostanti, riduce le interruzioni e velocizza l'aggiornamento. Le seguenti opzioni linuxConfig richiedono comunque la strategia di upgrade standard:

• Modalità cgroup Linux
• Hugepage Linux
• Sincronizzazione precisa dell'ora di Linux
• Linux VFIO
• Scheduler I/O del disco Linux

Come funzionano gli aggiornamenti in tempo reale

Gli aggiornamenti in tempo reale funzionano come segue per ogni configurazione supportata:

• Configurazioni sysctl: GKE riavvia il servizio systemd sysctl su ogni nodo per applicare i parametri del kernel nel campo linuxConfig.sysctl. Se aggiorni un parametro sysctl con spazio dei nomi, GKE riavvia anche il servizio kubelet per aggiornare la configurazione sysctl a livello di pod. Per i parametri supportati, consulta Opzioni di configurazione di sysctl.
• Configurazioni kubelet: GKE riavvia il servizio kubelet su ogni nodo per applicare i parametri nel campo kubeletConfig. La maggior parte delle opzioni di configurazione di kubelet supporta gli aggiornamenti in tempo reale. Tuttavia, le opzioni cpuManagerPolicy, shutdownGracePeriodSeconds e shutdownGracePeriodCriticalPodsSeconds richiedono la strategia di upgrade standard.

In entrambi i casi, GKE applica la modifica in loco sui nodi in esecuzione senza ricreare le VM, espellere i pod o creare VM temporanee con aumento del carico. GKE utilizza la somma delle impostazioni --max-surge-upgrade e --max-unavailable-upgrade del pool di nodi come limite di contemporaneità per determinare quanti nodi esistenti vengono aggiornati in parallelo.

Prerequisiti per gli aggiornamenti in tempo reale

Per utilizzare gli aggiornamenti in tempo reale, il cluster e il pool di nodi devono soddisfare i seguenti prerequisiti:

• Eseguire GKE versione 1.37.1-gke.1954000 o successiva.
• Attiva il componente aggiuntivo NodeReadinessController nel cluster. Durante un aggiornamento in tempo reale, questo controller applica temporaneamente il taint readiness.k8s.io/gke-node-live-update-reconciling:NoSchedule a ogni nodo in fase di aggiornamento, in modo che GKE non pianifichi nuovi pod sul nodo fino al completamento dell'aggiornamento:
  • Per i nuovi cluster, includi il componente aggiuntivo NodeReadinessController nel flag --addons durante la creazione del cluster. Questo flag attiva solo i componenti aggiuntivi che specifichi e disattiva tutti gli altri, quindi includi anche i componenti aggiuntivi predefiniti che vuoi mantenere.
  • Per i cluster esistenti, passa il flag --update-addons=NodeReadinessController=ENABLED durante un aggiornamento del cluster.

Applica un aggiornamento in tempo reale

Per applicare un aggiornamento in tempo reale, segui questi passaggi:

1. Crea o modifica il file YAML di configurazione del sistema dei nodi in modo che contenga la configurazione completa del pool di nodi, incluse le impostazioni kubelet o sysctl che vuoi modificare. Per evitare di reimpostare le impostazioni che non intendi modificare, inizia dalla configurazione esistente del pool di nodi.

2. Aggiorna il pool di nodi con il file di configurazione e imposta il valore del flag --node-config-update-mode su LIVE_UPDATE_WITHOUT_DRAIN:

   gcloud container node-pools update POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --system-config-from-file=SYSTEM_CONFIG_PATH \
       --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
   

   Sostituisci quanto segue:

   • POOL_NAME: il nome del pool di nodi che vuoi aggiornare
   • CLUSTER_NAME: il nome del cluster che contiene il pool di nodi
   • LOCATION: la zona o la regione di computing del cluster
   • SYSTEM_CONFIG_PATH: il percorso del file YAML che contiene la configurazione del sistema del nodo

3. Verifica che GKE abbia applicato le impostazioni aggiornate al node pool:

   gcloud container node-pools describe POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --format="yaml(config.kubeletConfig, config.linuxNodeConfig)"
   

   L'output comando mostra le impostazioni attive sul pool di nodi nei campi config.kubeletConfig e config.linuxNodeConfig.

4. (Facoltativo) Riavvia i pod esistenti. L'aggiornamento in tempo reale non interrompe i pod in esecuzione, pertanto GKE applica le impostazioni aggiornate solo ai pod che vengono avviati dopo il completamento dell'aggiornamento. Per applicare le impostazioni a un workload già in esecuzione, riavvia i relativi pod, ad esempio eseguendo kubectl rollout restart sul deployment.

Se un aggiornamento in tempo reale non va come previsto, il percorso di recupero dipende dal fatto che l'operazione di aggiornamento sia stata completata o meno:

• Se l'operazione di aggiornamento in tempo reale non va a buon fine, consulta Esegui il recupero da un aggiornamento in tempo reale non riuscito.
• Se l'operazione di aggiornamento in tempo reale va a buon fine, ma le nuove impostazioni causano un comportamento imprevisto del workload, consulta Annulla un aggiornamento in tempo reale completato.

Esegui il ripristino dopo un aggiornamento in tempo reale non riuscito

Se un aggiornamento in tempo reale non va a buon fine su un nodo, GKE interrompe immediatamente l'implementazione e lascia il pool di nodi in uno stato di aggiornamento parziale. Per esaminare i dettagli dell'errore, esegui una delle seguenti operazioni:

• Esegui il comando gcloud container operations describe. Nell'output, il campo statusMessage identifica il nodo in cui l'aggiornamento in tempo reale non è riuscito e l'errore segnalato dal nodo, ad esempio:

  statusMessage: 'Failed precondition: live update failed on node gke-my-cluster-default-pool-ae3770ee-2kk0:
    Live update fails with error: failed to write new kubelet config: ...'
  

• In Esplora log, controlla se sono presenti errori del componente gke-node-live-update-reconciler sui nodi interessati.

Poiché un aggiornamento in tempo reale non riuscito non modifica la configurazione archiviata del pool di nodi, la nuova applicazione della configurazione precedente con il comando gcloud container node-pools update non attiva un aggiornamento. Dopo aver esaminato l'errore, scegli una delle seguenti opzioni di recupero:

• Risolvi il problema e completa l'aggiornamento in tempo reale (consigliato): risolvi il problema che ha causato l'errore, quindi esegui nuovamente il comando gcloud container node-pools update della procedura precedente con la configurazione di destinazione.
• Ripristina la configurazione precedente: se non riesci a risolvere il problema, esegui il comando gcloud container node-pools rollback per riportare il pool di nodi alla configurazione precedente. A differenza di un aggiornamento in tempo reale, questo comando ricrea tutti i nodi nel pool di nodi, interrompendo i workload in esecuzione su di essi.

Ripristina un aggiornamento in tempo reale completato

Se un'operazione di aggiornamento in tempo reale va a buon fine, ma un'impostazione appena applicata causa un comportamento imprevisto del workload, ripristina la modifica applicando un altro aggiornamento in tempo reale con la configurazione precedente. Questo aggiornamento in tempo reale ripristina la configurazione precedente senza espellere i pod o riavviare i nodi. Il comando gcloud container node-pools rollback non è disponibile dopo un'operazione riuscita; funziona solo quando l'operazione non va a buon fine.

Per ripristinare un aggiornamento in tempo reale completato:

1. Aggiorna il file YAML di configurazione del sistema del nodo in modo che contenga la configurazione precedente completa del pool di nodi. Se un'impostazione non è stata configurata in precedenza, impostala esplicitamente sul valore predefinito anziché ometterla o lasciare la sezione vuota. Per i valori predefiniti, consulta Opzioni di configurazione di Kubelet e Opzioni di configurazione di Sysctl.

2. Applica la configurazione precedente al pool di nodi:

   gcloud container node-pools update POOL_NAME \
       --cluster=CLUSTER_NAME \
       --location=LOCATION \
       --system-config-from-file=SYSTEM_CONFIG_PATH \
       --node-config-update-mode=LIVE_UPDATE_WITHOUT_DRAIN
   

Aggiorna utilizzando la strategia di upgrade standard

Utilizza la strategia di upgrade standard se stai aggiornando opzioni di configurazione che non supportano gli aggiornamenti in tempo reale, se il tuo cluster o pool di nodi esegue una versione di GKE precedente alla 1.37.1-gke.1954000 o se vuoi che GKE svuoti e ripianifichi automaticamente i pod sui nodi appena creati.

Per aggiornare un pool di nodi esistente utilizzando la strategia di upgrade standard, esegui il seguente comando:

gcloud container node-pools update POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --system-config-from-file=SYSTEM_CONFIG_PATH

Sostituisci quanto segue:

• POOL_NAME: il nome del pool di nodi che vuoi aggiornare
• CLUSTER_NAME: il nome del cluster che contiene il pool di nodi
• LOCATION: la zona o la regione di computing del cluster
• SYSTEM_CONFIG_PATH: il percorso del file YAML che contiene la configurazione del sistema del nodo

Questa modifica richiede la nuova creazione dei nodi, il che può causare interruzioni dei workload in esecuzione. Per ulteriori informazioni su questa modifica specifica, trova la riga corrispondente nella tabella Modifiche manuali che ricreano i nodi utilizzando una strategia di upgrade dei nodi senza rispettare le policy di manutenzione.

Per ulteriori informazioni sugli aggiornamenti dei nodi, consulta Pianificazione delle interruzioni degli aggiornamenti dei nodi.

Attenzione: GKE inizia immediatamente a ricreare i nodi per questa modifica utilizzando la strategia di upgrade dei nodi, indipendentemente dalle policy di manutenzione attive. GKE dipende dalla disponibilità delle risorse per la modifica. La disattivazione degli upgrade automatici dei nodi non impedisce questa modifica.

Modifica una configurazione di sistema del nodo

Puoi modificare la configurazione di sistema di un nodo a seconda che utilizzi ComputeClasses o un file di configurazione.

Per ComputeClasses

Per modificare la configurazione di sistema dei nodi quando utilizzi ComputeClasses, scegli uno dei seguenti metodi:

Metodo 1: aggiorna la classe ComputeClass esistente

Se aggiorni nodeSystemConfig in una ComputeClass esistente, GKE applica la configurazione aggiornata solo ai nodi appena creati. I nodi esistenti non vengono aggiornati automaticamente.

Per eseguire la migrazione dei workload ai nodi con la nuova configurazione, puoi eseguire una delle seguenti operazioni:

• Configura la migrazione attiva nella tua ComputeClass.
• Per attivare uno scale up dei nuovi nodi, riavvia o ricrea manualmente i workload.

Per aggiornare la classe ComputeClass, modifica il file YAML e applicalo:

kubectl apply -f custom-sysconfig.yaml

Metodo 2: crea una nuova classe ComputeClass

Per assicurarti che venga eseguita la migrazione dei workload ai nuovi nodi con la configurazione aggiornata, segui questi passaggi:

1. Crea una nuova classe ComputeClass con un nome diverso e la configurazione aggiornata.
2. Aggiorna il selettore dei nodi nelle specifiche del workload per fare riferimento alla nuova classe ComputeClass.
3. Applica le specifiche del workload aggiornate. Il gestore della scalabilità automatica dei cluster eseguirà il provisioning di nuovi nodi con la nuova configurazione e, infine, fare lo scale down dei nodi precedenti.
4. Elimina il vecchio oggetto ComputeClass.

Per i file di configurazione

Per modificare la configurazione di sistema dei nodi quando utilizzi un file di configurazione, puoi creare un nuovo pool di nodi con la configurazione che preferisci o aggiornare la configurazione di sistema dei nodi di un pool di nodi esistente.

Modifica creando un pool di nodi

Per modificare la configurazione di sistema di un nodo creando un pool di nodi, segui questi passaggi:

1. Crea un file di configurazione con la configurazione che preferisci.
2. Aggiungi la configurazione a un nuovo pool di nodi.
3. Esegui la migrazione dei workload al nuovo pool di nodi.
4. Elimina il vecchio node pool.

Modifica aggiornando un pool di nodi esistente

Per modificare la configurazione del sistema operativo dei nodi di un pool di nodi esistente, consulta Aggiorna la configurazione del sistema operativo dei nodi per un node pool esistente.

Recupera la configurazione del sistema del nodo esistente

Per recuperare la configurazione del sistema dei nodi esistente del pool di nodi, ad esempio se hai già personalizzato la configurazione e vuoi aggiungerla, utilizza il comando gcloud container node-pools describe. L'output del comando elenca tutte le configurazioni esistenti in kubeletConfig e linuxNodeConfig.

Attenzione: quando aggiorni la configurazione del nodo Linux in base a questo output, devi specificare i parametri nel campo linuxConfig nel comando di aggiornamento. Il comando describe mostra queste impostazioni in linuxNodeConfig, ma per gli aggiornamenti il campo corretto è linuxConfig. L'utilizzo del campo di output linuxNodeConfig in una richiesta di aggiornamento non applicherà le modifiche.

Ad esempio, vedi il seguente snippet che mostra il formato di output del comando describe:

  kubeletConfig:
    allowedUnsafeSysctls:
    - kernel.shm*
    - kernel.msg*
    - kernel.sem
    - fs.mqueue.*
    - net.*
    cpuManagerPolicy: static
    insecureKubeletReadonlyPortEnabled: false
    maxParallelImagePulls: 2
  linuxNodeConfig: # IMPORTANT: Use linuxConfig when updating these settings
    sysctl:
      net.core.somaxconn: '2048'
      net.ipv4.tcp_rmem: 4096 87380 6291456

Se non hai ancora impostato una configurazione di sistema dei nodi, l'output non elenca kubeletConfig o linuxNodeConfig.

Reimposta la configurazione del sistema del nodo esistente

Se vuoi ripristinare i valori predefiniti della configurazione di sistema del nodo, aggiorna il file di configurazione con valori vuoti per i campi kubelet e sysctl, ad esempio:

```yaml
kubeletConfig: {}
linuxConfig:
  sysctl: {}
```

Elimina una configurazione di sistema del nodo

Per rimuovere una configurazione di sistema dei nodi, segui i passaggi a seconda che tu stia utilizzando ComputeClasses o un file di configurazione.

Per ComputeClasses

Per rimuovere la configurazione di sistema dei nodi personalizzata:

1. Rimuovi il selettore di nodi cloud.google.com/compute-class dalle specifiche del workload.
2. Applica le specifiche del workload aggiornate. GKE ricrea i workload sui nodi predefiniti. Il gestore della scalabilità automatica dei cluster eseguirà fare lo scale down ed eliminerà i nodi di cui è stato eseguito il provisioning per la classe ComputeClass.

3. Elimina l'oggetto ComputeClass dal cluster:

   kubectl delete computeclass CUSTOM_COMPUTE_CLASS_NAME
   

Per i file di configurazione

Per rimuovere una configurazione di sistema del nodo applicata utilizzando un file di configurazione, segui questi passaggi:

1. Crea un nuovo pool di nodi senza il file di configurazione.
2. Esegui la migrazione dei workload al nuovo pool di nodi.
3. Elimina il node pool con la precedente configurazione di sistema dei nodi.

Opzioni di configurazione per kubelet

Le tabelle in questa sezione descrivono le opzioni kubelet che puoi modificare.

Gestione della CPU

La tabella seguente descrive le opzioni di gestione della CPU per kubelet.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
cpuCFSQuota	Deve essere true o false.	true	Questa impostazione applica il limite di CPU del pod. Se imposti questo valore su false, i limiti della CPU per i pod vengono ignorati. Ignorare i limiti della CPU potrebbe essere utile in determinati scenari in cui i pod sono sensibili ai limiti della CPU. Il rischio di disattivare cpuCFSQuota è che un pod non autorizzato possa consumare più risorse della CPU del previsto.
cpuCFSQuotaPeriod	Deve essere un periodo di tempo.	"100ms"	Questa impostazione imposta il valore del periodo della quota CFS della CPU, cpu.cfs_period_us, che specifica il periodo di frequenza con cui deve essere riallocato l'accesso di un cgroup alle risorse della CPU. Questa opzione ti consente di ottimizzare il comportamento di limitazione della CPU.
reservedSystemCPUs (Anteprima)	Deve essere un elenco di core della CPU specifici da prenotare (ad esempio, 0-1 o 0,1 per prenotare i core 0 e 1). Poiché i core sono indicizzati a partire da zero, i valori devono essere inferiori al numero di vCPU sul tipo di macchina.	none	Riserva esplicitamente core della CPU specifici per i servizi del sistema host, come i daemon del sistema operativo e il servizio kubelet. Per impostazione predefinita, questi servizi possono essere eseguiti su qualsiasi core della CPU, il che può causare problemi di prestazioni per i workload sensibili alla CPU. Sebbene l'impostazione cpuManagerPolicy: static assegni core dedicati ai pod Guaranteed con richieste di CPU intere, non impedisce ai servizi del sistema host di utilizzare questi core. L'aggiunta dell'impostazione reservedSystemCPUs limita i servizi del sistema host ai propri core riservati, impedendo loro di interrompere i core esclusivi dei workload. Per eseguire questa attività, GKE assegna automaticamente il cgroup system.slice ai core riservati all'avvio del nodo. La prenotazione delle CPU di sistema riduce la capacità allocabile complessiva dei nodi. Sebbene i pod Burstable e BestEffort possano ancora essere eseguiti su questi core riservati, le loro richieste di CPU, incluse le richieste frazionarie dei DaemonSet GKE, vengono comunque conteggiate ai fini della capacità allocabile del nodo. Poiché i workload Guaranteed esclusivi richiedono core interi, anche piccole richieste frazionarie riducono il numero di core esclusivi disponibili. Assicurati di prenotare core della CPU sufficienti in reservedSystemCPUs. Se prenoti un numero troppo basso di core, i daemon del sistema host e i processi del sistema operativo potrebbero subire limitazioni della CPU in caso di carico elevato, il che può causare instabilità o perdita di pacchetti di rete.

Gestione della memoria ed eliminazione

La tabella seguente descrive le opzioni modificabili per la gestione e l'eliminazione della memoria. Questa sezione contiene anche una tabella separata che descrive le opzioni modificabili per il flag evictionSoft.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
evictionSoft	Mappa dei nomi degli indicatori. Per le limitazioni dei valori, consulta la tabella seguente.	none	Questa impostazione mappa i nomi degli indicatori a una quantità o a una percentuale che definisce le soglie di espulsione soft. Una soglia di espulsione soft deve avere un periodo di tolleranza. kubelet non espelle i pod finché non viene superato il periodo di tolleranza.
evictionSoftGracePeriod	Mappa dei nomi degli indicatori. Per ogni nome di indicatore, il valore deve essere una durata positiva inferiore a 5m. Le unità di tempo valide sono ns, us (o µs), ms, s o m.	none	Questa impostazione mappa i nomi degli indicatori alle durate che definiscono i periodi di tolleranza per le soglie di soft eviction. Ogni soglia di espulsione soft deve avere un periodo di tolleranza corrispondente.
evictionMinimumReclaim	Mappa dei nomi degli indicatori. Per ogni nome di indicatore, il valore deve essere una percentuale positiva inferiore a 10%.	none	Questa impostazione mappa i nomi degli indicatori alle percentuali che definiscono la quantità minima di una determinata risorsa che kubelet recupera quando esegue un'espulsione dei pod.
evictionMaxPodGracePeriodSeconds	Il valore deve essere un numero intero compreso tra 0 e 300.	0	Questa impostazione definisce, in secondi, il periodo di tolleranza massimo per la terminazione dei pod durante l'eliminazione.
singleProcessOOMKill	Il valore deve essere true o false.	true per i nodi cgroupv1, false per i nodi cgroupv2.	Questa impostazione determina se i processi nel container vengono terminati per memoria esaurita singolarmente o come gruppo. Disponibile su GKE versioni 1.32.4-gke.1132000, 1.33.0-gke.1748000 o successive.

La tabella seguente mostra le opzioni modificabili per il flag evictionSoft. Le stesse opzioni si applicano anche ai flag evictionSoftGracePeriod e evictionMinimumReclaim con limitazioni diverse.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
memoryAvailable	Il valore deve essere una quantità maggiore di 100Mi e inferiore a 50% della memoria del nodo.	none	Questa impostazione rappresenta la quantità di memoria disponibile prima dell'eviction soft. Definisce la quantità di segnale memory.available in kubelet .
nodefsAvailable	Il valore deve essere compreso tra 10% e 50%.	none	Questa impostazione rappresenta i nodef disponibili prima dell'eliminazione temporanea. Definisce la quantità di segnale nodefs.available in kubelet .
nodefsInodesFree	Il valore deve essere compreso tra 5% e 50%.	none	Questa impostazione rappresenta gli inode nodefs liberi prima dell'eliminazione soft. Definisce la quantità di segnale nodefs.inodesFree in kubelet .
imagefsAvailable	Il valore deve essere compreso tra 15% e 50%.	none	Questa impostazione rappresenta l'imagefs disponibile prima dell'espulsione soft. Definisce la quantità di segnale imagefs.available in kubelet .
imagefsInodesFree	Il valore deve essere compreso tra 5% e 50%.	none	Questa impostazione rappresenta gli inode imagefs liberi prima dell'espulsione soft. Definisce la quantità di segnale imagefs.inodesFree in kubelet.
pidAvailable	Il valore deve essere compreso tra 10% e 50%.	none	Questa impostazione rappresenta i PID disponibili prima dell'espulsione soft. Definisce la quantità di segnale pid.available in kubelet.

Gestione dei PID

La tabella seguente descrive le opzioni modificabili per la gestione dei PID.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
podPidsLimit	Il valore deve essere compreso tra 1024 e 4194304.	none	Questa impostazione imposta il numero massimo di ID di processo (PID) che ogni pod può utilizzare.

Logging

La tabella seguente descrive le opzioni modificabili per il logging.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
containerLogMaxSize	Il valore deve essere un numero positivo e un suffisso di unità compreso tra 10Mi e 500Mi compresi.	10Mi	Questa impostazione controlla l'impostazione containerLogMaxSize della policy di rotazione dei log dei container, che consente di configurare la dimensione massima di ogni file di log. Il valore predefinito è 10Mi. Le unità valide sono Ki, Mi e Gi.
containerLogMaxFiles	Il valore deve essere un numero intero compreso tra 2 e 10 inclusi.	5	Questa impostazione controlla l'impostazione containerLogMaxFiles della policy di rotazione dei file di log del container, che consente di configurare il numero massimo di file consentiti per ogni container. Il valore predefinito è 5. La dimensione totale dei log (container_log_max_size*container_log_max_files) per container non può superare l'1% dello spazio di archiviazione totale del nodo.

Garbage collection delle immagini

La tabella seguente descrive le opzioni modificabili per la garbage collection delle immagini.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
imageGcHighThresholdPercent	Il valore deve essere un numero intero compreso tra 10 e 85 inclusi e superiore a imageGcLowThresholdPercent.	85	Questa impostazione definisce la percentuale di utilizzo del disco al di sopra della quale viene eseguita la garbage collection delle immagini. Rappresenta l'utilizzo massimo del disco per la garbage collection. La percentuale viene calcolata dividendo il valore di questo campo per 100.
imageGcLowThresholdPercent	Il valore deve essere un numero intero compreso tra 10 e 85 inclusi e inferiore a imageGcHighThresholdPercent.	80	Questa impostazione definisce la percentuale di utilizzo del disco prima della quale non viene mai eseguita la garbage collection delle immagini. Rappresentano l'utilizzo minimo del disco per la garbage collection. La percentuale viene calcolata dividendo il valore di questo campo per 100.
imageMinimumGcAge	Il valore deve essere un periodo di tempo non superiore a 2m. Le unità di tempo valide sono ns, us (o µs), ms, s, m o h.	2m	Questa impostazione definisce l'età minima di un'immagine inutilizzata prima che venga sottoposta a garbage collection.
imageMaximumGcAge	Il valore deve essere una durata di tempo.	0s	Questa impostazione definisce l'età massima per cui un'immagine può rimanere inutilizzata prima di essere sottoposta a garbage collection. Il valore predefinito di questo campo è 0s, che disattiva il campo. Pertanto, le immagini non verranno sottoposte a garbage collection in base al fatto che non sono utilizzate. Se specificato, questo valore deve essere maggiore del valore del campo imageMinimumGcAge. Disponibile su GKE versioni 1.30.7-gke.1076000, 1.31.3-gke.1023000 o successive.

Pull delle immagini

La tabella seguente descrive le opzioni modificabili per il pull delle immagini.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
maxParallelImagePulls	Il valore deve essere un numero intero compreso tra 2 e 5 inclusi.	2 o 3 in base al tipo di disco.	Questa impostazione definisce il numero massimo di pull di immagini in parallelo. Il valore predefinito è determinato dal tipo di disco di avvio.

Sicurezza e operazioni non sicure

La tabella seguente descrive le opzioni modificabili per la configurazione della sicurezza e la gestione delle operazioni non sicure.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
allowedUnsafeSysctls	Elenco di sysctl nomi o gruppi. I gruppi sysctl consentiti sono i seguenti: kernel.shm* kernel.msg* kernel.sem fs.mqueue.* net.*.	none	Questa impostazione definisce una lista consentita separata da virgole di nomi sysctl o gruppi sysctl non sicuri che possono essere impostati sui pod.
insecureKubeletReadonlyPortEnabled	Il valore deve essere un valore booleano, true o false.	false	Questa impostazione disattiva la porta di sola lettura 10255 non sicura di kubelet su ogni nuovo pool di nodi del cluster. Se configuri questa impostazione in questo file, non puoi utilizzare un client API GKE per modificarla a livello di cluster.

Resource Manager

Kubernetes offre una suite di gestori delle risorse. Puoi configurare questi gestori delle risorse per coordinare e ottimizzare l'allineamento delle risorse dei nodi per i pod configurati con requisiti specifici per le risorse di CPU, dispositivi e memoria (hugepage).

La tabella seguente descrive le opzioni modificabili per i gestori delle risorse.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
cpuManagerPolicy	Il valore deve essere none o static.	none	Questa impostazione controlla la policy CPU Manager di kubelet. Il valore predefinito è none, ovvero lo schema di affinità della CPU predefinito, che non fornisce alcuna affinità oltre a quella eseguita automaticamente dallo scheduler del sistema operativo. Se imposti questo valore su static, i pod che si trovano nella classe QoS Guaranteed e hanno richieste di CPU intere possono essere assegnati a CPU esclusive.
memoryManager.policy	Il valore deve essere None o Static.	None	Questa impostazione controlla la policy Gestione della memoria di kubelet. Con il valore predefinito None, Kubernetes agisce come se il gestore della memoria non fosse presente. Se imposti questo valore su Static, la policy Gestore della memoria invia suggerimenti di topologia che dipendono dal tipo di pod. Per maggiori dettagli, consulta Policy statica. Questa impostazione è supportata per i cluster con il control plane che esegue GKE versione 1.32.3-gke.1785000 o successive.
topologyManager	Il valore deve essere una delle impostazioni supportate per ciascuno dei rispettivi campi. Non puoi impostare il campo topologyManager quando utilizzi le istruzioni di Terraform per aggiungere la configurazione a un node pool Standard.	policy: none scope: container	Queste impostazioni controllano la configurazione di kubelet Topology Manager utilizzando i campi secondari policy e scope. Il gestore della topologia coordina l'insieme di componenti responsabili delle ottimizzazioni delle prestazioni relative all'isolamento della CPU, alla memoria e alla località dei dispositivi. Puoi configurare le impostazioni della policy e dell'ambito indipendentemente l'una dall'altra. Per saperne di più su queste impostazioni, consulta Ambiti e policy del gestore della topologia. Le seguenti risorse GKE supportano questa impostazione: Cluster con il control plane che esegue GKE versione 1.32.3-gke.1785000 o successive. Per i cluster con il control plane e i nodi che eseguono la versione 1.33.0-gke.1712000 o successive, il gestore della topologia riceve anche informazioni sulla topologia della GPU. Nodi con i seguenti tipi di macchine: A2, A3, A4, C3, C4, C4A, C4N, G2, G4, M3, N4

Ritardo di riavvio del container

Questa impostazione controlla il tempo massimo di attesa tra i tentativi di riavvio del container quando un container si trova in uno stato CrashLoopBackOff. Puoi configurare questa impostazione per i node pool Standard che eseguono GKE versione 1.35 o successive.

Attenzione: un ritardo molto breve su un container che non funziona in modo persistente può comportare un consumo elevato di CPU e risorse sul nodo, con un potenziale impatto su altri workload a causa dell'esaurimento delle risorse. Valuta la possibilità di ridurlo solo quando i vantaggi di tentativi più rapidi superano i rischi di un maggiore utilizzo delle risorse.

La tabella seguente descrive le opzioni modificabili per crashLoopBackOff.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
crashLoopBackOff.maxContainerRestartPeriod	Il valore deve essere una durata positiva inferiore o uguale a 5 minuti (5m). Le unità di tempo valide sono ns, us (o µs), ms, s o m.	none	La durata massima del ritardo di backoff che può essere accumulata per i riavvii dei container. Il ritardo tra i riavvii aumenta in modo esponenziale da un valore iniziale fino a questo limite massimo. Il limite massimo predefinito per un cluster Kubernetes è 5 minuti. Per saperne di più, consulta Ritardo di riavvio del container configurabile.

Terminazione controllata delle VM spot in GKE

La tabella seguente descrive le opzioni modificabili per il periodo di terminazione e arresto normale delle VM spot in GKE. Per utilizzare queste opzioni, il control plane del cluster deve eseguire GKE 1.35.0-gke.1171000 o versioni successive. Per ulteriori informazioni, consulta Come funzionano le VM spot in GKE.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
shutdownGracePeriodSeconds	Il valore deve essere un numero intero che rappresenta la durata in secondi. I valori consentiti sono 0, 30 o 120.	30	Specifica la durata totale in secondi del ritardo di arresto del nodo per terminare i pod in modo controllato.
shutdownGracePeriodCriticalPodsSeconds	Il valore deve essere un numero intero compreso tra 0 e 120 (inclusi) e deve essere inferiore a shutdownGracePeriodSeconds. Valido solo se è impostato anche shutdownGracePeriodSeconds.	15	Specifica la durata in secondi utilizzata per terminare i pod critici durante l'arresto di un nodo.

Prenotazioni di risorse di sistema

Anteprima

Questo prodotto o questa funzionalità sono soggetti ai "Termini dell'offerta pre-GA" nella sezione Termini di servizio generali dei Termini specifici dei servizi. I prodotti e le funzionalità pre-GA sono disponibili "così come sono" e potrebbero avere un supporto limitato. Per ulteriori informazioni, consulta le descrizioni della fase di lancio.

Per i node pool Standard che eseguono Linux e GKE 1.37 o versioni successive, puoi personalizzare la quantità di memoria e CPU riservata ai componenti di sistema. In questo modo puoi ottimizzare la capacità allocabile per scenari specifici, come la gestione di pull di immagini con volumi elevati o l'esecuzione di DaemonSet di nodi personalizzati. Per saperne di più sulle prenotazioni predefinite, consulta Informazioni sul dimensionamento dei nodi GKE.

La tabella seguente descrive le opzioni modificabili per le prenotazioni delle risorse di sistema.

kubelet impostazioni di configurazione	Limitazioni	Impostazione predefinita	Descrizione
reservedResourcesConfig.memoryReservedMib	Il valore deve essere un numero intero. Deve essere maggiore o uguale alla prenotazione di memoria predefinita per i pool di nodi creati con la versione 1.37 o successive e inferiore al 50% della capacità di memoria totale del nodo.	Consulta la sezione Prenotazioni di memoria.	La quantità di memoria da prenotare per i componenti di sistema, in mebibyte (MiB).
reservedResourcesConfig.cpuReservedMillicore	Il valore deve essere un numero intero. Deve essere maggiore o uguale alla prenotazione della CPU predefinita per i node pool creati con la versione 1.37 o successive e inferiore al 50% della capacità della CPU totale del nodo.	Vedi Prenotazioni di CPU.	La quantità di CPU da riservare ai componenti di sistema, in millicore.

Verifica le prenotazioni effettive

Per controllare le prenotazioni attive applicate al tuo pool di nodi, controlla i campi di output effectiveMemoryReservedMib e effectiveCpuReservedMillicore:

gcloud container node-pools describe POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --format="yaml(config.kubeletConfig.reservedResourcesConfig)"

Opzioni di configurazione sysctl

Per ottimizzare le prestazioni del sistema, puoi modificare i parametri del kernel Linux. Le tabelle in questa sezione descrivono i vari parametri del kernel che puoi configurare.

Parametri del file system (fs.*)

La tabella seguente descrive i parametri modificabili per il file system Linux. Queste impostazioni controllano il comportamento del file system Linux, ad esempio i limiti della gestione di file e il monitoraggio degli eventi.

Parametro Sysctl	Limitazioni	Descrizione
fs.aio-max-nr	Il valore deve essere compreso tra [65536, 4194304].	Questa impostazione definisce il numero massimo di richieste di I/O asincrone a livello di sistema.
fs.file-max	Deve essere compreso tra [104857, 67108864].	Questa impostazione definisce il numero massimo di handle di file che il kernel Linux può allocare.
fs.inotify.max_user_instances	Deve essere compreso tra [8192, 1048576].	Questa impostazione definisce il numero massimo di istanze inotify che un utente può creare.
fs.inotify.max_user_watches	Deve essere compreso tra [8192, 1048576].	Questa impostazione definisce il numero massimo di watch inotify che un utente può creare.
fs.nr_open	Il valore deve essere compreso tra [1048576, 2147483584].	Questa impostazione definisce il numero massimo di descrittori del file che possono essere aperti da un processo.

Parametri kernel (kernel.*)

La tabella seguente descrive i parametri modificabili per il kernel Linux. Queste impostazioni configurano le funzionalità principali del kernel, inclusa l'allocazione della memoria condivisa.

Parametro sysctl	Limitazioni	Descrizione
kernel.shmmni	Deve essere compreso tra [4096, 32768].	Questa impostazione definisce il numero massimo di segmenti di memoria condivisa a livello di sistema. Se questo valore non è impostato, il valore predefinito è 4096.
kernel.shmmax	Il valore deve essere compreso tra [0, 18446744073692774399].	Questa impostazione definisce la dimensione massima, in byte, di un singolo segmento di memoria condivisa consentito dal kernel. Questo valore viene ignorato se è maggiore della quantità effettiva di RAM, il che significa che tutta la RAM disponibile può essere condivisa.
kernel.shmall	Il valore deve essere compreso tra [0, 18446744073692774399].	Questa impostazione definisce la quantità totale di pagine di memoria condivisa che possono essere utilizzate contemporaneamente sul sistema. Una pagina è di 4096 byte sull'architettura AMD64 e Intel 64.
kernel.perf_event_paranoid	Il valore deve essere compreso tra -1 e 3.	Questa impostazione controlla l'utilizzo del sistema di eventi di prestazioni da parte di utenti senza privilegi e senza CAP_PERFMON. Il valore predefinito è 2 nel kernel.
kernel.sched_rt_runtime_us	Il valore deve essere compreso tra [-1, 1000000].	Questa impostazione definisce un limite globale per il tempo che può essere utilizzato dalla programmazione in tempo reale.
kernel.softlockup_panic	Facoltativo (booleano).	Questa impostazione controlla se il kernel va in panic quando viene rilevato un soft lockup.
kernel.yama.ptrace_scope	Deve essere compreso tra [0, 3].	Questa impostazione definisce l'ambito e le limitazioni per la chiamata di sistema ptrace(), influendo sul debug e sul tracciamento dei processi. I valori supportati includono: 0: autorizzazioni ptrace classiche. 1: ptrace limitato, che è l'impostazione predefinita in molte distribuzioni. Solo processi figlio o CAP_SYS_PTRACE. 2: ptrace solo per amministratori. Solo i processi con CAP_SYS_PTRACE. 3: no ptrace. Le chiamate ptrace non sono consentite.
kernel.kptr_restrict	Deve essere compreso tra [0, 2].	Questa impostazione indica se sono presenti limitazioni per l'esposizione degli indirizzi del kernel tramite /proc e altre interfacce.
kernel.dmesg_restrict	Facoltativo (booleano).	Questa impostazione indica se agli utenti non privilegiati è impedito l'utilizzo di dmesg(8) per visualizzare i messaggi dal buffer di log del kernel.
kernel.sysrq	Il valore deve essere compreso tra [0, 511].	Questa impostazione controlla le funzioni che possono essere richiamate tramite il tasto SysRq. I valori possibili sono i seguenti: 0: disattiva completamente sysrq. 1: attiva tutte le funzioni sysrq. >1: maschera di bit delle funzioni sysrq consentite. Per saperne di più, consulta Linux Magic System Request Key Hacks.
kernel.keys.maxbytes	Deve essere compreso tra [20.000, 2.097.152].	Questa impostazione definisce il numero massimo di byte che un utente non root può conservare nella sezione del payload di tutte le sue chiavi.
kernel.keys.maxkeys	Deve essere compreso tra [200, 1048576].	Questa impostazione definisce il numero massimo di chiavi che un utente non root può possedere.

Parametri di rete (net.*)

La tabella seguente descrive i parametri modificabili per il networking. Queste impostazioni ottimizzano le prestazioni e il comportamento dello stack di networking, dai buffer dei socket al monitoraggio delle connessioni.

Parametro sysctl	Limitazioni	Descrizione
net.core.busy_poll	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce il timeout del busy poll a bassa latenza per poll e select. Rappresenta il tempo approssimativo in µs per il ciclo di attesa degli eventi.
net.core.busy_read	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce il timeout del polling occupato a bassa latenza per le letture dei socket. Rappresenta il tempo approssimativo in µs per il ciclo di attesa dei pacchetti nella coda del dispositivo.
net.core.netdev_max_backlog	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce il numero massimo di pacchetti in coda sul lato INPUT quando l'interfaccia riceve i pacchetti più velocemente di quanto il kernel possa elaborarli.
net.core.rmem_default	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce la dimensione predefinita del buffer del socket di ricezione, in byte.
net.core.rmem_max	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce la dimensione massima del buffer del socket di ricezione, in byte.
net.core.wmem_default	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce l'impostazione predefinita, in byte, del buffer di invio del socket.
net.core.wmem_max	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce la dimensione massima del buffer del socket di invio, in byte.
net.core.optmem_max	Qualsiasi numero intero positivo, inferiore a 2147483647.	Questa impostazione definisce la dimensione massima del buffer ausiliario consentita per socket.
net.core.somaxconn	Il valore deve essere compreso tra [128, 2147483647].	Questa impostazione definisce il limite del backlog socket listen(), noto nello spazio utente come SOMAXCONN. Questo valore è impostato su 128 per impostazione predefinita.
net.ipv4.tcp_rmem	{min, default, max} (ciascuno > 0, memoria in byte).	Questa impostazione definisce la dimensione minima, in byte, del buffer di ricezione utilizzato dai socket UDP in moderazione. L'impostazione predefinita è 1 pagina.
net.ipv4.tcp_wmem	{min, default, max} (ciascuno > 0, memoria in byte).	Questa impostazione definisce la dimensione minima, in byte, del buffer di invio utilizzato dai socket UDP in moderazione. L'impostazione predefinita è 1 pagina.
net.ipv4.tcp_tw_reuse	Il valore deve essere compreso tra {0, 1}.	Questa impostazione definisce se consentire il riutilizzo dei socket nello stato TIME_WAIT per le nuove connessioni quando è sicuro dal punto di vista del protocollo. Il valore predefinito è 0.
net.ipv4.tcp_max_orphans	Deve essere compreso tra [16384, 262144].	Questa impostazione definisce il numero massimo di socket TCP non collegati a nessun handle di file utente.
net.ipv4.tcp_max_tw_buckets	Deve essere compreso tra [4096, 2147483647].	Questa impostazione definisce il numero massimo di socket timewait mantenuti contemporaneamente dal sistema. Se questo numero viene superato, il socket in stato TIME_WAIT viene immediatamente eliminato e viene visualizzato un avviso.
net.ipv4.tcp_syn_retries	Il valore deve essere compreso tra [1, 127].	Questa impostazione definisce il numero di volte in cui vengono ritrasmessi i SYN iniziali per un tentativo di connessione TCP attiva.
net.ipv4.tcp_ecn	Deve essere compreso tra [0, 2].	Questa impostazione controlla l'utilizzo della notifica esplicita di congestione (ECN) da parte di TCP. L'ECN viene utilizzato solo quando entrambe le estremità della connessione TCP indicano il supporto per questa funzionalità.
net.ipv4.tcp_mtu_probing	Deve essere compreso tra [0, 2].	Questa impostazione controlla la Path MTU Discovery del livello di pacchettizzazione TCP. I valori supportati sono i seguenti: 0: disattivato. 1: disattivato per impostazione predefinita, attivato quando viene rilevato un black hole ICMP. 2: sempre attivo. Utilizza l'MSS iniziale di tcp_base_mss.
net.ipv4.tcp_congestion_control	Deve essere uno dei valori supportati della colonna Descrizione.	Questa impostazione non è supportata quando GKE Dataplane V2 è abilitato nel cluster. I seguenti valori supportati dipendono dal tipo di immagine: Container-Optimized OS: reno, cubic, bbr, lp, htcp (disponibile su GKE versioni 1.34.1-gke.3355001 o successive) Ubuntu: reno, cubic, bbr, lp, htcp, vegas, dctcp, bic, cdg, highspeed, hybla, illinois, nv, scalable, veno, westwood, yeah
net.ipv6.conf.all.disable_ipv6	Valore booleano.	La modifica di questo valore equivale a modificare l'impostazione conf/default/disable_ipv6 e tutte le impostazioni disable_ipv6 per interfaccia con lo stesso valore.
net.ipv6.conf.default.disable_ipv6	Valore booleano.	Questa impostazione disabilita il funzionamento di IPv6.
net.netfilter.nf_conntrack_acct	Il valore deve essere compreso tra {0, 1}.	Questa impostazione attiva l'accounting del flusso di monitoraggio della connessione. Il valore predefinito è 0, il che significa che l'impostazione è disattivata. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.netfilter.nf_conntrack_max	Il valore deve essere compreso tra [65536, 4194304].	Questa impostazione definisce le dimensioni della tabella di monitoraggio delle connessioni. Se viene raggiunto il valore massimo, la nuova connessione non andrà a buon fine. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.netfilter.nf_conntrack_buckets	Deve essere compreso tra [65536, 524288].	Questa impostazione definisce le dimensioni della tabella hash. L'impostazione consigliata è il risultato di quanto segue: nf_conntrack_max = nf_conntrack_buckets * 4. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.netfilter.nf_conntrack_tcp_timeout_close_wait	Deve essere compreso tra [60, 3600].	Questa impostazione definisce il periodo, in secondi, per il quale le connessioni TCP possono rimanere nello stato CLOSE_WAIT. Il valore predefinito è 3600. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.netfilter.nf_conntrack_tcp_timeout_established	Deve essere compreso tra [600, 86400].	Questa impostazione definisce la durata, in secondi, delle connessioni inattive prima che vengano eliminate automaticamente dalla tabella di monitoraggio delle connessioni. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.netfilter.nf_conntrack_tcp_timeout_time_wait	Il valore deve essere compreso tra 1 e 600.	Questa impostazione definisce il periodo, in secondi, per il quale le connessioni TCP possono rimanere nello stato TIME_WAIT. Il valore predefinito è 120. Disponibile su GKE 1.32.0-gke.1448000 o versioni successive.
net.ipv4.neigh.default.gc_thresh1	Il valore deve essere compreso tra [0, 262144].	Questa impostazione definisce il numero minimo di voci da conservare nella cache ARP. Il garbage collector non viene eseguito se il numero di voci è inferiore a questa impostazione. L'impostazione di questo valore su 0 può causare il thrashing della cache e un peggioramento delle prestazioni.
net.ipv4.neigh.default.gc_thresh2	Deve essere compreso tra [512, 524288].	Questa impostazione definisce il numero massimo di voci da conservare nella cache ARP. Il garbage collector consente al numero di voci di superare questo valore per 5 secondi prima di avviare la garbage collection soft.
net.ipv4.neigh.default.gc_thresh3	Deve essere compreso tra [1024, 1048576].	Questa impostazione definisce il numero massimo di voci da conservare nella cache ARP. Il garbage collector è progettato per essere eseguito sempre se il numero di voci supera questa impostazione.

Parametri della memoria virtuale (vm.*)

La tabella seguente descrive i parametri modificabili per il sottosistema di memoria virtuale. Queste impostazioni gestiscono il sottosistema della memoria virtuale, che controlla il modo in cui il kernel gestisce la memoria, lo swapping e la memorizzazione nella cache del disco.

Parametro sysctl	Limitazioni	Descrizione
vm.max_map_count	Il valore deve essere compreso tra [65536, 2147483647].	Questo file definisce il numero massimo di aree della mappa di memoria che un processo può avere.
vm.dirty_background_ratio	Il valore deve essere compreso tra [1, 100].	Questa impostazione definisce la percentuale di memoria di sistema che può essere riempita con pagine dirty prima che i thread di svuotamento del kernel in background inizino il writeback. Il valore deve essere inferiore al valore del campo vm.dirty_ratio.
vm.dirty_background_bytes	Il valore deve essere compreso tra [0, 68719476736].	Questa impostazione definisce la quantità di memoria dirty in corrispondenza della quale i thread di svuotamento del kernel in background avviano il writeback. Tieni presente che vm.dirty_background_bytes è la controparte di vm.dirty_background_ratio. È possibile specificare solo una di queste impostazioni.
vm.dirty_expire_centisecs	Il valore deve essere compreso tra [0, 6000].	Questa impostazione definisce l'età massima, in centesimi di secondo, per cui i dirty data possono rimanere in memoria prima che i thread del flusher del kernel li scrivano sul disco.
vm.dirty_ratio	Il valore deve essere compreso tra [1, 100].	Questa impostazione definisce la percentuale di memoria di sistema che può essere riempita con dirty page prima che i processi che eseguono scritture siano costretti a bloccare e scrivere dirty data in modo sincrono.
vm.dirty_bytes	Il valore deve essere compreso tra [0, 68719476736].	Questa impostazione definisce la quantità di memoria dirty in cui un processo che genera scritture su disco avvia il writeback. Il valore minimo consentito per vm.dirty_bytes è di due pagine in byte. Qualsiasi valore inferiore a questo limite verrà ignorato e verrà mantenuta la configurazione precedente. Tieni presente che vm.dirty_bytes è la controparte di vm.dirty_ratio. È possibile specificare solo una di queste impostazioni.
vm.dirty_writeback_centisecs	Il valore deve essere compreso tra [0, 1000].	Questa impostazione definisce l'intervallo, in centesimi di secondo, in cui i thread di flusher del kernel si attivano per scrivere i dirty data precedenti sul disco.
vm.overcommit_memory	Deve essere compreso tra {0, 1, 2}.	Questa impostazione determina la strategia del kernel per la gestione dell'overcommit della memoria. I valori sono i seguenti: 0: rifiuta allocazioni di grandi dimensioni 1: consenti sempre (valore predefinito) 2: impedisce il commit oltre lo swap + il rapporto della RAM Questa impostazione non è supportata su macchine con meno di 15 GB di memoria.
vm.overcommit_ratio	Il valore deve essere compreso tra [0, 100].	Questa impostazione definisce la percentuale di RAM fisica consentita per l'overcommit quando il valore del campo vm.overcommit_memory è impostato su 2.
vm.vfs_cache_pressure	Il valore deve essere compreso tra [0, 100].	Questa impostazione regola la preferenza del kernel per il recupero della memoria utilizzata per le cache dentry (directory) e inode.
vm.swappiness	Il valore deve essere compreso tra [0, 200].	Questa impostazione controlla la tendenza del kernel a spostare i processi dalla memoria fisica al disco di swap. Il valore predefinito è 60.
vm.watermark_scale_factor	Deve essere compreso tra [10, 3000].	Questa impostazione controlla l'aggressività di kswapd. Definisce la memoria rimanente prima che kswapd si attivi e la memoria da liberare prima che si disattivi. Il valore predefinito è 10.
vm.min_free_kbytes	Deve essere compreso tra [67584, 1048576].	Questa impostazione definisce la memoria libera minima prima dell'OOM. Il valore predefinito è 67584.

Per saperne di più sui valori supportati per ogni flag sysctl, consulta la documentazione di gcloud CLI --system-config-from-file.

Spazi dei nomi Linux diversi potrebbero avere valori univoci per un determinato flag sysctl, ma altri potrebbero essere globali per l'intero nodo. L'aggiornamento delle opzioni sysctl utilizzando una configurazione del sistema del nodo aiuta a garantire che sysctl venga applicato a livello globale sul nodo e in ogni spazio dei nomi, in modo che ogni pod abbia valori sysctl identici in ogni spazio dei nomi Linux.

Opzioni di configurazione della modalità cgroup Linux

Attenzione: GKE ritira cgroupv1 con la versione secondaria 1.31 e rimuove il supporto per cgroupv1 con la versione 1.35. Per ulteriori informazioni su come GKE sta eseguendo la transizione a cgroupv2 e su come puoi preparare i tuoi cluster per questa transizione, consulta Esegui la migrazione dei nodi a Linux cgroupv2.

Il runtime del container e kubelet utilizzano i cgroup del kernel Linux per la gestione delle risorse, ad esempio per limitare la quantità di CPU o memoria a cui può accedere ogni container in un pod. Esistono due versioni del sottosistema cgroup nel kernel: cgroupv1 e cgroupv2. Il supporto di Kubernetes per cgroupv2 è stato introdotto come alpha nella versione 1.18 di Kubernetes, beta nella versione 1.22 e GA nella versione 1.25. Per ulteriori informazioni, consulta la documentazione di Kubernetes sui cgroup v2.

La configurazione del sistema dei nodi ti consente di personalizzare la configurazione dei cgroup dei tuoi pool di nodi. Puoi utilizzare cgroupv1 o cgroupv2. GKE utilizza cgroupv2 per i nuovi node pool Standard che eseguono la versione 1.26 e successive e cgroupv1 per i node pool che eseguono versioni precedenti alla 1.26. Per i pool di nodi creati con il provisioning automatico dei nodi, la configurazione di cgroup dipende dalla versione iniziale del cluster, non dalla versione del pool di nodi. cgroupv1 non è supportato sulle macchine Arm.

Puoi utilizzare la configurazione di sistema del nodo per modificare l'impostazione di un pool di nodi in modo da utilizzare esplicitamente cgroupv1 o cgroupv2. L'upgrade alla versione 1.26 di un pool di nodi esistente che utilizza cgroupv1 non modifica l'impostazione in cgroupv2. I node pool esistenti che eseguono una versione precedente alla 1.26 e che non includono una configurazione cgroup personalizzata continueranno a utilizzare cgroupv1. Per modificare l'impostazione, devi specificare esplicitamente cgroupv2 per il pool di nodi esistente.

Ad esempio, per configurare il pool di nodi in modo che utilizzi cgroupv2, utilizza un file di configurazione del sistema del nodo come il seguente:

linuxConfig:
  cgroupMode: 'CGROUP_MODE_V2'

Le opzioni cgroupMode supportate sono le seguenti:

• CGROUP_MODE_V1: utilizza cgroupv1 sul pool di nodi.
• CGROUP_MODE_V2: utilizza cgroupv2 sul pool di nodi.
• CGROUP_MODE_UNSPECIFIED: utilizza la configurazione cgroup GKE predefinita.

Per utilizzare cgroupv2, si applicano i seguenti requisiti e limitazioni:

• Per un pool di nodi che esegue una versione precedente alla 1.26, devi utilizzare gcloud CLI versione 408.0.0 o successiva. In alternativa, utilizza gcloud beta con la versione 395.0.0 o successive.
• I cluster e i node pool devono eseguire GKE versione 1.24.2-gke.300 o successiva.
• Devi utilizzare l'immagine del nodo Container-Optimized OS con containerd o Ubuntu con containerd.
• Se uno dei tuoi workload dipende dalla lettura del file system cgroup (/sys/fs/cgroup/...), assicurati che sia compatibile con l'API cgroupv2.
• Se utilizzi strumenti di monitoraggio o di terze parti, assicurati che siano compatibili con cgroupv2.
• Se utilizzi workload Java (JDK), ti consigliamo di utilizzare versioni che supportano completamente cgroupv2, tra cui JDK 8u372, JDK 11.0.16 o versioni successive o JDK 15 o versioni successive.

Verifica la configurazione di cgroup

Quando aggiungi una configurazione di sistema dei nodi, GKE deve ricreare i nodi per implementare le modifiche. Dopo aver aggiunto la configurazione a un pool di nodi e aver ricreato i nodi, puoi verificare la nuova configurazione.

Puoi verificare la configurazione di cgroup per i nodi in un pool di nodi utilizzando gcloud CLI o lo strumento a riga di comando kubectl:

gcloud CLI

Controlla la configurazione di cgroup per un pool di nodi:

gcloud container node-pools describe POOL_NAME \
  --format='value(Config.effectiveCgroupMode)'

Sostituisci POOL_NAME con il nome del tuo pool di nodi.

L'output potenziale è uno dei seguenti:

• EFFECTIVE_CGROUP_MODE_V1: i nodi utilizzano cgroupv1
• EFFECTIVE_CGROUP_MODE_V2: i nodi utilizzano cgroupv2

L'output mostra solo la nuova configurazione di cgroup dopo la ricreazione dei nodi nel pool di nodi. L'output è vuoto per i node pool di Windows Server, che non supportano cgroup.

kubectl

Per utilizzare kubectl per verificare la configurazione di cgroup per i nodi in questo node pool, seleziona un nodo e connettiti utilizzando le seguenti istruzioni:

1. Crea una shell interattiva con qualsiasi nodo nel pool di nodi. Nel comando, sostituisci mynode con il nome di un nodo qualsiasi nel pool di nodi.
2. Identifica la versione di cgroup sui nodi Linux.

Opzioni di configurazione delle hugepage Linux

Puoi utilizzare hugepage preallocate manualmente o hugepage trasparenti assegnate automaticamente.

Hugepage preallocate

Puoi utilizzare un file di configurazione del sistema del nodo per preallocare hugepages. Kubernetes supporta le hugepage pre-allocate come tipo di risorsa, in modo simile alla CPU o alla memoria.

Per utilizzare le hugepage, si applicano le seguenti limitazioni e requisiti:

• Per garantire che il nodo non sia completamente occupato da hugepage, la dimensione complessiva delle hugepage allocate non può superare i seguenti valori:
  • Su macchine con meno di 30 GB di memoria: 60% della memoria totale. Ad esempio, su una macchina e2-standard-2 con 8 GB di memoria, non puoi allocare più di 4,8 GB per le hugepage.
  • Su macchine con più di 30 GB di memoria: 80% della memoria totale. Ad esempio, sulle macchine c4a-standard-8 con 32 GB di memoria, le hugepage non possono superare i 25,6 GB.
• Le hugepage da 1 GB sono disponibili solo sui tipi di macchine A3, C2D, C3, C3D, C4, C4A, C4D, C4N, CT5E, CT5LP, CT6E, H3, M2, M3, M4, Z3 o Z4D.

La tabella seguente descrive le impostazioni modificabili per le hugepage Linux.

Parametro di configurazione	Limitazioni	Valore predefinito	Descrizione
hugepage_size2m	Conteggio di numeri interi. Soggetto ai limiti di allocazione della memoria descritti in precedenza.	0	Questa impostazione prealloca un numero specifico di hugepage da 2 MB.
hugepage_size1g	Conteggio di numeri interi. Soggetto alle limitazioni relative alla memoria e al tipo di macchina descritte in precedenza.	0	Questa impostazione prealloca un numero specifico di hugepage da 1 GB.

Transparent Huge Pages (THP)

Puoi utilizzare un file di configurazione di sistema del nodo per attivare il supporto di Transparent HugePage del kernel Linux. Con THP, il kernel assegna automaticamente hugepage ai processi senza pre-allocazione manuale.

La tabella seguente descrive i parametri modificabili per THP.

Parametro di configurazione	Valori supportati	Valore predefinito	Descrizione
transparentHugepageEnabled	TRANSPARENT_HUGEPAGE_ENABLED_ALWAYS: transparent hugepage è abilitato a livello di sistema. TRANSPARENT_HUGEPAGE_ENABLED_MADVISE: transparent hugepage è abilitato all'interno delle regioni MADV_HUGEPAGE. Questa impostazione è la configurazione predefinita del kernel. TRANSPARENT_HUGEPAGE_ENABLED_NEVER: transparent hugepage è disabilitato. TRANSPARENT_HUGEPAGE_ENABLED_UNSPECIFIED: il valore predefinito. GKE non modifica la configurazione del kernel.	UNSPECIFIED	Questa impostazione controlla se THP è abilitato per la memoria anonima.
transparentHugepageDefrag	TRANSPARENT_HUGEPAGE_DEFRAG_ALWAYS: un'applicazione che richiede THP si blocca in caso di errore di allocazione e recupera direttamente le pagine e compatta la memoria nel tentativo di allocare immediatamente un THP. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER: un'applicazione attiva kswapd in background per recuperare pagine e attiva kcompactd per compattare la memoria in modo che THP sia disponibile nel prossimo futuro. È responsabilità di khugepaged installare le pagine THP in un secondo momento. TRANSPARENT_HUGEPAGE_DEFRAG_DEFER_WITH_MADVISE: un'applicazione entra in modalità di recupero e compattazione diretta come di consueto, ma solo per le regioni che hanno utilizzato madvise(MADV_HUGEPAGE). In tutte le altre regioni, kswapd viene attivato in background per recuperare le pagine e kcompactd viene attivato per compattare la memoria in modo che THP sia disponibile nel prossimo futuro. TRANSPARENT_HUGEPAGE_DEFRAG_MADVISE: un'applicazione entra in modalità di recupero e compattazione diretta come di consueto, ma solo per le regioni che hanno utilizzato madvise(MADV_HUGEPAGE). In tutte le altre regioni, kswapd viene attivato in background per recuperare le pagine e kcompactd viene attivato per compattare la memoria in modo che THP sia disponibile nel prossimo futuro. TRANSPARENT_HUGEPAGE_DEFRAG_NEVER: un'applicazione non entra mai in modalità di recupero o compattazione diretta. TRANSPARENT_HUGEPAGE_DEFRAG_UNSPECIFIED: il valore predefinito. GKE non modifica la configurazione del kernel.	UNSPECIFIED	Questa impostazione definisce la configurazione della deframmentazione per THP.

THP è disponibile su GKE versione 1.33.2-gke.4655000 o successive. È abilitato anche per impostazione predefinita sui nuovi pool di nodi TPU in GKE versione 1.33.2-gke.4655000 o successive. THP non viene attivato quando esegui l'upgrade dei node pool esistenti a una versione supportata o successiva.

Opzione di sincronizzazione dell'ora precisa di Linux

Se la sincronizzazione precisa dell'ora e il monitoraggio della precisione della sincronizzazione dell'ora sono importanti per i tuoi workload, puoi configurare l'ora precisa per sincronizzare l'orologio della VM con quello dell'host utilizzando chrony e ptp_kvm. La sincronizzazione precisa dell'ora è disponibile in GKE versione 1.36.0-gke.3241000 e successive. Questa configurazione è progettata per ottenere un'accuratezza entro 1 ms per le configurazioni supportate. Per ulteriori informazioni sui tipi di macchine, sui sistemi operativi e sulle zone supportati, consulta Configura l'ora esatta per le VM di Compute Engine.

La tabella seguente descrive il parametro per configurare la sincronizzazione precisa dell'ora con GKE:

Parametro di configurazione	Valori supportati	Valore predefinito	Descrizione
File di configurazione: accurateTimeConfig.enablePtpKvmTimeSync Terraform: accurate_time_config.enable_ptp_kvm_time_sync	true o false	false	Questa impostazione consente una sincronizzazione precisa dell'ora. Questa funzionalità è supportata solo con tipi di macchine, sistemi operativi e zone specifici.

Dopo aver attivato la sincronizzazione dell'ora precisa, GKE raccoglie ed esporta le seguenti informazioni:

• La metrica compute.googleapis.com/instance/clock_accuracy/ptp_kvm/nanosecond_accuracy, che indica l'accuratezza dell'orologio dell'host VM rispetto al fuso orario UTC.
• Il log projects/PROJECT_ID/logs/chrony.tracking, che contiene i log di monitoraggio di chrony. Questi log forniscono informazioni come la frequenza di guadagno o perdita dell'orologio di sistema.

Puoi utilizzare queste informazioni per creare metriche basate su log e dashboard in Cloud Monitoring per analizzare le prestazioni e l'affidabilità della sincronizzazione dell'ora.

Ad esempio, la seguente configurazione gke-clock-metric.json definisce una metrica basata su log dell'errore massimo del clock dell'host:

{
  "name": "phc-clock-max-error",
  "description": "Maximum error of the VM clock from the host clock exposed by ptp_kvm",
  "filter": "resource.type=\"k8s_node\" AND log_id(\"chrony.tracking\")",
  "metricDescriptor": {
    "metricKind": "DELTA",
    "valueType": "DISTRIBUTION",
    "unit": "s",
    "labels": []
  },
  "valueExtractor": "REGEXP_EXTRACT(textPayload, \"^.*PHC0.* ([-\\\\d\\\\.eE]+)$\")",
  "bucketOptions": {
    "explicitBuckets": {
      "bounds": [
        0.0, 5.0E-7, 1.0E-6, 2.0E-6, 4.0E-6, 5.0E-6, 8.0E-6, 1.0E-5, 2.0E-5,
        1.0E-4, 0.001, 0.01, 0.1, 1.0
      ]
    }
  }
}

La seguente configurazione gke-metrics-dashboard.json definisce una dashboard di Monitoring che aggrega i dati sugli errori della metrica basata su log e della metrica di accuratezza UTC:

{
  "displayName": "Overall Clock Accuracy",
  "dashboardFilters": [],
  "labels": {},
  "mosaicLayout": {
    "columns": 48,
    "tiles": [
      {
        "width": 28,
        "height": 28,
        "widget": {
          "xyChart": {
            "dataSets": [
              {
                "plotType": "LINE",
                "targetAxis": "Y1",
                "timeSeriesQuery": {
                  "prometheusQuery": "(\n  histogram_quantile(1, sum by (le, node_name) (\n    increase(logging_googleapis_com:user_phc_clock_max_error_bucket{monitored_resource=\"k8s_node\"}[1m])\n  )) * 1000000000\n)\n+ on(node_name) group_left()\nlabel_replace(\n  compute_googleapis_com:instance_clock_accuracy_ptp_kvm_nanosecond_accuracy{monitored_resource=\"gce_instance\"},\n  \"node_name\", \"$1\", \"instance_name\", \"(.*)\"\n)\n",
                  "unitOverride": "ns"
                }
              }
            ],
            "chartOptions": {
              "displayHorizontal": false,
              "mode": "COLOR"
            },
            "thresholds": [],
            "yAxis": {
              "label": "Clock Accuracy",
              "scale": "LINEAR"
            }
          }
        }
      }
    ]
  }
}

Opzioni di configurazione VFIO di Linux

La tabella seguente descrive il parametro per configurare VFIO (Virtual Function I/O) su un nodo. VFIO consente a driver sicuri, non privilegiati e in spazio utente di accedere ai dispositivi di I/O.

Parametro di configurazione	Limitazioni	Valore predefinito	Descrizione
nodeVfioConfig.dmaEntryLimit	Deve essere un numero intero compreso tra 65535 e 4194304.	65535	Specifica il numero massimo di voci DMA (pagine) che possono essere mappate dal driver VFIO IOMMU tipo 1 per un container. Questo limite influisce sulla quantità totale di memoria host che può essere bloccata per l'accesso diretto al dispositivo, il che è spesso fondamentale per i dispositivi ad alte prestazioni come TPU e GPU. Questa impostazione corrisponde al seguente parametro del kernel: /sys/module/vfio_iommu_type1/parameters/dma_entry_limit. Potrebbero essere necessari valori più elevati per i workload che mappano regioni di memoria di grandi dimensioni. Disponibile su GKE 1.36.0-gke.3009000 o versioni successive.

Opzioni di configurazione dello scheduler I/O del disco Linux

La tabella seguente descrive i parametri per configurare lo scheduler di I/O del disco per i node pool.

Parametro di configurazione	Valori supportati	Valore predefinito	Descrizione
diskIoScheduler.nodeSystemIoScheduler	mq-deadline, bfq, kyber, none	bfq per l'immagine Container-Optimized OS, none per l'immagine Ubuntu	Configura lo scheduler di I/O per il disco di avvio o l'SSD locale temporaneo che esegue i workload di sistema dei nodi. Disponibile su GKE 1.36.0-gke.3009000 o versioni successive.
diskIoScheduler.nodeAttachedDiskIoScheduler	mq-deadline, bfq, kyber, none	none	Configura lo scheduler di I/O per i dischi collegati. Disponibile su GKE versione 1.36.0-gke.3009000 o successive.

Opzioni di override del kernel Linux

Puoi utilizzare un file di configurazione del sistema del nodo per eseguire l'override di parametri specifici del kernel Linux, tra cui la riga di comando del kernel e le impostazioni LRU multi-generazione. Queste impostazioni sono supportate per i cluster che eseguono GKE versione 1.35.0-gke.1018000 o successive.

Opzioni della riga di comando del kernel Linux

La tabella seguente descrive le opzioni della riga di comando del kernel modificabili.

Parametro di configurazione	Valori supportati	Descrizione
specRstackOverflow	SPEC_RSTACK_OVERFLOW_OFF	Modifica la mitigazione dell'overflow dello stack di ritorno speculativo (SRSO). L'unico valore supportato è SPEC_RSTACK_OVERFLOW_OFF.
initOnAlloc	INIT_ON_ALLOC_OFF	Modifica il parametro init_on_alloc nella riga di comando del kernel. L'unico valore supportato è INIT_ON_ALLOC_OFF.

Opzioni di configurazione LRU multi-generazione

La tabella seguente descrive le opzioni LRU multi-generazione modificabili.

Parametro di configurazione	Valori supportati	Descrizione
enabled	true, false	Attiva o disattiva l'LRU multi-generazione. Questa impostazione consente di configurare il kill switch.
minTtlMs	Intero positivo	Facoltativo. Configura il valore di prevenzione del thrashing di min_ttl_ms per LRU multi-generazione.

Opzioni di configurazione dei file del sistema operativo

Puoi utilizzare un file di configurazione del sistema dei nodi per aggiungere voci a file di configurazione del sistema operativo specifici sui tuoi nodi. Queste impostazioni sono supportate per i cluster che eseguono GKE versione 1.35.0-gke.1018000 o successive.

Voci /etc/hosts aggiuntive

Questo campo aggiunge voci di file /etc/hosts, come nell'esempio seguente:

linuxConfig:
  additionalEtcHosts:
    - ip: 1.2.3.4
      host: myownpersonaldomain.com
    - ip: 5.6.7.8
      host: otherpersonaldomain.com

Voci aggiuntive di /etc/systemd/resolved.conf

Questo campo aggiunge /etc/systemd/resolved.conf voci di file. Questo campo accetta un array di coppie chiave-valore. Sono supportate le seguenti chiavi:

• DNS
• FallbackDNS
• Domains
• LLMNR
• MulticastDNS
• DNSSEC
• DNSOverTLS
• Cache
• CacheFromLocalhost
• DNSStubListener
• DNSStubListenerExtra
• ReadEtcHosts
• ResolveUnicastSingleLabel
• StaleRetentionSec

L'esempio seguente aggiunge due valori del server DNS (8.8.8.8 e 8.8.4.4) alla chiave DNS e un valore di dominio (myownpersonaldomain.com) alla chiave Domains:

linuxConfig:
  additionalEtcSystemdResolvedConf:
    - key: DNS
      value:
        - 8.8.8.8
        - 8.8.4.4
    - key: Domains
      value:
        - myownpersonaldomain.com

Voci /etc/resolv.conf aggiuntive

Questo campo aggiunge /etc/resolv.conf voci di file. Questo campo accetta un array di coppie chiave/valore. Sono supportate le seguenti chiavi:

• nameserver
• search
• sortlist
• options

L'esempio seguente aggiunge un valore del server DNS (1.1.1.1) alla chiave nameserver e un valore del dominio (myownpersonaldomain.com) alla chiave search:

linuxConfig:
  additionalEtcResolvConf:
    - key: nameserver
      value:
        - 1.1.1.1
    - key: search
      value:
        - myownpersonaldomain.com

Configurazione del fuso orario

Il campo timeZone imposta il fuso orario sul nodo, ad esempio America/Los_Angeles. Questa impostazione è supportata per i cluster che eseguono GKE 1.35.0-gke.1018000 o versioni successive.

L'esempio seguente imposta il campo timeZone su America/Los_Angeles:

linuxConfig:
  timeZone: America/Los_Angeles

Passaggi successivi

• Scopri come eseguire la migrazione dei nodi a Linux cgroupv2.
• Scopri come aggiungere e gestire i pool di nodi.
• Scopri come personalizzare la configurazione di containerd nei nodi GKE.
• Scopri come eseguire automaticamente il bootstrap dei nodi GKE con DaemonSet.