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'unità 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 inoltre 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 i volumi SSD locali ai nodi quando crei i pool di nodi. In questo modo, vengono migliorate le prestazioni dello spazio di archiviazione temporaneo per i tuoi carichi di lavoro che utilizzano volumi emptyDir o volumi permanenti locali. Puoi creare pool di nodi con SSD locale nei limiti dei tipi di macchine del tuo cluster e nelle quote del tuo 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 altro nodo in qualsiasi momento.
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. In questo modo, viene garantito un accesso più rapido ai dati critici di kubelet, ai log dei pod e ai file di runtime dei 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 presentano uno dei seguenti requisiti:
- Vuoi eseguire applicazioni che scaricano ed elaborano i 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 accedere ai blocchi non elaborati su uno spazio di archiviazione temporaneo 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.
Spazio di archiviazione temporanea
Ti consigliamo di utilizzare l'opzione --ephemeral-storage-local-ssd per eseguire il provisioning dell'unità SSD locale per lo spazio di archiviazione temporaneo del nodo (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 maggiore larghezza di banda I/O rispetto al disco permanente predefinito e tempi di avvio dei pod migliorati.
L'utilizzo di un'unità SSD locale per lo spazio di archiviazione temporaneo del nodo significa che i volumi dell'unità SSD locale del disco di avvio non sono disponibili per altri utilizzi. Non modificare i dispositivi SSD locali come /dev/nvme*
direttamente utilizzando un Daemonset, HostPath o un altro meccanismo con privilegi; altrimenti,
il nodo potrebbe non riuscire.
Se hai bisogno di un controllo granulare sui volumi SSD locali, utilizza l'approccio con blocchi non elaborati.
Archiviazione del dispositivo di blocco
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 dispositivi a blocchi perché, ad esempio, il livello del file system introduce un overhead non necessario.
Gli scenari comuni per l'utilizzo dell'archiviazione dei dispositivi di blocco includono:
- Database in cui i dati sono organizzati direttamente nello spazio di archiviazione sottostante.
- Software che implementa a sua volta un tipo di servizio di archiviazione (sistemi di archiviazione definiti dal software).
In GKE versione v1.25.3-gke.1800 e successive, puoi creare
cluster e node pool con unità SSD NVMe locali a blocchi non formattati collegate utilizzando
l'opzione --local-nvme-ssd-block. Puoi quindi personalizzare lo spazio di 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 basato su SSD locale.
Puoi anche utilizzare l'approccio di accesso ai blocchi con l'unità 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. A tale scopo, 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 pool di nodi GKE dipende dal tipo di macchina di base. GKE supporta i volumi SSD locali sulle serie di macchine 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 della macchina, 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 di serie e tipi di macchine disponibili, consulta la guida Risorsa e confronto tra famiglie di macchine nella documentazione di Compute Engine.
Requisiti delle 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 il pool di nodi deve eseguire GKE 1.25.3-gke.1800 o versioni successive.
Per eseguire il provisioning dell'SSD locale 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 corrispondente, 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 3ª generazione con SSD locale, il tuo cluster o node pool 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 node pool deve eseguire una delle seguenti versioni 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 una quantità fissa di volumi SSD locali. Non specifichi il numero di volumi SSD locali da includere. La capacità dell'unità SSD locale disponibile per i tuoi cluster è invece definita implicitamente come parte della forma della VM.
Per un elenco delle serie di macchine e del numero consentito di SSD locali corrispondente, consulta Scegliere un numero valido di SSD locali nella documentazione di Compute Engine.
Modello di utilizzo per i volumi SSD locali
Per utilizzare i volumi SSD locali nei cluster, segui questi passaggi generali:
- Esegui la 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 SSD locale crea un pool di nodi GKE con SSD locale collegato e configurato come archiviazione temporanea locale o archiviazione a blocchi non elaborati, a seconda dei parametri scelti. Per scoprire di più sulle opzioni per il provisioning dell'SSD locale, consulta Parametri SSD locale. - 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 locale permanente. Per scoprire di più su queste opzioni, consulta Accesso alle SSD locali.
Parametri dell'unità SSD locale su GKE
La seguente tabella riassume i parametri consigliati forniti da GKE per il provisioning dello spazio di archiviazione SSD locale sui cluster. Puoi utilizzare la CLI gcloud 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 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 sotto il cofano. Formato: file system (emptyDir di Kubernetes) Integrazione dello scheduler Kubernetes: completamente integrata per impostazione predefinita. Lo scheduler di Kubernetes garantirà lo spazio sul nodo prima del posizionamento e ridimensionerà 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 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 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 la visualizzazione di video locali, la pianificazione è integrata. Per scoprire come utilizzare questo parametro API, consulta Provisioning e utilizzo dello spazio di archiviazione a blocchi non elaborati basato su SSD locali. |
Supporto per i parametri SSD locale esistenti
La tabella seguente riassume questi parametri SSD locale esistenti e i relativi sostituti consigliati:
| Parametri SSD locale esistenti | Comando gcloud CLI | Profilo SSD locale | Versione GA consigliata dei parametri SSD locale |
|---|---|---|---|
| Parametro Numero dischi 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à di 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à sui nodi e gestire i vicini rumorosi. Se attivi la visualizzazione di video locali, 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 pod: no Ciclo di vita dei dati: pod Dimensioni e necessità di configurazione RAID: fino a 9 TiB. GKE configura automaticamente RAID sotto il cofano. Formato: file system (emptyDir di Kubernetes) Integrazione dello scheduler Kubernetes: completamente integrata per impostazione predefinita. Lo scheduler di Kubernetes garantirà lo spazio sui nodi prima del posizionamento e ne eseguirà la scalabilità, 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 pod: no Ciclo di vita dei dati: Nodo Dimensioni e necessità di configurazione RAID: 375 GiB. Devi configurare manualmente il RAID per dimensioni maggiori. Formato: file system (ext-4) o blocco non elaborato Integrazione con lo scheduler Kubernetes: no per impostazione predefinita. Devi assicurarti la capacità sui nodi e gestire i vicini rumorosi. |
gcloud container clusters create |
Accesso all'unità 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
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 scratch temporaneo 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 nel tuo cluster viene eseguito uno dei seguenti elementi:
- Carichi di lavoro che utilizzano StatefulSets e volumeClaimTemplates.
- Workload che condividono pool di nodi. Ogni volume SSD locale può essere prenotato tramite un PersistentVolumeClaim e percorsi host specifici non sono codificati direttamente nella specifica del pod.
- Pod che richiedono la gravità dei dati per la stessa unità SSD locale. Un pod viene sempre pianificato sullo stesso nodo del suo PersistentVolume locale.
Per saperne di più, consulta questo esempio e la documentazione di Volumes di Kubernetes open source.
Limitazioni
L'applicazione deve gestire in modo corretto 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, sottoposto ad upgrade o si verifica un errore non recuperabile.
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 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 archiviazione permanente, ti consigliamo di utilizzare un'opzione di archiviazione durevole (ad esempio 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'unità SSD locale non possono essere modificate dopo la creazione del pool di nodi. Non puoi attivare, disattivare o aggiornare la configurazione dell'SSD locale per un node pool esistente. Per apportare modifiche, devi eliminare il node pool 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 del pool di nodi. GKE non supporta la presenza, nello stesso pool di nodi, di alcuni pod che utilizzano volumi emptyDir dell'SSD locale supportati da un'unità SSD locale e di altri pod che utilizzano volumi emptyDir supportati da un disco di avvio del nodo. Se hai carichi di lavoro che utilizzano volumi emptyDir basati su un disco di avvio del nodo, pianifica i carichi di lavoro in 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'unità 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'unità 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 utilizza l'archiviazione temporanea basata su SSD locale.
- Provisioning e utilizzo di archiviazione a blocchi non elaborati basata su SSD locale.