Informazioni sul dimensionamento dei nodi GKE

Questa pagina descrive come pianificare le dimensioni dei nodi nei pool di nodi standard di Google Kubernetes Engine (GKE) per ridurre il rischio di interruzioni dei carichi di lavoro e terminazioni per esaurimento delle risorse.

Questa pianificazione non è necessaria in GKE Autopilot perché Google Cloud gestisce i nodi per te. Tuttavia, questo documento aiuta gli operatori dei cluster Autopilot che vogliono capire quanta capacità delle risorse di un nodo è disponibile per i workload.

Vantaggi dei nodi di dimensioni adeguate

Se ti assicuri che i nodi siano dimensionati correttamente per ospitare i workload e gestire i picchi di attività, otterrai i seguenti vantaggi:

  • Maggiore affidabilità del workload grazie a un rischio ridotto di espulsione per esaurimento delle risorse.
  • Scalabilità migliorata per scalare i workload durante i periodi di traffico elevato.
  • Costi inferiori perché i nodi non sono troppo grandi per le tue esigenze, il che potrebbe comportare uno spreco di risorse.

Risorse allocabili del nodo

I nodi GKE eseguono componenti di sistema che consentono al nodo di funzionare come parte del cluster. Questi componenti utilizzano risorse dei nodi, come CPU e memoria. Potresti notare una differenza tra le risorse totali del nodo, che si basano sulle dimensioni dell'istanza Compute Engine sottostante, e le risorse disponibili per le richieste dei tuoi carichi di lavoro GKE. Questa differenza è dovuta al fatto che GKE riserva una quantità predefinita di risorse per la funzionalità di sistema e l'affidabilità dei nodi. Lo spazio su disco che GKE riserva per le risorse di sistema varia in base all'immagine del nodo. Le risorse rimanenti disponibili per i tuoi carichi di lavoro sono chiamate risorse allocabili.

Quando definisci i pod in un manifest, puoi specificare le richieste e i limiti delle risorse nella specifica del pod. Quando GKE posiziona i pod su un nodo, il pod richiede le risorse specificate dalle risorse allocabili sul nodo. Quando pianifichi le dimensioni dei nodi nei tuoi pool di nodi, devi considerare quante risorse sono necessarie ai tuoi workload per funzionare correttamente.

Controllare le risorse allocabili su un nodo

Per esaminare le risorse allocabili su un nodo esistente, esegui questo comando:

kubectl get node NODE_NAME \
    -o=yaml | grep -A 7 -B 7 capacity

Sostituisci NODE_NAME con il nome del nodo.

L'output è simile al seguente:

allocatable:
  attachable-volumes-gce-pd: "127"
  cpu: 3920m
  ephemeral-storage: "47060071478"
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 13498416Ki
  pods: "110"
capacity:
  attachable-volumes-gce-pd: "127"
  cpu: "4"
  ephemeral-storage: 98831908Ki
  hugepages-1Gi: "0"
  hugepages-2Mi: "0"
  memory: 16393264Ki
  pods: "110"

In questo output, i valori nella sezione allocatable sono le risorse allocabili sul nodo. I valori nella sezione capacity sono le risorse totali sul nodo. Le unità di archiviazione temporanea sono byte.

Prenotazioni delle risorse GKE

GKE riserva quantità specifiche di risorse di memoria e CPU sui nodi in base alle dimensioni totali della risorsa disponibile sul nodo. I tipi di macchine più grandi eseguono più container e pod, quindi la quantità di risorse che GKE riserva aumenta per le macchine più grandi. I nodi Windows Server richiedono anche più risorse rispetto ai nodi Linux equivalenti, per tenere conto dell'esecuzione del sistema operativo Windows e dei componenti Windows Server che non possono essere eseguiti nei container.

Prenotazioni di memoria e CPU

Le sezioni seguenti descrivono le prenotazioni predefinite di memoria e CPU in base al tipo di macchina.

Per i node pool Standard che eseguono GKE 1.37 o versioni successive, puoi personalizzare la quantità di CPU e memoria riservata ai componenti di sistema. Per saperne di più, consulta Prenotazioni di risorse di sistema (anteprima).

Prenotazioni di memoria

GKE calcola le prenotazioni di memoria nei seguenti modi, a seconda della versione di GKE su cui è stato creato il pool di nodi:

  • Se il pool di nodi è stato creato con GKE 1.37 o versioni successive, GKE utilizza la seguente formula:

    MemoryReserved = Min(EarlierMemoryReservation, (15 MiB * MaxPodsPerNode) + BaseOverhead)

    GKE utilizza il valore più basso di un calcolo che tiene conto della densità dei pod o di EarlierMemoryReservation, ovvero il calcolo della prenotazione per i node pool creati con la versione 1.36 o precedente.

    In questa formula, il valore di BaseOverhead dipende dalla configurazione del nodo, come segue:

    Vengono riservati altri 100 MiB di memoria per le soglie di espulsione dei pod.

  • Se il pool di nodi è stato creato con GKE 1.36 o versioni precedenti, GKE utilizza la seguente formula. GKE utilizza questa formula anche se ilpool di nodil viene aggiornato in un secondo momento alla versione 1.37 o successiva:

    • 255 MiB per le macchine con meno di 1 GiB di memoria
    • 25% dei primi 4 GiB di memoria
    • 20% dei successivi 4 GiB di memoria (fino a 8 GiB)
    • 10% dei successivi 8 GiB di memoria (fino a 16 GiB)
    • 6% dei successivi 112 GiB di memoria (fino a 128 GiB)
    • 2% di qualsiasi memoria superiore a 128 GiB
    • 100 MiB di memoria aggiuntiva per le soglie di espulsione dei pod
    • Se lo streaming delle immagini è attivato, viene utilizzato un buffer aggiuntivo, come descritto in Riserva di memoria per lo streaming delle immagini.

Prenotazioni della CPU

Per i node pool creati su GKE versione 1.37 o successive, GKE limita la prenotazione totale della CPU a 1 vCPU (1000 mCPU) o meno per le istanze di computing standard non frazionarie. I componenti di sistema possono comunque superare questo limite quando necessario. Il limite di 1 vCPU contribuisce a garantire che le istanze di computing con molti core non perdano più core di capacità allocabile per le prenotazioni di sistema. Il limite di 1 vCPU non si applica ai node pool creati su GKE 1.36 o versioni precedenti. GKE calcola le prenotazioni di CPU utilizzando la seguente formula:

  • 6% del primo core
  • 1% del core successivo (fino a 2 core)
  • 0,5% dei 2 core successivi (fino a 4 core)
  • 0,25% di tutti i core superiori a 4 core

Per i tipi di macchine E2 con core condiviso, GKE riserva comunque un totale di 1060 millicore.

Prenotazione dello spazio di archiviazione temporanea locale

GKE fornisce nodi con archiviazione temporanea locale, supportata da dispositivi collegati localmente, come il disco di avvio del nodo o gli SSD locali. L'archiviazione temporanea non ha alcuna garanzia di disponibilità e i dati al suo interno potrebbero andare persi se un nodo non funziona e viene eliminato.

GKE riserva una parte dello spazio di archiviazione temporaneo totale del nodo come un unico file system che kubelet può utilizzare durante l'eliminazione dei pod e per altri componenti di sistema in esecuzione sul nodo. Puoi allocare lo spazio di archiviazione temporaneo rimanente ai tuoi pod per utilizzarlo per scopi quali i log. Per scoprire come specificare richieste e limiti di spazio di archiviazione temporaneo nei pod, consulta Spazio di archiviazione temporaneo locale.

GKE calcola la prenotazione dello spazio di archiviazione temporaneo locale come segue:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

I valori effettivi variano in base alle dimensioni e al tipo di dispositivo che supporta lo spazio di archiviazione.

Archiviazione temporanea supportata dal disco di avvio del nodo

Per impostazione predefinita, l'archiviazione temporanea è supportata dal disco di avvio del nodo. In questo caso, GKE determina il valore della soglia di espulsione nel seguente modo:

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

La soglia di espulsione è sempre pari al 10% della capacità totale del disco di avvio.

GKE determina il valore della prenotazione di sistema come segue:

SYSTEM_RESERVATION = Min(50% * BOOT_DISK_CAPACITY, 6GiB + 35% * BOOT_DISK_CAPACITY, 100 GiB)

L'importo della prenotazione di sistema è il più basso tra i seguenti:

  • 50% della capacità del disco di avvio
  • 35% della capacità del disco di avvio + 6 GiB
  • 100 GiB

Ad esempio, se il disco di avvio è di 300 GiB, si applicano i seguenti valori:

  • 50% della capacità: 150 GiB
  • 35% della capacità + 6 GiB: 111 GiB
  • 100 GiB

GKE riserverebbe quanto segue:

  • Riserva di sistema: 100 GiB (il valore più basso)
  • Soglia di sfratto: 30 GiB

Lo spazio di archiviazione temporanea totale riservato è di 130 GiB. La capacità rimanente, 170 GiB, è spazio di archiviazione temporanea allocabile.

Archiviazione temporanea supportata da SSD locali

Se lo spazio di archiviazione temporaneo è supportato da SSD locali, GKE calcola la soglia di espulsione come segue:

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB

In questo calcolo, SSD_NUMBER è il numero di SSD locali collegati. Tutte le unità SSD locali hanno una dimensione di 375 GiB, quindi la soglia di espulsione è pari al 10% della capacità di archiviazione temporanea totale. Tieni presente che questo valore viene calcolato prima della formattazione delle unità, quindi la capacità utilizzabile è inferiore di diversi punti percentuali, a seconda delle versioni immagine dei nodi.

GKE calcola la prenotazione di sistema in base al numero di SSD collegati, nel seguente modo:

Numero di SSD locali Riserva di sistema (GiB)
1 50 GiB
2 75 GiB
3 o più 100 GiB

Utilizza le prenotazioni delle risorse per pianificare le dimensioni dei nodi

  1. Considera i requisiti delle risorse dei tuoi workload al momento del deployment e sotto carico. Sono incluse le richieste e i limiti pianificati per i carichi di lavoro, nonché l'overhead per adattarsi allo scale up.

  2. Valuta se vuoi un numero ridotto di nodi di grandi dimensioni o un numero elevato di nodi di piccole dimensioni per eseguire i tuoi workload.

    • Un numero ridotto di nodi di grandi dimensioni è adatto per workload ad alta intensità di risorse che non richiedono un'alta affidabilità. La scalabilità automatica dei nodi è meno agile perché è necessario rimuovere più pod per eseguire lo scale down.
    • Un numero elevato di nodi di piccole dimensioni è ideale per i workload ad alta disponibilità che non richiedono molte risorse. La scalabilità automatica dei nodi è più agile perché è necessario rimuovere meno pod per eseguire lo scale down.

  3. Utilizza la guida al confronto delle famiglie di macchine Compute Engine per determinare la serie e la famiglia di macchine che vuoi per i tuoi nodi.

  4. Considera i requisiti di archiviazione temporanea dei tuoi workload. Il disco di avvio del nodo è sufficiente? Hai bisogno di SSD locali?

  5. Calcola le risorse allocabili sul tipo di macchina scelto utilizzando le informazioni nelle sezioni precedenti. Confronta questo valore con le risorse e l'overhead necessari.

    • Se il tipo di macchina scelto è troppo grande, valuta la possibilità di utilizzare una macchina più piccola per evitare di pagare per le risorse aggiuntive.
    • Se il tipo di macchina scelto è troppo piccolo, valuta la possibilità di utilizzare una macchina più grande per ridurre il rischio di interruzioni del workload.

Passaggi successivi