Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes (AKS)

Le applicazioni in esecuzione in Azure Kubernetes Service (AKS) possono avere la necessità di memorizzare e recuperare dati. Anche se alcuni carichi di lavoro dell'applicazione possono usare l'archiviazione locale e veloce in nodi non necessari, altri richiedono spazio di archiviazione permanente in volumi di dati più regolari all'interno della piattaforma Azure.

Potrebbero essere necessari più pod:

• Condividere gli stessi volumi di dati.
• Ricollegare i volumi di dati se il pod viene riprogrammato in un nodo diverso.

Potrebbe anche essere necessario raccogliere e archiviare dati sensibili o informazioni di configurazione dell'applicazione in pod.

Questo articolo introduce i concetti di base per rendere disponibili risorse di archiviazione per le applicazioni nel servizio Azure Kubernetes:

• Volumi
• Volumi permanenti
• Classi di archiviazione
• Attestazioni di volume permanente

Dimensioni predefinite del disco del sistema operativo

Quando si crea un nuovo cluster o si aggiunge un nuovo pool di nodi a un cluster esistente, il numero di vCPU determina per impostazione predefinita le dimensioni del disco del sistema operativo. Il numero di vCPU si basa sullo SKU della macchina virtuale. Nella tabella seguente sono elencate le dimensioni predefinite del disco del sistema operativo per ogni SKU di macchina virtuale:

Macchina virtuale SKU Cores (vCPU)	Livello di default del disco del sistema operativo	Operazioni di I/O al secondo di cui è stato effettuato il provisioning	Velocità effettiva (MB/s) con provisioning
1 - 7	P10/128G	500	100
8 - 15	P15/256G	1100	125
16 - 63	P20/512G	2300	150
64+	P30/1024G	5000	200

Importante

Le dimensioni predefinite del disco del sistema operativo sono usate solo per nuovi cluster o pool di nodi quando i dischi del sistema operativo temporanei non sono supportati e non viene specificata una dimensione predefinita del disco del sistema operativo. Le dimensioni predefinite del disco del sistema operativo potrebbero influire sulle prestazioni o sui costi del cluster. Non è possibile modificare le dimensioni del disco del sistema operativo dopo la creazione del cluster o del pool di nodi. Le dimensioni predefinite del disco influiscono sui cluster o sui pool di nodi creati a partire da luglio 2022.

Disco del sistema operativo temporaneo

Per impostazione predefinita, Azure replica automaticamente il disco del sistema operativo per una macchina virtuale in Archiviazione di Azure per evitare la perdita di dati quando la macchina virtuale viene spostata in un altro host. Tuttavia, poiché i contenitori non sono progettati per rendere persistente lo stato locale, questo comportamento offre un valore limitato, fornendo alcuni svantaggi. Questi svantaggi includono, ad esempio, il provisioning dei nodi più lento e una latenza di lettura/scrittura superiore.

Al contrario, i dischi temporanei del sistema operativo vengono archiviati solo nel computer host, proprio come un disco temporaneo. Con questa configurazione si ottiene una latenza di lettura/scrittura inferiore, insieme a un ridimensionamento più rapido dei nodi e agli aggiornamenti del cluster.

Nota

Quando non si richiedono in modo esplicito dischi gestiti di Azure per il sistema operativo, il servizio Azure Kubernetes usa il sistema operativo temporaneo, se possibile per una configurazione specifica del pool di nodi.

I requisiti di dimensione e le raccomandazioni per i dischi temporanei del sistema operativo sono disponibili nella documentazione delle macchine virtuali di Azure. Di seguito sono riportate alcune considerazioni generali sul ridimensionamento:

• Se si sceglie di usare le dimensioni predefinite della macchina virtuale del servizio Azure Kubernetes Standard_DS2_v2 SKU con le dimensioni predefinite del disco del sistema operativo pari a 100 GiB, la dimensione predefinita della macchina virtuale supporta il sistema operativo temporaneo, ma ha solo 86 GiB di dimensioni della cache. Questa configurazione verrà impostata per impostazione predefinita su dischi gestiti se non viene specificata in modo esplicito. Se si richiede un sistema operativo temporaneo, viene visualizzato un errore di convalida.

• Se si richiede lo stesso SKU di Standard_DS2_v2 con un disco del sistema operativo da 60 GiB, per impostazione predefinita questa configurazione è temporanea. La dimensione richiesta di 60 GiB è inferiore alla dimensione massima della cache di 86 GiB.

• Se si seleziona lo SKU di Standard_D8s_v3con disco del sistema operativo da 100 GB, questa dimensione di macchina virtuale supporta il sistema operativo temporaneo e ha 200 GiB di spazio nella cache. Se non si specifica il tipo di disco del sistema operativo, il pool di nodi riceverà il sistema operativo temporaneo per impostazione predefinita.

La generazione più recente della serie di macchine virtuali non ha una cache dedicata, ma solo una risorsa di archiviazione temporanea. Ad esempio, se è stata selezionata la dimensione della macchina virtuale Standard_E2bds_v5 con le dimensioni predefinite del disco del sistema operativo pari a 100 GiB, supporta dischi temporanei del sistema operativo, ma ha solo 75 GB di spazio di archiviazione temporanea. Questa configurazione viene impostata per impostazione predefinita su dischi del sistema operativo gestiti se non viene specificata in modo esplicito. Se si richiede un disco del sistema operativo temporaneo, viene visualizzato un errore di convalida.

• Se si richiede la stessa dimensione della macchina virtuale Standard_E2bds_v5 con un disco del sistema operativo da 60 GiB, per impostazione predefinita questa configurazione viene predefinito per i dischi temporanei del sistema operativo. La dimensione richiesta di 60 GiB è inferiore alla memoria temporanea massima di 75 GiB.

• Se si seleziona Standard_E4bds_v5 SKU con un disco del sistema operativo GiB da 100 GiB, questa dimensione di macchina virtuale supporta il sistema operativo temporaneo e ha 150 GiB di archiviazione temporanea. Se non si specifica il tipo di disco del sistema operativo, per impostazione predefinita Azure effettua il provisioning di un disco temporaneo del sistema operativo nel pool di nodi.

Chiavi gestite dal cliente

È possibile gestire la crittografia per il disco temporaneo del sistema operativo con le proprie chiavi in un cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Usare la chiave gestita dal cliente con il disco di Azure nel servizio Azure Kubernetes.

Volumi

Kubernetes considera in genere singoli pod come risorse temporanee e eliminabili. Le applicazioni hanno diversi approcci disponibili per l'uso e la persistenza dei dati. Un volume rappresenta un modo per archiviare, recuperare e salvare i dati tra i pod e per l'intero ciclo di vita dell'applicazione.

I volumi tradizionali vengono creati come risorse Kubernetes supportate da Archiviazione di Azure. È possibile creare manualmente volumi di dati da assegnare ai pod direttamente o lasciare che vengano creati automaticamente da Kubernetes. I volumi di dati possono essere usati: dischi di Azure, File di Azure, Azure NetApp Fileso BLOB di Azure.

Nota

A seconda dello SKU della macchina virtuale in uso, il driver CSI del disco di Azure potrebbe avere un limite di volume per nodo. Per alcune macchine virtuali con prestazioni elevate (ad esempio, 16 core), il limite è di 64 volumi per nodo. Per identificare il limite per OGNI SKU di macchina virtuale, esaminare la colonna Numero massimo di dischi di dati per ogni SKU di macchina virtuale offerto. Per un elenco degli SKU delle macchine virtuali offerti e dei limiti di capacità dettagliati corrispondenti, vedere Dimensioni delle macchine virtuali per utilizzo generico.

Per determinare meglio il carico di lavoro tra File di Azure e Azure NetApp Files, vedere le informazioni fornite nell'articolo Confronto tra file di Azure e file Azure NetApp.

Disco di Azure

Usare Disco di Azure per creare una risorsa Kubernetes DataDisk. I tipi di dischi includono:

• SSD Premium (consigliate per la maggior parte dei carichi di lavoro)
• Dischi Ultra
• SSD Standard
• HDD standard

Suggerimento

Per la maggior parte dei carichi di lavoro di produzione e di sviluppo, usare le unità SSD Premium.

Poiché un disco di Azure è montato come ReadWriteOnce, è disponibile solo per un singolo nodo. Per i volumi di archiviazione accessibili dai pod in più nodi contemporaneamente, usare File di Azure.

File di Azure

Usare File di Azure per montare una condivisione SMB (Server Message Block) versione 3.1.1 o NFS (Network File System) versione 4.1. I file di Azure consentono di condividere dati tra più nodi e pod e possono utilizzare:

• Archiviazione Premium di Azure supportata da UNITÀ SSD a prestazioni elevate
• Archiviazione Standard di Azure supportata da hdd normali

Azure NetApp Files

• Risorse di archiviazione Ultra
• Archiviazione Premium
• Archiviazione standard

Archiviazione BLOB di Azure

Usare Archiviazione BLOB di Azure per creare un contenitore di archiviazione BLOB e montarlo usando il protocollo NFS v3.0 o BlobFuse.

• BLOB in blocchi

Tipi di volume

I volumi Kubernetes rappresentano più di un semplice disco tradizionale per l'archiviazione e il recupero di informazioni. I volumi di Kubernetes possono anche essere usati come modo per inserire dati in un pod per l'uso da parte dei contenitori.

I tipi di volume comuni in Kubernetes includono:

emptyDir

Usato comunemente come spazio temporaneo per un pod. Tutti i contenitori all'interno di un pod possono accedere ai dati nel volume. I dati scritti in questo tipo di volume vengono mantenuti solo per la durata del pod. Una volta eliminato il pod, viene eliminato anche il volume. Questo volume usa in genere l'archiviazione su disco del nodo locale sottostante, ma può esistere anche solo nella memoria del nodo.

secret

È possibile usare volumi segreti per inserire dati sensibili in pod, ad esempio password.

1. Creare un segreto usando l'API di Kubernetes.
2. Definire il pod o la distribuzione e richiedere un segreto specifico.
   • I segreti vengono forniti solo ai nodi con un pod pianificato che li richiede.
   • Il segreto viene archiviato in tmpfs, non scritto su disco.
3. Quando si elimina l'ultimo pod in un nodo che richiede un segreto, il segreto viene eliminato dal tmpfs del nodo.
   • I segreti sono memorizzati all'interno di un determinato spazio dei nomi e sono accessibili solo ai pod dello stesso spazio dei nomi.

configMap

Si può utilizzare configMap per inserire le proprietà di coppie chiave-valore nei pod, ad esempio le informazioni di configurazione dell'applicazione. Definire le informazioni di configurazione dell'applicazione come risorsa Kubernetes, facilmente aggiornate e applicate alle nuove istanze di pod durante la distribuzione.

Come usare un segreto:

1. Creare un oggetto ConfigMap usando l'API Kubernetes.
2. Richiedere ConfigMap quando si definisce un pod o una distribuzione.
   • ConfigMap vengono archiviati all'interno di un determinato spazio dei nomi e sono accessibili solo da pod all'interno dello stesso spazio dei nomi.

Volumi permanenti

I volumi definiti e creati come parte del ciclo di vita del pod esistono solo fino all'eliminazione del pod. I pod si aspettano in genere che le rispettive risorse di archiviazione rimangano disponibili se un pod viene ripianificato su un host diverso durante un evento di manutenzione, in particolare in StatefulSets. Un volume permanente è una risorsa di archiviazione creata e gestita dall'API di Kubernetes che può esistere oltre la durata di un singolo pod.

È possibile usare i seguenti servizi dati di Archiviazione di Azure per fornire il volume permanente:

• Disco di Azure
• File di Azure
• Archiviazione di Container Azure (anteprima).

Come indicato nella sezione sui volumi, la scelta di dischi di Azure o file di Azure dipende spesso dalla necessità di accedere contemporaneamente ai dati o al livello di prestazioni.

Un amministratore del cluster può creare in modo statico un volume permanente, oppure il volume può essere creato in modo dinamico dal server API Kubernetes. Se un pod viene pianificato e richiede risorse di archiviazione attualmente non disponibili, Kubernetes può creare la risorsa di archiviazione sottostante Dischi di Azure o File di Azure e collegarla al pod. Il provisioning dinamico usa una classe di archiviazione per identificare il tipo di risorsa da creare.

Importante

I volumi persistenti non possono essere condivisi dai pod Windows e Linux a causa delle differenze nel supporto del file system tra i due sistemi operativi.

Classi di archiviazione

Per specificare livelli di archiviazione diversi, ad esempio Premium e Standard, è possibile creare una classe di archiviazione.

Una classe di archiviazione definisce anche criteri di recupero. Quando si elimina il volume permanente, i criteri di recupero controllano il comportamento della risorsa di Archiviazione di Azure sottostante. La risorsa sottostante può essere eliminata o mantenuta per l'uso con un pod futuro.

Per i cluster che usano i driver CSI (Container Storage Interface) vengono create le classi di archiviazione aggiuntive seguenti:

Classe di archiviazione	Descrizione
managed-csi	Usa l'archiviazione con ridondanza locale (LRS) di SSD Standard di Azure per creare un disco gestito. I criteri di recupero garantiscono che il disco di Azure sottostante venga eliminato nel momento in cui viene eliminato il pod che lo ha usato. La classe di archiviazione configura anche i volumi permanenti in modo che siano espandibili. È possibile modificare l'attestazione del volume permanente per specificare le nuove dimensioni. A partire dalla versione 1.29 di Kubernetes, nei cluster del servizio Azure Kubernetes distribuiti in più zone di disponibilità, questa classe di archiviazione usa l'archiviazione con ridondanza della zona SSD Standard di Azure per creare dischi gestiti.
managed-csi-premium	Usa l'archiviazione con ridondanza locale (LRS) Premium di Azure per creare un disco gestito. Anche in questo caso, i criteri di recupero garantiscono che il disco di Azure sottostante venga eliminato nel momento in cui viene eliminato il pod che lo ha usato. Analogamente, questa classe di archiviazione consente l'espansione dei volumi persistenti. A partire dalla versione 1.29 di Kubernetes, nei cluster del servizio Azure Kubernetes distribuiti in più zone di disponibilità, questa classe di archiviazione usa l'archiviazione con ridondanza della zona Premium di Azure per creare dischi gestiti.
azurefile-csi	Usa l'archiviazione Standard di Azure per creare una condivisione file di Azure. I criteri di recupero garantiscono che la condivisione file di Azure sottostante venga eliminata nel momento in cui viene eliminato il volume persistente che l'ha usato.
azurefile-csi-premium	Usa l'archiviazione Premium di Azure per creare una condivisione file di Azure. I criteri di recupero garantiscono che la condivisione file di Azure sottostante venga eliminata nel momento in cui viene eliminato il volume persistente che l'ha usato.
azureblob-nfs-premium	Usa l'archiviazione Premium di Azure per creare un contenitore di archiviazione BLOB di Azure e connettersi usando il protocollo NFS v3. I criteri di recupero garantisce che il contenitore di archiviazione BLOB di Azure sottostante venga eliminato quando viene eliminato il volume persistente che l’ha usato.
azureblob-fuse-premium	Usa l'Archiviazione Premium di Azure per creare un contenitore di archiviazione BLOB di Azure e connettersi usando BlobFuse. I criteri di recupero garantisce che il contenitore di archiviazione BLOB di Azure sottostante venga eliminato quando viene eliminato il volume persistente che l’ha usato.

A meno che non si specifichi una classe di archiviazione per un volume permanente, viene usata la classe di archiviazione predefinita. Assicurarsi che i volumi usino lo spazio di archiviazione appropriato necessario quando si richiedono volumi persistenti.

Importante

A partire da Kubernetes versione 1.21, il servizio Azure Kubernetes usa solo i driver CSI per impostazione predefinita e la migrazione CSI è abilitata. Anche se i volumi persistenti nell'albero esistenti continuano a funzionare, a partire dalla versione 1.26, il servizio Azure Kubernetes non supporterà più i volumi creati usando il driver nell'albero e l'archiviazione di cui è stato effettuato il provisioning per file e dischi.

La classe default sarà uguale a managed-csi.

A partire dalla versione 1.29 di Kubernetes, quando si distribuiscono cluster del servizio Azure Kubernetes in più zone di disponibilità, il servizio Azure Kubernetes ora usa l'archiviazione con ridondanza della zona (ZRS) per creare dischi gestiti all'interno di classi di archiviazione predefinite. L'archiviazione con ridondanza della zona garantisce la replica sincrona dei dischi gestiti di Azure in più zone di disponibilità di Azure nell'area scelta. Questa strategia di ridondanza migliora la resilienza delle applicazioni e protegge i dati dagli errori del data center.

Tuttavia, è importante notare che l'archiviazione con ridondanza della zona (ZRS) comporta un costo più elevato rispetto all'archiviazione con ridondanza locale. Se l'ottimizzazione dei costi è una priorità, è possibile creare una nuova classe di archiviazione con il parametro skuname impostato su Archiviazione con ridondanza locale. È quindi possibile usare la nuova classe di archiviazione nell'attestazione di volume persistente (PVC).

È possibile creare una classe di archiviazione per altre esigenze usando kubectl. L'esempio seguente usa Managed Disks Premium e specifica che il disco di Azure sottostante deve essere conservato quando viene eliminato il pod:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-premium-retain
provisioner: disk.csi.azure.com
parameters:
  skuName: Premium_ZRS
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Nota

Il servizio Azure Kubernetes riconcilia le classi di archiviazione predefinite e sovrascrive le modifiche apportate a tali classi di archiviazione.

Per altre informazioni sulle classi di archiviazione, vedere StorageClass in Kubernetes.

Attestazioni di volume permanente

Un'attestazione di volume permanente richiede l'archiviazione di una determinata classe di archiviazione, di una modalità di accesso e delle dimensioni. Il server API di Kubernetes può fornire dinamicamente la risorsa di archiviazione di Azure sottostante se nessuna risorsa esistente può soddisfare la richiesta in base alla classe di archiviazione definita.

La definizione del pod include il montaggio del volume dopo la connessione del volume al pod.

Dopo che una risorsa di archiviazione disponibile è stata assegnata al pod che richiede l'archiviazione, il volume permanente viene associato a un'attestazione di volume permanente. I volumi permanenti vengono mappati alle attestazioni in un mapping 1:1.

Il manifesto YAML di esempio seguente mostra un'attestazione di volume permanente che usa la classe di archiviazione managed-premium e richiede un disco Azure con dimensioni di 5Gi:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: azure-managed-disk
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: managed-premium-retain
  resources:
    requests:
      storage: 5Gi

Quando si crea una definizione di pod, è necessario specificare anche:

• Attestazione di volume permanente per richiedere l'archiviazione desiderata.
• Il volume di montaggio per le applicazioni di lettura e scrittura di dati.

Il manifesto YAML di esempio seguente mostra come l'attestazione di volume permanente precedente può essere usata per montare un volume in /mnt/azure:

kind: Pod
apiVersion: v1
metadata:
  name: nginx
spec:
  containers:
    - name: myfrontend
      image: mcr.microsoft.com/oss/nginx/nginx:1.15.5-alpine
      volumeMounts:
      - mountPath: "/mnt/azure"
        name: volume
  volumes:
    - name: volume
      persistentVolumeClaim:
        claimName: azure-managed-disk

Per montare un volume in un contenitore di Windows, specificare la lettera e il percorso dell'unità. Ad esempio:

...      
      volumeMounts:
      - mountPath: "d:"
        name: volume
      - mountPath: "c:\k"
        name: k-dir
...

Passaggi successivi

Per le procedure consigliate associate, vedere Procedure consigliate per l'archiviazione e i backup nel servizio Azure Kubernetes e nelle considerazioni sull'archiviazione del servizio Azure Kubernetes.

Per informazioni su come usare i driver CSI, vedere gli articoli sulle procedure seguenti:

• Driver CSI (Container Storage Interface) per Dischi di Azure, File di Azure e Archiviazione BLOB di Azure nel servizio Azure Kubernetes
• Usare il driver CSI del disco di Azure nel servizio Azure Kubernetes
• Usare il driver CSI di File di Azure nel servizio Azure Kubernetes
• Usare il driver CSI di Archiviazione BLOB di Azure nel servizio Azure Kubernetes
• Configurare Azure NetApp Files per il servizio Azure Kubernetes

Per altre informazioni sui concetti fondamentali di Kubernetes e del servizio Azure Kubernetes, vedere gli articoli seguenti:

• Kubernetes/Cluster e carichi di lavoro del servizio Azure Kubernetes
• Kubernetes/Identità del servizio Azure Kubernetes
• Sicurezza di Kubernetes/servizio Azure Kubernetes
• Kubernetes/Reti virtuali nel servizio Azure Kubernetes
• Kubernetes/Ridimensionamento nel servizio Azure Kubernetes