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 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 in un nodo è disponibile per l'utilizzo da parte dei carichi di lavoro.
Vantaggi dei nodi dimensionati correttamente
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à del carico di lavoro 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 le risorse dei nodi, come CPU e memoria. Potresti notare una differenza tra le risorse totali del nodo, che si basano sulle dimensioni della macchina virtuale (VM) Compute Engine sottostante, e le risorse disponibili per i tuoi carichi di lavoro GKE da richiedere. 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 node pool, devi considerare quante risorse sono necessarie ai tuoi workload 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 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 macchina più grandi eseguono più container e pod, quindi la quantità di risorse riservate da GKE 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.
Riservare 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 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
GKE riserva anche 100 MiB di memoria aggiuntiva su ogni nodo per gestire l'espulsione dei pod.
Prenotazioni della CPU
Per le risorse CPU, GKE riserva quanto segue:
- 6% del primo core
- 1% del core successivo (fino a 2 core)
- 0,5% dei due core successivi (fino a 4 core)
- 0,25% di tutti i core oltre i 4 core
Per i tipi di macchine con core condivisi E2, GKE riserva un totale di 1060 millicore.
Prenotazione dello spazio di archiviazione temporanea locale
GKE fornisce nodi con spazio di archiviazione temporanea locale, supportato da dispositivi collegati localmente, come il disco di avvio del nodo o le SSD locali. L'archiviazione temporanea non offre alcuna garanzia di disponibilità e i dati nell'archiviazione temporanea potrebbero essere persi se un nodo non funziona e viene eliminato.
GKE riserva una parte dell'archiviazione temporanea totale del nodo come singolo file system da utilizzare per kubelet durante l'espulsione dei pod e per altri componenti di sistema in esecuzione sul nodo. Puoi allocare lo spazio di archiviazione effimero rimanente ai tuoi pod per utilizzarlo per scopi quali i log. Per scoprire come specificare richieste e limiti di 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 esegue il backup dello spazio di archiviazione.
Spazio di archiviazione temporanea supportato 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 sfratto nel seguente modo:
EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY
La soglia di sfratto è 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 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 espulsione: 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 l'archiviazione temporanea è supportata 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 collegati. Tutti gli
SSD locali hanno una dimensione di 375 GiB, quindi la soglia di sfratto è il 10% della capacità totale
dello spazio di archiviazione temporaneo. 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 delle immagini dei nodi.
GKE calcola la prenotazione di sistema in base al numero di SSD collegati, come segue:
| Numero di SSD locali | Riserva di sistema (GiB) |
|---|---|
| 1 | 50 GB |
| 2 | 75 GiB |
| 3 o più | 100 GiB |
Utilizzare le prenotazioni delle risorse per pianificare le dimensioni dei nodi
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 consentire lo scale up.
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 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 è ideale per i carichi di lavoro ad alta disponibilità che non richiedono molte risorse. La scalabilità automatica dei nodi è più agile perché perché si verifichi uno scale down è necessario eliminare meno pod.
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.
Prendi in considerazione i requisiti di archiviazione temporanea dei tuoi workload. Il disco di avvio del nodo è sufficiente? Hai bisogno di SSD locali?
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 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 carico di lavoro.