Condividi tramite

Opzioni di archiviazione per un cluster Kubernetes

  • Articolo

Questo articolo confronta le funzionalità di archiviazione di Amazon Elastic Kubernetes Service (Amazon EKS) e servizio Azure Kubernetes (AKS) e descrive le opzioni per archiviare i dati del carico di lavoro nel servizio Azure Kubernetes.

Nota

Questo articolo fa parte di una serie di articoli che aiutano i professionisti che hanno familiarità con Amazon EKS per comprendere servizio Azure Kubernetes (servizio Azure Kubernetes).

Opzioni di archiviazione amazon EKS

Quando si eseguono applicazioni che richiedono l'archiviazione dei dati, Amazon EKS offre diversi tipi di 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 i riavvii, è possibile usare volumi temporanei. Kubernetes supporta diversi tipi di volumi temporanei, ad esempio emptyDir, configMap, downwardAPI, secrete hostPath. Per garantire efficienza e prestazioni dei costi, è importante scegliere il volume host più appropriato. In Amazon EKS, è possibile utilizzare gp3 come volume radice dell'host, il quale offre prezzi più bassi rispetto ai volumi gp2.

Un'altra opzione per i volumi effimeri è gli store di istanze di Amazon EC2, che forniscono un'archiviazione temporanea a livello di blocco per le istanze EC2. Questi volumi sono fisicamente collegati agli host ed esistono solo durante la durata dell'istanza. L'uso dei volumi dell'archivio locale in Kubernetes richiede il partizionamento, la configurazione e la formattazione dei dischi usando Amazon EC2 user-data.

Volumi permanenti

Anche se Kubernetes è in genere associato all'esecuzione di applicazioni senza stato, esistono casi in cui è necessaria l'archiviazione dei dati persistente. i volumi persistenti di Kubernetes (PV) possono essere utilizzati per archiviare i dati in modo indipendente dai pod, consentendo la persistenza dei dati oltre la vita utile di un determinato pod. Amazon EKS supporta diversi tipi di opzioni di archiviazione per i televisori, tra cui Amazon EBS, Amazon EFS, Amazon FSx per Lustree Amazon FSx per NetApp ONTAP.

i volumi di Amazon EBS sono adatti per l'archiviazione di blocco e sono particolarmente idonei per i database e le applicazioni ad alta intensità di throughput. 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 express blocchi io2.

Amazon EFS è un file system elastico e serverless che può essere condiviso tra più container e nodi. Aumenta e si riduce automaticamente man mano che i file vengono aggiunti o rimossi, eliminando la necessità di pianificare la capacità. La driver CSI (Amazon Elastic File System Container Storage Interface) di Amazon Elastic File System viene usata per integrare Amazon EFS con Kubernetes.

Amazon FSx per Lustre offre un'archiviazione file parallela ad alte prestazioni, ideale per scenari che richiedono operazioni a velocità effettiva elevata e bassa latenza. Può essere collegato 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.

Gli utenti di Amazon EKS possono usare strumenti come AWS Compute Optimizer e Velero per ottimizzare le configurazioni di archiviazione e gestire backup e snapshot.

Opzioni di archiviazione AKS

Le applicazioni in esecuzione nel 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. 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.

Questo articolo presenta le opzioni di archiviazione e i concetti di base che offrono capacità di archiviazione alle applicazioni in AKS.

Tipi di volume

I volumi Kubernetes rappresentano più di un semplice disco tradizionale per l'archiviazione e il recupero di informazioni. I volumi Kubernetes possono essere usati anche per inserire dati in un pod, che saranno poi utilizzati dai container.

I tipi di volume comuni in Kubernetes includono EmptyDirs, Secrete 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 nel 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. Queste informazioni verrebbero altrimenti incluse in una specifica Pod o in un'immagine di un contenitore. Usando un segreto, è possibile evitare di incorporare dati riservati direttamente nel codice dell'applicazione. Poiché i segreti possono essere creati indipendentemente dai pod che li usano, esiste un rischio ridotto di esporre il segreto (e i relativi dati) durante i processi di creazione, visualizzazione e modifica dei pod. Kubernetes, insieme alle applicazioni in esecuzione nel cluster, può anche adottare precauzioni aggiuntive con i segreti, ad esempio impedire la scrittura dei dati sensibili nell'archiviazione non volatile. Anche se i segreti sono simili a ConfigMap, sono progettati appositamente per archiviare dati riservati.

È possibile usare i segreti per gli scopi seguenti:

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

ConfigMaps

Un ConfigMap è un oggetto Kubernetes usato per archiviare dati non riservati 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 . Un oggetto ConfigMap consente di separare la configurazione specifica dell'ambiente dalle immagini del contenitore , in modo che le applicazioni siano facilmente portabili.

ConfigMap non fornisce la segretezza o la crittografia. Se i dati che vuoi archiviare sono riservati, usa un Secret anziché un ConfigMap, o usa strumenti aggiuntivi (di terze parti) per mantenere i tuoi dati privati.

È possibile usare un oggetto ConfigMap per impostare i dati di configurazione separatamente dal codice dell'applicazione. Si supponga, ad esempio, di sviluppare un'applicazione che sia possibile eseguire nel proprio computer (per lo sviluppo) e nel cloud (per gestire il traffico reale). Scrivere il codice da cercare in una variabile di ambiente denominata DATABASE_HOST. In locale, si imposta tale variabile su localhost. Nel cloud, puoi impostarlo per fare riferimento a un servizio Kubernetes che espone il componente del database al tuo cluster. In questo modo è possibile recuperare un'immagine del contenitore in esecuzione 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 (PV) è una risorsa di archiviazione creata e gestita dall'API 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:

Come indicato nella sezione Volumi, la scelta di Dischi di Azure o File di Azure è spesso determinata dalla necessità di accedere simultaneamente ai dati o al livello di prestazioni.

Diagramma di volumi permanenti in un cluster del servizio Azure Kubernetes.

Un amministratore del cluster può in modo statico creare un volume permanente oppure creare un volume dinamicamente dal server API Kubernetes. Se un pod è pianificato e richiede l'archiviazione attualmente non disponibile, Kubernetes può creare il disco di Azure o l'archiviazione file sottostante e collegarlo 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.

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. Archiviazione Azure Container si integra con Kubernetes, consentendo il provisioning dinamico e automatico di volumi di dati persistenti. Azure Container Storage supporta i dischi di Azure, i dischi temporanei e la SAN elastica di Azure (in anteprima) come archiviazione di supporto, offrendo flessibilità e scalabilità per le applicazioni stateful in esecuzione 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 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 di 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:

Classe di archiviazione Descrizione
managed-csi Usa l'archiviazione con ridondanza locale dell'unità 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 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 di Azure Premium per creare un disco gestito. Il criterio di recupero garantisce di nuovo che il disco di Azure sottostante venga eliminato quando viene eliminato il volume permanente 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. Il criterio di recupero garantisce che la condivisione file di Azure sottostante venga eliminata quando viene eliminato il volume permanente usato.
azurefile-csi-premium Usa Archiviazione Premium di Azure per creare una condivisione file di Azure. Il criterio di recupero garantisce che la condivisione file di Azure sottostante venga eliminata quando viene eliminato il volume permanente 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. Il criterio di recupero garantisce che il contenitore di archiviazione BLOB di Azure sottostante venga eliminato quando viene eliminato il volume permanente usato.
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 viene eliminato il volume permanente 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, AKS usa driver CSI per impostazione predefinita e la migrazione CSI è abilitata. Anche se i volumi persistenti integrati esistenti continuano a funzionare, a partire dalla versione 1.26, Azure Kubernetes Service non supporterà più i volumi creati utilizzando il driver integrato e l'archiviazione 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 usa ora 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 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 LRS (Archiviazione con ridondanza locale). È quindi possibile utilizzare la nuova classe di archiviazione nella richiesta di volume persistente (PVC).

È 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

Tenere presente che il servizio Azure Kubernetes riconcilia le classi di archiviazione predefinite e sovrascriverà le modifiche apportate a tali classi di archiviazione.

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

Attestazioni di volume persistente

Una Persistent Volume Claim (PVC) 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 una volta che il volume è stato connesso al pod.

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

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 premium gestita e richiede un disco di Azure 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:

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

L'esempio di manifesto YAML seguente illustra come usare il reclamo di volume persistente precedente per montare un volume su /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à. Per esempio:

...      
      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 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.

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 di Azure sulla macchina virtuale. Di seguito sono riportate alcune considerazioni generali sul ridimensionamento:

  • Se si sceglie di utilizzare la dimensione predefinita della macchina virtuale AKS Standard_DS2_v2 SKU con una dimensione del disco del sistema operativo predefinita di 100 GiB, questa macchina virtuale supporta un sistema operativo effimero, ma ha solo 86 GiB di capacità 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, questa configurazione verrà impostata, per impostazione predefinita, come disco OS effimero. 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 di Standard_E2bds_v5 con un disco del sistema operativo da 60 GiB, per impostazione predefinita questa configurazione viene impostata ai dischi del sistema operativo effimeri. La dimensione richiesta di 60 GiB è inferiore alla memoria temporanea massima di 75 GiB.
  • Se si seleziona Standard_E4bds_v5 SKU con disco del sistema operativo 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 su AKS.

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 rendere persistenti i dati tra i pod e il ciclo di vita dell'applicazione.

I volumi tradizionali vengono creati come risorse Kubernetes sostenute dalla piattaforma di archiviazione di Azure. È possibile creare manualmente volumi di dati da assegnare direttamente ai pod o farli creare automaticamente da Kubernetes. I volumi di dati possono usare: 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 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 relativi limiti di capacità dettagliati, vedere dimensioni delle macchine virtuali per utilizzo generico.

Per determinare la soluzione migliore per il carico di lavoro tra File di Azure e Azure NetApp Files, esaminare le informazioni fornite nell'articolo confronto tra File di Azure e Azure NetApp Files.

Azure Disk

Per impostazione predefinita, un cluster AKS viene fornito con classi di archiviazione pre-create managed-csi e managed-csi-premium che usano l'Archiviazione su disco. 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 di dischi consentono il provisioning di volumi statici e dinamici. I criteri di recupero assicurano che il disco venga eliminato con il volume permanente. È possibile espandere il disco modificando l'attestazione del volume permanente.

Queste classi di archiviazione usano dischi gestiti di Azure con l'archiviazione con ridondanza locale. L'archiviazione con ridondanza locale implica che i dati abbiano tre compie sincrone all'interno di un'unica posizione fisica nell'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 di archiviazione con ridondanza di zona. L'archiviazione con ridondanza di zona replica in modo sincrono il disco gestito di Azure tra tre zone di disponibilità di Azure nell'area selezionata. Ogni zona di disponibilità è una posizione fisica separata con alimentazione, raffreddamento e rete indipendenti. I dischi ZRS offrono almeno 99,999999999999% (12 9) di durabilità in un determinato anno. Un disco gestito ZRS può essere collegato da una macchina virtuale in una zona di disponibilità diversa . I dischi ZRS non sono attualmente disponibili in tutte le regioni di Azure. Per maggiori informazioni sui dischi con archiviazione a ridondanza di zona (ZRS), consulta l'opzione ZRS per i dischi di Azure per una maggiore disponibilità. Inoltre, per ridurre il rischio di perdita di dati, è possibile eseguire backup o snapshot regolari dei dati di archiviazione su disco usando backup del servizio Azure Kubernetes o soluzioni di terze parti, ad esempio Velero o di Backup di Azure che possono usare tecnologie snapshot predefinite.

È possibile usare Azure Disk per creare una risorsa DataDisk di Kubernetes . I tipi di dischi includono:

Mancia

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

Poiché un disco di Azure viene 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.

Dischi SSD Premium v2 di Azure

I dischi SSD Premium v2 di Azure offrono carichi di lavoro aziendali intensi da I/O, una latenza del disco submillisecond coerente e un numero elevato di operazioni di I/O al secondo e velocità effettiva. Le prestazioni (capacità, velocità effettiva e operazioni di I/O al secondo) dei dischi SSD Premium v2 possono essere configurate in modo indipendente in qualsiasi momento, semplificando la realizzazione di scenari efficienti a livello di costi, pur soddisfacendo le esigenze di prestazioni. Per maggiori informazioni su come configurare un cluster del servizio Azure Kubernetes nuovo o esistente per l'uso di dischi SSD Premium di Azure v2, consultare la sezione Usare dischi SSD Premium di Azure v2 in servizio Azure Kubernetes.

Archiviazione su disco Ultra

Archiviazione su disco Ultra è un livello di disco gestito di Azure che offre velocità effettiva, un numero elevato di operazioni di I/O al secondo e archiviazione su disco a bassa latenza coerente per VM di Azure. L'archiviazione su disco Ultra è destinata a carichi di lavoro che sono dati e transazioni pesanti. Analogamente ad altri SKU di archiviazione su disco e Amazon EBS, Archiviazione su disco Ultra monta un pod alla volta e non fornisce l'accesso simultaneo.

Usare il flag --enable-ultra-ssd per abilitare l'archiviazione su disco Ultra nel cluster AKS.

Se si sceglie Archiviazione su disco Ultra, valutare le sue limitazioni e assicurarsi di selezionare una dimensione di macchina virtuale compatibile. Archiviazione su disco Ultra è disponibile con la replica di archiviazione con ridondanza locale.

Bring Your Own Key (BYOK)

Azure crittografa tutti i dati inattivi in un disco gestito. Per impostazione predefinita, i dati vengono crittografati con chiavi gestite da Microsoft. Per un maggiore controllo sulle chiavi di crittografia, è possibile fornire chiavi gestite dal cliente da usare per la crittografia dei dati inattivi sia per il sistema operativo sia per i dischi dati per i cluster del servizio Azure Kubernetes. Per maggiori informazioni, consultare la sezione Bring Your Own Keys (BYOK) con Azure Managed Disks nel servizio Azure Kubernetes.

File di Azure

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 (Network File System) versione 4.1 supportata da Archiviazione di Azure. Questo processo fornisce una risorsa di archiviazione collegata alla rete simile a Amazon EFS. Come per l'archiviazione su disco, sono disponibili due opzioni:

  • File di Azure l'archiviazione Standard è supportata da normali unità disco rigido (HDD).
  • File di Azure Archiviazione Premium esegue il backup della condivisione file con unità SSD ad alte prestazioni. La dimensione minima della condivisione file per Premium è 100 GB.

File di Azure sono disponibili le opzioni di replica dell'account di archiviazione seguenti per proteggere i dati in caso di errore:

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

Azure NetApp Files

di Azure NetApp Files è un servizio di archiviazione file a consumo di livello aziendale e a prestazioni elevate in esecuzione in Azure e supporta volumi che usano NFS (NFSv3 o NFSv4.1), SMBe a doppio protocollo (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 staticamente volumi di Azure NetApp Files . In questo scenario la creazione di volumi è esterna ad AKS. I volumi vengono creati usando l'interfaccia della riga di comando di Azure o dal portale di Azure e quindi vengono esposti a Kubernetes tramite la creazione di un PersistentVolume. I volumi di Azure NetApp Files creati in modo statico presentano molte limitazioni, ad esempio l'impossibilità di espandersi, la necessità di eseguire il provisioning eccessivo e così via. I volumi creati in modo statico non sono consigliati per la maggior parte dei casi d'uso.
  • Creare dinamicamente volumi di Azure NetApp Files , orchestrando attraverso Kubernetes. Questo metodo è il modo preferito per creare più volumi direttamente tramite Kubernetes e viene ottenuto 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 altre informazioni, vedere Configurare Azure NetApp Files per il servizio Azure Kubernetes.

Archiviazione BLOB di Azure

Il driver di interfaccia di archiviazione dei contenitori (CSI) di Azure Blob Storage è un driver conforme alla specifica CSI utilizzato dal servizio Azure Kubernetes (AKS) per gestire il ciclo di vita dell'archiviazione Blob di Azure. CSI è uno standard per esporre sistemi di archiviazione a blocchi e file arbitrari a carichi di lavoro containerizzati su Kubernetes.

Adottando e utilizzando CSI, AKS ora può scrivere, distribuire e iterare i plug-in per esporre nuovi sistemi di archiviazione o migliorare quelli esistenti in Kubernetes. L'uso dei driver CSI in AKS evita la necessità di modificare il codice principale di Kubernetes e aspettare i suoi cicli di rilascio.

Quando si monta l'archiviazione BLOB di Azure come file system in un contenitore o in un pod, consente di usare l'archiviazione BLOB con una serie di applicazioni che gestiscono enormi quantità di dati non strutturati. Per esempio:

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

È possibile accedere ai dati nell'archivio oggetti tramite le applicazioni BlobFuse o il protocollo NFS (Network File System) 3.0. Prima dell'introduzione del driver CSI di archiviazione blob di Azure, l'unica opzione consisteva nell'installare manualmente un driver non supportato per accedere all'archiviazione blob dall'applicazione in esecuzione nel servizio Azure Kubernetes. Quando il driver CSI di Azure Blob storage è abilitato su AKS, sono disponibili due classi di archiviazione predefinite: azureblob-fuse-premium e azureblob-nfs-premium.

Per creare un cluster AKS con il supporto dei driver CSI, vedere driver CSI su AKS. Per altre informazioni sulle differenze di accesso tra ognuno dei tipi di archiviazione di Azure usando il protocollo NFS, vedere Confrontare l'accesso a File di Azure, Archiviazione BLOB e Azure NetApp Files con NFS.

Cache HPC di Azure

Azure Cache HPC velocizza l'accesso ai dati per le attività HPC, con tutta la scalabilità delle soluzioni cloud. Se si sceglie questa soluzione di archiviazione, assicurarsi di distribuire il cluster AKS in un'are che supporta cache HPC di Azure.

Server NFS

L'opzione migliore per l'accesso NFS condiviso consiste nell'usare File di Azure o Azure NetApp Files. È anche possibile creare un server NFS in una VM di Azure che esporta volumi.

Tenere presente che questa opzione supporta solo il provisioning statico. È necessario effettuare manualmente il provisioning delle condivisioni NFS nel server e non eseguire questa operazione dal servizio Azure Kubernetes automaticamente.

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

Porta Le Tue Chiavi (BYOK) con dischi di Azure

Azure Storage crittografa tutti i dati inattivi in un account di archiviazione, 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 di crittografia, è possibile fornire chiavi gestite dal cliente da usare per la crittografia a riposo dei dischi del sistema operativo e dei dati nei cluster del servizio Azure Kubernetes (AKS). Per altre informazioni, vedi:

Azure Container Storage

Archiviazione di Azure Container è un servizio di gestione, distribuzione e orchestrazione basato sul cloud creato in modo nativo per i contenitori. Si integra con Kubernetes e consente di effettuare in modo dinamico e automatico il provisioning di volumi persistenti per archiviare dati per le applicazioni con stato in esecuzione nei cluster Kubernetes.

Archiviazione contenitori di Azure usa le offerte di Archiviazione di Azure esistenti per l'archiviazione dei dati effettiva, offrendo una soluzione di orchestrazione e gestione dei volumi creata appositamente per i contenitori. Le opzioni di archiviazione di backup supportate includono:

  • Dischi di Azure: controllo granulare degli SKU e delle configurazioni di archiviazione. Sono adatti per i database di livello 1 e per utilizzo generico.
  • Dischi temporanei: usa le risorse di archiviazione locale nei nodi del servizio Azure Kubernetes (NVMe o SSD temporaneo). Ideale per le applicazioni senza requisiti di durabilità dei dati o con supporto predefinito per la replica dei dati. Il servizio Azure Kubernetes individua l'archiviazione temporanea disponibile nei nodi del servizio Azure Kubernetes e la acquisisce per la distribuzione del volume.
  • Azure Elastic SAN: effettua il provisioning di una risorsa completamente gestita su richiesta. Adatto per database generici, servizi di streaming e messaggistica, ambienti CD/CI e altri carichi di lavoro di livello 1/livello 2. Più cluster possono accedere a una singola SAN contemporaneamente, tuttavia i volumi permanenti possono essere collegati solo da un utente alla volta.

Fino ad ora, la fornitura di archiviazione cloud per i container richiedeva l'utilizzo di driver CSI (Container Storage Interface) individuali per utilizzare i servizi di storage destinati ai carichi di lavoro incentrati sull'infrastruttura distribuita come servizio (IaaS) e farli funzionare per i container. In questo modo si crea un sovraccarico operativo e si aumenta il rischio di problemi relativi alla disponibilità dell'applicazione, alla scalabilità, alle prestazioni, all'usabilità e ai costi.

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 di volumi gestiti tramite controller di archiviazione basati su microservizi in un ambiente Kubernetes e dà vita a una vera archiviazione nativa del contenitore.

Archiviazione contenitori di Azure è adatta negli scenari seguenti:

  • 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. Ciò include un disco temporaneo che offre una latenza estremamente bassa per carichi di lavoro come Cassandra, nonché SAN di Elastic in Azure che fornisce destinazioni native iSCSI e con provisioning condiviso.

  • Semplificare la gestione dei volumi con Kubernetes: fornendo l'orchestrazione del volume tramite il piano di controllo Kubernetes, Azure Container Storage semplifica la distribuzione e la gestione dei volumi all'interno di Kubernetes, senza la necessità di spostarsi tra piani di controllo diversi.

  • Ridurre il costo totale di proprietà (TCO): migliorare l'efficienza dei costi aumentando la scalabilità dei volumi persistenti supportati per ogni pod o nodo. Ridurre le risorse di archiviazione necessarie per il provisioning condividendo in modo dinamico le risorse di archiviazione. Si noti che il supporto per l'aumento delle prestazioni per il pool di archiviazione stesso non è fornito.

Archiviazione contenitori di Azure offre i vantaggi principali seguenti:

  • Aumento rapido dei pod con stato: Azure Container Storage monta volumi persistenti su protocolli di archiviazione a blocchi di rete (NVMe-oF o iSCSI), offrendo collegamento e scollegamento rapidi di volumi persistenti. È possibile iniziare in piccolo e distribuire risorse di piccole dimensioni in base alle esigenze, assicurandosi che le applicazioni non vengano interrotte o non abbiano carenza di risorse durante l'inizializzazione o nell'ambiente di produzione. La resilienza delle applicazioni è stata migliorata con i respawn dei pod nel cluster, richiedendo un rapido spostamento dei volumi persistenti. Usando i protocolli di rete remoti, Archiviazione contenitori di Azure si associa strettamente al ciclo di vita dei pod per supportare applicazioni con stato altamente resilienti e su larga scala in AKS.

  • Prestazioni migliorate per i carichi di lavoro con stato: Azure Container Storage consente prestazioni di lettura superiori e offre prestazioni di scrittura quasi simili a quelle su disco usando NVMe-oF su RDMA. Ciò consente ai clienti di soddisfare in modo conveniente i requisiti di prestazioni per vari carichi di lavoro dei contenitori, tra cui il livello 1 a I/O intensivo, l'utilizzo generico, quello sensibile alla velocità effettiva e quello di sviluppo/test. Accelerare il tempo di collegamento/scollegamento dei volumi persistenti e ridurre al minimo il tempo di failover dei pod.

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

Soluzioni di terze parti

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

  • Rook trasforma i sistemi di archiviazione distribuiti in servizi di archiviazione auto-gestione automatizzando le attività di amministratore dell'archiviazione. 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 oggetti, blocchi 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, offrendo 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 risorse di archiviazione granulari per i contenitori, ripristino di emergenza, sicurezza dei dati e migrazioni multicloud.
  • Quobyte offre archiviazione 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 kubernetes

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

Modalità di accesso alle classi di archiviazione

Per impostazione predefinita, in Kubernetes, versione 1.21 e successive, le classi di archiviazione AKS e Amazon EKS usano solo i driver CSI (Container Storage Interface).

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

Service ReadWriteOnce ReadOnlyMany ReadWriteMany
Dischi di Azure X
File di Azure X X X
Azure NetApp Files X X X
Server NFS X X X
Cache HPC di Azure X X X

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 corretto per evitare la presenza di dischi inutilizzati quando si eliminano i pod.

Backup

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. Assicurarsi di controllare quali servizi supportano le prenotazioni di Azure. Consultare anche la sezione Gestione dei costi per un cluster Kubernetes.

Collaboratori

Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.

Autori principali:

Altri contributori:

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

Passaggi successivi