Questa pagina è stata tradotta dall'API Cloud Translation.

Pianifica le dimensioni dei nodi GKE Standard

Standard

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 senza risorse. Questa pianificazione non è necessaria in GKE Autopilot perché Google gestisce i nodi per te.

Vantaggi dei nodi di dimensioni adeguate

Garantire che i nodi siano dimensionati correttamente per supportare i carichi di lavoro e gestire i picchi di attività offre vantaggi quali:

Migliore affidabilità dei carichi di lavoro grazie a un rischio ridotto di eliminazione delle risorse esaurite.
Scalabilità migliorata per la scalabilità dei carichi di lavoro durante i periodi di traffico elevato.
Costi inferiori perché i nodi non sono troppo grandi per le tue esigenze, il che potrebbe portare a sprechi 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 risorse dei nodi, come CPU e memoria. Potresti notare una differenza tra le risorse totali del nodo, che sono basate sulle dimensioni della macchina virtuale (VM) Compute Engine sottostante e le risorse disponibili per la richiesta dei 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 prenota per le risorse di sistema varia in base all'immagine del nodo. Le risorse rimanenti disponibili per i carichi di lavoro sono chiamate risorse allocabili.

Quando definisci i pod in un manifest, puoi specificare le richieste e i limiti di risorse nella specifica del pod. Quando GKE posiziona i pod su un nodo, richiede le risorse specificate alle risorse allocabili sul nodo. Quando pianifichi le dimensioni dei nodi nei tuoi pool di nodi, dovresti considerare di quante risorse i tuoi carichi di lavoro hanno bisogno per funzionare correttamente.

Controlla le risorse allocabili su un nodo

Per ispezionare 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 corrispondono alle 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 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 prenota aumenta per le macchine di dimensioni maggiori. Inoltre, i nodi Windows Server richiedono più risorse dei 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 seguenti sezioni 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 GiB 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)
2% di memoria superiore a 128 GiB

Inoltre, GKE prenota altri 100 MiB di memoria su ogni nodo per gestire l'eliminazione 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 tutti i core sopra i 4 core

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

Prenotazione dello spazio di archiviazione temporaneo locale

GKE fornisce nodi con archiviazione temporanea locale, supportati da dispositivi collegati localmente, come il disco di avvio del nodo o gli SSD locali. L'archiviazione temporanea non garantisce la disponibilità e i dati nello spazio di archiviazione temporanea potrebbero andare persi se un nodo si guasta e viene eliminato.

GKE prenota una parte dell'archiviazione temporanea totale del nodo come singolo file system che il 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 usarli per scopi come i log. Per scoprire come specificare richieste e limiti di archiviazione temporanea nei tuoi pod, consulta Archiviazione temporanea locale.

GKE calcola la prenotazione dell'archiviazione temporanea locale come segue:

EVICTION_THRESHOLD + SYSTEM_RESERVATION

I valori effettivi variano in base alle dimensioni e al tipo di dispositivo utilizzato per 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 eliminazione come segue:

EVICTION_THRESHOLD = 10% * BOOT_DISK_CAPACITY

La soglia di eliminazione è 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:

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

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

Archiviazione temporanea supportata da SSD locali

Se lo spazio di archiviazione temporaneo è supportato da SSD locali, GKE calcola la soglia di eliminazione 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 eliminazione è pari al 10% della capacità di archiviazione temporanea totale. Tieni presente che questo viene calcolato prima che le unità vengano formattate, 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 collegati, 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

Considera i requisiti in termini di risorse dei tuoi carichi di lavoro al momento del deployment e sotto carico. Ciò include le richieste e i limiti pianificati per i carichi di lavoro, nonché l'overhead per consentire lo scale up.
Valuta se vuoi che un numero ridotto di nodi di grandi dimensioni o un numero elevato di nodi piccoli per eseguire i carichi di lavoro.
- Un numero ridotto di nodi grandi è ideale per carichi di lavoro ad alta intensità di risorse che non richiedono un'alta disponibilità. La scalabilità automatica dei nodi è meno agile perché è necessario rimuovere più pod affinché si verifichi uno scale down.
- Un numero elevato di nodi di piccole dimensioni funziona bene per carichi di lavoro a disponibilità elevata che non richiedono un uso intensivo delle risorse. La scalabilità automatica dei nodi è più agile perché è necessario rimuovere meno pod affinché venga eseguito lo scale down.
Utilizza la guida al confronto tra le famiglie di macchine di Compute Engine per determinare le serie e la famiglia di macchine utilizzate per i 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 le informazioni riportate nelle sezioni precedenti. Confrontalo con le risorse e l'overhead di cui hai bisogno.
- Se il tipo di macchina scelto è troppo grande, prendi in considerazione una macchina più piccola per evitare di pagare per 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.