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 gli SSD locali su GKE per ottenere uno spazio di archiviazione ad alte prestazioni non persistente (temporaneo) collegato a ogni nodo del cluster. Gli SSD locali forniscono 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 gli SSD locali 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, le prestazioni dell'archiviazione temporanea per i workload che utilizzano volumi emptyDir o PersistentVolume locali migliorano. Puoi creare pool di nodi 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 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. 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 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
Gli SSD locali sono 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 l'accesso a blocchi non elaborati su uno spazio di 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 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 scrivibili dei container e le immagini che costituiscono l'archiviazione temporanea dei nodi sugli SSD locali. I vantaggi includono una larghezza di banda I/O migliorata rispetto a Persistent Disk predefinito e tempi di avvio dei pod migliorati.
L'utilizzo degli 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 direttamente i dispositivi SSD locali, ad esempio /dev/nvme*, utilizzando un DaemonSet con privilegi, HostPath o un altro meccanismo; in caso contrario, il nodo potrebbe non riuscire.
Se hai bisogno di un controllo granulare sui volumi SSD locali, utilizza invece l'
approccio a blocchi non elaborati.
Archiviazione dello spazio sul dispositivo 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 i seguenti:
- 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 pool di nodi 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 workload che richiedono specificamente l'accesso all'archiviazione a blocchi supportata da SSD locali.
Puoi anche utilizzare l'approccio di accesso a blocchi con gli SSD locali 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 e i pool di nodi GKE dipende dal tipo di macchina sottostante. GKE supporta i volumi SSD locali nelle 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.
GKE non supporta l'utilizzo della serie di macchine C4N con gli 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 gli SSD locali, il cluster o il pool di nodi deve eseguire GKE versione 1.25.3-gke.1800 o successive.
Per eseguire il provisioning degli 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 corrispondente, consulta la sezione consulta la sezione 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 gli SSD locali, il cluster o il 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 gli SSD locali, il cluster o il 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 locali o con una quantità fissa di volumi SSD locali. Non devi specificare il numero di volumi SSD locali da includere. Al contrario, la capacità SSD locale disponibile per i cluster è definita implicitamente come parte della forma della VM.
Per un elenco delle serie di macchine e del numero consentito di SSD locali corrispondente, consulta la sezione 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:
- Esegui il provisioning di un pool di nodi con SSD locali collegati: per creare un pool di nodi GKE
con SSD locali collegati, passa il parametro di archiviazione temporanea o
di archiviazione a blocchi non elaborati quando chiami il comando
create cluster. L'impostazione dei parametri SSD locali crea un pool di nodi GKE con SSD locali collegati e configurati come spazio di archiviazione temporanea locale o spazio di archiviazione a blocchi non elaborati, a seconda dei parametri scelti. Per saperne di più sulle opzioni per il provisioning degli SSD locali, consulta la sezione Parametri degli SSD locali. - Accedi ai dati dai volumi SSD locali: per utilizzare i dati dai volumi SSD locali, puoi utilizzare una struttura Kubernetes come emptyDir o un volume permanente locale. Per saperne di più su queste opzioni, consulta la sezione Accesso agli 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 |
1.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 (emptyDir di Kubernetes) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler Kubernetes aiuta a garantire che lo spazio sul nodo sia disponibile prima del posizionamento e a scalare i nodi, se necessario. Per scoprire come utilizzare questo parametro API, consulta la sezione Eseguire il provisioning e utilizzare lo spazio di archiviazione temporanea supportato da SSD locali. |
| Blocco SSD NVMe locale | gcloud container clusters create |
1.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 assicurarti della capacità sui nodi e gestire i vicini rumorosi. Se attivi i PV locali, la pianificazione è integrata. Per scoprire come utilizzare questo parametro API, consulta la sezione Eseguire il provisioning e utilizzare lo spazio di archiviazione a blocchi non elaborati supportato da SSD locali. |
Supporto per i parametri degli 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 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à di configurazione RAID: 375 GiB. Devi configurare manualmente RAID per dimensioni maggiori. Formato: file system (ext-4) Integrazione dello scheduler Kubernetes: No, per impostazione predefinita. Devi assicurarti della capacità sui nodi e gestire i vicini rumorosi. Se attivi i PV locali, la pianificazione è integrata. |
gcloud container clusters create |
| Parametro 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 (emptyDir di Kubernetes) Integrazione dello scheduler Kubernetes: completamente integrato per impostazione predefinita. Lo scheduler Kubernetes aiuta a garantire che lo spazio sui nodi sia disponibile prima del posizionamento e a scalare i nodi, se necessario. |
gcloud container clusters create |
| Parametro dei volumi SSD locali (alfa) | 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. Devi configurare manualmente RAID per dimensioni maggiori. Formato: file system (ext-4) o blocco non elaborato Integrazione dello scheduler Kubernetes: No, per impostazione predefinita. Devi assicurarti della 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 versione v1.25.3-gke.1800 e successive, puoi utilizzare lo spazio di archiviazione temporanea come
un volume emptyDir
supportato da SSD locali tramite l'opzione --ephemeral-storage-local-ssd. Ti consigliamo questo approccio nella maggior parte dei casi, incluse le applicazioni che richiedono uno spazio temporaneo temporaneo ad alte prestazioni.
GKE ti consente di configurare un pool di nodi in modo che monti lo spazio di archiviazione temporanea dei nodi su SSD locali 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 cluster è in esecuzione una delle seguenti opzioni:
- Workload che utilizzano StatefulSets e volumeClaimTemplates.
- Workload che condividono i pool di nodi. Ogni volume SSD locale può essere riservato tramite un PersistentVolumeClaim e gli 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 relativo PersistentVolume locale.
Per saperne di più, consulta questo esempio e la documentazione open source dei volumi Kubernetes.
Gestione della manutenzione dell'host
Alcuni nodi GKE che utilizzano SSD locali, come i tipi di macchine Z3 con più di 18 TiB di SSD Titanium collegati, non supportano la migrazione live durante la manutenzione dell'host. Al contrario, la VM si arresta e si riavvia in loco. Per un elenco delle famiglie di macchine con comportamenti specifici durante gli eventi di manutenzione, consulta la sezione Informazioni sugli eventi host nella documentazione di Compute Engine.
A causa del potenziale tempo di inattività prolungato dei nodi sui tipi di macchine che si riavviano, devi progettare le applicazioni per la resilienza e prevedere che i pod vengano terminati e riprogrammati su altri nodi.
Analogamente ai nodi con GPU e TPU collegate, puoi configurare il cluster per gestire questi eventi di manutenzione in modo graduale. Il componente maintenance-handler 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 elimina in sicurezza i pod esistenti. In questo modo, i pod possono essere riprogrammati su altri nodi disponibili nel cluster e vengono rispettati tutti i PodDisruptionBudget configurati.
Per istruzioni dettagliate sulla configurazione dei workload per gestire questi eventi, consulta la sezione Gestire le interruzioni dei nodi GKE che non eseguono la migrazione live.
Limitazioni
L'applicazione deve gestire in modo graduale la perdita dell'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 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 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 le operazioni del ciclo di vita del cluster o dell'applicazione.
Le impostazioni di configurazione degli SSD locali non possono essere modificate dopo la creazione del pool di nodi. Non puoi abilitare, disabilitare 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 gli SSD locali; 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 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, pianificali su un pool di nodi diverso.
I cluster Autopilot e il provisioning automatico dei nodi supportano gli SSD locali solo tramite ComputeClass personalizzate
Ti consigliamo di utilizzare gli SSD locali come spazio di archiviazione temporanea per i workload in esecuzione su VM ottimizzate per lo spazio di 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 saperne di più, consulta la sezione Esperienza di manutenzione per le istanze Z3 . Poiché le VM Z3 con 88 o più vCPU vengono terminate, i dati negli SSD locali 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
- Scopri come eseguire il provisioning e utilizzare lo spazio di archiviazione temporanea supportato da SSD locali.
- Scopri come eseguire il provisioning e utilizzare lo spazio di archiviazione a blocchi non elaborati supportato da SSD locali.
- Scopri come utilizzare i dischi permanenti dedicati come volumi temporanei.
- Scopri come creare i volumi.
- Scopri come utilizzare il driver CSI per il disco permanente di Compute Engine.