Configurazione dell'archiviazione

Articolo
10/16/2024

Concetti relativi all'archiviazione di Kubernetes

Kubernetes fornisce un livello di astrazione dell'infrastruttura sullo stack tecnologico di virtualizzazione sottostante (facoltativo) e sull'hardware. Kubernetes astrae l'archiviazione tramite le Classi di 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, quindi viene creato un volume persistente in tale risorsa di archiviazione di cui è stato effettuato il provisioning e il pod viene montato nel volume persistente da un'attestazione di volume persistente.

Kubernetes consente ai provider di infrastruttura di archiviazione di collegare i driver (detti anche "Componenti aggiuntivi") che estendono Kubernetes. I componenti aggiuntivi di archiviazione devono essere conformi allo standard di Container Storage Interface. Ci sono decine di componenti aggiuntivi che possono essere trovati in questo elenco di driver CSI non definitivo. Il driver CSI specifico da usare 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 del 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 dei volumi persistenti eseguendo i comandi seguenti:

kubectl get persistentvolumes -n <namespace>

kubectl get persistentvolumeclaims -n <namespace>

Esempio di visualizzazione di volumi persistenti:


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 dei volumi persistenti:


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ò esporre i dati al rischio di perdita totale di dati in caso di errore hardware o potrebbe comportare prestazioni non 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 in genere offre automaticamente la ridondanza dei dati, ma non è veloce quanto l'archiviazione locale.

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 è così o meno.

La proprietà supplementalGroups 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 titolare del trattamento dei dati

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

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

Al momento del provisioning del controller trattamento dei dati, la classe di archiviazione da usare per ognuno di questi volumi permanenti viene specificata passando il parametro --storage-class | -sc per il comando az arcdata dc create o impostando le classi di archiviazione nel file del modello di distribuzione control.json usato. Se si usa il portale di Azure per creare controller dei 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 come predefiniti 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 parametro --storage-class 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 di 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 varia 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 persistenti 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`	Classe di archiviazione per tutti i file di dati (.mdf, ndf). Se non viene specificata un'opzione, per impostazione predefinita viene applicata la classe di archiviazione per il controller dei dati.
`--storage-class-logs`, `-g`	Classe di archiviazione per tutti i file di log. Se non viene specificata un'opzione, per impostazione predefinita viene applicata la classe di archiviazione per il controller dei dati.
`--storage-class-data-logs`	Classe di archiviazione per i file di log delle transazioni del database. Se non viene specificata un'opzione, per impostazione predefinita viene applicata la classe di archiviazione per il controller dei dati.
`--storage-class-backups`	Classe di archiviazione per tutti i file di backup. Se non viene specificata un'opzione, per impostazione predefinita viene applicata 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 di Istanza gestita di SQL di Azure con mapping al volume persistente per i dati e i log:

Nome parametro, nome breve	Percorso all'interno del contenitore `mssql-miaa`	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 con 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 persistente 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 persistenti e volumi persistenti.

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

Istanza	Attestazioni dei volumi permanenti
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 modello a pod singolo 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, in modo che, se un pod o un nodo muore, quando viene eseguito il backup il pod può connettersi di nuovo al volume persistente. Al contrario, un'istanza gestita di Azure SQL a disponibilità elevata usa 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 dei volumi permanenti 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. Inoltre, usare 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 persistente per i dati, e un altro volume persistente per i log. La tabella seguente elenca il numero di volumi persistenti necessari per un singolo controller di dati, un'istanza gestita di SQL di Azure, un'istanza di Database di Azure per PostgreSQL e un'istanza di Azure PostgreSQL HyperScale:

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
Azure PostgreSQL	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
Azure PostgreSQL	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 persistenti. Analogamente, quando si effettua il provisioning di un cluster del servizio Azure Kubernetes con cinque (5) nodi, selezionare una dimensione di macchina virtuale appropriata per il pool di nodi in modo che sia possibile collegare 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 di Kubernetes usata, l'hardware usato, il componente aggiuntivo CSI usato e le classi di archiviazione usate. Questo consente ai clienti di scegliere la classe di archiviazione, il sistema operativo, la distribuzione di Kubernetes e l'hardware migliori 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 gestiti basati sul cloud pubblico, si consiglia di seguire le raccomandazioni seguenti:

Servizio cloud pubblico	Elemento consigliato
Servizio Azure Kubernetes (AKS)	Il servizio Azure Kubernetes include due tipi di archiviazione: File di Azure e Azure Managed Disks. 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` (livello Standard di File di Azure), `azurefile-premium` (livello Premium di File di Azure), `default` (livello Standard di Dischi di Azure) e `managed-premium` (livello Premium di Dischi di Azure). La classe di archiviazione predefinita è `default` (livello Standard Dischi di Azure). Ci sono differenze di prezzo 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 è importante tenere in considerazione il costo, `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 sull'archiviazione del servizio Azure Kubernetes.
AWS Elastic Kubernetes Service (EKS)	Elastic Kubernetes Service di Amazon ha una classe di archiviazione primaria, basata sul driver di archiviazione CSI di EBS. È l'opzione consigliata per i carichi di lavoro di produzione. È disponibile un nuovo driver di archiviazione, il driver di archiviazione CSI di 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 sull'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'unica, è 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.

Condividi tramite