Questa pagina descrive come pianificare la dimensione dei nodi in Google Kubernetes Engine (GKE) Pool di nodi standard per ridurre il rischio di interruzioni dei carichi di lavoro e terminazioni per risorse esterne.
Questa pianificazione non è necessaria in GKE Autopilot perché Google Cloud gestisce i nodi per te. Tuttavia, questo documento consente di creare cluster Autopilot di operatori che vogliono capire quanta capacità delle risorse disponibili per l'uso da parte dei 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 il ridimensionamento 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 un parte del tuo cluster. Questi componenti utilizzano risorse dei nodi, come CPU la 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 di risorse e limiti nella specifica del pod. Quando GKE posiziona i pod su 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 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 allocabili
risorse sul nodo. I valori nella sezione capacity sono le risorse
totali sul nodo. Le unità di archiviazione temporanea sono byte.
Prenotazioni di risorse GKE
GKE prenota quantità specifiche di risorse di memoria e CPU di nodi in base alla dimensione totale della risorsa disponibile sul nodo. Più grande di macchine eseguono più container e pod, quindi la quantità di risorse GKE prenota lo scale up per 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 seguenti sezioni descrivono le prenotazioni di memoria e CPU predefinite basate 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
- 20% dei successivi 4 GiB di memoria (fino a 8 GiB)
- 10% degli 8 GiB di memoria successivi (fino a 16 GiB)
- 6% dei successivi 112 GiB di memoria (fino a 128 GiB)
- Il 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 riserva quanto segue:
- 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 qualsiasi core superiore a 4 core
Per tipi di macchine E2 con core condivisi, GKE prenota un totale di 1060 millisecondi.
Prenotazione dello spazio di archiviazione temporaneo 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. Temporaneo non ha alcuna garanzia di disponibilità e i dati nello spazio di archiviazione viene perso se un nodo si guasta e viene eliminato.
GKE prenota una parte dell'archiviazione temporanea totale del nodo un singolo file system che il kubelet può usare durante l'eliminazione dei pod e per altri componenti di sistema in esecuzione sul nodo. Puoi allocare le risorse temporanee rimanenti ai tuoi pod per utilizzarlo per scopi come 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.
Spazio di archiviazione temporanea basato sul 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 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 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 riserva quanto segue:
- Riserva di sistema: 100 GiB (il valore più basso)
- Soglia di espulsione: 30 GiB
Lo spazio di archiviazione temporaneo totale riservato è di 130 GiB. La capacità rimanente, 170 GiB, è costituita da spazio di archiviazione temporaneo allocabile.
Archiviazione temporanea supportata 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 unità 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 viene calcolato prima che le unità vengano
quindi la capacità utilizzabile è di diversi percento in meno, a seconda
delle versioni delle immagini dei nodi.
GKE calcola la prenotazione del sistema in base al numero di SSD collegate, come segue:
| Numero di SSD locali | Prenotazione di sistema (GiB) |
|---|---|
| 1 | 50 GiB |
| 2 | 75 GiB |
| 3 o più | 100 GiB |
Utilizza le prenotazioni di risorse per pianificare le dimensioni dei nodi
Tieni conto dei requisiti delle risorse dei 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 funziona bene per carichi di lavoro che richiedono molte risorse che non richiedono l'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 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.
Utilizza la Guida al confronto tra famiglie di macchine Compute Engine per determinare le serie di macchine e la famiglia che preferisci per i tuoi nodi.
Considera i 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 il metodo informazioni 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 usare una macchina più grande per ridurre il rischio di interruzioni del carico di lavoro.