Panoramica dello spazio di archiviazione per i cluster GKE

Questo documento illustra le opzioni di archiviazione supportate da GKE e alcune considerazioni chiave per selezionare l'opzione migliore per le esigenze della tua attività. Per determinare la famiglia di macchine appropriata per la tua selezione, consulta Confronto delle serie di macchine.

GKE supporta i seguenti tipi di archiviazione e integrazioni:

Archiviazione a blocchi (Persistent Disk)

I volumi Persistent Disk sono dispositivi di archiviazione di rete durevoli gestiti da Compute Engine a cui i cluster GKE possono accedere come se si trattasse di dischi fisici su un computer desktop o un server. Quando i cluster richiedono spazio di archiviazione aggiuntivo, puoi collegare più volumi di Persistent Disk ai nodi o ridimensionare i volumi di Persistent Disk esistenti. Puoi consentire a GKE di eseguire il provisioning dinamico di PersistentVolume supportati da Persistent Disk oppure puoi eseguire il provisioning manuale dei dischi.

Questa opzione di archiviazione è supportata sui cluster GKE Autopilot e Standard.

Per impostazione predefinita, i volumi Persistent Disk sono risorse zonali (mantenute in una singola zona all'interno di una regione). Puoi creare volumi di Persistent Disk regionali (mantenuti in due zone nella stessa regione). Puoi anche collegare un volume di Persistent Disk in modalità di sola lettura a più nodi contemporaneamente. Questa funzionalità è supportata sia per i volumi Persistent Disk a livello di zona sia di regione.

Lo spazio di archiviazione del Persistent Disk su GKE è permanente, il che significa che i dati memorizzati sui dischi verranno conservati anche se il pod che li utilizza viene terminato.

Perché utilizzare l'archiviazione Persistent Disk

Utilizza l'archiviazione Persistent Disk se i tuoi cluster richiedono l'accesso a un'archiviazione a blocchi durevole, ad alte prestazioni e ad alta disponibilità. Un volume Persistent Disk è in genere collegato a un singolo pod. Questa opzione di archiviazione supporta la modalità di accesso ReadWriteOnce. GKE supporta la configurazione dei volumi Persistent Disk con una serie di opzioni di latenza e prestazioni, tra cui:

  • Disco permanente bilanciato: adatto per applicazioni aziendali standard. Questa opzione offre un equilibrio tra prestazioni e costi. Supportati da unità a stato solido (SSD). Questa è l'opzione predefinita per il provisioning dinamico dei volumi su cluster e nodi che eseguono GKE 1.24 o versioni successive.
  • Disco permanente per le prestazioni: adatto per analisi dello scale out, database e memorizzazione nella cache permanente. Questa opzione è ideale per i carichi di lavoro sensibili alle prestazioni. Supportati da unità a stato solido (SSD).
  • Disco permanente standard: adatto a carichi di lavoro di big data e big compute. Questa opzione è il tipo di disco più conveniente. Supportati da unità disco rigido (HDD) standard.
  • Extreme Persistent Disk: adatto per applicazioni aziendali come SAP HANA e Oracle. Questa opzione offre le massime prestazioni per soddisfare le esigenze dei più grandi database in memoria. Supportati da unità a stato solido (SSD). Per le applicazioni sensibili alle prestazioni, in cui Persistent Disk non offre prestazioni sufficienti, utilizza i dischi Hyperdisk Extreme.

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Archiviazione a blocchi (Google Cloud Hyperdisk)

I volumi Hyperdisk utilizzano l'archiviazione a blocchi di nuova generazione. Google Cloud I volumi Hyperdisk ti consentono di ottimizzare dinamicamente le prestazioni dell'archiviazione a blocchi in base al tuo carico di lavoro. Puoi configurare le operazioni di I/O al secondo (IOPS) e il throughput in modo indipendente per le tue applicazioni e adattarti alle mutevoli esigenze di prestazioni nel tempo.

Questa opzione di archiviazione è supportata sui cluster GKE Autopilot e Standard. I volumi Hyperdisk sono risorse di zona, soggette a disponibilità regionale. Lo spazio di archiviazione Hyperdisk su GKE è persistente, il che significa che i dati archiviati sui dischi verranno conservati anche se il pod che li utilizza viene terminato.

Perché utilizzare l'archiviazione Hyperdisk

Utilizza l'archiviazione Hyperdisk se devi ridimensionare e regolare dinamicamente IOPS o throughput. Un volume Hyperdisk viene in genere collegato a un singolo pod. Questa opzione di archiviazione supporta la modalità di accesso ReadWriteOnce. Puoi scegliere tra le seguenti opzioni di archiviazione Hyperdisk per GKE in base alle tue esigenze di rapporto prezzo/prestazioni:

  • Hyperdisk bilanciato: la soluzione ideale per la maggior parte dei carichi di lavoro. Questa è una buona opzione per il deployment della maggior parte delle app aziendali e line-of-business, nonché di database e server web.
  • Throughput Hyperdisk: ottimizzato per un throughput elevato a costi contenuti. Questa è una buona opzione se il tuo caso d'uso ha come target l'analisi di scalabilità orizzontale (ad esempio Hadoop o Kafka), il ripristino di dati freddi dai server di backup e carichi di lavoro sensibili ai costi orientati alla velocità effettiva.
  • Hyperdisk Extreme: ottimizzato per le prestazioni IOPS. Questa è una buona opzione se stai eseguendo il deployment di carichi di lavoro ad alte prestazioni, ad esempio sistemi di gestione di database.
  • Hyperdisk ML: ottimizzato per i workload di addestramento e inferenza AI/ML che devono caricare rapidamente i pesi del modello. Utilizza questa opzione per ridurre l'inattività delle risorse GPU/TPU dovuta a colli di bottiglia della latenza.

Le opzioni di archiviazione Hyperdisk sono supportate nei cluster GKE Autopilot e Standard.

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Archiviazione a blocchi (pool di archiviazione Hyperdisk)

Un pool di archiviazione Hyperdisk è un pool di risorse di archiviazione (capacità, throughput e IOPS) di cui è stato eseguito il provisioning e che i dischi nel cluster GKE possono utilizzare. Le risorse di archiviazione sono condivise tra tutti gli Hyperdisk che crei all'interno del pool di archiviazione.

I cluster GKE Standard consentono di includere in un pool di archiviazione sia i dischi di avvio Hyperdisk (per i sistemi operativi) sia gli Hyperdisk collegati (per l'archiviazione dei dati). I cluster GKE Autopilot supportano solo gli Hyperdisk collegati per i pool di archiviazione.

Per iniziare a utilizzare questa opzione di archiviazione, consulta le seguenti risorse:

Archiviazione temporanea e a blocchi non elaborati (SSD locale)

I dischi SSD locali sono unità fisiche collegate direttamente ai nodi. Possono offrire prestazioni migliori, ma sono effimeri. Ogni volume SSD locale è collegato a un nodo specifico. Non puoi spostare il volume in un altro nodo.

Questa opzione di archiviazione è supportata sui cluster GKE Standard. Il supporto di Autopilot per l'SSD locale è disponibile in anteprima sulle macchine A2 Ultra A100, sui cluster e sui pool di nodi che eseguono GKE 1.27 e versioni successive.

L'archiviazione temporanea supportata dall'archiviazione SSD locale su GKE è legata al ciclo di vita di un pod. Quando il pod viene terminato, viene eliminato anche lo spazio di archiviazione temporaneo associato.

Perché utilizzare l'SSD locale

L'utilizzo dell'archiviazione SSD locale nei cluster GKE è adatto se hai bisogno della memorizzazione nella cache a caldo per i database e per l'analisi in tempo reale o di uno spazio di archiviazione temporaneo ottimizzato per Flash che offre le latenze più basse. L'archiviazione SSD locale può essere particolarmente efficace come livello di memorizzazione nella cache davanti a Cloud Storage per i casi d'uso di AI/ML, elaborazione batch, analisi e database in memoria.

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Archiviazione di file

Filestore fornisce un file system condiviso basato su cloud per dati non strutturati, con accesso al Network File System (NFS). Le istanze Filestore fungono da file server su Google Cloud che forniscono spazio di archiviazione durevole con accesso ReadWriteMany per i tuoi cluster GKE. Le istanze Filestore sono disaccoppiate dall'host e richiedono un intervento manuale minimo. I failover dei workload sono fluidi perché non sono necessarie operazioni di infrastruttura per collegare o scollegare i volumi.

Questa opzione di archiviazione è supportata sui cluster GKE Autopilot e Standard. Lo spazio di archiviazione Filestore con il livello di servizio Enterprise ha come impostazione predefinita la disponibilità regionale, mentre gli altri livelli di servizio hanno la disponibilità zonale. Lo spazio di archiviazione Filestore su GKE è permanente, il che significa che i dati archiviati nelle istanze verranno conservati anche se il pod che li utilizza viene terminato.

Perché utilizzare lo spazio di archiviazione Filestore

Utilizza l'archiviazione Filestore se le tue applicazioni richiedono l'accesso al file system di rete (NFS) e più lettori e autori. Questa opzione di archiviazione è adatta se il tuo caso d'uso riguarda sistemi di gestione dei contenuti, migrazione di applicazioni, analisi dei dati, rendering ed elaborazione multimediale.

Per una maggiore efficienza dei costi, Filestore Multishares per GKE ti consente di condividere un'istanza di livello Enterprise Filestore di 10 GiB o più grande con un massimo di 80 PersistentVolume.

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Archiviazione di oggetti (Cloud Storage FUSE)

Cloud Storage è uno spazio di archiviazione di oggetti per dati binari e di oggetti, blob e dati non strutturati. Il driver CSI di Cloud Storage FUSE gestisce l'integrazione di Cloud Storage FUSE con le API Kubernetes per utilizzare i bucket Cloud Storage esistenti come volumi. Puoi utilizzare il driver CSI di Cloud Storage FUSE per montare i bucket come file system sui nodi GKE.

Il driver CSI di Cloud Storage FUSE supporta le modalità di accesso ReadWriteMany, ReadOnlyMany e ReadWriteOnce nei cluster GKE Autopilot e Standard. Gli oggetti Cloud Storage sono disponibili a livello regionale. I dati di Cloud Storage su GKE sono persistenti, il che significa che i dati archiviati nei bucket rimarranno anche se il pod che li utilizza viene terminato.

Perché utilizzare Cloud Storage FUSE

L'opzione FUSE di Cloud Storage è adatta se hai bisogno della semantica dei file davanti a Cloud Storage per la portabilità. Cloud Storage FUSE è anche una scelta comune per gli sviluppatori che vogliono archiviare e accedere ai dati di addestramento e dei modelli di machine learning (ML) come oggetti in Cloud Storage.

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Database gestiti

Un database gestito, come Cloud SQL o Spanner, offre un overhead operativo ridotto ed è ottimizzato per l'infrastruttura Google Cloud. I database gestiti richiedono meno impegno per la manutenzione e il funzionamento rispetto a un database di cui esegui il deployment direttamente in Kubernetes.

Perché utilizzare i database gestiti

L'utilizzo di un database gestito Google Cloud consente ai tuoi carichi di lavoro stateful su GKE di accedere a dati permanenti automatizzando le attività di manutenzione come backup, applicazione di patch e scalabilità. Crea un database, sviluppa la tua app e lascia che Google Cloud la ridimensioni per te. Tuttavia, ciò significa anche che potresti non avere accesso alla versione esatta di un database, di un'estensione o al tipo esatto di database che ti interessa.

GKE fornisce il supporto per la connessione ai servizi di database gestiti, tra cui: Google Cloud

Per iniziare a utilizzare questa opzione di archiviazione, consulta queste risorse:

Artefatti build (Artifact Registry)

Artifact Registry è un gestore di repository per immagini container, pacchetti di sistemi operativi e pacchetti di linguaggio creati e distribuiti da te.

Perché utilizzare Artifact Registry

Artifact Registry è un'opzione adatta per archiviare le tue immagini container private, i grafici Helm e altri artefatti di build.

Per eseguire il pull delle immagini dai repository Docker di Artifact Registry a GKE, consulta Deployment su Google Kubernetes Engine nella documentazione di Artifact Registry.

Passaggi successivi