Opzioni di archiviazione per un cluster Kubernetes

Questo articolo confronta le funzionalità di archiviazione del servizio Amazon Elastic Kubernetes e del servizio Azure Kubernetes. Descrive anche le opzioni di archiviazione per i dati del carico di lavoro su AKS.

Opzioni di archiviazione amazon EKS

Amazon EKS offre diversi tipi di volumi di archiviazione per le applicazioni che richiedono l'archiviazione dei dati. È possibile usare questi volumi per l'archiviazione temporanea e di lunga durata.

Volumi temporanei

Per le applicazioni che richiedono volumi locali temporanei, ma non è necessario rendere persistenti i dati dopo il riavvio, usare volumi temporanei. Kubernetes supporta diversi tipi di volumi temporanei, ad esempio emptyDir, ConfigMap, downwardAPI, secret e hostPath. Per garantire l'efficienza e le prestazioni dei costi, scegliere il volume host più appropriato. In Amazon EKS è possibile usare gp3 come volume radice dell'host, che costa meno dei volumi gp2.

È anche possibile usare archivi di istanze amazon EC2, che forniscono spazio di archiviazione temporaneo a livello di blocco per le istanze EC2. Questi volumi sono fisicamente collegati agli host ed esistono solo durante la durata dell'istanza. Per usare i volumi dell'archivio locale in Kubernetes, è necessario partizionare, configurare e formattare i dischi usando i dati utente di Amazon EC2.

Volumi permanenti

In genere Si usa Kubernetes per eseguire applicazioni senza stato, ma a volte è necessaria l'archiviazione dei dati persistente. È possibile usare volumi permanenti Kubernetes per archiviare i dati in modo indipendente dai pod in modo che i dati possano rimanere persistenti oltre la durata di un determinato pod. Amazon EKS supporta diversi tipi di opzioni di archiviazione per volumi persistenti, tra cui Amazon EBS, Amazon Elastic File System (EFS),Amazon FSx per Lustre e Amazon FSx per NetApp ONTAP.

Utilizzare i volumi Amazon EBS per l'archiviazione a livello di blocco e per i database e le applicazioni a elevato consumo di larghezza di banda. Gli utenti di Amazon EKS possono usare la generazione più recente di archiviazione a blocchi gp3 per un equilibrio tra prezzo e prestazioni. Per le applicazioni con prestazioni più elevate, è possibile usare volumi io2 Block Express.

Amazon EFS è un file system elastico serverless che è possibile condividere tra più contenitori e nodi. Aumenta e si riduce automaticamente man mano che i file vengono aggiunti o rimossi, eliminando così la necessità di pianificare la capacità. Il driver Amazon EFS Container Storage Interface (CSI) integra Amazon EFS con Kubernetes.

Amazon FSx per Lustre offre un'archiviazione file parallela ad alte prestazioni. Usare questo tipo di archiviazione per scenari che richiedono operazioni a velocità effettiva elevata e bassa latenza. È possibile collegare questa risorsa di archiviazione file a un repository di dati Amazon S3 per archiviare set di dati di grandi dimensioni. Amazon FSx per NetApp ONTAP è una soluzione di archiviazione condivisa completamente gestita basata sul file system ONTAP di NetApp.

Per ottimizzare le configurazioni di archiviazione e gestire backup e snapshot, usare strumenti come AWS Compute Optimizer e Velero.

Opzioni di archiviazione AKS

Le applicazioni eseguite su AKS potrebbero dover archiviare e recuperare dati. Alcuni carichi di lavoro dell'applicazione possono usare l'archiviazione locale e veloce in nodi vuoti non usati. Altri carichi di lavoro dell'applicazione richiedono tuttavia l'archiviazione che persiste in volumi di dati più regolari all'interno della piattaforma Azure. Diversi pod potrebbero essere necessari:

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

Le sezioni seguenti illustrano le opzioni di storage e i concetti principali che forniscono storage alle vostre applicazioni in AKS.

Tipi di volume

I volumi Kubernetes rappresentano più di un semplice disco tradizionale per archiviare e recuperare informazioni. È anche possibile utilizzare i volumi Kubernetes per immettere dati in un pod affinché siano utilizzati dai suoi contenitori.

I tipi di volume comuni in Kubernetes includono emptyDirs, segreti e ConfigMaps.

EmptyDirs

Per un pod che definisce un volume emptyDir, il volume viene creato quando il pod viene assegnato a un nodo. Come suggerisce il nome, il volume emptyDir è inizialmente vuoto. Tutti i contenitori nel pod possono leggere e scrivere gli stessi file nel volume emptyDir, anche se questo volume può essere montato nello stesso percorso o in percorsi diversi in ogni contenitore. Quando un pod viene rimosso da un nodo per qualsiasi motivo, i dati in emptyDir vengono eliminati definitivamente.

Segreti

Un segreto è un oggetto che contiene una piccola quantità di dati sensibili, ad esempio una password, un token o una chiave. Se non si usa un segreto, queste informazioni vengono incluse in una specifica del pod o in un'immagine del contenitore. Un segreto impedisce la necessità di incorporare dati riservati direttamente nel codice dell'applicazione. È possibile creare segreti indipendentemente dai pod che li usano. Questa procedura riduce il rischio di esporre il segreto e i relativi dati quando si creano, visualizzano e modificano i pod. Kubernetes e le applicazioni eseguite nel cluster possono adottare precauzioni aggiuntive con i segreti, ad esempio impedire la scrittura di dati sensibili nell'archiviazione non volatile. I segreti sono simili a ConfigMap, ma sono progettati appositamente per archiviare dati riservati.

È possibile usare i segreti per gli scopi seguenti:

• Impostare le variabili di ambiente per un contenitore.
• Specificare credenziali come chiavi SSH o password per i pod.
• Consentire al kubelet di scaricare le immagini del container dai registri privati.

Il piano di controllo Kubernetes usa anche segreti, ad esempio segreti del token bootstrap, per automatizzare la registrazione dei nodi.

ConfigMaps

Un oggetto ConfigMap è un oggetto Kubernetes usato per archiviare i dati non condizionali in coppie chiave-valore. I pod possono utilizzare i ConfigMap come variabili di ambiente, argomenti della riga di comando o come file di configurazione in un volume . È possibile usare un oggetto ConfigMap per separare le configurazioni specifiche dell'ambiente dalle immagini del contenitore, semplificando la portabilità delle applicazioni.

Gli oggetti ConfigMap non forniscono la segretezza o la crittografia. Se si desidera archiviare dati riservati, usare un segreto anziché un ConfigMap o usare altri strumenti di partner per mantenere i dati privati.

È possibile usare un oggetto ConfigMap per impostare i dati di configurazione separatamente dal codice dell'applicazione. Ad esempio, è possibile sviluppare un'applicazione da eseguire nel computer per lo sviluppo e l'esecuzione nel cloud per gestire il traffico reale. È possibile scrivere il codice da cercare in una variabile di ambiente denominata DATABASE_HOST. In locale, impostare tale variabile su localhost. Nel cloud, configurarlo affinché faccia riferimento a un servizio Kubernetes che espone il componente del database al cluster. Questo approccio consente di recuperare un'immagine del contenitore eseguita nel cloud ed eseguire il debug dello stesso codice in locale, se necessario.

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 spesso si aspettano che lo spazio di archiviazione rimanga se un pod viene spostato su un host diverso durante eventi di manutenzione, soprattutto nei StatefulSet. Un volume permanente è una risorsa di archiviazione creata e gestita dall'API Kubernetes. Un volume persistente può esistere oltre la durata di un singolo pod. Per fornire il volume permanente, è possibile usare gli strumenti di Archiviazione di Azure seguenti:

• Azure disk storage
• File di Azure
• Azure NetApp Files
• Archiviazione BLOB di Azure
• Archiviazione Azure Container

Per decidere tra Archiviazione su disco di Azure o File di Azure, valutare se l'applicazione necessita di accesso simultaneo ai dati o di un livello di prestazioni specifico.

Un amministratore del cluster può creare in modo statico un volume permanente o il server API Kubernetes può creare dinamicamente un volume. Se un pod è pianificato e richiede l'archiviazione attualmente non disponibile, Kubernetes può creare il disco o l'archiviazione file di Azure sottostante e collegarlo al pod. Il provisioning dinamico usa una classe di archiviazione per identificare il tipo di risorsa da creare.

Se si desidera una soluzione completamente gestita per l'accesso a livello di blocco ai dati, considerare di usare Azure Container Storage anziché i driver CSI. Azure Container Storage si integra con Kubernetes per offrire il provisioning dinamico e automatico di volumi persistenti. Azure Container Storage supporta i dischi di Azure, i dischi temporanei e l'Azure Elastic SAN (anteprima) come memoria di appoggio. Queste opzioni offrono flessibilità e scalabilità per le applicazioni con stato eseguite nei cluster Kubernetes.

Classi di archiviazione

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

Una classe di archiviazione definisce anche un criterio di recupero . Quando si elimina un 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.

I cluster che usano Archiviazione Azure Container hanno 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, 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 necessario quando si richiedono volumi persistenti.

La default classe è la stessa della managed-csi classe .

Per Kubernetes versione 1.29 e successive, quando si distribuiscono cluster del servizio Azure Kubernetes in più zone di disponibilità, il servizio Azure Kubernetes usa l'archiviazione con ridondanza della zona per creare dischi gestiti all'interno di classi di archiviazione predefinite. ZRS assicura la replica sincrona dei dischi gestiti di Azure in più zone di disponibilità di Azure nella regione scelta. Questa strategia di ridondanza migliora la resilienza delle applicazioni e consente di proteggere i dati dagli errori del data center.

Tuttavia, l'archiviazione con ridondanza della zona costa più dell'archiviazione con ridondanza locale. Se l'ottimizzazione dei costi è una priorità, è possibile creare una nuova classe di archiviazione con il skuname parametro impostato su Archiviazione con ridondanza locale. È quindi possibile usare la nuova classe di archiviazione nell'attestazione del volume permanente.

È possibile creare una classe di archiviazione per altre esigenze usando kubectl. L'esempio seguente usa dischi gestiti 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

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

Per altre informazioni, vedere StorageClass in Kubernetes.

Richieste di volumi persistenti

Un'attestazione di volume permanente richiede l'archiviazione di una determinata classe di archiviazione, 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 classe di archiviazione definita.

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

Dopo l'assegnazione di una risorsa di archiviazione disponibile al pod che richiede l'archiviazione, il volume permanente viene associato a un'attestazione di volume permanente. Ogni volume permanente è associato a un'attestazione di volume permanente per garantire l'archiviazione dedicata.

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

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:

• Richiesta di volume persistente per richiedere lo spazio di archiviazione desiderato.
• Il montaggio del volume consente alle applicazioni di leggere e scrivere dati.

Il seguente esempio di manifesto YAML mostra come la precedente richiesta di volume persistente possa montare in /mnt/azure un volume.

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 dell'unità e il percorso:

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

Disco del sistema operativo temporaneo

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

Al contrario, i dischi temporanei del sistema operativo vengono archiviati solo nel computer host, ad esempio un disco temporaneo. Questa configurazione offre una latenza di lettura e scrittura inferiore e un ridimensionamento dei nodi più rapido e aggiornamenti del cluster.

Se non si richiedono dischi gestiti di Azure per il sistema operativo, AKS usa per impostazione predefinita dischi temporanei del sistema operativo, se possibile, in base alla configurazione del pool di nodi.

Per i requisiti e le raccomandazioni sulle dimensioni, vedere Dischi temporanei del sistema operativo per le macchine virtuali di Azure. Considerare le considerazioni di ridimensionamento seguenti:

• Se si utilizzano le dimensioni predefinite della VM AKS Standard_DS2_v2 SKU con le dimensioni predefinite del disco del sistema operativo pari a 100 GiB, le dimensioni predefinite della VM supportano dischi effimeri del sistema operativo, ma hanno solo una dimensione della cache pari a 86 GiB. Questa configurazione è impostata sui dischi gestiti se non lo specifichi. Se si richiede un disco del 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 viene predefinito per i dischi temporanei del sistema operativo. La dimensione richiesta di 60 GiB è inferiore alla dimensione massima della cache di 86 GiB.

• Se si seleziona lo SKU Standard_D8s_v3 con un disco del sistema operativo da 100 GB, questa dimensione di macchina virtuale supporta i dischi temporanei del sistema operativo e ha dimensioni della cache pari a 200 GiB. Se non si specifica il tipo di disco del sistema operativo, il pool di nodi riceve i dischi temporanei del sistema operativo per impostazione predefinita.

La generazione più recente della serie di macchine virtuali non ha una cache dedicata e dispone solo di una risorsa di archiviazione temporanea.

• Se si selezionano le dimensioni della macchina virtuale Standard_E2bds_v5 con le dimensioni predefinite del disco del sistema operativo pari a 100 GiB, la macchina virtuale supporta dischi temporanei del sistema operativo, ma ha solo 75 GB di spazio di archiviazione temporaneo. Questa configurazione usa per impostazione predefinita i dischi del sistema operativo gestito se non lo si specifica. Se si richiede un disco del sistema operativo temporaneo, viene visualizzato un errore di convalida.

• Se si richiede la stessa dimensione di macchina virtuale Standard_E2bds_v5 con un disco da 60 GiB per il sistema operativo, questa configurazione viene impostata per l'uso di dischi OS effimeri. La dimensione richiesta di 60 GiB è inferiore alla memoria temporanea massima di 75 GiB.

• Se si seleziona lo SKU Standard_E4bds_v5 con un disco del sistema operativo da 100 GiB, questa dimensione di VM supporta dischi OS effimeri e dispone di 150 GiB di archiviazione temporanea. Se non si specifica il tipo di disco del sistema operativo, 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 usando le proprie chiavi in un cluster del servizio Azure Kubernetes. Per altre informazioni, vedere Bring Your Own Keys with Azure Managed Disks in AKS (Usare chiavi personalizzate con dischi gestiti di Azure nel servizio Azure Kubernetes).

Volumi

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

I volumi tradizionali vengono creati come risorse di Kubernetes e sono supportati da Azure Storage. È possibile creare manualmente volumi di dati da assegnare direttamente ai pod o farli creare automaticamente da Kubernetes. I volumi di dati possono usare Archiviazione su disco Azure, Azure Files, Azure NetApp Files o Archiviazione BLOB.

Per decidere tra File di Azure e Azure NetApp Files, vedere Confronto tra File di Azure e Azure NetApp Files.

Archiviazione su disco di Azure

Per impostazione predefinita, un cluster AKS include classi di archiviazione precreate managed-csi e managed-csi-premium che usano l'archiviazione su disco di Azure. Analogamente a Amazon EBS, queste classi creano un disco gestito o un dispositivo a blocchi collegato al nodo per l'accesso ai pod.

Le classi del disco consentono il provisioning di volumi sia statici che dinamici. La politica di recupero assicura che il disco venga eliminato con il volume persistente. Per espandere il disco, modificare la richiesta di volume persistente.

Queste classi di archiviazione usano dischi gestiti di Azure con LRS (archiviazione con ridondanza locale). I dati nell'archiviazione con ridondanza locale hanno tre copie sincrone all'interno di una singola posizione fisica in un'area primaria di Azure. L'archiviazione con ridondanza locale è l'opzione di replica meno costosa, ma non offre protezione da un errore del data center. È possibile definire classi di archiviazione personalizzate che usano dischi gestiti con ZRS (archiviazione ridondante della zona).

L'archiviazione ridondante della zona (ZRS) replica sincronicamente il disco gestito di Azure attraverso tre zone di disponibilità di Azure nella regione. Ogni zona di disponibilità è una posizione fisica separata con alimentazione, raffreddamento e rete indipendenti. I dischi ZRS offrono almeno 99,9999999999% di durabilità nell'arco di un anno. Un disco gestito con ridondanza a livello di zona (ZRS) può essere associato a una macchina virtuale in una zona di disponibilità diversa. I dischi dell'archiviazione con ridondanza della zona non sono disponibili in tutte le aree di Azure. Per altre informazioni, vedere Opzioni di archiviazione con ridondanza della zona per i dischi di Azure per migliorare la disponibilità.

Per ridurre il rischio di perdita di dati, usare il backup del servizio Azure Kubernetes per eseguire backup regolari o snapshot dei dati di archiviazione su disco. In alternativa, è possibile usare soluzioni partner, ad esempio Velero o Backup di Azure, con tecnologia snapshot predefinita.

È possibile usare l'archiviazione su disco di Azure per creare una risorsa Kubernetes DataDisk . È possibile usare i tipi di dischi seguenti:

• SSD Premium (consigliato per la maggior parte dei carichi di lavoro)
• Premium SSD v2
• Archiviazione su disco Ultra di Azure
• SSD Standard
• Azure Standard HDD

Un disco di Azure viene montato come ReadWriteOnce, quindi è disponibile solo per un singolo nodo. Per i volumi di archiviazione a cui i pod in più nodi possono accedere contemporaneamente, usare File di Azure.

Dischi SSD Premium v2

I dischi SSD Premium v2 sono progettati per carichi di lavoro aziendali intensi di input/output(I/O). Offrono una latenza del disco submilliseconda coerente, operazioni di input/output elevate al secondo (IOPS) e velocità effettiva elevata. È possibile configurare in modo indipendente le prestazioni (capacità, operazioni di I/O al secondo e velocità effettiva) di dischi SSD Premium v2 in qualsiasi momento. In questo modo è possibile migliorare facilmente l'efficienza dei costi soddisfando le esigenze di prestazioni. Per altre informazioni su come configurare un cluster del servizio Azure Kubernetes nuovo o esistente per l'uso di dischi SSD Premium v2, vedere Usare dischi SSD Premium v2 nel servizio Azure Kubernetes.

Archiviazione su disco Ultra

Ultra Disk Storage è un livello di disco gestito di Azure che offre alta velocità effettiva, elevati IOPS e archiviazione su disco a bassa latenza costante per le macchine virtuali di Azure. Usare l'archiviazione su disco Ultra per carichi di lavoro a elevato utilizzo di dati e transazioni. Analogamente ad altri SKU di archiviazione su disco e Amazon EBS, l'archiviazione su disco Ultra monta un pod alla volta e non fornisce l'accesso simultaneo.

Per abilitare l'archiviazione su disco Ultra nel cluster del servizio Azure Kubernetes, usare il flag --enable-ultra-ssd.

Tenere presente le limitazioni di Archiviazione su disco Ultra e selezionare una dimensione di macchina virtuale compatibile. L'archiviazione Ultra Disk ha la replica con ridondanza locale (LRS).

Porta le tue chiavi (BYOK)

Azure crittografa tutti i dati in un disco gestito a riposo, inclusi il sistema operativo e i dischi dati di un cluster AKS. Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi crittografiche, è possibile fornire chiavi gestite dal cliente per garantire la crittografia dei dati a riposo sia per il sistema operativo che per i dischi dati nei cluster AKS. Per altre informazioni, vedere BYOK con dischi gestiti di Azure in AKS e crittografia sul lato server dell'archiviazione su disco di Azure.

File di Azure

L'archiviazione su disco non può fornire l'accesso simultaneo a un volume, ma è possibile usare File di Azure per montare una condivisione SMB (Server Message Block) versione 3.1.1 o una condivisione NFS versione 4.1 supportata da Archiviazione di Azure. Questo processo fornisce una risorsa di archiviazione collegata alla rete simile a Amazon EFS. File di Azure offre due opzioni di archiviazione:

• Lo spazio di archiviazione Standard di Azure per i file supporta la condivisione file con normali dischi rigidi (HDD).

• Archiviazione Premium di Azure Files supporta la condivisione file con unità a stato solido (SSD) ad alte prestazioni. La dimensione minima della condivisione file per Premium è 100 GB.

Azure Files include le seguenti opzioni di replica dell'account di archiviazione per proteggere i tuoi dati in caso di errore.

• Standard_LRS: Standard LRS
• Standard_GRS: Archiviazione con ridondanza geografica standard (GRS)
• Standard_ZRS: Standard ZRS
• Standard_RAGRS: archiviazione con ridondanza geografica con accesso in lettura standard (RA-GRS)
• Standard_RAGZRS: archiviazione standard con ridondanza geografica e accesso in lettura (RA-GZRS)
• Premium_LRS: Premium LRS
• Premium_ZRS: Premium Archiviazione con ridondanza della zona

Per ottimizzare i costi per File di Azure, acquistare prenotazioni di capacità di File di Azure.

Azure NetApp Files

Azure NetApp Files è un servizio di archiviazione file a consumo di livello aziendale, a prestazioni elevate e a consumo eseguito in Azure e supporta volumi usando volumi NFS (NFSv3 o NFSv4.1), SMB e dual protocol (NFSv3 e SMB o NFSv4.1 e SMB). Gli utenti di Kubernetes hanno due opzioni per l'uso dei volumi di Azure NetApp Files per i carichi di lavoro Kubernetes:

• Creare volumi di Azure NetApp Files in modo statico. Creare volumi all'esterno del servizio Azure Kubernetes tramite l'interfaccia della riga di comando di Azure o il portale di Azure. Dopo la creazione, questi volumi vengono esposti a Kubernetes creando un oggetto PersistentVolume. I volumi di Azure NetApp Files creati in modo statico presentano molte limitazioni. Ad esempio, non possono essere espansi e devono essere sottoposto a overprovisioning. Non è consigliabile creare volumi statici per la maggior parte dei casi d'uso.

• Creare volumi di Azure NetApp Files in modo dinamico tramite Kubernetes. Questo è il metodo preferito per creare più volumi direttamente tramite Kubernetes usando Astra Trident. Astra Trident è un agente di orchestrazione di archiviazione dinamica conforme a CSI che consente di effettuare il provisioning dei volumi in modo nativo tramite Kubernetes.

Per ulteriori informazioni, vedere Configurare Azure NetApp Files per AKS.

Archiviazione BLOB

Il driver CSI di Blob Storage è un driver conforme alla specifica CSI usato da AKS per gestire il ciclo di vita del Blob Storage. CSI è uno standard per esporre sistemi di archiviazione a blocchi e file arbitrari a carichi di lavoro containerizzati su Kubernetes.

Adottare e usare il CSI in modo che il servizio Azure Kubernetes possa scrivere, distribuire e eseguire l'iterazione dei plug-in. I plug-in espongono nuovi sistemi di archiviazione o migliorano i sistemi di archiviazione esistenti in Kubernetes. I driver CSI in AKS eliminano la necessità di modificare il codice Kubernetes di base e di attendere i cicli di rilascio.

Quando si monta l'archiviazione BLOB come file system in un contenitore o in un pod, è possibile usarla con applicazioni che gestiscono grandi quantità di dati non strutturati, ad esempio:

• Dati dei file di log.
• Immagini, documenti e streaming video o audio.
• Dati di ripristino di emergenza.

Le applicazioni possono accedere ai dati nell'archivio oggetti tramite BlobFuse o il protocollo NFS 3.0. Prima dell'introduzione del driver CSI per Blob Storage, l'unica opzione era installare manualmente un driver non supportato per accedere al Blob Storage dalla tua applicazione in esecuzione su AKS. Un driver CSI di archiviazione Blob abilitato su Azure Kubernetes Service (AKS) ha due classi di archiviazione predefinite: azureblob-fuse-premium e azureblob-nfs-premium.

Per creare un cluster del servizio Azure Kubernetes con supporto per i driver CSI, vedere Driver CSI nel servizio Azure Kubernetes. Per altre informazioni, vedere Confrontare l'accesso a File di Azure, Archiviazione BLOB e Azure NetApp Files con NFS.

Cache HPC di Azure

Cache HPC accelera l'accesso ai tuoi dati per le attività di elaborazione ad alte prestazioni e offre la scalabilità delle soluzioni cloud. Se si sceglie questa soluzione di archiviazione, assicurarsi di distribuire il cluster AKS in un'area che supporta HPC Cache.

Server NFS

Per l'accesso NFS condiviso, è consigliabile usare File di Azure o Azure NetApp Files. È anche possibile creare un server NFS in una macchina virtuale di Azure che esporta volumi.

Questa opzione supporta solo il provisioning statico. È necessario effettuare manualmente il provisioning delle condivisioni NFS nel server. Non è possibile effettuare automaticamente il provisioning di condivisioni NFS in AKS.

Questa soluzione si basa sull'infrastruttura distribuita come servizio (IaaS) anziché sulla piattaforma distribuita come servizio (PaaS). È possibile gestire il server NFS, inclusi gli aggiornamenti del sistema operativo, la disponibilità elevata, i backup, il ripristino di emergenza e la scalabilità.

Archiviazione dei container di Azure

Archiviazione contenitori di Azure è un servizio di gestione, distribuzione e orchestrazione basato sul cloud creato in modo nativo per i contenitori. Si integra con Kubernetes in modo che sia possibile eseguire dinamicamente e automaticamente il provisioning di volumi persistenti per archiviare i dati per le applicazioni con stato eseguite nei cluster Kubernetes.

Azure Container Storage utilizza le offerte esistenti di Archiviazione di Azure per l'archiviazione effettiva dei dati e offre una soluzione di orchestrazione e gestione dei volumi creata appositamente per i container. Azure Container Storage supporta il seguente spazio di archiviazione di supporto:

• Dischi di Azure: Fornire un controllo granulare degli SKU e delle configurazioni di archiviazione. I dischi di Azure soddisfano i database di livello 1 e per utilizzo generico.

• Dischi effimeri: Utilizzare le risorse di archiviazione locali nei nodi di Azure Kubernetes Services (NVMe o temp SSD). I dischi temporanei soddisfano le applicazioni che non hanno requisiti di durabilità dei dati o che dispongono del supporto predefinito per la replica dei dati. AKS individua l'archiviazione effimera disponibile nei nodi AKS e la acquisisce per la distribuzione del volume.

• SAN elastico: Risorse completamente gestite e disponibili su richiesta. Elastic SAN si adatta ai database per utilizzo generico, ai servizi di streaming e di messaggistica, all'integrazione continua e agli ambienti di recapito continuo e ad altri carichi di lavoro di livello 1 o di livello 2. Più cluster possono accedere contemporaneamente a una singola rete di archiviazione (SAN). Tuttavia, i volumi persistenti possono essere collegati solo a un utente alla volta.

In precedenza, per fornire l'archiviazione cloud per i contenitori, sono necessari singoli driver CSI per adattare i servizi di archiviazione destinati ai carichi di lavoro incentrati su IaaS. Questo metodo ha creato un sovraccarico operativo e ha aumentato il rischio di problemi correlati alla disponibilità, alla scalabilità, alle prestazioni, all'usabilità e ai costi dell'applicazione.

Azure Container Storage deriva da OpenEBS, una soluzione open source che offre funzionalità di archiviazione dei contenitori per Kubernetes. Azure Container Storage offre una soluzione di orchestrazione dei volumi gestiti tramite controller di archiviazione basati su microservizi in un ambiente Kubernetes. Questa funzionalità abilita la vera risorsa di archiviazione nativa del contenitore.

Azure Container Storage si adatta ai seguenti scenari:

• Accelerare le iniziative da macchina virtuale a contenitore: Azure Container Storage espone l'intera gamma di offerte di archiviazione a blocchi di Azure che in precedenza erano disponibili solo per le macchine virtuali e le rende disponibili per i contenitori. Questa risorsa di archiviazione include l'archiviazione temporanea su disco, che offre una latenza estremamente bassa per carichi di lavoro come Cassandra. Include anche Elastic SAN, che fornisce destinazioni native iSCSI e provisioning condiviso.

• Semplificare la gestione dei volumi con Kubernetes: Archiviazione container di Azure offre l'orchestrazione dei volumi tramite il piano di controllo di Kubernetes. Questa funzionalità semplifica la distribuzione e la gestione dei volumi all'interno di Kubernetes, senza dover passare da un piano di controllo all'altro.

• Ridurre il costo totale di proprietà: Per migliorare l'efficienza dei costi, aumentare la scalabilità dei volumi persistenti supportati per ogni pod o nodo. Per ridurre le risorse di archiviazione necessarie per il provisioning, condividere dinamicamente le risorse di archiviazione. Il supporto per la scalabilità orizzontale per il pool di archiviazione stesso non è incluso.

Azure Container Storage offre i seguenti vantaggi principali:

• Aumentare rapidamente il numero di pod con stato: Archiviazione Azure Container monta volumi persistenti tramite protocolli di archiviazione a blocchi di rete, ad esempio NVMe-oF o iSCSI. Questa funzionalità garantisce un collegamento rapido e lo scollegamento di volumi persistenti. È possibile iniziare in piccolo e distribuire le risorse in base alle esigenze per garantire che le applicazioni non vengano interrotte o compromesse durante l'inizializzazione o in produzione. Quando un pod viene riavviato nel cluster, il volume persistente associato deve essere spostato rapidamente nel nuovo pod per mantenere la resilienza dell'applicazione. Usando protocolli di rete remoti, Azure Container Storage è strettamente integrato con il ciclo di vita dei pod per supportare applicazioni stateful altamente resilienti e ad alta scalabilità su AKS.

• Migliorare le prestazioni per i carichi di lavoro con stato: Archiviazione contenitore di Azure consente prestazioni di lettura superiori e offre prestazioni di scrittura quasi paragonabili a quelle di un disco con NVMe-oF su RDMA. Questa funzionalità consente di soddisfare in modo conveniente i requisiti di prestazioni per vari carichi di lavoro dei contenitori, tra cui carichi di lavoro di I/O di livello 1, utilizzo generico, sensibile alla velocità effettiva e carichi di lavoro di sviluppo/test. Accelerare i tempi di collegamento e scollegamento dei volumi persistenti e ridurre al minimo il tempo di failover dei pod.

• Orchestrare i volumi nativi di Kubernetes: Creare pool di archiviazione e volumi permanenti, acquisire snapshot e gestire l'intero ciclo di vita dei volumi usando kubectl comandi senza passare da set di strumenti a diverse operazioni del piano di controllo.

Soluzioni per i partner

Come Amazon EKS, il servizio Azure Kubernetes è un'implementazione di Kubernetes ed è possibile integrare soluzioni di archiviazione Kubernetes partner. Ecco alcuni esempi di soluzioni di archiviazione dei partner per Kubernetes:

• Rook trasforma i sistemi di archiviazione distribuiti in servizi di archiviazione auto-gestione automatizzando le attività di amministratore di Archiviazione di Azure. Rook offre i servizi tramite un operatore Kubernetes per ogni provider di archiviazione.

• GlusterFS è un file system di rete scalabile gratuito e open source che usa hardware comune off-the-shelf per creare soluzioni di archiviazione distribuite di grandi dimensioni per attività a elevato utilizzo di dati e larghezza di banda.

• Ceph offre un servizio di archiviazione unificato affidabile e scalabile con interfacce di oggetto, blocco e file da un singolo cluster creato da componenti hardware di base.

• L'archiviazione di oggetti multicloud MinIO consente alle aziende di creare un'infrastruttura dati compatibile con AWS S3 in qualsiasi cloud. Offre un'interfaccia coerente e portabile per i dati e le applicazioni.

• Portworx è una soluzione end-to-end di archiviazione e gestione dei dati per progetti Kubernetes e iniziative basate su contenitori. Portworx offre l'archiviazione granulare del contenitore, il ripristino di emergenza, la sicurezza dei dati e le migrazioni multicloud.

• Quobyte offre archiviazione di file e oggetti ad alte prestazioni che è possibile distribuire in qualsiasi server o cloud per ridimensionare le prestazioni, gestire grandi quantità di dati e semplificare l'amministrazione.

• Ondat offre un livello di archiviazione coerente in qualsiasi piattaforma. È possibile eseguire un database o qualsiasi carico di lavoro permanente in un ambiente Kubernetes senza dover gestire il livello di archiviazione.

Considerazioni sull'archiviazione su Kubernetes

Quando si sceglie una soluzione di archiviazione per Amazon EKS o AKS, prendere in considerazione i fattori seguenti.

Modalità di accesso alle classi di archiviazione

In Kubernetes versione 1.21 e successive, per impostazione predefinita, le classi di archiviazione del servizio Azure Kubernetes e Amazon EKS usano solo driver CSI .

Diversi servizi supportano classi di archiviazione con modalità di accesso diverse.

Provisioning dinamico e statico

Effettuare il provisioning dinamico dei volumi per ridurre il sovraccarico di gestione della creazione statica di volumi persistenti. Impostare un criterio di recupero appropriato per eliminare i dischi inutilizzati quando si eliminano i pod.

Copia di sicurezza

Scegliere uno strumento per eseguire il backup dei dati persistenti. Lo strumento deve corrispondere al tipo di archiviazione, ad esempio snapshot, Backup di Azure, Velero o Kasten.

Ottimizzazione dei costi

Per ottimizzare i costi di Archiviazione di Azure, usare le prenotazioni di Azure se il servizio li supporta. Per altre informazioni, vedere Gestione dei costi per un cluster Kubernetes.

Collaboratori

Microsoft gestisce questo articolo. I collaboratori seguenti hanno scritto questo articolo.

Autori principali:

• Paolo Salvatori | Ingegnere del sistema principale
• Laura Nicolas | Senior Cloud Solution Architect

Altri contributori:

• Chad Kittel | Principal Software Engineer
• Prezzo ed | Senior Content Program Manager
• Theano Petersen | Redattore tecnico

Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.

Passaggi successivi

• Training: Servizi di archiviazione di Azure
• Training: Archiviare i dati in Azure
• Training: Introduzione a Kubernetes
• Training: Introduzione ad Azure NetApp Files

Risorse correlate

• AKS per professionisti di Amazon EKS
• Gestione delle identità e degli accessi Kubernetes
• Monitoraggio e registrazione Kubernetes
• Accesso sicuro alla rete Kubernetes
• Gestione dei costi per Kubernetes
• Gestione del nodo e del pool di nodi Kubernetes
• Governance del cluster