Le unità a stato solido (SSD) locali sono unità SSD di dimensione fissa, 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 permanente (temporaneo) collegato a ogni nodo nel tuo cluster. Gli SSD locali offrono inoltre velocità effettiva più elevata e 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 un SSD locale con un'interfaccia NVMe per l'archiviazione temporanea locale o l'archiviazione a blocchi non elaborata.
Se utilizzi GKE con cluster Standard, puoi collegare volumi SSD locali ai nodi durante la creazione dei pool di nodi. Ciò migliora le prestazioni dell'archiviazione temporanea per i carichi di lavoro che utilizzano emptyDir Volumes o PersistentVolume locali. Puoi creare pool di nodi con SSD locale entro i limiti del tipo di macchina del cluster e le quotas del progetto.
Un disco SSD locale è collegato a un solo nodo e i nodi stessi sono temporanei. È possibile pianificare un carico di lavoro su un nodo diverso in qualsiasi momento.
Per ulteriori informazioni sui vantaggi e sulle limitazioni degli SSD locali, come le prestazioni e il numero consentito di dischi SSD per tipo di macchina, consulta la sezione SSD locali nella documentazione di Compute Engine.
Perché scegliere gli SSD locali per GKE
L'SSD locale è una buona scelta se i tuoi carichi di lavoro hanno uno dei seguenti requisiti:
- Vuoi eseguire applicazioni che scaricano ed elaborano dati, ad esempio 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 l'accesso non elaborato ai blocchi per l'archiviazione temporanea ad alte prestazioni.
- Vuoi eseguire applicazioni di dati specializzate e vuoi utilizzare volumi SSD locali come una 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 degli SSD locali per l'archiviazione temporanea dei nodi (questa è l'impostazione predefinita se utilizzi una serie di macchine di terza generazione).
Questo approccio inserisce i volumi emptyDir, i livelli dei container scrivibili e le immagini che insieme costituiscono l'archiviazione temporanea dei nodi sull'SSD locale. I vantaggi includono una migliore larghezza di banda di I/O rispetto al Persistent Disk predefinito e tempi di avvio dei pod migliorati.
Se utilizzi un SSD locale per l'archiviazione temporanea dei nodi, i volumi SSD locali del disco di avvio non sono disponibili per altri utilizzi. Non modificare il disco di avvio direttamente utilizzando un Daemonset con privilegi, HostPath o un altro meccanismo, altrimenti il nodo potrebbe restituire un errore. Se hai bisogno di un controllo granulare sui volumi SSD locali, utilizza invece l'approccio raw block.
Archiviazione dispositivo a blocchi
L'archiviazione a blocchi consente l'accesso casuale ai dati in blocchi di dimensioni fisse. Alcune applicazioni specializzate richiedono l'accesso diretto per l'archiviazione a dispositivo a blocchi perché, ad esempio, il livello del file system introduce un overhead non necessario.
Gli scenari comuni per l'utilizzo dell'archiviazione a dispositivo a blocchi includono i seguenti:
- Database in cui i dati sono organizzati direttamente nell'archiviazione sottostante.
- Software che implementa a sua volta un qualche tipo di servizio di archiviazione (sistemi di archiviazione software-defined).
In GKE versione 1.25.3-gke.1800 e successive, puoi creare cluster e pool di nodi con SSD NVMe locali a blocco non elaborati collegati, utilizzando l'opzione --local-nvme-ssd-block. Puoi quindi personalizzare l'archiviazione a blocchi formattando un file system di tua scelta (come ZFS o HDFS) e configurando il RAID. Questa opzione è adatta se hai bisogno di un controllo aggiuntivo per eseguire carichi di lavoro che richiedono in particolare l'accesso all'archiviazione a blocchi supportata da SSD locali.
Puoi anche utilizzare l'approccio al blocco con l'SSD locale se vuoi una cache di dati unificata per condividere dati tra i pod e i dati sono collegati 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 dati tra i pod.
Requisiti delle macchine
Il modo in cui esegui il provisioning degli SSD locali per i cluster GKE e i pool di nodi dipende dal tipo di macchina sottostante. GKE supporta i volumi SSD locali sulle serie di macchine di Compute Engine di prima, seconda e terza generazione. I volumi SSD locali richiedono il 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, vedi la guida alle risorse e al confronto per le famiglie di macchine nella documentazione di Compute Engine.
Requisiti per le 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 degli SSD locali su una serie di macchine di prima o seconda generazione, devi specificare il numero di volumi SSD locali da utilizzare con la VM. Per un elenco delle serie di macchine e del numero consentito corrispondente di SSD locali, vedi Scegliere un numero di SSD locali valido nella documentazione di Compute Engine.
Requisiti per le serie di macchine di terza generazione
Se vuoi utilizzare una serie di macchine di terza generazione con SSD locale, il cluster o il pool di nodi deve eseguire una delle seguenti versioni di GKE o versioni 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
Per le serie di macchine di terza generazione, ogni tipo di macchina è preconfigurato senza SSD locali o con una quantità fissa di volumi SSD locali. Non devi specificare il numero di volumi SSD locali da includere. Invece, la capacità degli SSD locali disponibile per i tuoi cluster è implicitamente definita come parte della forma della VM.
Per un elenco delle serie di macchine e del numero consentito corrispondente di SSD locali, vedi Scegliere un numero di SSD locali valido 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 collegato: per creare un pool di nodi GKE con SSD locali collegati, passa il parametro relativo all'archiviazione temporanea o all'archiviazione a blocchi non elaborato quando chiami il comando
create cluster. L'impostazione dei parametri SSD locale crea un pool di nodi GKE con SSD locale collegato e configurato come archiviazione temporanea locale o archiviazione a blocchi non elaborata in base ai parametri scelti. Per scoprire di più sulle opzioni per il provisioning degli SSD locali, consulta Parametri SSD locali. - Accesso ai dati da volumi SSD locali: per utilizzare i dati dai volumi SSD locali, puoi utilizzare un costrutto Kubernetes come emptyDir o un volume permanente locale. Per saperne di più su queste opzioni, consulta Accesso a SSD locali.
Parametri SSD locali su GKE
La tabella seguente riassume i parametri consigliati forniti da GKE per il provisioning dell'archiviazione SSD locale sui cluster. Puoi utilizzare gcloud CLI per trasmettere 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à della configurazione RAID: fino a 9 TiB. GKE configura automaticamente il RAID in background. Formato: file system (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrata per impostazione predefinita. Lo scheduler Kubernetes assicurerà lo spazio sul nodo prima del posizionamento e, se necessario, scala i nodi. Per scoprire come utilizzare questo parametro API, consulta Eseguire il provisioning e l'utilizzo dell'archiviazione temporanea supportata da SSD locali. |
| 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 PV locali. Ciclo di vita dei dati: nodo Dimensioni e necessità della 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à dei nodi e gestire i vicini rumorosi. Se attivi l'oggetto PV locale, la pianificazione è integrata. Per scoprire come utilizzare questo parametro API, consulta Eseguire il provisioning e l'utilizzo dell'archiviazione a blocchi non elaborata supportata da SSD locali. |
Supporto per i parametri SSD locali esistenti
La seguente tabella riassume questi parametri SSD locali esistenti e i relativi sostituti consigliati:
| Parametri SSD locali esistenti | Comando gcloud CLI | Profilo SSD locale | Versione GA consigliata dei parametri SSD locali |
|---|---|---|---|
| Parametro di conteggio degli SSD locali | gcloud container clusters create |
Tecnologia di archiviazione: SCSI Dati condivisi tra i pod: Sì, tramite PV locali Ciclo di vita dei dati: nodo Dimensioni e necessità della configurazione RAID: 375 GiB. Devi configurare manualmente il RAID per dimensioni maggiori. Formato: file system (ext-4) Integrazione dello scheduler Kubernetes: no per impostazione predefinita. Devi garantire la capacità dei nodi e gestire i vicini rumorosi. Se attivi l'oggetto PV locale, la pianificazione è integrata. |
gcloud container clusters create |
| Parametro dello spazio di archiviazione temporaneo (beta) | gcloud beta container clusters create |
Tecnologia di archiviazione: NVMe Dati condivisi tra i pod: no Ciclo di vita dei dati: pod Dimensioni e necessità della configurazione RAID: fino a 9 TiB. GKE configura automaticamente il RAID in background. Formato: file system (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrata per impostazione predefinita. Lo scheduler Kubernetes assicurerà lo spazio sui nodi prima del posizionamento e, se necessario, scala i nodi. |
gcloud container clusters create |
| Parametro Volume SSD locali (alpha) | gcloud alpha container clusters create |
Tecnologia di archiviazione: NVMe o SCSI Dati condivisi tra i pod: no Ciclo di vita dei dati: nodo Dimensioni e necessità della configurazione RAID: 375 GiB. Per le dimensioni più grandi, devi configurare manualmente il RAID. Formato: file system (ext-4) o blocco non elaborato Integrazione dello scheduler Kubernetes: no per impostazione predefinita, devi garantire la capacità sui nodi e gestire i vicini rumorosi. |
gcloud container clusters create |
Accesso SSD locale
Puoi accedere ai volumi SSD locali con uno dei seguenti metodi.
Volume emptyDir
Nella versione GKE v1.25.3-gke.1800 e 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, comprese le applicazioni che richiedono spazio temporaneo ad alte prestazioni.
GKE consente di configurare un pool di nodi per montare l'archiviazione temporanea dei nodi su SSD locale con un'interfaccia NVMe.
Per saperne di più, consulta questo esempio.
Volume permanente locale
Un volume permanente locale rappresenta un disco locale collegato a un singolo nodo. I volumi permanenti locali consentono di condividere risorse SSD locali tra i pod. Poiché il disco locale è un disco SSD locale, i dati sono ancora temporanei.
Consigliamo questo approccio se sul cluster viene eseguita una delle seguenti azioni:
- Carichi di lavoro che utilizzano StatefulSets e StatefulSets.
- Carichi di lavoro che condividono pool di nodi. Ogni volume SSD locale può essere prenotato tramite un PersistentVolumeClaim e hostPath specifici non sono 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 suo PersistentVolume locale.
Per saperne di più, consulta questo esempio e la documentazione open source di Kubernetes Volumes.
Limitazioni
La tua applicazione deve gestire agevolmente la perdita dell'accesso ai dati sui volumi SSD locali. I dati scritti su un disco SSD locale non vengono mantenuti quando il pod o il nodo viene eliminato, riparato, eseguito l'upgrade o si verifica 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 sui pod, mentre il parametro di blocco degli SSD locali NVMe configura i volumi SSD locali in modo che abbiano un ciclo di vita dei dati basato su nodi.
Se hai bisogno di archiviazione permanente, ti consigliamo di utilizzare un'opzione di archiviazione durevole (come Disco permanente, Filestore o Cloud Storage). Puoi anche utilizzare repliche a livello di regione per ridurre al minimo il rischio di perdita di dati durante il ciclo di vita del cluster o delle operazioni del ciclo di vita delle applicazioni.
Le impostazioni di configurazione degli SSD locali non possono essere modificate dopo aver creato il pool di nodi. Non puoi abilitare, disabilitare o aggiornare la configurazione SSD locale per un pool di nodi esistente. Per apportare modifiche, devi eliminare il pool di nodi e ricrearne uno nuovo.
I pod che utilizzano emptyDir usano in modo trasparente l'SSD locale, ma ciò è vero per tutti i pod su tutti i nodi nel pool di nodi. GKE non supporta a disporre, nello stesso pool di nodi, di alcuni pod che utilizzano volumi emptyDir degli SSD locali supportati da SSD locale e altri pod che usano volumi emptyDir supportati da un disco di avvio nodo. Se hai carichi di lavoro che utilizzano volumi emptyDir supportati da un disco di avvio nodo, pianifica i carichi di lavoro su un pool di nodi diverso.
Il provisioning automatico dei nodi e dei cluster Autopilot non è supportato per le SSD locali.
Ti consigliamo di utilizzare SSD locale come archiviazione temporanea per i carichi di lavoro in esecuzione su VM ottimizzate per l'archiviazione (Z3). I nodi Z3 vengono terminati durante gli eventi di manutenzione. Per questo motivo, i dati nell'SSD locale di questi nodi potrebbero non essere disponibili durante gli eventi di manutenzione e il recupero dei dati non è garantito dopo la manutenzione.
Passaggi successivi
- Esegui il provisioning e l'utilizzo dell'archiviazione temporanea supportata da SSD locali.
- Esegui il provisioning e utilizza l'archiviazione a blocchi non elaborata supportata da SSD locali.