Le unità a stato solido (SSD) locali sono unità SSD di dimensioni fisse che possono essere montate su una singola VM 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. Gli SSD locali offrono anche velocità effettiva superiore e latenza inferiore rispetto ai dischi standard.
Nella versione 1.25.3-gke.1800 e successive, puoi configurare un pool di nodi GKE per utilizzare 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 pool di nodi. In questo modo, le prestazioni dello spazio di archiviazione temporaneo migliorano per i carichi di lavoro che utilizzano volumi emptyDir o volumi permanenti locali. Puoi creare pool di nodi con SSD locale entro i limiti del tipo di macchina del cluster e le quote del progetto.
Un disco SSD locale è collegato a un solo nodo e i nodi stessi sono temporanei. Un carico di lavoro può essere pianificato su un nodo diverso in qualsiasi momento.
Quando configuri gli 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. Ciò garantisce
un accesso più rapido a dati kubelet critici, log dei pod e file di runtime del container.
Per ulteriori informazioni sui vantaggi e sui limiti dell'SSD locale, ad esempio le prestazioni e il numero consentito di dischi SSD per tipo di macchina, consulta SSD locali nella documentazione di Compute Engine.
Perché scegliere l'SSD locale 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, 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 accedere ai blocchi non elaborati sull'archiviazione temporanea 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 ottenere prestazioni migliori per le 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 lo spazio di archiviazione effimero dei nodi (questa è l'opzione predefinita se utilizzi una serie di macchine di terza generazione).
Questo approccio inserisce i volumi emptyDir, i livelli scrivibili dei container e le immagini che insieme costituiscono lo spazio di archiviazione temporaneo del nodo sull'SSD locale. I vantaggi
includono una larghezza di banda I/O migliore rispetto al Persistent Disk predefinito e tempi di avvio dei pod più rapidi.
L'utilizzo dell'SSD locale per lo spazio di archiviazione temporanea del nodo significa che i volumi SSD locali del disco di avvio non sono disponibili per altri utilizzi. Non modificare i dispositivi SSD locali, ad esempio /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
a blocchi non elaborati.
Archiviazione di dispositivi a blocchi
L'archiviazione dei dispositivi a blocchi consente l'accesso casuale ai dati in blocchi di dimensioni fisse. Alcune applicazioni specializzate richiedono l'accesso diretto all'archiviazione dei dispositivo a blocchi perché, ad esempio, il livello del file system introduce un overhead non necessario.
Gli scenari comuni per l'utilizzo dell'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 versione v1.25.3-gke.1800 e successive, puoi creare
cluster e node pool con SSD NVMe locali a blocchi non elaborati collegati utilizzando l'opzione
--local-nvme-ssd-block. Puoi quindi personalizzare l'archiviazione a blocchi
formattando un file system a tua scelta (ad esempio ZFS o HDFS) e configurando RAID. Questa opzione è adatta se hai bisogno di un controllo aggiuntivo per eseguire
carichi di lavoro che richiedono specificamente l'accesso allo spazio di archiviazione a blocchi supportato da SSD locale.
Puoi anche utilizzare l'approccio di blocco dell'accesso con l'SSD locale se vuoi una cache di dati unificata per condividere i dati tra i pod e i dati sono legati a un ciclo di vita del nodo. Per farlo, installa un DaemonSet con una configurazione RAID, formatta un filesystem e utilizza un PersistentVolume locale per condividere i dati tra i pod.
Requisiti della macchina
Il modo in cui esegui il provisioning dell'SSD locale per i cluster e i node pool GKE
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 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, consulta 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 l'SSD locale, il cluster o ilpool di nodil deve eseguire GKE versione 1.25.3-gke.1800 o successive.
Per eseguire il provisioning di SSD locale 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, consulta Scegliere 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 opool di nodil deve eseguire una delle seguenti versioni di GKE o versioni successive:
- 1.25.13-gke.200 a 1.26
- 1.26.8-gke.200 a 1.27
- 1.27.5-gke.200 a 1.28
- 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 versioni 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 una quantità fissa di volumi SSD locali. Non specifichi il numero di volumi SSD locali da includere. Al contrario, la capacità SSD locale disponibile per i tuoi cluster è definita implicitamente come parte della forma della VM.
Per un elenco delle serie di macchine e del numero consentito corrispondente di SSD locali, consulta Scegliere 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 cluster, segui questi passaggi generali:
- Provisiona un pool di nodi con SSD locale collegato: per creare un pool di nodi GKE con SSD locali collegati, trasmetti il parametro di archiviazione temporanea o di archiviazione a blocchi non elaborati quando chiami il comando
create cluster. L'impostazione dei parametri dell'SSD locale crea un pool di nodi GKE con l'SSD locale collegato e configurato come spazio di archiviazione temporaneo locale o spazio di archiviazione a blocchi non elaborati a seconda dei parametri scelti. Per saperne di più sulle opzioni per il provisioning dell'SSD locale, consulta Parametri SSD locale. - Accedere ai dati dai volumi SSD locali: per utilizzare i dati dai volumi SSD locali, puoi utilizzare un costrutto Kubernetes come emptyDir o un volume permanente locale. Per scoprire di più su queste opzioni, consulta Accesso SSD locale.
Parametri SSD locale su GKE
La seguente tabella 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à di configurazione RAID:fino a 9 TiB. GKE configura automaticamente RAID in background. Formato: File System (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler Kubernetes garantirà lo spazio sul nodo prima del posizionamento e scalerà i nodi, se necessario. Per scoprire come utilizzare questo parametro API, consulta Provisioning e utilizzo dello spazio di archiviazione temporaneo basato su 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 PV locali. Ciclo di vita dei dati: nodo Dimensioni e necessità di configurazione RAID:fino a 9 TiB. Devi configurare manualmente 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 la PV locale, la pianificazione è integrata. Per scoprire come utilizzare questo parametro API, consulta Provisioning e utilizzo dello spazio di archiviazione a blocchi non elaborati supportato da SSD locali. |
Supporto dei parametri SSD locali esistenti
La tabella seguente riepiloga questi parametri SSD locali esistenti e i relativi sostituti consigliati:
| Parametri SSD locale esistenti | Comando gcloud CLI | Profilo SSD locale | Versione GA consigliata dei parametri SSD locale |
|---|---|---|---|
| Parametro Local SSD Count | gcloud container clusters create |
Tecnologia di archiviazione: SCSI Dati condivisi tra i pod: sì, tramite i PV locali Ciclo di vita dei dati: nodo Dimensioni e necessità di configurazione RAID: 375 GiB. Devi configurare manualmente il RAID per le dimensioni più grandi. Formato: file system (ext-4) Integrazione dello scheduler Kubernetes: no per impostazione predefinita. Devi assicurarti la capacità sui nodi e gestire i vicini rumorosi. Se attivi la PV locale, la pianificazione è integrata. |
gcloud container clusters create |
| Parametro Spazio di archiviazione temporanea (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à di configurazione RAID: fino a 9 TiB. GKE configura automaticamente RAID in background. Formato: File System (Kubernetes emptyDir) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler Kubernetes garantirà lo spazio sui nodi prima del posizionamento e scalerà i nodi, se necessario. |
gcloud container clusters create |
| Parametro Volumi 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à di 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 assicurarti 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
In GKE versione v1.25.3-gke.1800 e successive, puoi utilizzare l'archiviazione temporanea come
un 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 uno spazio di scratch effimero ad alte prestazioni.
GKE ti consente di configurare un node pool 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 ti consentono di condividere le risorse SSD locali tra i pod. Poiché il disco locale è un disco SSD locale, i dati sono ancora temporanei.
Ti consigliamo questo approccio se sul tuo cluster è in esecuzione uno dei seguenti elementi:
- Carichi di lavoro che utilizzano StatefulSets e volumeClaimTemplates.
- Workload che condividono i pool di nodi. Ogni volume SSD locale può essere riservato tramite un PersistentVolumeClaim e i percorsi host specifici non sono codificati direttamente nelle specifiche del pod.
- Pod che richiedono la gravità dei dati sulla stessa unità SSD locale. Un pod viene sempre pianificato sullo stesso nodo del relativo PersistentVolume locale.
Per saperne di più, consulta questo esempio e la documentazione sui volumi di Kubernetes open source.
Limitazioni
La tua 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 a upgrade o si verifica un errore non recuperabile.
Il parametro SSD locale di archiviazione temporanea configura i volumi SSD locali in modo che abbiano un ciclo di vita dei dati basato sui 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 sui nodi.
Se hai bisogno di 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 il ciclo di vita del cluster o le operazioni del ciclo di vita dell'applicazione.
Le impostazioni di configurazione dell'SSD locale non possono essere modificate dopo la creazione del pool di nodi. Non puoi abilitare, disabilitare o aggiornare la configurazione dell'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 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 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 non sono supportati per le unità SSD locali.
Ti consigliamo di utilizzare l'SSD locale come spazio di archiviazione temporaneo per i carichi di lavoro in esecuzione su VM ottimizzate per l'archiviazione (Z3). La migrazione live è supportata per le VM Z3 con meno di 88 vCPU, ma le VM Z3 con 88 o più vCPU vengono terminate durante gli eventi di manutenzione. Per maggiori informazioni, consulta Esperienza di manutenzione per le istanze Z3. Poiché le VM Z3 con 88 o più vCPU 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 la sezione Persistenza dei dischi dopo la terminazione dell'istanza.
Passaggi successivi
- Esegui il provisioning e utilizza l'archiviazione temporanea supportata da SSD locali.
- Esegui il provisioning e utilizza l'archiviazione a blocchi non elaborati supportata da SSD locali.