Le unità a stato solido (SSD) locali sono unità SSD di dimensioni fisse che possono essere montate su una singola VM di Compute Engine. Puoi utilizzare l'SSD locale su GKE per ottenere uno spazio di archiviazione ad alte prestazioni non persistente (temporaneo) collegato a ogni nodo del cluster. Le unità SSD locali offrono anche una velocità effettiva superiore e una latenza inferiore rispetto ai dischi standard.
Nella versione 1.25.3-gke.1800 e successive, puoi configurare un pool di nodi GKE in modo che utilizzi l'SSD locale con un'interfaccia NVMe per l'archiviazione temporanea locale o l'archiviazione a blocchi non elaborati.
Se utilizzi GKE con cluster Standard, puoi collegare volumi SSD locali ai nodi quando crei i node pool. In questo modo, le prestazioni dell'archiviazione temporanea per i workload che utilizzano volumi emptyDir o PersistentVolume locali migliorano. Puoi creare node pool con SSD locali entro i limiti del tipo di macchina del cluster e le quote del progetto.
Un disco SSD locale è collegato a un solo nodo. I nodi stessi sono temporanei, il che significa che un workload può essere pianificato su un nodo diverso. Per assicurarti che i workload che richiedono SSD locali siano pianificati sui nodi appropriati, utilizza l'affinità dei nodi.
Ad esempio, utilizza l'etichetta del nodo cloud.google.com/gke-ephemeral-storage-local-ssd: "true".
Quando configuri le unità SSD locali, GKE monta automaticamente le seguenti directory sul volume SSD locale per migliorare le prestazioni: /var/lib/kubelet, /var/log/pods e /var/lib/containerd. Questo approccio contribuisce a garantire un accesso più rapido ai dati kubelet critici, ai log dei pod e ai file di runtime dei container.
Per ulteriori informazioni sui vantaggi e sulle limitazioni delle unità SSD locali, ad esempio le prestazioni e il numero consentito di dischi SSD per tipo di macchina, consulta Unità SSD locali nella documentazione di Compute Engine.
Perché scegliere gli SSD locali per GKE
L'SSD locale è una buona scelta se i tuoi workload hanno uno dei seguenti requisiti:
- Vuoi eseguire applicazioni che scaricano ed elaborano dati, come AI o machine learning, analisi, elaborazione batch, memorizzazione nella cache locale e database in memoria.
- Le tue applicazioni hanno esigenze di archiviazione specializzate e vuoi un accesso ai blocchi non elaborati su uno spazio di archiviazione temporaneo ad alte prestazioni.
- Vuoi eseguire applicazioni di dati specializzate e utilizzare i volumi SSD locali come cache a livello di nodo per i tuoi pod. Puoi utilizzare questo approccio per migliorare le prestazioni delle applicazioni di database in memoria come Aerospike o Redis.
Archiviazione temporanea
Ti consigliamo di utilizzare l'opzione --ephemeral-storage-local-ssd per eseguire il provisioning dell'SSD locale per l'archiviazione temporanea dei nodi (questa è l'impostazione predefinita se utilizzi una serie di macchine di terza generazione).
Questo approccio consente di inserire volumi emptyDir, livelli scrivibili dei container e immagini che insieme costituiscono l'archiviazione temporanea dei nodi su un SSD locale. I vantaggi includono una larghezza di banda di I/O migliore rispetto al Persistent Disk predefinito e tempi di avvio dei pod più rapidi.
L'utilizzo di SSD locali per l'archiviazione temporanea dei nodi significa che i volumi SSD locali del disco di avvio non sono disponibili per altri usi. Non modificare i dispositivi SSD locali come /dev/nvme*
direttamente utilizzando un DaemonSet con privilegi, HostPath o un altro meccanismo; in caso contrario,
il nodo potrebbe non funzionare.
Se hai bisogno di un controllo granulare sui volumi SSD locali, utilizza l'approccio con blocco non formattato.
Spazio di archiviazione dei dispositivi a blocchi
Lo spazio sul dispositivo a blocchi consente l'accesso casuale ai dati in blocchi di dimensioni fisse. Alcune applicazioni specializzate richiedono l'accesso diretto allo spazio sul dispositivo a blocchi perché, ad esempio, il livello del file system introduce un overhead non necessario.
Gli scenari comuni per l'utilizzo dello spazio di archiviazione dei dispositivo a blocchi includono:
- Database in cui i dati sono organizzati direttamente nello spazio di archiviazione sottostante.
- Software che implementa un tipo di servizio di archiviazione (sistemi di archiviazione software-defined).
In GKE v1.25.3-gke.1800 e versioni successive, puoi creare cluster e node pool con SSD NVMe locali a blocchi non formattati collegati utilizzando l'opzione --local-nvme-ssd-block. Puoi quindi personalizzare l'archiviazione a blocchi formattando un file system di tua scelta (ad esempio ZFS o HDFS) e configurando il RAID. Questa opzione è adatta se hai bisogno di un controllo aggiuntivo per eseguire workload che richiedono specificamente l'accesso all'archiviazione a blocchi supportata da SSD locale.
Puoi anche utilizzare l'approccio di accesso a blocchi con SSD locale se vuoi una cache di dati unificata per condividere i dati tra i pod e i dati sono legati al ciclo di vita di un nodo. Per farlo, installa un DaemonSet con una configurazione RAID, formatta un file system e utilizza un PersistentVolume locale per condividere i dati tra i pod.
Requisiti della macchina
Il modo in cui esegui il provisioning degli SSD locali per i cluster GKE e i node pool dipende dal tipo di macchina sottostante. GKE supporta i volumi SSD locali sulle serie di macchine di prima, seconda e terza generazione di Compute Engine. I volumi SSD locali richiedono un tipo di macchina n1-standard-1 o superiore.
Il tipo di macchina predefinito, e2-medium, non è supportato.
Per identificare la serie di macchine, utilizza il numero nel nome del tipo di macchina. Ad esempio, le macchine N1 sono di prima generazione e le macchine N2 sono di seconda generazione.
Per un elenco delle serie e dei tipi di macchine disponibili, consulta la guida alle risorse e al confronto per le famiglie di macchine nella documentazione di Compute Engine.
GKE non supporta l'utilizzo della serie di macchine C4N con SSD locali. Il supporto degli SSD locali è disponibile con questa serie di macchine in anteprima con Compute Engine.
Requisiti delle serie di macchine di prima e seconda generazione
Per utilizzare una serie di macchine di prima o seconda generazione con SSD locale, il cluster o il pool di nodi deve eseguire GKE versione 1.25.3-gke.1800 o successiva.
Per eseguire il provisioning di SSD locali su una serie di macchine di prima o seconda generazione, specifica il numero di volumi SSD locali da utilizzare con la VM. Per un elenco delle serie di macchine e del numero consentito di SSD locali, consulta Scegli un numero valido di SSD locali nella documentazione di Compute Engine.
Requisiti delle serie di macchine di terza e quarta generazione
Se vuoi utilizzare una serie di macchine di terza generazione con SSD locale, il tuo cluster o pool di nodi deve eseguire una delle seguenti versioni di GKE o successive:
- Da 1.25.13-gke.200 a 1.26
- Da 1.26.8-gke.200 a 1.27
- Da 1.27.5-gke.200 a 1.28
- Da 1.28.1-gke.200 a 1.29
Se vuoi utilizzare una serie di macchine di quarta generazione con SSD locale, il tuo cluster o pool di nodi deve eseguire una delle seguenti versioni di GKE o successive:
- 1.32.1-gke.1357000
Per le serie di macchine di terza e quarta generazione, ogni tipo di macchina è preconfigurato senza SSD locale o con un volume fisso di SSD locali. Non specifichi il numero di volumi SSD locali da includere. La capacità delle unità SSD locali disponibile per i cluster viene invece definita implicitamente come parte della forma della VM.
Per un elenco delle serie di macchine e del numero consentito di SSD locali corrispondenti, consulta Scegli un numero valido di SSD locali nella documentazione di Compute Engine.
Pattern di utilizzo per i volumi SSD locali
Per utilizzare i volumi SSD locali nei tuoi cluster, segui questi passaggi generali:
- Esegui il provisioning di un pool di nodi con SSD locale collegata: per creare un pool di nodi GKE con SSD locali collegate, passa il parametro di archiviazione temporanea o di archiviazione a blocchi non elaborati quando chiami il comando
create cluster. L'impostazione dei parametri degli SSD locali crea un pool di nodi GKE con SSD locali collegati e configurati come archiviazione temporanea locale o archiviazione a blocchi non formattati, a seconda dei parametri scelti. Per scoprire di più sulle opzioni per il provisioning delle unità SSD locali, consulta Parametri delle unità SSD locali. - Accedi ai dati dai volumi SSD locali: per utilizzare i dati dei volumi SSD locali, puoi utilizzare un costrutto Kubernetes come emptyDir o un volume permanente locale. Per saperne di più su queste opzioni, consulta Accesso alle unità SSD locali.
Parametri degli SSD locali su GKE
La tabella seguente riassume i parametri consigliati forniti da GKE per il provisioning dello spazio di archiviazione SSD locale sui cluster. Puoi utilizzare gcloud CLI per passare questi parametri.
| Tipo di SSD locale | Comando gcloud CLI | Disponibilità di GKE | Profilo SSD locale |
|---|---|---|---|
| SSD locale per archiviazione temporanea | gcloud container clusters create |
v1.25.3-gke.1800 o versioni successive |
Tecnologia di archiviazione: NVMe Dati condivisi tra i pod: No Ciclo di vita dei dati: pod Dimensioni e necessità di configurazione RAID: fino a 9 TiB. GKE configura automaticamente il RAID in background. Formato: File System (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler di Kubernetes aiuta a garantire che lo spazio sul nodo sia disponibile prima del posizionamento e scala i nodi se necessario. Per scoprire come utilizzare questo parametro API, consulta Esegui il provisioning e utilizza lo spazio di archiviazione temporaneo supportato da SSD locale. |
| Blocco SSD NVMe locale | gcloud container clusters create |
v1.25.3-gke.1800 o versioni successive |
Tecnologia di archiviazione: NVMe Dati condivisi tra i pod: sì, tramite i PV locali. Ciclo di vita dei dati: nodo Dimensioni e necessità di configurazione RAID: fino a 9 TiB. Devi configurare manualmente il RAID per dimensioni maggiori. Formato: blocco non elaborato Integrazione dello scheduler Kubernetes: no, per impostazione predefinita. Devi garantire la capacità sui nodi e gestire i vicini rumorosi. Se attivi il PV locale, la pianificazione è integrata. Per scoprire come utilizzare questo parametro dell'API, consulta Esegui il provisioning e utilizza l'archiviazione a blocchi non elaborati supportata da SSD locali. |
Supporto dei parametri SSD locali esistenti
La tabella seguente riassume questi parametri degli SSD locali esistenti e i relativi sostituti consigliati:
| Parametri degli SSD locali esistenti | Comando gcloud CLI | Profilo SSD locale | Versione GA consigliata dei parametri degli SSD locali |
|---|---|---|---|
| Parametro Numero di SSD locali | gcloud container clusters create |
Tecnologia di archiviazione: SCSI Condivisione dei dati tra i pod: sì, tramite VP locali Ciclo di vita dei dati: nodo Dimensioni e necessità di configurazione RAID: 375 GiB. Per dimensioni maggiori, devi configurare manualmente il RAID. Formato: File system (ext-4) Integrazione con lo scheduler di Kubernetes: no per impostazione predefinita. Devi garantire la capacità sui nodi e gestire i vicini rumorosi. Se attivi l'opzione per il fotovoltaico locale, la programmazione è integrata. |
gcloud container clusters create |
| Parametro Archiviazione temporanea (beta) | gcloud beta container clusters create |
Tecnologia di archiviazione: NVMe Condivisione dei dati tra i pod: no Ciclo di vita dei dati: pod Dimensioni e necessità di configurazione RAID: fino a 9 TiB. GKE configura automaticamente il RAID in background. Formato: File System (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler di Kubernetes aiuta a garantire che lo spazio sui nodi sia disponibile prima del posizionamento e scala i nodi se necessario. |
gcloud container clusters create |
| Parametro dei volumi SSD locali (alpha) | gcloud alpha container clusters create |
Tecnologia di archiviazione: NVMe o SCSI Condivisione dei dati tra i pod: no Ciclo di vita dei dati: nodo Dimensioni e necessità di configurazione RAID: 375 GiB. Per dimensioni maggiori, devi configurare manualmente il RAID. Formato: file system (ext-4) o blocco non elaborato Integrazione dello scheduler di Kubernetes: no per impostazione predefinita. Devi garantire la capacità sui nodi e gestire i vicini rumorosi. |
gcloud container clusters create |
Accesso agli SSD locali
Puoi accedere ai volumi SSD locali con uno dei seguenti metodi.
Volume emptyDir
In GKE v1.25.3-gke.1800 e versioni successive, puoi utilizzare l'archiviazione temporanea come volume emptyDir supportato da SSD locale tramite l'opzione --ephemeral-storage-local-ssd. Consigliamo questo approccio per la maggior parte dei casi, incluse le applicazioni che richiedono spazio temporaneo ad alte prestazioni.
GKE ti consente di configurare un node pool per montare l'archiviazione temporanea dei nodi su un'unità SSD locale con un'interfaccia NVMe.
Per saperne di più, vedi questo esempio.
Volume permanente locale
Un volume permanente locale rappresenta un disco locale collegato a un singolo nodo. I volumi permanenti locali ti consentono di condividere le risorse degli SSD locali tra i pod. Poiché il disco locale è un disco SSD locale, i dati sono comunque temporanei.
Ti consigliamo questo approccio se sul tuo cluster viene eseguito uno dei seguenti elementi:
- Workload che utilizzano StatefulSets e volumeClaimTemplates.
- Workload che condividono i node pool. Ogni volume SSD locale può essere prenotato tramite un PersistentVolumeClaim e gli HostPath specifici non vengono codificati direttamente nella specifica del pod.
- Pod che richiedono la gravità dei dati sullo stesso SSD locale. Un pod viene sempre pianificato sullo stesso nodo del relativo PersistentVolume locale.
Per saperne di più, consulta questo esempio e la documentazione di Kubernetes open source sui volumi.
Gestione della manutenzione dell'host
Alcuni nodi GKE che utilizzano SSD locali, come i tipi di macchine Z3 con più di 18 TiB di Titanium SSD collegati, non supportano la migrazione live durante la manutenzione dell'host. La VM viene invece arrestata e riavviata in loco. Per un elenco delle famiglie di macchine che hanno comportamenti specifici durante gli eventi di manutenzione, consulta Informazioni sugli eventi dell'host nella documentazione di Compute Engine.
A causa del potenziale tempo di inattività prolungato dei nodi sui tipi di macchina che si riavviano, devi progettare le tue applicazioni in modo che siano resilienti e prevedere che i pod vengano terminati e ripianificati su altri nodi.
Analogamente ai nodi con GPU e TPU collegate, puoi configurare il cluster in modo che gestisca questi eventi di manutenzione in modo controllato. Il componente gestore della manutenzione di GKE rileva automaticamente la manutenzione imminente sui nodi con SSD locali. Prima dell'inizio della manutenzione, il gestore applica un taint al nodo per impedire la pianificazione di nuovi pod e poi espelle in sicurezza i pod esistenti. In questo modo, i pod possono essere ripianificati su altri nodi disponibili nel cluster e vengono rispettati i PodDisruptionBudget configurati.
Per istruzioni dettagliate sulla configurazione dei workload per la gestione di questi eventi, consulta Gestisci le interruzioni dei nodi GKE che non eseguono la migrazione live.
Limitazioni
L'applicazione deve gestire correttamente la perdita di accesso ai dati sui volumi SSD locali. I dati scritti su un disco SSD locale non vengono conservati quando il pod o il nodo viene eliminato, riparato, sottoposto ad upgrade o presenta un errore irreversibile.
Il parametro SSD locale per l'archiviazione temporanea configura i volumi SSD locali in modo che abbiano un ciclo di vita dei dati basato su pod, mentre il parametro del blocco SSD locale NVMe configura i volumi SSD locali in modo che abbiano un ciclo di vita dei dati basato su nodi.
Se hai bisogno di uno spazio di archiviazione permanente, ti consigliamo di utilizzare un'opzione di archiviazione durevole (come Persistent Disk, Filestore o Cloud Storage). Puoi anche utilizzare le repliche regionali per ridurre al minimo il rischio di perdita di dati durante le operazioni del ciclo di vita del cluster o dell'applicazione.
Le impostazioni di configurazione dell'SSD locale non possono essere modificate dopo la creazione del pool di nodi. Non puoi attivare, disattivare o aggiornare la configurazione degli SSD locali per un pool di nodi esistente. Per apportare modifiche, devi eliminare il pool di nodi e crearne uno nuovo.
I pod che utilizzano emptyDir utilizzano in modo trasparente l'SSD locale; tuttavia, questo vale per tutti i pod su tutti i nodi in quel pool di nodi. GKE non supporta la presenza, nello stesso pool di nodi, di alcuni pod che utilizzano volumi emptyDir di SSD locali supportati da SSD locali e altri pod che utilizzano volumi emptyDir supportati da un disco di avvio del nodo. Se hai workload che utilizzano volumi emptyDir supportati da un disco di avvio del nodo, pianifica i workload su un pool di nodi diverso.
I cluster Autopilot e il provisioning automatico dei nodi supportano le unità SSD locali solo tramite classi di computing personalizzate
Utilizza l'SSD locale come archiviazione temporanea per i workload in esecuzione su VM Z3, VM Z4D o VM Z4M ottimizzate per l'archiviazione. La migrazione live è supportata per queste macchine alle seguenti condizioni:
VM Z3 con un massimo di 18 TiB di Titanium SSD collegata, ma le VM Z3 con più di 18 TiB di Titanium SSD vengono terminate durante gli eventi di manutenzione. Per saperne di più, consulta Esperienza di manutenzione per le istanze Z3. Poiché le VM Z3 con più di 18 TiB di Titanium SSD vengono terminate, i dati nell'SSD locale per i nodi potrebbero non essere disponibili durante gli eventi di manutenzione e il recupero dei dati non è garantito dopo la manutenzione. Per saperne di più, consulta Persistenza dei dischi dopo la terminazione dell'istanza.
VM Z4D con un massimo di 42 TiB di Titanium SSD collegata, ma le VM Z4D con più di 42 TiB di Titanium SSD collegata vengono terminate durante gli eventi di manutenzione.
Le VM Z4M con un massimo di 48 TiB di Titanium SSD collegata supportano la migrazione live se non utilizzano Cloud RDMA. Le VM Z4M con più di 48 TiB di Titanium SSD collegata, nonché qualsiasi VM Z4M configurata per utilizzare Cloud RDMA, vengono terminate durante gli eventi di manutenzione.
Passaggi successivi
- Scopri come eseguire il provisioning e utilizzare l'archiviazione temporanea supportata da SSD locali.
- Scopri come eseguire il provisioning e utilizzare l'archiviazione a blocchi non elaborati supportata da SSD locali.
- Scopri come utilizzare i Persistent Disk dedicati come volumi temporanei.
- Scopri come creare volumi.
- Scopri come utilizzare il driver CSI per il disco permanente di Compute Engine.