Questa pagina è stata tradotta dall'API Cloud Translation.

Informazioni sulle dimensioni dei nodi GKE

Autopilot Standard

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 è obbligatoria in GKE Autopilot perché Google Cloud gestisce i nodi al posto tuo. 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 supportare i carichi di lavoro per gestire picchi di attività offre vantaggi quali:

Migliore affidabilità dei carichi di lavoro grazie a un rischio ridotto di esaurimento delle risorse l'eliminazione.
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 sprecare risorse.

Risorse allocabili dei nodi

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 nodo, si basano sulle dimensioni della macchina virtuale (VM) Compute Engine sottostante, e le risorse disponibili per GKE carichi di lavoro da richiedere. Questa differenza è dovuta al fatto che GKE prenota quantità predefinita di risorse per la funzionalità di sistema e l'affidabilità del nodo. Lo spazio su disco riservato da GKE per le risorse di sistema è diverso in base al nodo dell'immagine. La le risorse rimanenti disponibili per i carichi di lavoro 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 tuoi pool di nodi, valuta di quante risorse i 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 allocabili risorse sul nodo. I valori nella sezione capacity corrispondono ai totali risorse 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. Nodi Windows Server richiedono anche più risorse rispetto ai nodi Linux equivalenti, per tenere conto dell'esecuzione per il sistema operativo Windows e per i componenti Windows Server che non possono essere eseguiti containerizzati.

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 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

GKE prenota inoltre 100 MiB aggiuntivi 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

di Gemini Advanced.

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 archiviazione temporanea locale, supportata da dai dispositivi collegati in locale, come il disco di avvio del nodo o gli 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 unico 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 spazio di archiviazione ai tuoi pod per utilizzarlo per scopi come i log. Per scoprire come specificare richieste e limiti di archiviazione temporanea nei tuoi pod, 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 associato 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 è spazio di archiviazione temporaneo allocabile.

Archiviazione temporanea supportata da SSD locali

Se lo spazio di archiviazione temporaneo è supportato 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. Tutti le unità SSD locali hanno una dimensione di 375 GiB, quindi la soglia di eliminazione è pari al 10% del totale di archiviazione temporanea. 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 di sistema in base al numero 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 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 un numero ridotto di nodi di grandi dimensioni o un numero elevato di nodi piccoli 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 rimuovere più pod affinché si verifichi uno 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é perché venga eseguito lo scale down è necessario rimuovere meno pod.
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? Hai bisogno di SSD locali?
Calcola le risorse allocabili sul tipo di macchina scelto utilizzando il metodo informazioni 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 evitando 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.