Usare il driver CSI (Container Storage Interface) di File di Azure nel servizio Azure Kubernetes

Il driver CSI (Container Storage Interface) di File di Azure è un driver conforme alla specifica CSI usato dal servizio Azure Kubernetes per gestire il ciclo di vita delle condivisioni file 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.

Per creare un cluster del servizio Azure Kubernetes con il supporto per i driver CSI, vedere Abilitare i driver CSI nel servizio Azure Kubernetes.

Nuove funzionalità del driver CSI di File di Azure

Oltre alle funzionalità originali del driver nella struttura, il driver CSI di File di Azure supporta le nuove funzionalità seguenti:

• NFS (Network File System) versione 4.1
• Endpoint privato
• Creazione di un montaggio di grandi dimensioni di condivisioni file in parallelo.

Usare un volume permanente con File di Azure

Un volume permanente 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 File di Azure per connettersi usando il protocollo Server Message Block (SMB) o il protocollo NFS. Questo articolo illustra come creare in modo dinamico una condivisione di file di Azure per l'uso da più pod in un cluster del servizio Azure Kubernetes. Per il provisioning statico, vedere Creare e usare manualmente un volume con una condivisione di File di Azure.

Con le condivisioni di File di Azure non esiste alcun limite per il numero di montaggio in un nodo.

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

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

Una classe di archiviazione permette di definire come creare una condivisione file di Azure. Nel gruppo di risorse del nodo viene creato automaticamente un account di archiviazione da usare insieme alla classe di archiviazione per contenere le condivisioni file di Azure. Scegliere uno degli SKU di ridondanza di archiviazione di Azure seguenti per skuName:

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

Quando si usano i driver CSI di archiviazione nel servizio Azure Kubernetes, sono disponibili due StorageClasses predefinite che usano i driver di archiviazione CSI di File di Azure. Le altre classi di archiviazione CSI vengono create con il cluster insieme alle classi di archiviazione predefinite nella struttura.

• azurefile-csi: usa Archiviazione Standard di Azure per creare una condivisione file di Azure.
• azurefile-csi-premium: usa Archiviazione Premium di Azure per creare una condivisione file di Azure.

Il criterio di recupero in entrambe le classi di archiviazione garantisce che la condivisione file di Azure sottostante venga eliminata quando viene eliminato il rispettivo volume permanente. Le classi di archiviazione configurano anche le condivisioni file in modo che siano espandibili. È sufficiente modificare l'attestazione di volume permanente con le nuove dimensioni.

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 una condivisione file di Azure per lo SKU e le dimensioni desiderate. Quando si crea una definizione di pod, l'attestazione di volume permanente viene specificata per richiedere lo spazio di archiviazione desiderato.

Creare un'attestazione di volume permanente di esempio e un pod che stampa la data corrente in un outfile eseguendo i comandi kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/pvc-azurefile-csi.yaml
kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/nginx-pod-azurefile.yaml

L'output del comando è simile all'esempio seguente:

persistentvolumeclaim/pvc-azurefile created
pod/nginx-azurefile created

Quando il pod risulta in esecuzione, è possibile verificare che la condivisione file sia montata correttamente eseguendo il comando seguente e verificando che l'output contenga outfile:

kubectl exec nginx-azurefile -- ls -l /mnt/azurefile

L'output del comando è simile all'esempio seguente:

total 29
-rwxrwxrwx 1 root root 29348 Aug 31 21:59 outfile

Creare una classe di archiviazione personalizzata

Le classi di archiviazione predefinite soddisfano gli scenari più comuni, ma non tutti. Per alcuni casi, potrebbe essere necessario personalizzare la propria classe di archiviazione con i propri parametri. Ad esempio, usare il manifesto seguente per configurare mountOptions della condivisione file.

Il valore predefinito per fileMode e dirMode è 0777 per le condivisioni file montate in Kubernetes. È possibile specificare le diverse opzioni di montaggio nell'oggetto classe di archiviazione.

Creare un file denominato azure-file-sc.yaml e incollare il manifesto di esempio seguente:

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: my-azurefile
provisioner: file.csi.azure.com
reclaimPolicy: Delete
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0640
  - file_mode=0640
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict # https://linux.die.net/man/8/mount.cifs
  - nosharesock
parameters:
  skuName: Standard_LRS

Creare la classe di archiviazione eseguendo il comando kubectl apply:

kubectl apply -f azure-file-sc.yaml

L'output del comando è simile all'esempio seguente:

storageclass.storage.k8s.io/my-azurefile created

Il driver CSI di File di Azure supporta la creazione di snapshot di volumi permanenti e delle condivisioni file sottostanti.

Creare una classe snapshot del volume con il comando kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshotclass-azurefile.yaml

L'output del comando è simile all'esempio seguente:

volumesnapshotclass.snapshot.storage.k8s.io/csi-azurefile-vsc created

Creare uno snapshot del volume dall'attestazione di volume permanente creata dinamicamente all'inizio di questa esercitazione, pvc-azurefile.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/snapshot/volumesnapshot-azurefile.yaml

L'output del comando è simile all'esempio seguente:

volumesnapshot.snapshot.storage.k8s.io/azurefile-volume-snapshot created

Verificare che lo snapshot sia stato creato correttamente eseguendo il comando seguente:

kubectl describe volumesnapshot azurefile-volume-snapshot

L'output del comando è simile all'esempio seguente:

Name:         azurefile-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1beta1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T22:37:41Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  955091
  Self Link:         /apis/snapshot.storage.k8s.io/v1beta1/namespaces/default/volumesnapshots/azurefile-volume-snapshot
  UID:               c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azurefile
  Volume Snapshot Class Name:      csi-azurefile-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-c359a38f-35c1-4fb1-9da9-2c06d35ca0f4
  Ready To Use:                        false
Events:                                <none>

Ridimensionare un volume permanente

È possibile richiedere un volume più grande per un PVC. Modificare l'oggetto PVC e specificare una dimensione maggiore. Questa modifica attiva l'espansione del volume sottostante che restituisce il PV.

Nel servizio Azure Kubernetes la classe di archiviazione azurefile-csi predefinita supporta già l'espansione, quindi usare l'attestazione di volume permanente creata in precedenza con questa classe di archiviazione. L'attestazione di volume permanente ha richiesto una condivisione file di 100 GiB. È possibile confermarlo eseguendo:

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile

L'output del comando è simile all'esempio seguente:

Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  100G  128K  100G   1% /mnt/azurefile

Espandere l'attestazione di volume permanente aumentando il campo spec.resources.requests.storage:

kubectl patch pvc pvc-azurefile --type merge --patch '{"spec": {"resources": {"requests": {"storage": "200Gi"}}}}'

L'output del comando è simile all'esempio seguente:

persistentvolumeclaim/pvc-azurefile patched

Verificare che sia l'attestazione di volume permanente sia il file system all'interno del pod visualizzino le nuove dimensioni:

kubectl get pvc pvc-azurefile
NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS    AGE
pvc-azurefile   Bound    pvc-5e5d9980-da38-492b-8581-17e3cad01770   200Gi      RWX            azurefile-csi   64m

kubectl exec -it nginx-azurefile -- df -h /mnt/azurefile
Filesystem                                                                                Size  Used Avail Use% Mounted on
//f149b5a219bd34caeb07de9.file.core.windows.net/pvc-5e5d9980-da38-492b-8581-17e3cad01770  200G  128K  200G   1% /mnt/azurefile

Usare un volume permanente con l'archiviazione privata di File di Azure (endpoint privato)

Se le risorse di File di Azure sono protette con un endpoint privato, è necessario creare una classe di archiviazione personalizzata. Assicurarsi di aver configurato le impostazioni DNS per risolvere l'indirizzo IP dell'endpoint privato nel nome di dominio completo della stringa di connessione. Personalizzare i parametri seguenti:

• resourceGroup: gruppo di risorse in cui viene distribuito l'account di archiviazione.
• storageAccount: nome dell'account di archiviazione.
• server: nome di dominio completo dell'endpoint privato dell'account di archiviazione.

Creare un file denominato private-azure-file-sc.yaml e quindi incollare il manifesto di esempio seguente nel file. Sostituire i valori per <resourceGroup> e <storageAccountName>.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: private-azurefile-csi
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  resourceGroup: <resourceGroup>
  storageAccount: <storageAccountName>
  server: <storageAccountName>.file.core.windows.net
reclaimPolicy: Delete
volumeBindingMode: Immediate
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=0
  - gid=0
  - mfsymlinks
  - cache=strict  # https://linux.die.net/man/8/mount.cifs
  - nosharesock  # reduce probability of reconnect race
  - actimeo=30  # reduce latency for metadata-heavy workload

Creare la classe di archiviazione usando il comando kubectl apply:

kubectl apply -f private-azure-file-sc.yaml

L'output del comando è simile all'esempio seguente:

storageclass.storage.k8s.io/private-azurefile-csi created

Creare un file denominato private-pvc.yaml e quindi incollare il manifesto di esempio seguente nel file:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: private-azurefile-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: private-azurefile-csi
  resources:
    requests:
      storage: 100Gi

Creare l'attestazione di volume permanente usando il comando kubectl apply:

kubectl apply -f private-pvc.yaml

Condivisioni file NFS

File di Azure supporta il protocollo NFS v4.1. Il supporto di NFS versione 4.1 per File di Azure offre un file system NFS completamente gestito come servizio basato su una piattaforma di archiviazione resiliente distribuita a disponibilità elevata e altamente durevole.

Questa opzione è ottimizzata per carichi di lavoro ad accesso casuale con aggiornamenti dei dati sul posto e offre supporto completo per il file system POSIX. Questa sezione illustra come usare condivisioni NFS con il driver CSI di File di Azure in un cluster del servizio Azure Kubernetes.

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.
• L'entità servizio del cluster o l'identità del servizio gestita (MSI) del servizio Azure Kubernetes deve essere aggiunta al ruolo Collaboratore all'account di archiviazione.

Ottimizzazione delle opzioni di lettura e scrittura

Questa sezione fornisce informazioni su come gestire l'ottimizzazione delle prestazioni di NFS con il driver CSI di File di Azure con le opzioni rsize e wsize. Le opzioni rsize e wsize impostano le dimensioni massime di trasferimento di un'operazione NFS. Se rsize o wsize non sono specificati durante il montaggio, il client e il server negoziano le dimensioni massime supportate dalle due opzioni. Attualmente, sia Azure NetApp Files sia le distribuzioni Linux moderne supportano dimensioni di lettura e scrittura fino a 1.048.576 byte (1 MiB).

Le prestazioni ottimali si basano su una comunicazione efficiente tra client e server. L'aumento o la riduzione dei valori delle dimensioni delle opzioni di lettura e scrittura per mount possono migliorare le prestazioni di NFS. Le dimensioni predefinite dei pacchetti di lettura/scrittura trasferiti tra client e server sono 8 KB per NFS versione 2 e 32 KB per NFS versione 3 e 4. Queste impostazioni predefinite possono essere troppo grandi o troppo piccole. La riduzione di rsize e wsize potrebbe migliorare le prestazioni di NFS in una rete congestionata inviando pacchetti più piccoli per ogni risposta di lettura e richiesta di scrittura di NFS. Questo può tuttavia aumentare il numero di pacchetti necessari per inviare dati attraverso la rete, aumentando il traffico di rete totale e l'utilizzo della CPU nel client e nel server.

È importante eseguire test per trovare un valore per rsize e wsize che supporta il trasferimento efficiente di pacchetti, senza riduzione della velocità effettiva e aumento della latenza.

Per altre informazioni sull'ottimizzazione di rsize e wsize, vedere Procedure consigliate per le opzioni di montaggio NFS Linux per Azure NetApp Files.

Ad esempio, per configurare un valore massimo per rsize e wsize pari a 256 KiB, configurare mountOptions nella classe di archiviazione come segue:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30
  - rsize=262144
  - wsize=262144

Creare una classe di archiviazione di condivisione file NFS

Creare un file denominato nfs-sc.yaml e copiare il manifesto seguente. Per un elenco di mountOptionssupportate, vedere Opzioni di montaggio NFS.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile-csi-nfs
provisioner: file.csi.azure.com
allowVolumeExpansion: true
parameters:
  protocol: nfs
mountOptions:
  - nconnect=4
  - noresvport
  - actimeo=30

Dopo aver modificato e salvato il file, creare la classe di archiviazione con il comando kubectl apply:

kubectl apply -f nfs-sc.yaml

L'output del comando è simile all'esempio seguente:

storageclass.storage.k8s.io/azurefile-csi-nfs created

Creare una distribuzione con una condivisione file supportata da NFS

È possibile distribuire un set con stato di esempio che salva i timestamp in un file data.txt con il comando kubectl apply:

kubectl apply -f

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: statefulset-azurefile
  labels:
    app: nginx
spec:
  podManagementPolicy: Parallel  # default is OrderedReady
  serviceName: statefulset-azurefile
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
    spec:
      nodeSelector:
        "kubernetes.io/os": linux
      containers:
        - name: statefulset-azurefile
          image: mcr.microsoft.com/oss/nginx/nginx:1.19.5
          command:
            - "/bin/bash"
            - "-c"
            - set -euo pipefail; while true; do echo $(date) >> /mnt/azurefile/outfile; sleep 1; done
          volumeMounts:
            - name: persistent-storage
              mountPath: /mnt/azurefile
  updateStrategy:
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  volumeClaimTemplates:
    - metadata:
        name: persistent-storage
      spec:
        storageClassName: azurefile-csi-nfs
        accessModes: ["ReadWriteMany"]
        resources:
          requests:
            storage: 100Gi

L'output del comando è simile all'esempio seguente:

statefulset.apps/statefulset-azurefile created

Convalidare il contenuto del volume eseguendo il comando seguente:

kubectl exec -it statefulset-azurefile-0 -- df -h

L'output del comando è simile all'esempio seguente:

Filesystem      Size  Used Avail Use% Mounted on
...
/dev/sda1                                                                                 29G   11G   19G  37% /etc/hosts
accountname.file.core.windows.net:/accountname/pvc-fa72ec43-ae64-42e4-a8a2-556606f5da38  100G     0  100G   0% /mnt/azurefile
...

Contenitori Windows

Il driver CSI di File di Azure supporta anche i nodi e i contenitori Windows. Per usare i contenitori Windows, seguire la Guida introduttiva per contenitori di Windows per aggiungere un pool di nodi Windows.

Dopo aver creato un pool di nodi Windows, usare le classi di archiviazione predefinite, ad esempio azurefile-csi, o crearne una personalizzata. È possibile distribuire un set con stato basato su Windows di esempio che salva i timestamp in un file data.txt eseguendo il comando kubectl apply:

kubectl apply -f https://raw.githubusercontent.com/kubernetes-sigs/azurefile-csi-driver/master/deploy/example/windows/statefulset.yaml

L'output del comando è simile all'esempio seguente:

statefulset.apps/busybox-azurefile created

Convalidare il contenuto del volume eseguendo il comando kubectl exec seguente:

kubectl exec -it busybox-azurefile-0 -- cat c:\\mnt\\azurefile\\data.txt # on Linux/MacOS Bash
kubectl exec -it busybox-azurefile-0 -- cat c:\mnt\azurefile\data.txt # on Windows Powershell/CMD

L'output del comando è simile all'esempio seguente:

2020-08-27 22:11:01Z
2020-08-27 22:11:02Z
2020-08-27 22:11:04Z
(...)

Passaggi successivi

• Per informazioni su come usare il driver CSI per Dischi di Azure, vedere Usare Dischi di Azure con il driver CSI.
• Per informazioni su come usare il driver CSI per l'archiviazione BLOB di Azure, vedere Usare l'archiviazione BLOB di Azure con il driver CSI.
• Per altre informazioni sulle procedure consigliate per l'archiviazione, vedere Procedure consigliate per l'archiviazione e i backup nel servizio Azure Kubernetes.