Configurazione dell'archiviazione

Articolo
10/24/2023

Concetti relativi all'archiviazione kubernetes

Kubernetes fornisce un livello di astrazione dell'infrastruttura sullo stack tecnologico di virtualizzazione sottostante (facoltativo) e sull'hardware. Il modo in cui Kubernetes astrae l'archiviazione è tramite le classi Archiviazione. Quando si effettua il provisioning di un pod, è possibile specificare una classe di archiviazione per ogni volume. Al momento del provisioning del pod, viene chiamato il provisioner della classe di archiviazione per effettuare il provisioning dell'archiviazione e quindi viene creato un volume permanente in tale risorsa di archiviazione di cui è stato effettuato il provisioning e quindi il pod viene montato nel volume permanente da un'attestazione di volume permanente.

Kubernetes consente ai provider di infrastruttura di archiviazione di collegare i driver (detti anche "Addons") che estendono Kubernetes. Archiviazione componenti aggiuntivi devono essere conformi al Standard dell'interfaccia Archiviazione contenitore. Ci sono decine di componenti aggiuntivi che possono essere trovati in questo elenco non definitivo di driver CSI. Il driver CSI specifico usato dipende da fattori quali l'esecuzione in un servizio Kubernetes gestito ospitato nel cloud o il provider OEM usato per l'hardware.

Per visualizzare le classi di archiviazione configurate nel cluster Kubernetes, eseguire questo comando:

kubectl get storageclass

Output di esempio da un cluster servizio Azure Kubernetes (servizio Azure Kubernetes):

NAME                PROVISIONER                AGE
azurefile           kubernetes.io/azure-file   15d
azurefile-premium   kubernetes.io/azure-file   15d
default (default)   kubernetes.io/azure-disk   4d3h
managed-premium     kubernetes.io/azure-disk   4d3h

Per ottenere informazioni dettagliate su una classe di archiviazione, eseguire questo comando:

kubectl describe storageclass/<storage class name>

Esempio:

kubectl describe storageclass/azurefile

Name:            azurefile
IsDefaultClass:  No
Annotations:     kubectl.kubernetes.io/last-applied-configuration={"allowVolumeExpansion":true,"apiVersion":"storage.k8s.io/v1beta1","kind":"StorageClass","metadata":{"annotations":{},"labels":{"kubernetes.io/cluster-service":"true"},"name":"azurefile"},"parameters":{"sku
Name":"Standard_LRS"},"provisioner":"kubernetes.io/azure-file"}

Provisioner:           kubernetes.io/azure-file
Parameters:            skuName=Standard_LRS
AllowVolumeExpansion:  True
MountOptions:          <none>
ReclaimPolicy:         Delete
VolumeBindingMode:     Immediate
Events:                <none>

È possibile visualizzare i volumi persistenti di cui è attualmente stato effettuato il provisioning e le attestazioni di volume persistente eseguendo i comandi seguenti:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Esempio di visualizzazione di volumi permanenti:


kubectl get persistentvolumes -n arc

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                      STORAGECLASS   REASON   AGE
pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            Delete           Bound    arc/sqldemo11-data-claim   default                 7d3h
pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            Delete           Bound    arc/data-metricsdb-0       default                 7d14h
pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            Delete           Bound    arc/sqldemo11-logs-claim   default                 7d3h
pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            Delete           Bound    arc/data-controller        default                 7d14h
pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            Delete           Bound    arc/logs-controller        default                 7d14h
pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            Delete           Bound    arc/logs-metricsdb-0       default                 7d14h
pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            Delete           Bound    arc/sqldemo10-logs-claim   default                 7d14h
pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            Delete           Bound    arc/sqldemo10-data-claim   default                 7d14h
pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            Delete           Bound    arc/data-controldb         default                 7d14h
pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            Delete           Bound    arc/logs-controldb         default                 7d14h
pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            Delete           Bound    arc/logs-logsdb-0          default                 7d14h
pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            Delete           Bound    arc/data-logsdb-0          default                 7d14h

Esempio di visualizzazione delle attestazioni di volume persistente:


kubectl get persistentvolumeclaims -n arc

NAME                   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
data-controldb         Bound    pvc-a39c85d4-5cd9-4249-9915-68a70a9bb5e5   15Gi       RWO            default        7d14h
data-controller        Bound    pvc-4ccda3e4-fee3-4a89-b92d-655c04fa62ad   15Gi       RWO            default        7d14h
data-logsdb-0          Bound    pvc-ecd7d07f-2c2c-421d-98d7-711ec5d4a0cd   15Gi       RWO            default        7d14h
data-metricsdb-0       Bound    pvc-3e772f20-ed89-4642-b34d-8bb11b088afa   15Gi       RWO            default        7d14h
logs-controldb         Bound    pvc-c9cbd74a-76ca-4be5-b598-0c7a45749bfb   10Gi       RWO            default        7d14h
logs-controller        Bound    pvc-63e6bb4c-7240-4de5-877e-7e9ea4e49c91   10Gi       RWO            default        7d14h
logs-logsdb-0          Bound    pvc-d576e9d4-0a09-4dd7-b806-be8ed461f8a4   10Gi       RWO            default        7d14h
logs-metricsdb-0       Bound    pvc-8a1467fe-5eeb-4d73-b99a-f5baf41eb493   10Gi       RWO            default        7d14h
sqldemo10-data-claim   Bound    pvc-9fb79ba3-bd3e-42aa-aa09-3090135d4513   15Gi       RWO            default        7d14h
sqldemo10-logs-claim   Bound    pvc-8e2cacbc-e953-4901-8591-e77df9af309c   10Gi       RWO            default        7d14h
sqldemo11-data-claim   Bound    pvc-07fc7b9f-9a37-4796-9442-4405147120da   15Gi       RWO            default        7d4h
sqldemo11-logs-claim   Bound    pvc-41b33bbd-debb-4153-9a41-02ce2bf9c665   10Gi       RWO            default        7d4h

Fattori da considerare quando si sceglie la configurazione di archiviazione

La selezione della classe di archiviazione corretta è importante per la resilienza e le prestazioni dei dati. La scelta della classe di archiviazione errata può mettere i dati a rischio di perdita totale di dati in caso di errore hardware o potrebbe comportare prestazioni meno ottimali.

Esistono in genere due tipi di archiviazione:

Archiviazione locale: archiviazione di cui è stato effettuato il provisioning nei dischi rigidi locali in un determinato nodo. Questo tipo di archiviazione può essere ideale in termini di prestazioni, ma richiede una progettazione specifica per la ridondanza dei dati replicando i dati in più nodi.
Archiviazione remota, condivisa: archiviazione con provisioning in un dispositivo di archiviazione remoto, ad esempio un servizio di archiviazione SAN, NAS o cloud come EBS o File di Azure. Questo tipo di archiviazione offre in genere automaticamente la ridondanza dei dati, ma non è veloce quanto l'archiviazione locale può essere.

Classi di archiviazione basate su NFS

A seconda della configurazione del server NFS e del provisioner della classe di archiviazione, potrebbe essere necessario impostare supplementalGroups nelle configurazioni dei pod per le istanze del database e potrebbe essere necessario modificare la configurazione del server NFS per usare gli ID gruppo passati dal client (anziché cercare GLI ID gruppo nel server usando l'ID utente passato). Rivolgersi all'amministratore NFS per determinare se si tratta del caso.

La supplementalGroups proprietà accetta una matrice di valori che è possibile impostare durante la distribuzione. Il controller di dati di Azure Arc si applica a tutte le istanze di database create.

Per impostare questa proprietà, eseguire il comando seguente:

az arcdata dc config add --path custom/control.json --json-values 'spec.security.supplementalGroups="1234556"'

Configurazione dell'archiviazione del controller di dati

Alcuni servizi in Azure Arc per i servizi dati dipendono dalla configurazione per l'uso di archiviazione condivisa remota perché i servizi non hanno la possibilità di replicare i dati. Questi servizi sono disponibili nella raccolta di pod del titolare del trattamento dei dati:

Servizio	Attestazioni di volume permanente
OpenSearch	`<namespace>/logs-logsdb-0`, `<namespace>/data-logsdb-0`
InfluxDB	`<namespace>/logs-metricsdb-0`, `<namespace>/data-metricsdb-0`
Istanza SQL del controller	`<namespace>/logs-controldb`, `<namespace>/data-controldb`
Servizio API controller	`<namespace>/data-controller`

Al momento del provisioning del titolare del trattamento dei dati, la classe di archiviazione da usare per ognuno di questi volumi permanenti viene specificata passando la classe --storage-class | -sc parametro al az arcdata dc create comando o impostando le classi di archiviazione nel file del modello di distribuzione control.json usato. Se si usa il portale di Azure per creare il controller dati nella modalità connessa diretta, il modello di distribuzione scelto include la classe di archiviazione predefinita nel modello oppure è possibile selezionare un modello che non dispone di una classe di archiviazione predefinita. Se il modello non definisce una classe di archiviazione, il portale richiede una classe. Se si usa un modello di distribuzione personalizzato, è possibile specificare la classe di archiviazione.

I modelli di distribuzione forniti predefinito hanno una classe di archiviazione predefinita specificata per l'ambiente di destinazione, ma può essere sottoposta a override durante la distribuzione. Vedere la procedura dettagliata per creare modelli di configurazione personalizzati per modificare la configurazione della classe di archiviazione per i pod del controller dati in fase di distribuzione.

Se si imposta la classe di archiviazione usando il --storage-class parametro o -sc, tale classe di archiviazione viene usata sia per le classi di archiviazione di log che per le classi di archiviazione dei dati. Se si impostano le classi di archiviazione nel file modello di distribuzione, è possibile specificare classi di archiviazione diverse per i log e i dati.

Fattori importanti da considerare quando si sceglie una classe di archiviazione per i pod del controller dati:

È necessario usare una classe di archiviazione condivisa remota per garantire la durabilità dei dati e in modo che, se un pod o un nodo muore, quando viene eseguito il backup, il pod può connettersi di nuovo al volume permanente.
I dati scritti nell'istanza SQL del controller, nel database delle metriche e nei log sono in genere piuttosto bassi e non sono sensibili alla latenza, quindi l'archiviazione a prestazioni ultra veloci non è fondamentale. Se si dispone di utenti che usano spesso le interfacce Grafana e Kibana e si dispone di un numero elevato di istanze di database, gli utenti potrebbero trarre vantaggio dall'esecuzione più rapida dell'archiviazione.
La capacità di archiviazione necessaria è variabile con il numero di istanze di database distribuite perché vengono raccolti log e metriche per ogni istanza del database. I dati vengono conservati nei log e nel database delle metriche per due (2) settimane prima che vengano eliminati.
La modifica della classe di archiviazione dopo la distribuzione è difficile, non documentata e non supportata. Assicurarsi di scegliere correttamente la classe di archiviazione in fase di distribuzione.

Nota

Se non viene specificata alcuna classe di archiviazione, viene usata la classe di archiviazione predefinita. Può esistere una sola classe di archiviazione predefinita per ogni cluster Kubernetes. È possibile modificare la classe di archiviazione predefinita.

Configurazione dell'archiviazione dell'istanza del database

Ogni istanza del database dispone di dati, log e volumi persistenti di backup. Le classi di archiviazione per questi volumi permanenti possono essere specificate in fase di distribuzione. Se non viene specificata alcuna classe di archiviazione, viene usata la classe di archiviazione predefinita.

Quando si crea un'istanza usando az sql mi-arc create o az postgres server-arc create, sono disponibili quattro parametri che è possibile usare per impostare le classi di archiviazione:

Nome parametro, nome breve	Utilizzo
`--storage-class-data`, `-d`	Archiviazione classe per tutti i file di dati (con estensione mdf, ndf). Se non specificato, per impostazione predefinita viene predefinito la classe di archiviazione per il controller di dati.
`--storage-class-logs`, `-g`	Archiviazione classe per tutti i file di log. Se non specificato, per impostazione predefinita viene predefinito la classe di archiviazione per il controller di dati.
`--storage-class-data-logs`	Archiviazione classe per i file di log delle transazioni del database. Se non specificato, per impostazione predefinita viene predefinito la classe di archiviazione per il controller di dati.
`--storage-class-backups`	Archiviazione classe per tutti i file di backup. Se non specificato, per impostazione predefinita la classe di archiviazione per i dati (`--storage-class-data`). Usare una classe di archiviazione in grado di supportare ReadWriteMany (RWX) per i backup. Altre informazioni sulle modalità di accesso.

Avviso

Se non si specifica una classe di archiviazione per i backup, la distribuzione usa la classe di archiviazione specificata per i dati. Se questa classe di archiviazione non è in grado di supportare RWX, il ripristino temporizzato potrebbe non funzionare come desiderato.

La tabella seguente elenca i percorsi all'interno del contenitore Istanza gestita di SQL di Azure di cui è stato eseguito il mapping al volume permanente per i dati e i log:

Nome parametro, nome breve	Percorso all'interno del `mssql-miaa` contenitore	Descrizione
`--storage-class-data`, `-d`	/var/opt	Contiene directory per l'installazione di mssql e altri processi di sistema. La directory mssql contiene dati predefiniti (inclusi i log delle transazioni), il log degli errori e le directory di backup
`--storage-class-logs`, `-g`	/var/log	Contiene directory che archiviano l'output della console (stderr, stdout), altre informazioni di registrazione dei processi all'interno del contenitore

La tabella seguente elenca i percorsi all'interno del contenitore di istanze di PostgreSQL di cui è stato eseguito il mapping al volume permanente per i dati e i log:

Nome parametro, nome breve	Percorso all'interno del contenitore postgres	Descrizione
`--storage-class-data`, `-d`	/var/opt/postgresql	Contiene directory di dati e log per l'installazione di postgres
`--storage-class-logs`, `-g`	/var/log	Contiene directory che archiviano l'output della console (stderr, stdout), altre informazioni di registrazione dei processi all'interno del contenitore

Ogni istanza del database ha un volume permanente separato per file di dati, log e backup. Ciò significa che esiste una separazione dell'I/O per ognuno di questi tipi di file in base al modo in cui il provisioner del volume effettua il provisioning dell'archiviazione. Ogni istanza del database ha le proprie attestazioni di volume persistente e volumi persistenti.

Se sono presenti più database in una determinata istanza del database, tutti i database usano la stessa attestazione di volume persistente, volume permanente e classe di archiviazione. Tutti i backup: sia i backup differenziali del log che i backup completi usano la stessa attestazione del volume permanente e il volume permanente. Le attestazioni di volume permanente per i pod dell'istanza del database sono illustrate di seguito:

Istanza	Attestazioni di volume permanente
Istanza gestita di database SQL di Azure	`<namespace>/logs-<instance name>-0`, `<namespace>/data-<instance name>-0`
Istanza di Database di Azure per PostgreSQL	`<namespace>/logs--<instance name>-0`, `<namespace>/data--<instance name>-0`
Azure PostgreSQL	`<namespace>/logs-<instance name>-<ordinal>`, `<namespace>/data-<instance name>-0`

Fattori importanti da considerare quando si sceglie una classe di archiviazione per i pod dell'istanza del database:

A partire dalla versione di febbraio 2022 dei servizi dati di Azure Arc, è necessario specificare una classe di archiviazione in grado di supportare ReadWriteMany (RWX) per i backup. Altre informazioni sulle modalità di accesso. Se non viene specificata alcuna classe di archiviazione per i backup, viene usata la classe di archiviazione predefinita in kubernetes e, se non è in grado di supportare RWX, la distribuzione di un'istanza gestita di SQL di Azure potrebbe non riuscire.
Le istanze di database possono essere distribuite in un singolo modello di pod o in un modello a più pod. Un esempio di modello a pod singolo è un piano tariffario per utilizzo generico di Istanza gestita di SQL di Azure. Un esempio di modello a più pod è un piano tariffario business critical a disponibilità elevata di Istanza gestita di SQL di Azure. Le istanze di database distribuite con il modello a pod singolo devono usare una classe di archiviazione condivisa remota per garantire la durabilità dei dati e in modo che, se un pod o un nodo muore, quando viene eseguito il backup, il pod può connettersi di nuovo al volume permanente. Al contrario, un'istanza gestita di SQL di Azure a disponibilità elevata usa i gruppi di disponibilità AlwaysOn per replicare i dati da un'istanza a un'altra in modo sincrono o asincrono. In particolare nel caso in cui i dati vengano replicati in modo sincrono, sono sempre presenti più copie dei dati, in genere tre copie. Per questo motivo, è possibile usare l'archiviazione locale o le classi di archiviazione condivise remote per i file di dati e di log. Se si usa l'archiviazione locale, i dati vengono comunque mantenuti anche nel caso di un pod, un nodo o un hardware di archiviazione non riuscito perché sono presenti più copie dei dati. Data questa flessibilità, è possibile scegliere di usare l'archiviazione locale per ottenere prestazioni migliori.
Le prestazioni del database sono in gran parte una funzione della velocità effettiva di I/O di un determinato dispositivo di archiviazione. Se il database è pesante nelle letture o nelle operazioni di scrittura, è consigliabile scegliere una classe di archiviazione con hardware progettato per quel tipo di carico di lavoro. Ad esempio, se il database viene usato principalmente per le operazioni di scrittura, è possibile scegliere l'archiviazione locale con RAID 0. Se il database viene usato principalmente per le letture di una piccola quantità di "dati ad accesso frequente", ma esiste un volume di archiviazione complessivo elevato di dati ad accesso sporadico, è possibile scegliere un dispositivo SAN in grado di archiviare a livelli. La scelta della classe di archiviazione corretta non è diversa dalla scelta del tipo di archiviazione da usare per qualsiasi database.
Se si usa un provisioner del volume di archiviazione locale, assicurarsi che i volumi locali di cui è stato effettuato il provisioning per i dati, i log e i backup siano ogni destinazione su dispositivi di archiviazione sottostanti diversi per evitare conflitti nell'I/O su disco. Il sistema operativo deve anche trovarsi in un volume montato in uno o più dischi separati. Questo è essenzialmente lo stesso materiale sussidiario seguito per un'istanza di database su hardware fisico.
Poiché tutti i database in una determinata istanza condividono un'attestazione di volume permanente e un volume permanente, assicurarsi di non inserire nella stessa istanza del database le istanze di database occupate. Se possibile, separare i database occupati nelle proprie istanze di database per evitare conflitti di I/O. Usare inoltre l'etichetta del nodo destinata alle istanze del database in nodi separati in modo da distribuire il traffico di I/O complessivo tra più nodi. Se si usa la virtualizzazione, assicurarsi di distribuire il traffico di I/O non solo a livello di nodo, ma anche l'attività di I/O combinata eseguita da tutte le macchine virtuali del nodo in un determinato host fisico.

Stima dei requisiti di archiviazione

Ogni pod che contiene dati con stato usa almeno due volumi persistenti, un volume permanente per i dati e un altro volume permanente per i log. La tabella seguente elenca il numero di volumi persistenti necessari per un singolo controller di dati, istanza gestita di SQL di Azure, Database di Azure per PostgreSQL istanza e istanza hyperscale di Azure PostgreSQL:

Tipo di risorsa	Numero di pod con stato	Numero obbligatorio di volumi persistenti
Titolare del trattamento dei dati	4 (`control`, `controldb`, `logsdb`, `metricsdb`)	4 * 2 = 8
Istanza gestita di SQL di Azure	1	2
PostgreSQL di Azure	1	2

La tabella seguente mostra il numero totale di volumi persistenti necessari per una distribuzione di esempio:

Tipo di risorsa	Numero di istanze	Numero obbligatorio di volumi persistenti
Titolare del trattamento dei dati	1	4 * 2 = 8
Istanza gestita di SQL di Azure	5	5 * 2 = 10
PostgreSQL di Azure	5	5 * 2 = 10
Numero totale di volumi persistenti		8 + 10 + 10 = 28

Questo calcolo può essere usato per pianificare l'archiviazione per il cluster Kubernetes in base al provisioner o all'ambiente di archiviazione. Ad esempio, se il provisioner di archiviazione locale viene usato per un cluster Kubernetes con cinque (5) nodi, per la distribuzione di esempio sopra ogni nodo è necessaria almeno l'archiviazione per 10 volumi permanenti. Analogamente, quando si esegue il provisioning di un cluster servizio Azure Kubernetes (AKS) con cinque (5) nodi che selezionano una dimensione di macchina virtuale appropriata per il pool di nodi, in modo che possano essere collegati 10 dischi dati è fondamentale. Altre informazioni su come ridimensionare i nodi per le esigenze di archiviazione per i nodi del servizio Azure Kubernetes sono disponibili qui.

Scelta della classe di archiviazione corretta

Siti locali e perimetrali

Microsoft e i partner OEM, OS e Kubernetes hanno un programma di convalida per i servizi dati di Azure Arc. Questo programma fornisce risultati di test confrontabili da un toolkit di test di certificazione. I test valutano la compatibilità delle funzionalità, i risultati dei test di stress e le prestazioni e la scalabilità. I risultati del test indicano il sistema operativo usato, la distribuzione kubernetes usata, HW usato, il componente aggiuntivo CSI usato e le classi di archiviazione usate. Questo consente ai clienti di scegliere la migliore classe di archiviazione, sistema operativo, distribuzione kubernetes e hardware per i propri requisiti. Altre informazioni su questo programma e sui risultati dei test sono disponibili qui.

Cloud pubblico, servizi Kubernetes gestiti

Per i servizi Kubernetes basati sul cloud pubblico, è possibile eseguire le raccomandazioni seguenti:

Servizio cloud pubblico	Elemento consigliato
Servizio Azure Kubernetes (AKS)	servizio Azure Kubernetes (servizio Azure Kubernetes) include due tipi di archiviazione: File di Azure e Managed Disks di Azure. Ogni tipo di archiviazione ha due livelli di prezzo/prestazioni: standard (HDD) e Premium (SSD). Di conseguenza, le quattro classi di archiviazione fornite nel servizio Azure Kubernetes sono `azurefile` (File di Azure livello Standard), (File di Azure livello Premium), `defaultazurefile-premium` (livello Standard dischi di Azure) e `managed-premium` (livello Premium dischi di Azure). La classe di archiviazione predefinita è `default` (livello Standard dischi di Azure). Esistono differenze sostanziali tra i tipi e i livelli da considerare. Per i carichi di lavoro di produzione con requisiti a prestazioni elevate, è consigliabile usare `managed-premium` per tutte le classi di archiviazione. Per i carichi di lavoro di sviluppo/test, i modelli di verifica e così via, dove il costo è una considerazione, è `azurefile` l'opzione meno costosa. Tutte e quattro le opzioni possono essere usate per situazioni che richiedono l'archiviazione condivisa remota, perché sono tutti dispositivi di archiviazione collegati alla rete in Azure. Altre informazioni sui Archiviazione del servizio Azure Kubernetes.
Aws Elastic Kubernetes Service (EKS)	Il servizio Elastic Kubernetes di Amazon ha una classe di archiviazione primaria, basata sul driver di archiviazione CSI di EBS. Questa opzione è consigliata per i carichi di lavoro di produzione. È disponibile un nuovo driver di archiviazione , il driver di archiviazione CSI EFS, che può essere aggiunto a un cluster del servizio Azure Kubernetes, ma è attualmente in una fase beta e soggetto a modifiche. Sebbene AWS indichi che questo driver di archiviazione è supportato per la produzione, non è consigliabile usarlo perché è ancora in versione beta e soggetto a modifiche. La classe di archiviazione EBS è l'impostazione predefinita e viene chiamata `gp2`. Altre informazioni sul Archiviazione EKS.
Google Kubernetes Engine (GKE)	Google Kubernetes Engine (GKE) ha una sola classe di archiviazione denominata `standard`. Questa classe viene usata per i dischi persistenti GCE. Essendo l'unico, è anche l'impostazione predefinita. Anche se esiste un provisioner di volumi statici locale per GKE che è possibile usare con unità SSD collegate direttamente, non è consigliabile usarlo perché non è gestito o supportato da Google. Altre informazioni sull'archiviazione GKE.