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 workload e di terminazioni dovute a 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 in un nodo è disponibile per l'utilizzo da parte dei workload.

Vantaggi dei nodi con dimensioni adeguate

Assicurarsi che i nodi abbiano le dimensioni corrette per ospitare i workload e gestire i picchi di attività offre vantaggi come i seguenti:

  • Maggiore affidabilità dei workload grazie a un rischio ridotto di eliminazione dovuta a esaurimento delle risorse.
  • Scalabilità migliorata per la scalabilità dei 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 dei nodi

I nodi GKE eseguono componenti di sistema che consentono al nodo di funzionare come parte del cluster. Questi componenti utilizzano le 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 i workload GKE da richiedere. Questa differenza è dovuta al fatto che GKE riserva una quantità predefinita di risorse per la funzionalità del sistema e l'affidabilità dei nodi. Lo spazio su disco riservato da GKE per le risorse di sistema varia in base all'immagine del nodo. Le risorse rimanenti disponibili per i workload 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 inserisce i pod su un nodo, il pod richiede le risorse specificate dalle risorse allocabili sul nodo. Quando pianifichi le dimensioni dei nodi nei pool di nodi, devi considerare quante risorse sono necessarie ai workload per funzionare correttamente.

Controllare le risorse allocabili su un nodo

Per controllare le risorse allocabili su un nodo esistente, esegui il comando seguente:

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 spazio 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 delle risorse disponibili sul nodo. I tipi di macchine più grandi eseguono più container e pod, quindi la quantità di risorse riservate da GKE aumenta per le macchine più grandi. Anche i nodi Windows Server richiedono più risorse rispetto ai nodi Linux equivalenti, per tenere conto dell'esecuzione del sistema operativo Windows e dei componenti di 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 pool di nodi 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 delle 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 versione 1.37 o successive, GKE utilizza la seguente formula:

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

    GKE utilizza il valore inferiore di un calcolo che tiene conto della densità dei pod o EarlierMemoryReservation, ovvero il calcolo della prenotazione per i pool di nodi creati con la versione 1.36 o precedenti.

    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 eliminazione dei pod.

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

    • 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 memoria superiore a 128 GiB
    • Altri 100 MiB di memoria per le soglie di eliminazione dei pod
    • Se lo streaming di immagini è abilitato, un buffer aggiuntivo, come descritto in Prenotazione di memoria per lo streaming di immagini.

Prenotazioni di CPU

Per i pool di nodi creati con GKE versione 1.37 o successive, GKE limita la prenotazione totale della CPU a 1 vCPU (1000 mCPU) o meno per le istanze di calcolo 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 calcolo con un numero elevato di core non perdano più core di capacità allocabile per le prenotazioni di sistema. Il limite di 1 vCPU non si applica ai pool di nodi creati con GKE versione 1.36 o 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 successivi 2 core (fino a 4 core)
  • 0,25% di tutti i core superiori a 4 core

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

Prenotazione dello spazio di archiviazione temporanea locale

GKE fornisce ai nodi spazio di archiviazione temporanea locale, supportato da dispositivi collegati localmente, come il disco di avvio del nodo o gli SSD locali. Lo spazio di archiviazione temporanea non ha alcuna garanzia di disponibilità e i dati nello spazio di archiviazione temporanea potrebbero essere persi se un nodo non funziona e viene eliminato.

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

GKE calcola la prenotazione dello spazio di archiviazione temporanea locale nel seguente modo:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

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

Spazio di archiviazione temporanea supportato dal disco di avvio del nodo

Per impostazione predefinita, lo spazio di archiviazione temporanea è supportato dal disco di avvio del nodo. In questo caso, GKE determina il valore della soglia di eliminazione nel seguente modo:

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

La soglia di eliminazione è sempre il 10% della capacità totale del disco di avvio.

GKE determina il valore della prenotazione di sistema nel seguente modo:

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

L'importo della prenotazione di sistema è il più basso dei 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 riserverà quanto segue:

  • Prenotazione di sistema: 100 GiB (il valore più basso)
  • Soglia di eliminazione: 30 GiB

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

Spazio di archiviazione temporanea supportato da SSD locali

Se lo spazio di archiviazione temporanea è supportato da SSD locali, GKE calcola la soglia di eliminazione nel seguente modo:

EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB

In questo calcolo, SSD_NUMBER è il numero di SSD locali collegati. Tutti gli SSD locali hanno dimensioni di 375 GiB, quindi la soglia di eliminazione è il 10% della capacità totale dello spazio di archiviazione temporanea. 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 dell'immagine del nodo.

GKE calcola la prenotazione di sistema in base al numero di SSD collegati, come segue:

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

Utilizzare le prenotazioni delle risorse per pianificare le dimensioni dei nodi

  1. Considera i requisiti delle risorse dei workload al momento del deployment e sotto carico. Sono incluse le richieste e i limiti pianificati per i workload, nonché l'overhead per la scalabilità verticale.

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

    • Un numero ridotto di nodi di grandi dimensioni è ideale per i workload che richiedono molte risorse e non richiedono alta affidabilità. La scalabilità automatica dei nodi è meno agile perché è necessario eliminare 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 eliminare 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 nodi.

  4. Considera i requisiti di spazio di archiviazione temporanea dei 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 di cui hai bisogno.

    • Se il tipo di macchina scelto è troppo grande, valuta la possibilità di utilizzare una macchina più piccola per evitare di pagare 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 dei workload.

Passaggi successivi