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 del carico di lavoro e interruzioni per esaurimento delle risorse.
Questa pianificazione non è necessaria in GKE Autopilot perché Google Cloud gestisce i nodi per te. Tuttavia, questo documento è utile per gli operatori dei cluster Autopilot che vogliono capire quanta parte della capacità delle risorse di un nodo è disponibile per i carichi di lavoro.
Vantaggi dei nodi di dimensioni adeguate
Assicurarsi che i nodi siano dimensionati correttamente per soddisfare i carichi di lavoro e gestire gli picchi di attività offre vantaggi quali:
- Maggiore affidabilità del carico di lavoro grazie a un rischio ridotto di espulsione per esaurimento delle risorse.
- Scalabilità migliorata per la scalabilità dei carichi di lavoro durante i periodi di traffico elevato.
- Riduci i costi perché i nodi non sono troppo grandi per le tue esigenze, il che potrebbe comportare un'inutile 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 del nodo, come CPU e memoria. Potresti notare una differenza tra le risorse totali del tuo nodo, che si basano sulle dimensioni della macchina virtuale (VM) di Compute Engine sottostante, e le risorse disponibili che i carichi di lavoro GKE possono 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 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 carichi di lavoro per funzionare correttamente.
Controllare le risorse allocabili su un nodo
Per controllare le risorse allocabili su un nodo esistente, esegui il seguente 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 spazio di archiviazione temporanea sono i byte.
Prenotazioni di 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, pertanto la quantità di risorse che GKE riserva aumenta per le macchine più grandi. I nodi Windows Server richiedono inoltre 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 di memoria e CPU predefinite in base al tipo di macchina.
Prenotazioni di memoria
Per le risorse di memoria, GKE riserva quanto segue:
- 255 MiB di memoria per le macchine con meno di 1 GiB di memoria
- 25% dei primi 4 GB di memoria
- Il 20% dei successivi 4 GB di memoria (fino a 8 GB)
- 10% dei successivi 8 GB di memoria (fino a 16 GB)
- Il 6% dei successivi 112 GiB di memoria (fino a 128 GiB)
- 2% di qualsiasi memoria superiore a 128 GiB
GKE riserva inoltre 100 MiB di memoria aggiuntiva su ogni nodo per gestire l'espulsione dei pod.
Prenotazioni CPU
Per le risorse CPU, GKE si riserva quanto segue:
- 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 qualsiasi core superiore a 4 core
Per i tipi di macchine E2 con core condivisi, GKE si riserva un totale di 1060 millicore.
Prenotazione dello spazio di archiviazione temporanea locale
GKE fornisce ai nodi spazio di archiviazione temporaneo locale, supportato da dispositivi collegati localmente come il disco di avvio del nodo o le SSD locali. L'archiviazione temporanea non ha alcuna garanzia di disponibilità e i dati archiviati in questo tipo di spazio potrebbero andare persi se un nodo si arresta in modo anomalo e viene eliminato.
GKE riserva una parte dell'archiviazione temporanea totale del nodo come singolo file system da utilizzare da parte di kubelet durante l'espulsione 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 temporanea 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.
Spazio di archiviazione temporanea basato sul disco di avvio del nodo
Per impostazione predefinita, lo spazio di archiviazione temporaneo è supportato dal disco di avvio del nodo. In questo caso, GKE determina il valore della soglia di espulsione come segue:
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 del 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 GB, si applicano i seguenti valori:
- 50% della capacità: 150 GiB
- 35% della capacità + 6 GiB: 111 GiB
- 100 GiB
GKE prenoterà quanto segue:
- Riserva di sistema: 100 GiB (il valore più basso)
- Soglia di espulsione: 30 GiB
Lo spazio di archiviazione temporaneo riservato totale è di 130 GiB. La capacità rimanente, 170 GiB, è costituita da spazio di archiviazione temporaneo allocabile.
Spazio di archiviazione temporaneo supportato da SSD locali
Se lo spazio di archiviazione temporaneo è supportato da SSD locali, GKE calcola la soglia di espulsione nel seguente modo:
EVICTION_THRESHOLD = 10% * SSD_NUMBER * 375 GiB
In questo calcolo, SSD_NUMBER è il numero di SSD locali collegate. Tutti
gli SSD locali hanno una dimensione di 375 GiB, quindi la soglia di espulsione è pari al 10% della
capacità di archiviazione effimera totale. Tieni presente che questo valore viene calcolato prima della formattazione delle unità, pertanto la capacità utilizzabile è inferiore di alcune percentuali, a seconda delle versioni delle immagini del nodo.
GKE calcola la prenotazione del sistema in base al numero di SSD collegate, come segue:
| 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
Tieni conto dei requisiti delle risorse dei tuoi carichi di lavoro al momento del deployment e sotto carico. Sono incluse le richieste e i limiti pianificati per i carichi di lavoro, nonché il sovraccarico per supportare l'aumento di scala.
Valuta se vuoi un numero ridotto di nodi di grandi dimensioni o un numero elevato di nodi di piccole dimensioni per eseguire i tuoi carichi di lavoro.
- Un numero ridotto di nodi di grandi dimensioni è ideale per i carichi di lavoro che richiedono molte risorse e che non richiedono un'alta disponibilità. 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 funziona bene per i carichi di lavoro ad alta disponibilità che non richiedono molte risorse. La scalabilità automatica dei nodi è più agile perché occorre eliminare meno pod per eseguire lo scale down.
Consulta la guida al confronto delle famiglie di macchine Compute Engine per determinare la serie e la famiglia di macchine che preferisci per i tuoi nodi.
Tieni conto dei requisiti di archiviazione temporanea dei tuoi carichi di lavoro. Il disco di avvio del nodo è sufficiente? Hai bisogno di SSD locali?
Calcola le risorse allocabili sul tipo di macchina scelto utilizzando le informazioni riportate nelle sezioni precedenti. Confronta questo con le risorse e il carico aggiuntivo 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 del carico di lavoro.