Condividi tramite

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

  • Articolo

Il driver CSI (Container Storage Interface) di dischi di Azure è un driver conforme alla specifica CSI usato dal servizio Azure Kubernetes per gestire il ciclo di vita dei dischi 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 il driver CSI nel servizio Azure Kubernetes. Questo articolo descrive come usare il driver CSI del disco di Azure versione 1.

Nota

Il driver CSI del disco di Azure v2 (anteprima) migliora la scalabilità e riduce la latenza di failover dei pod. Usa dischi condivisi per effettuare il provisioning delle repliche degli allegati in più nodi del cluster e si integra con l'utilità di pianificazione dei pod per garantire che un nodo con una replica allegata venga scelto in caso di failover del pod. Il driver CSI del disco di Azure v2 (anteprima) offre anche la possibilità di ottimizzare le prestazioni. Se ti interessa partecipare all'anteprima, invia una richiesta: https://aka.ms/DiskCSIv2Preview. Questa versione di anteprima viene fornita senza un contratto di servizio e occasionalmente è possibile prevedere modifiche di rilievo durante l'anteprima. La versione di anteprima non è consigliata per i carichi di lavoro di produzione. Per altre informazioni, vedere le Condizioni supplementari per l'uso delle anteprime di Microsoft Azure.

Nota

I driver nell’albero sono i driver di archiviazione correnti che fanno parte del codice Kubernetes principale anziché i nuovi driver CSI, che sono plug-in.

Funzionalità del driver CSI su disco di Azure

Oltre alle funzionalità dei driver nell’albero, il driver CSI del disco di Azure supporta le funzionalità seguenti:

  • Miglioramenti delle prestazioni durante il collegamento e la disconnessione simultanei
    • I driver nell'albero collegano o scollegano dischi in serie, mentre i driver CSI collegano o scollegano i dischi in batch. Si verifica un miglioramento significativo quando sono presenti più dischi collegati a un nodo.
  • Sono supportati SSD Premium v1 e v2.
    • PremiumV2_LRS supporta solo la modalità di memorizzazione nella cache None
  • Supporto del disco di archiviazione con ridondanza della zona
    • Premium_ZRS, sono supportati i tipi di disco StandardSSD_ZRS. Il disco dell'archiviazione con ridondanza della zona o del nodo non di zona può essere pianificato, senza la restrizione che il volume del disco deve trovarsi nella stessa zona di un determinato nodo. Per altre informazioni, incluse le aree supportate, vedere Archiviazione con ridondanza della zona per i dischi gestiti.
  • Snapshot
  • Clonazione del volume
  • Ridimensionare il disco PV senza tempi di inattività

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 potenti (ad esempio, 16 core), il limite è di 64 volumi per nodo. Per identificare il limite per OGNI SKU di macchina virtuale, esaminare la colonna Numero massimo di dischi di dati per ogni SKU di macchina virtuale offerto. Per un elenco degli SKU delle macchine virtuali offerti e dei limiti di capacità dettagliati corrispondenti, vedere Dimensioni delle macchine virtuali per utilizzo generico.

Usare volumi persistenti CSI con Dischi 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. Questo articolo illustra come creare dinamicamente dei PV con disco di Azure per l'uso da parte di un singolo pod in un cluster del servizio Azure Kubernetes. Per il provisioning statico, vedere Creare un volume statico con Dischi di Azure.

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

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

Una classe di archiviazione viene usata per definire la creazione dinamica di un'unità di archiviazione con un volume permanente. Per altre informazioni sulle classi di archiviazione Kubernetes, vedere Kubernetes Storage Classes (Classi di archiviazione Kubernetes).

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

  • managed-csi: usa l'archiviazione con ridondanza locale (LRS) di SSD Standard di Azure per creare un disco gestito. 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. 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.

Il criterio di recupero in entrambe le classi di archiviazione garantisce che i dischi di Azure sottostanti vengano eliminati quando viene eliminato il rispettivo PV. Le classi di archiviazione configurano anche i PV in modo che siano espandibili. È sufficiente modificare l'attestazione del volume permanente (PVC) 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 un disco gestito 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 pod di esempio e il rispettivo PVC eseguendo il comando kubectl apply:

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

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

persistentvolumeclaim/pvc-azuredisk created
pod/nginx-azuredisk created

Quando il pod è in esecuzione, eseguire il comando seguente per creare un nuovo file denominato test.txt.

kubectl exec nginx-azuredisk -- touch /mnt/azuredisk/test.txt

Per verificare che il disco sia montato correttamente, eseguire il comando seguente e verificare che il file test.txt sia visualizzato nell'output:

kubectl exec nginx-azuredisk -- ls /mnt/azuredisk

lost+found
outfile
test.txt

Creare una classe di archiviazione personalizzata

Le classi di archiviazione predefinite sono adatte per gli scenari più comuni. Per alcuni casi, potrebbe essere necessario personalizzare la propria classe di archiviazione con i propri parametri. Ad esempio, è possibile modificare la classe volumeBindingMode.

È possibile utilizzare una classe volumeBindingMode: Immediate che garantisce che ciò avvenga immediatamente dopo la creazione del PVC. Quando i pool di nodi sono vincolati dalla topologia, ad esempio quando si usano le zone di disponibilità, i PV vengono associati o ne viene effettuato il provisioning senza conoscere i requisiti di pianificazione del pod.

Per risolvere questo scenario, è possibile usare volumeBindingMode: WaitForFirstConsumer, che ritarda l'associazione e il provisioning di un PV fino a quando non viene creato un pod che utilizza il PVC. In questo modo, il PV è conforme e viene effettuato il provisioning nella zona di disponibilità (o in un'altra topologia) specificata dai vincoli di pianificazione del pod. Le classi di archiviazione predefinite usano la classe volumeBindingMode: WaitForFirstConsumer.

Creare un file denominato sc-azuredisk-csi-waitforfirstconsumer.yaml e quindi incollare il manifesto seguente. La classe di archiviazione è la stessa della classe di archiviazione managed-csi, ma con una classe volumeBindingMode diversa.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: azuredisk-csi-waitforfirstconsumer
provisioner: disk.csi.azure.com
parameters:
  skuname: StandardSSD_LRS
allowVolumeExpansion: true
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

Creare la classe di archiviazione eseguendo il comando kubectl apply e specificando il file sc-azuredisk-csi-waitforfirstconsumer.yaml:

kubectl apply -f sc-azuredisk-csi-waitforfirstconsumer.yaml

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

storageclass.storage.k8s.io/azuredisk-csi-waitforfirstconsumer created

Snapshot del volume

Il driver CSI del disco di Azure supporta la creazione di snapshot di volumi persistenti. Come parte di questa funzionalità, il driver può eseguire snapshot completi o incrementali a seconda del valore impostato nel parametro incremental (per impostazione predefinita, è true).

Nella tabella seguente vengono forniti dettagli per tutti i parametri.

Nome Significato Valore disponibile Obbligatorio Default value
resourceGroup Gruppo di risorse per l'archiviazione degli snapshot GRUPPO DI RISORSE ESISTENTE No Se non specificato, lo snapshot verrà archiviato nello stesso gruppo di risorse dei dischi di Azure di origine
Incrementale Acquisire uno snapshot completo o incrementale true, false No true
tag Tag di Dischi di Azure Formato tag: 'key1=val1,key2=val2' No ""
userAgent Agente utente usato per l'attribuzione dell'utilizzo dei clienti No Useragent generato formattato driverName/driverVersion compiler/version (OS-ARCH)
subscriptionid Specificare l'ID sottoscrizione di Azure in cui verranno creati i dischi di Azure ID sottoscrizione di Azure No Se non è vuoto, resourceGroup deve essere specificato, incremental deve essere impostato come false

Creare uno snapshot del volume

Nota

Prima di procedere, assicurarsi che l'applicazione non scriva i dati nel disco di origine.

Per un esempio di questa funzionalità, creare una classe snapshot del volume con il comando kubectl apply:

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

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

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

Verrà ora creato uno snapshot del volume dal PVC che abbiamo creato dinamicamente all'inizio di questa esercitazione, pvc-azuredisk.

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

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

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

Per verificare che lo snapshot sia stato creato correttamente, eseguire il comando seguente:

kubectl describe volumesnapshot azuredisk-volume-snapshot

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

Name:         azuredisk-volume-snapshot
Namespace:    default
Labels:       <none>
Annotations:  API Version:  snapshot.storage.k8s.io/v1
Kind:         VolumeSnapshot
Metadata:
  Creation Timestamp:  2020-08-27T05:27:58Z
  Finalizers:
    snapshot.storage.kubernetes.io/volumesnapshot-as-source-protection
    snapshot.storage.kubernetes.io/volumesnapshot-bound-protection
  Generation:        1
  Resource Version:  714582
  Self Link:         /apis/snapshot.storage.k8s.io/v1/namespaces/default/volumesnapshots/azuredisk-volume-snapshot
  UID:               dd953ab5-6c24-42d4-ad4a-f33180e0ef87
Spec:
  Source:
    Persistent Volume Claim Name:  pvc-azuredisk
  Volume Snapshot Class Name:      csi-azuredisk-vsc
Status:
  Bound Volume Snapshot Content Name:  snapcontent-dd953ab5-6c24-42d4-ad4a-f33180e0ef87
  Creation Time:                       2020-08-31T05:27:59Z
  Ready To Use:                        true
  Restore Size:                        10Gi
Events:                                <none>

Creare un nuovo PVC basato su uno snapshot del volume

È possibile creare un nuovo PVC basato su uno snapshot del volume. Usare lo snapshot creato nel passaggio precedente e creare un nuovo PVC e un nuovo pod per utilizzarlo.

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

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

persistentvolumeclaim/pvc-azuredisk-snapshot-restored created
pod/nginx-restored created

Infine, verificare che sia lo stesso PVC creato prima controllando il contenuto tramite l’esecuzione del comando seguente:

kubectl exec nginx-restored -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Come previsto, è comunque possibile visualizzare il file test.txt creato in precedenza.

Clonare i volumi

Un volume clonato viene definito come duplicato di un volume Kubernetes esistente. Per altre informazioni sulla clonazione dei volumi in Kubernetes, vedere la documentazione concettuale per la clonazione dei volumi.

Il driver CSI per Dischi di Azure supporta la clonazione del volume. Per dimostrare, creare un volume clonato di quello creato in precedenza azuredisk-pvc e un nuovo pod per utilizzarlo.

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

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

persistentvolumeclaim/pvc-azuredisk-cloning created
pod/nginx-restored-cloning created

È possibile verificare il contenuto del volume clonato eseguendo il comando seguente e confermando che il file test.txt è stato creato:

kubectl exec nginx-restored-cloning -- ls /mnt/azuredisk

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

lost+found
outfile
test.txt

Ridimensionare un volume permanente senza tempi di inattività

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

Nota

Si noti che non viene mai creato un nuovo volume permanente per soddisfare l'attestazione. Viene invece ridimensionato un volume esistente.

Nel servizio Azure Kubernetes la classe di archiviazione managed-csi predefinita supporta già l'espansione, quindi usare l'attestazione di volume permanente creata in precedenza con questa classe di archiviazione. Il PVC ha richiesto un volume permanente da 10 Gi. Per confermare, eseguire il comando seguente:

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

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        9.8G   42M  9.8G   1% /mnt/azuredisk

Espandere il PVC aumentando il campo spec.resources.requests.storage eseguendo il comando seguente:

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

Nota

La compattazione dei volumi permanenti non è attualmente supportata. Il tentativo di applicare patch a un PVC esistente con una dimensione inferiore a quella corrente porta al seguente messaggio di errore: The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

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

persistentvolumeclaim/pvc-azuredisk patched

Eseguire il comando seguente per verificare che le dimensioni del volume siano aumentate:

kubectl get pv

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

NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                     STORAGECLASS   REASON   AGE
pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            Delete           Bound    default/pvc-azuredisk                     managed-csi             2d2h
(...)

E dopo alcuni minuti, eseguire i comandi seguenti per confermare le dimensioni del PVC:

kubectl get pvc pvc-azuredisk

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

NAME            STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc-azuredisk   Bound    pvc-391ea1a6-0191-4022-b915-c8dc4216174a   15Gi       RWO            managed-csi    2d2h

Eseguire il comando seguente per confermare le dimensioni del disco all'interno del pod:

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

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

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc         15G   46M   15G   1% /mnt/azuredisk

Bursting su richiesta

Il modello di bursting del disco su richiesta consente dei picchi di disco ogni volta che le esigenze superano la capacità corrente. Questo modello genera degli addebiti aggiuntivi ogni volta che il disco viene sottoposto a bursting. Il bursting su richiesta è disponibile solo per unità SSD Premium superiori a 512 GiB. Per altre informazioni sulle unità SSD Premium con provisioning di operazioni di I/O al secondo e velocità effettiva per disco, vedere Dimensioni SSD Premium. In alternativa, il bursting basato sul credito è la posizione in cui il disco viene sottoposto a bursting solo se ha crediti burst accumulati nel bucket di credito. Il bursting basato sul credito non genera addebiti aggiuntivi quando il disco viene sottoposto a bursting. Il bursting basato sul credito è disponibile solo per unità SSD Premium 512 GiB e più piccole, e SSD standard 1024 GiB e più piccole. Per altre informazioni sul bursting su richiesta, vedere Bursting su richiesta.

Importante

La classe di archiviazione managed-csi-premium predefinita ha un bursting su richiesta disabilitato e usa il bursting basato sul credito. Qualsiasi unità SSD Premium creata dinamicamente da un'attestazione di volume permanente basata sulla classe di archiviazione managed-csi-premium predefinita ha disabilitato anche il bursting su richiesta.

Per creare un volume permanente SSD Premium con bursting su richiesta abilitato, è possibile creare una nuova classe di archiviazione con il parametro enableBursting impostato su true come illustrato nel modello YAML seguente. Per altre informazioni sull'abilitazione del bursting su richiesta, vedere Bursting su richiesta. Per altre informazioni sulla creazione di una classe di archiviazione personalizzata con bursting su richiesta abilitato, vedere Creare una classe di archiviazione Premium CSI gestita con burst.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: burstable-managed-csi-premium
provisioner: disk.csi.azure.com
parameters:
  skuname: Premium_LRS
  enableBursting: "true"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

Contenitori Windows

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

Dopo aver creato un pool di nodi di Windows, è ora possibile usare le classi di archiviazione predefinite, ad esempio managed-csi. È possibile distribuire un set con stato basato su Windows di esempio che salva i timestamp nel file data.txt eseguendo il seguente comando kubectl apply:

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

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

statefulset.apps/busybox-azuredisk created

Per convalidare il contenuto del volume, eseguire il comando seguente:

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

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

2020-08-27 08:13:41Z
2020-08-27 08:13:42Z
2020-08-27 08:13:44Z
(...)

Passaggi successivi