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

Le applicazioni in esecuzione in servizio Azure Kubernetes (servizio Azure Kubernetes) potrebbero dover archiviare e recuperare i 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:

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.

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.

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

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 servizi di Archiviazione di Azure seguenti per fornire il volume permanente:

• Disco di Azure
• File di Azure
• Azure Container Storage

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.

Se si vuole una soluzione completamente gestita per l'accesso a livello di blocco ai dati, è consigliabile usare Archiviazione Azure Container anziché i driver CSI. Archiviazione azure Container si integra con Kubernetes, consentendo il provisioning dinamico e automatico di volumi persistenti. Archiviazione azure Container supporta dischi di Azure, dischi temporanei e SAN elastico di Azure (anteprima) come risorsa di archiviazione di backup, offrendo flessibilità e scalabilità per le applicazioni con stato in esecuzione nei cluster Kubernetes.

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 Archiviazione Azure Container, verrà visualizzata una classe di archiviazione aggiuntiva denominata acstor-<storage-pool-name>. Viene creata anche una classe di archiviazione interna.

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

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.

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

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 altre informazioni su Archiviazione azure Container, vedere gli articoli seguenti:

• Che cos'è Archiviazione azure Container?
• Usare Archiviazione contenitori di Azure con il servizio Azure Kubernetes

Per altre informazioni sull'uso dei driver CSI, vedere gli articoli 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