Partager via

Utiliser le pilote CSI (Container Storage Interface) Azure Disk dans Azure Kubernetes Service (AKS)

  • Article

Le pilote CSI (Container Storage interface) Azure Disks est un pilote conforme à la spécification CSI utilisé par Azure Kubernetes Service (AKS) pour gérer le cycle de vie d’Azure Disk.

CSI est une norme pour exposer des systèmes de stockage de blocs et de fichiers arbitraires à des charges de travail en conteneur sur Kubernetes. En adoptant et en utilisant CSI, AKS peut désormais écrire, déployer et itérer les plug-ins pour exposer de nouveaux systèmes de stockage ou améliorer les existants dans Kubernetes. L’utilisation de pilotes CSI dans AKS permet d’éviter de toucher au code Kubernetes de base et d’attendre ses cycles de mise en production.

Pour créer un cluster AKS avec prise en charge du pilote CSI, consultez Activation du pilote CSI sur AKS. Cet article explique comment utiliser la version 1 du pilote CSI de disque Azure.

Notes

Le pilote CSI de disque Azure v2 (préversion) améliore la scalabilité et réduit la latence de basculement des pods. Il utilise des disques partagés pour provisionner des réplicas d’attachement sur plusieurs nœuds de cluster, et s’intègre au planificateur de pods pour garantir qu’un nœud avec un réplica d’attachement est choisi lors d’un basculement de pod. Le pilote CSI de disque Azure v2 (préversion) offre également la possibilité d’optimiser les performances. Si vous souhaitez participer à la préversion, envoyez une demande : https://aka.ms/DiskCSIv2Preview. Cette préversion est fournie sans contrat de niveau de service, et il se peut que vous rencontriez de temps à temps des changements cassants pendant la préversion. La préversion n’est pas recommandée pour les charges de travail de production. Pour plus d’informations, consultez Conditions d’Utilisation Supplémentaires relatives aux Évaluations Microsoft Azure.

Notes

Les pilotes dans l’arborescence font référence aux pilotes de stockage actuels, qui font partie du code Kubernetes principal, par opposition aux nouveaux pilotes CSI, qui sont des plug-ins.

Fonctionnalités du pilote CSI de disque Azure

En plus des fonctionnalités de pilote intégrées à l’arborescence, le pilote CSI de disque Azure prend en charge les fonctionnalités suivantes :

  • Amélioration des performances pendant l’attachement et le détachement de disque simultané :
    • Les pilotes dans l’arborescence attachent et détachent des disques en série, tandis que les pilotes CSI les attachent et détachent par lots. La présence de disques attachés à un nœud donne lieu à une amélioration significative.
  • Les disques SSD Premium v1 et v2 sont pris en charge.
    • PremiumV2_LRS prend uniquement en charge le mode de mise en cache None
  • Prise en charge du stockage redondant interzone (ZRS, Zone-Redundant Storage) :
    • Les types de disque Premium_ZRS et StandardSSD_ZRS sont pris en charge. Un disque ZRS peut être planifié sur la zone ou le nœud non zonal, sans la restriction impliquant que le volume de disque doit être colocalisé dans la même zone qu’un nœud donné. Pour plus d’informations, notamment sur les régions prises en charge, consultez Stockage redondant interzone pour les disques managés.
  • Instantané
  • Clone de volume
  • Redimensionner les volumes persistants sur disque sans temps d’arrêt

Notes

Selon la référence SKU de machine virtuelle utilisée, le pilote CSI de disque Azure peut avoir une limite de volume par nœud. Pour certaines machines virtuelles puissantes (par exemple, 16 cœurs), la limite est de 64 volumes par nœud. Pour identifier la limite par référence SKU de machine virtuelle, passez en revue la colonne Nombre maximal de disques de données pour chaque référence SKU de machine virtuelle proposée. Pour obtenir la liste des références SKU de machine virtuelle proposées et leurs limites de capacité détaillées correspondantes, consultez Tailles de machine virtuelle à usage général.

Utilise des volumes persistants CSI avec les disques Azure

Un volume persistant représente un élément de stockage provisionné pour une utilisation dans des pods Kubernetes. Un volume persistant peut être utilisé par un ou plusieurs pods et être provisionné de façon statique ou dynamique. Cet article vous montre comment créer des volumes persistants de manière dynamique avec un disque Azure pour permettre à un pod unique de l’utiliser dans un cluster AKS. Pour l’approvisionnement statique, consultez Création d’un volume statique avec des disques Azure.

Pour plus d’informations sur les volumes Kubernetes, consultez Options de stockage pour les applications dans AKS.

Créer dynamiquement des volumes persistants de disques Azure à l’aide des classes de stockage intégrées

Une classe de stockage permet de définir la création dynamique d’une unité de stockage avec un volume persistant. Pour plus d’informations sur les classes de stockage Kubernetes, consultez Classes de stockage Kubernetes.

Lorsque vous utilisez le pilote CSI de disque Azure sur AKS, deux autres StorageClasses intégrées utilisent le pilote de stockage CSI de disque Azure. Les autres classes de stockage CSI sont créées avec le cluster en même temps que les classes de stockage par défaut dans l’arborescence.

  • managed-csi: Utilise un stockage localement redondant (LRS) Azure Standard SSD pour créer un disque managé. À compter de Kubernetes version 1.29, dans les clusters Azure Kubernetes Service (AKS) déployés sur plusieurs zones de disponibilité, cette classe de stockage utilise le stockage redondant interzone (ZRS) SSD Standard Azure pour créer des disques managés.
  • managed-csi-premium: Utilise un stockage localement redondant (LRS) Azure Premium pour créer un disque managé. À compter de Kubernetes version 1.29, dans les clusters Azure Kubernetes Service (AKS) déployés sur plusieurs zones de disponibilité, cette classe de stockage utilise le stockage redondant interzone (ZRS) Azure Premium pour créer des disques managés.

La stratégie de récupération des deux classes de stockage garantit que les disques Azure sous-jacents sont supprimés lorsque le volume persistant respectif est supprimé. Les classes de stockage configurent également les volumes persistants pour qu’ils soient extensibles. Vous devez simplement modifier la revendication de volume persistant (PVC) avec la nouvelle taille.

Pour utiliser ces classes de stockage, créez un PVC et un pod respectif qui les référence et les utilise. Une revendication de volume persistant est utilisée pour configurer automatiquement le stockage basé sur une classe de stockage. Un PVC peut utiliser l’une des classes de stockage précréées ou une classe de stockage définie par l’utilisateur pour créer un disque managé Azure pour la référence SKU et la taille de votre choix. Lorsque vous créez une définition de pod, la revendication de volume persistant est spécifiée pour demander le stockage souhaité.

Créez un exemple de pod et la revendication de volume persistant correspondante en exécutant la commande 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

La sortie de la commande ressemble à l’exemple suivant :

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

Une fois le pod en cours d’exécution, exécutez la commande suivante pour créer un fichier nommé test.txt.

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

Pour contrôler que le disque est correctement monté, exécutez la commande suivante et vérifiez la présence du fichier test.txt dans la sortie :

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

lost+found
outfile
test.txt

Créer une classe de stockage personnalisée

Les classes de stockage par défaut conviennent pour la plupart des scénarios courants. Dans certains cas, vous souhaiterez peut-être personnaliser votre propre classe de stockage avec vos propres paramètres. Par exemple, il est possible que vous souhaitiez changer la classe volumeBindingMode.

Vous pouvez utiliser une classe volumeBindingMode: Immediate qui garantit que cela se produit immédiatement après la création de la revendication de volume persistant. Lorsque vos pools de nœuds sont limités en termes de topologie (par exemple avec des zones de disponibilité), les volumes persistants sont liés ou approvisionnés sans tenir compte des exigences de planification du pod.

Dans un tel scénario, vous pouvez utiliser volumeBindingMode: WaitForFirstConsumer, qui retarde la liaison et l’approvisionnement d’un volume persistant jusqu’à ce qu’un pod utilisant le PVC soit créé. Ainsi, le volume persistant est conforme et approvisionné dans la zone de disponibilité (ou une autre topologie) spécifiée par les contraintes de planification du pod. Les classes de stockage par défaut utilisent la classe volumeBindingMode: WaitForFirstConsumer.

Créez un fichier nommé sc-azuredisk-csi-waitforfirstconsumer.yaml, puis collez-y le manifeste suivant. La classe de stockage est identique à la classe de stockage managed-csi, mais avec une classe volumeBindingMode différente.

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

Créez la classe de stockage en exécutant la commande kubectl apply et spécifiez votre fichier sc-azuredisk-csi-waitforfirstconsumer.yaml :

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

La sortie de la commande ressemble à l’exemple suivant :

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

Clichés instantanés de volume

Le pilote CSI de disque Azure prend en charge la création de captures instantanées de volumes persistants. Dans le cadre de cette fonctionnalité, le pilote peut effectuer des instantanéscomplets ou incrémentiels en fonction de la valeur définie dans le paramètre incremental (true, par défaut).

Le tableau suivant fournit des informations sur tous les paramètres.

Name Signification Valeur disponible Obligatoire Valeur par défaut
resourceGroup Groupe de ressources de stockage des captures instantanées GROUPE DE RESSOURCES EXISTANT Non Si le paramètre n’est pas spécifié, l’instantané est stocké dans le même groupe de ressources que les disques Azure source
incrémentielles Prendre un instantané complet ou incrémentiel true, false Non true
tags Balises des disques Azure Format des étiquettes : ’key1=val1,key2=val2’ Non ""
userAgent Agent utilisateur utilisé pour l’attribution de l’utilisation du client Non Agent utilisateur généré au format driverName/driverVersion compiler/version (OS-ARCH)
subscriptionID Spécifier l’ID d’abonnement Azure dans lequel les disques Azure seront créés ID d’abonnement Azure Non Si le paramètre n’est pas vide, resourceGroup doit être fourni et incremental défini comme false.

Créer un instantané de volume

Notes

Avant de continuer, vérifiez que l’application n’écrit pas de données sur le disque source.

Pour une illustration de cette fonctionnalité, créez une classe d’instantané de volume avec la commande kubectl apply :

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

La sortie de la commande ressemble à l’exemple suivant :

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

Nous allons à présent créer un instantané de volume à partir du PVC que nous avons créé de façon dynamique au début de ce tutoriel, pvc-azuredisk.

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

La sortie de la commande ressemble à l’exemple suivant :

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

Pour vérifier que l’instantané a été créé correctement, exécutez la commande suivante :

kubectl describe volumesnapshot azuredisk-volume-snapshot

La sortie de la commande ressemble à l’exemple suivant :

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>

Créer un PVC basé sur un instantané de volume

Vous pouvez créer un PVC basé sur un instantané de volume. Utilisez l’instantané créé à l’étape précédente, puis créez un PVC et un pod pour le consommer.

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

La sortie de la commande ressemble à l’exemple suivant :

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

Enfin, assurez-vous qu’il s’agit du même PVC que celui créé précédemment en vérifiant son contenu. Pour ce faire, exécutez la commande suivante :

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

La sortie de la commande ressemble à l’exemple suivant :

lost+found
outfile
test.txt

Comme attendu, nous pouvons toujours voir le fichier test.txt créé précédemment.

Cloner des volumes

Un volume cloné est défini comme un doublon d’un volume Kubernetes existant. Pour plus d’informations sur le clonage des volumes dans Kubernetes, consultez la documentation conceptuelle relative au clonage de volume.

Le pilote CSI des disques Azure prend en charge le clonage de volume. Pour une illustration, créez un volume cloné de celui créé précédemment azuredisk-pvc et un pod pour le consommer.

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

La sortie de la commande ressemble à l’exemple suivant :

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

Vous pouvez vérifier le contenu du volume cloné en exécutant la commande suivante et en confirmant que le fichier test.txt a été créé :

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

La sortie de la commande ressemble à l’exemple suivant :

lost+found
outfile
test.txt

Redimensionner un volume persistant sans temps d’arrêt

Vous pouvez demander un volume plus important pour un PVC. Modifiez l’objet PVC et spécifiez une taille supérieure. Cette modification déclenche l’expansion du volume sous-jacent qui stocke le PV.

Notes

Un nouveau PV n’est jamais créé pour satisfaire la revendication. Au lieu de cela, un volume existant est redimensionné.

Dans AKS, la classe de stockage intégrée managed-csi prend déjà en charge l’expansion, vous pouvez donc utiliser le PVC créé précédemment avec cette classe de stockage. Le PVC a demandé un volume persistant de 10 GI. Vous pouvez le confirmer en exécutant la commande suivante :

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

La sortie de la commande ressemble à l’exemple suivant :

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

Développez la revendication de volume persistant en augmentant le champ spec.resources.requests.storage à l’aide de la commande suivante :

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

Notes

La réduction des volumes persistants n’est actuellement pas prise en charge. Si vous essayez de corriger un PVC existant vers une taille inférieure à celle actuelle, le message d’erreur suivant s’affiche : The persistentVolumeClaim "pvc-azuredisk" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value.

La sortie de la commande ressemble à l’exemple suivant :

persistentvolumeclaim/pvc-azuredisk patched

Exécutez la commande suivante pour confirmer que la taille du volume a augmenté :

kubectl get pv

La sortie de la commande ressemble à l’exemple suivant :

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

Après quelques minutes, exécutez les commandes suivantes pour confirmer la taille de la revendication de volume persistant :

kubectl get pvc pvc-azuredisk

La sortie de la commande ressemble à l’exemple suivant :

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

Exécutez la commande suivante pour confirmer la taille du disque à l’intérieur du pod :

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

La sortie de la commande ressemble à l’exemple suivant :

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

Bursting à la demande

Un modèle de bursting de disque à la demande permet de réaliser des burstings de disque chaque fois que ses besoins dépassent sa capacité actuelle. Ce modèle génère des frais supplémentaires à chaque bursting de disque. Le bursting à la demande est disponible uniquement pour les disques SSD Premium d’une taille supérieure à 512 Gio. Pour plus d’informations sur les IOPS et le débit par seconde approvisionnés des disques SSD Premium, consultez Taille des disques SSD Premium. Dans le cas du bursting basé sur les crédits à l’inverse, le bursting de disque n’a lieu que si des crédits de bursting ont été accumulés dans le compartiment de crédits associé. Le bursting basé sur les crédits ne génère pas de frais supplémentaires lors des burstings de disque. Le bursting basé sur les crédits est uniquement disponible pour les disques SSD Premium de 512 Gio ou moins, et les disques SSD Standard de 1024 Gio ou moins. Pour plus d’informations sur le bursting à la demande, consultez Bursting à la demande.

Important

Le bursting à la demande est désactivé pour la classe de stockage managed-csi-premium par défaut, qui utilise le bursting basé sur les crédits. Tout disque SSD Premium créé dynamiquement par une revendication de volume persistant en fonction de la classe de stockage managed-csi-premium par défaut est également généré avec le bursting à la demande désactivé.

Pour générer un volume persistant SSD Premium sur lequel le bursting à la demande est activé, vous pouvez créer une classe de stockage avec le paramètre enableBursting défini true (cf. modèle YAML suivant). Pour plus d’informations sur l’activation du bursting à la demande, consultez Bursting à la demande. Pour plus d’informations sur la création d’une classe de stockage avec bursting à la demande activé, consultez Création d’une classe de stockage Premium CSI managée burstable.

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

Conteneurs Windows

Le pilote CSI de disque Azure prend en charge les nœuds et conteneurs Windows. Si vous souhaitez utiliser des conteneurs Windows, suivez le Guide de démarrage rapide sur les conteneurs Windows pour ajouter un pool de nœuds Windows.

Lorsque vous disposez d’un pool de nœuds Windows, vous pouvez utiliser les classes de stockage intégrées comme managed-csi. Vous pouvez déployer un exemple d’ensemble avec état basé sur Windows qui enregistre les horodatages dans le fichier data.txt en utilisant la commande kubectl apply suivante :

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

La sortie de la commande ressemble à l’exemple suivant :

statefulset.apps/busybox-azuredisk created

Pour valider le contenu du volume, exécutez la commande suivante :

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

La sortie de la commande ressemble à l’exemple suivant :

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

Étapes suivantes