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

  • Articolo

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:

Diagramma delle opzioni di archiviazione per le applicazioni in un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes s).

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 managed disks 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_v3 con 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 Files o 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 ad alte prestazioni (ad esempio, 16 core), il limite è di 64 volumi per nodo. Per identificare il limite per OGNI SKU di macchina virtuale, esaminare la colonna Max data disks (Numero massimo di dischi 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 File di Azure e confronto di Azure NetApp Files.

Disco di Azure

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

  • Dischi Ultra
  • SSD Premium
  • SSD Standard
  • HDD standard

Suggerimento

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

Poiché il disco di Azure è montato come ReadWriteOnce, sono disponibili 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 supportata da un account di archiviazione di Azure ai pod. File di Azure consente di condividere i dati tra più nodi e pod e può usare:

  • 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, anche se può esistere 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 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 vengono archiviati all'interno di uno spazio dei nomi specificato e sono accessibili solo dai pod all'interno dello stesso spazio dei nomi.

configMap

È possibile usare configMap per inserire le proprietà della coppia 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.
    • Config Mappe vengono archiviati all'interno di uno spazio dei nomi specificato e sono accessibili solo dai 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 a quando non si elimina il 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 Archiviazione di Azure servizi dati per fornire PersistentVolume:

Come indicato nella sezione Volumi , la scelta di dischi o file è spesso determinata dalla necessità di accesso simultaneo ai dati o al livello di prestazioni.

Diagramma dei volumi persistenti in un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes s).

Un amministratore del cluster può creare in modo statico un oggetto PersistentVolume oppure il volume viene creato in modo dinamico dal server API Kubernetes. Se un pod è pianificato e richiede attualmente l'archiviazione non disponibile, Kubernetes può creare l'archiviazione file o il disco di Azure sottostante e collegarlo al pod. Il provisioning dinamico usa una StorageClass per identificare il tipo di archiviazione di Azure 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 definire livelli di archiviazione diversi, ad esempio Premium e Standard, è possibile creare una StorageClass.

La StorageClass definisce anche i reclaimPolicy. Quando si elimina il volume permanente, il metodo reclaimPolicy controlla il comportamento della risorsa di archiviazione di Azure sottostante. La risorsa di archiviazione sottostante può essere eliminata o mantenuta per l'uso con un pod futuro.

Per i cluster che usano i driver CSI (Container Archiviazione Interface) vengono creati gli elementi aggiuntivi StorageClasses seguenti:

Classe di archiviazione Descrizione
managed-csi Usa l'archiviazione con ridondanza locale SSD Standard di Azure per creare un disco gestito. I criteri di recupero assicurano che il disco di Azure sottostante venga eliminato quando il volume permanente usato viene eliminato. La classe di archiviazione configura anche i volumi persistenti in modo che siano espandibili. è sufficiente modificare l'attestazione del volume permanente con le nuove dimensioni.
managed-csi-premium Usa l'archiviazione con ridondanza locale di Azure Premium per creare un disco gestito. Il criterio di recupero garantisce di nuovo che il disco di Azure sottostante venga eliminato quando il volume permanente usato viene eliminato. Analogamente, questa classe di archiviazione consente l'espansione dei volumi persistenti.
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 assicurano che la condivisione file di Azure sottostante venga eliminata quando il volume permanente usato viene eliminato.
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. Il criterio di recupero garantisce che il contenitore di archiviazione BLOB di Azure sottostante venga eliminato quando il volume permanente usato viene eliminato.
azureblob-fuse-premium Usa l'Archiviazione Premium di Azure per creare un contenitore di archiviazione BLOB di Azure e connettersi usando BlobFuse. Il criterio di recupero garantisce che il contenitore di archiviazione BLOB di Azure sottostante venga eliminato quando il volume permanente usato viene eliminato.

A meno che non si specifichi un oggetto StorageClass per un volume permanente, viene usata l'opzione StorageClass 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 default classe sarà uguale managed-csia .

È possibile creare una Archiviazione Class per altre esigenze usando kubectl. L'esempio seguente usa Managed Disks Premium e specifica che il disco di Azure sottostante deve essere conservato quando si elimina 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 Archiviazione Class in Kubernetes.

Attestazioni di volume permanente

Un oggetto PersistentVolumeClaim richiede l'archiviazione di una determinata Archiviazione Class, modalità di accesso e dimensioni. Il server API Kubernetes può effettuare dinamicamente il provisioning della risorsa di archiviazione di Azure sottostante se nessuna risorsa esistente può soddisfare l'attestazione in base alla Archiviazione Class definita.

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

Diagramma delle attestazioni di volume persistente in un cluster del servizio Azure Kubernetes (servizio Azure Kubernetes).

Dopo aver assegnato una risorsa di archiviazione disponibile al pod che richiede la risorsa di archiviazione, PersistentVolume viene associato a una richiesta PersistentVolumeClaim. I volumi permanenti sono 1:1 mappati alle attestazioni.

Il manifesto YAML di esempio seguente mostra un'attestazione di volume permanente che usa la StorageClass managed-premium e richiede un disco 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.
  • VolumeMount per le applicazioni per leggere e scrivere 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 Archiviazione Considerazioni.

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

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