Usare il Driver Container Storage Interface (CSI) di Archiviazione BLOB di Azure

  • Articolo

Il driver CSI (Container Storage Interface) di archiviazione BLOB di Azure è un driver conforme alla specifica CSI usato dal servizio Azure Kubernetes per gestire il ciclo di vita dell’archiviazione BLOB di Azure. CSI è uno standard per esporre sistemi di archiviazione file e a blocchi arbitrari a carichi di lavoro in contenitori in Kubernetes.

Adottando e usando CSI, il servizio Azure Kubernetes può ora scrivere, distribuire e eseguire l'iterazione dei plug-in per esporre nuovi sistemi di archiviazione o migliorare i sistemi di archiviazione esistenti in Kubernetes. L'uso dei driver CSI nel servizio Azure Kubernetes consente di evitare modifiche al codice Kubernetes principale e di attendere i 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 elaborano enormi quantità di dati non strutturati. Ad 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 il protocollo BlobFuse o Network File System (NFS) 3.0. Prima dell'introduzione del driver CSI di Archiviazione BLOB di Azure, l'unica opzione consiste 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 Archiviazione BLOB di Azure è abilitato nel servizio Azure Kubernetes, sono disponibili due classi di archiviazione predefinite: azureblob-fuse-premium e azureblob-nfs-premium.

Per creare un cluster del servizio Azure Kubernetes con il supporto per i driver CSI, vedere Driver CSI nel servizio Azure Kubernetes. 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.

Funzionalità del driver CSI di Archiviazione BLOB di Azure

Il driver CSI di Archiviazione BLOB di Azure supporta le funzionalità seguenti:

  • Protocollo BlobFuse e Network File System (NFS) versione 3.0

Operazioni preliminari

  • Assicurarsi che sia installata e configurata l'interfaccia della riga di comando di Azure versione 2.42 o successiva. Eseguire az --version per trovare la versione. Se è necessario eseguire l'installazione o l'aggiornamento, vedere Installare l'interfaccia della riga di comando di Azure. Se è stata installata l'estensione dell'interfaccia della riga di comando di Azure aks-preview, assicurarsi di aggiornare l'estensione alla versione più recente chiamando az extension update --name aks-preview.

  • Eseguire i passaggi descritti in questo collegamento se in precedenza è stato installato il driver open source di archiviazione BLOB CSI per accedere all'archiviazione BLOB di Azure dal cluster.

Nota

Se blobfuse-proxy non è abilitato durante l'installazione del driver open source, la disinstallazione del driver open source interromperà i montaggi blobfuse esistenti. Tuttavia, i montaggi NFS rimarranno invariati.

Abilitare il driver CSI in un cluster del servizio Azure Kubernetes nuovo o esistente

Usando l'interfaccia della riga di comando di Azure, è possibile abilitare il driver CSI dell'archiviazione BLOB in un cluster del servizio Azure Kubernetes nuovo o esistente prima di configurare un volume permanente per l'uso da parte dei pod nel cluster.

Per abilitare il driver in un nuovo cluster, includere il parametro --enable-blob-driver con il comando az aks create come illustrato nell'esempio seguente:

az aks create \
    --enable-blob-driver \
    --name myAKSCluster \
    --resource-group myResourceGroup \
    --generate-ssh-keys

Per abilitare il driver in un nuovo cluster, includere il parametro --enable-blob-driver con il comando az aks update come illustrato nell'esempio seguente:

az aks update --enable-blob-driver --name myAKSCluster --resource-group myResourceGroup

Viene richiesto di verificare che non sia installato un driver CSI BLOB open source. Dopo la conferma, per il completamento di questa azione possono essere necessari alcuni minuti. Una volta completata, nell'output visualizzerai lo stato dell'abilitazione del driver nel cluster. L'esempio seguente è simile alla sezione che indica i risultati del comando precedente:

"storageProfile": {
    "blobCsiDriver": {
      "enabled": true
    },

Disabilitare il driver CSI in un cluster del servizio Azure Kubernetes esistente

Usando l'interfaccia della riga di comando di Azure, è possibile disabilitare il driver CSI dell'archiviazione BLOB in un cluster del servizio Azure Kubernetes esistente dopo aver rimosso il volume permanente dal cluster.

Per disabilitare il driver in un nuovo cluster, includere il parametro --disable-blob-driver con il comando az aks update come illustrato nell'esempio seguente:

az aks update --disable-blob-driver --name myAKSCluster --resource-group myResourceGroup

Usare un volume permanente con Archiviazione BLOB di Azure

Un volume permanente (PV) rappresenta una parte di spazio di archiviazione di cui viene effettuato il provisioning per l'uso con i pod Kubernetes. Un volume permanente può essere usato da uno o più pod e se ne può effettuare il provisioning in modo dinamico o in modo statico. Se più pod necessitano di accesso simultaneo allo stesso volume di archiviazione, è possibile usare l’archiviazione BLOB di Azure per connettersi usando Network File System (NFS) o blobfuse. Questo articolo illustra come creare dinamicamente un contenitore di archiviazione BLOB di Azure per l'uso da parte di più pod in un cluster del servizio Azure Kubernetes.

Per altre informazioni sui volumi Kubernetes, vedere Opzioni di archiviazione per le applicazioni nel servizio Azure Kubernetes.

Creare in modo dinamico volumi permanenti di archiviazione BLOB di Azure usando le classi di archiviazione predefinite

Viene usata una classe di archiviazione per definire la modalità di creazione di un contenitore di archiviazione BLOB di Azure. Nel gruppo di risorse nodo viene creato automaticamente un account di archiviazione da usare insieme alla classe di archiviazione per contenere il contenitore di archiviazione BLOB di Azure. Scegliere uno degli SKU di ridondanza di archiviazione di Azure seguenti per skuName:

  • Standard_LRS: archiviazione con ridondanza locale Standard
  • Premium_LRS: archiviazione con ridondanza locale Premium.
  • Standard_ZRS: archiviazione con ridondanza della zona Standard
  • Premium_ZRS: archiviazione con ridondanza della zona Premium
  • Standard_GRS: archiviazione con ridondanza geografica Standard
  • Standard_RAGRS: archiviazione con ridondanza geografica e accesso in lettura Standard

Quando si usano i driver CSI di archiviazione nel servizio Azure Kubernetes, sono disponibili due classi di archiviazione predefinite aggiuntive che usano il driver di archiviazione CSI BLOB di Azure.

Il criterio di recupero in entrambe le classi di archiviazione garantisce che l'archivio BLOB di Azure sottostante venga eliminato quando viene eliminato il rispettivo volume permanente. Le classi di archiviazione configurano anche il contenitore per essere espandibili per impostazione predefinita, perché il parametro set allowVolumeExpansion è impostato su vero.

Nota

La compattazione dei volumi permanenti non è supportata.

Usare il comando kubectl get sc per visualizzare le classi di archiviazione. L'esempio seguente illustra la creazione preliminare di classi di archiviazione azureblob-fuse-premium e azureblob-nfs-premium all'interno di un cluster servizio Azure Kubernetes:

NAME                                  PROVISIONER       RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION     AGE
azureblob-fuse-premium               blob.csi.azure.com   Delete          Immediate              true                   23h
azureblob-nfs-premium                blob.csi.azure.com   Delete          Immediate              true                   23h

Per usare queste classi di archiviazione, creare un'attestazione di volume permanente e i rispettivi pod che vi fanno riferimento e le usano. Un'attestazione di volume permanente viene usata per effettuare automaticamente il provisioning dell'archiviazione in base a una classe di archiviazione. Un'attestazione di volume permanente può usare una delle classi di archiviazione già create o una classe di archiviazione definita dall'utente per creare un contenitore di archiviazione BLOB di Azure per lo SKU, le dimensioni e il protocollo desiderati per comunicare con esso. Quando si crea una definizione di pod, l'attestazione di volume permanente viene specificata per richiedere lo spazio di archiviazione desiderato.

Uso di un oggetto StatefulSet

Per rendere persistente un volume di archiviazione per il carico di lavoro, è possibile usare un oggetto StatefulSet. In questo modo è più semplice associare i volumi esistenti ai nuovi pod che sostituiscono eventuali errori. Gli esempi seguenti illustrano come configurare un oggetto StatefulSet per l'archiviazione BLOB usando Blobfuse o il protocollo NFS.

Prerequisiti

  • L'identità del piano di controllo del cluster del servizio Azure Kubernetes, ovvero il nome del cluster del servizio Azure Kubernetes, viene aggiunta al ruolo Collaboratore nella rete virtuale e in NetworkSecurityGroup.

  1. Creare un file denominato azure-blob-nfs-ss.yaml e copiarlo nel codice YAML seguente.

    apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-blob-nfs
  labels:
    app: nginx
spec:
  serviceName: statefulset-blob-nfs
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
        - name: statefulset-blob-nfs
          image: mcr.microsoft.com/oss/nginx/nginx:1.22
          volumeMounts:
            - name: persistent-storage
              mountPath: /mnt/blob
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  volumeClaimTemplates:
    - metadata:
        name: persistent-storage
      spec:
        storageClassName: azureblob-nfs-premium
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 100Gi

  2. Creare StatefulSet con il comando kubectl create:

    kubectl create -f azure-blob-nfs-ss.yaml

Passaggi successivi