5.10. Opérateur Azure Disk CSI Driver
5.10.1. Vue d'ensemble
OpenShift Container Platform est capable de provisionner des volumes persistants (PV) à l'aide du pilote Container Storage Interface (CSI) pour Microsoft Azure Disk Storage.
Il est recommandé de se familiariser avec le stockage persistant et la configuration des volumes CSI lorsque l'on travaille avec un opérateur et un pilote CSI.
Pour créer des PV provisionnés CSI qui se montent sur des ressources de stockage Azure Disk, OpenShift Container Platform installe l'opérateur Azure Disk CSI Driver et le pilote Azure Disk CSI par défaut dans l'espace de noms openshift-cluster-csi-drivers
.
-
Le site Azure Disk CSI Driver Operator fournit une classe de stockage nommée
managed-csi
que vous pouvez utiliser pour créer des réclamations de volumes persistants (PVC). L'Azure Disk CSI Driver Operator prend en charge l'approvisionnement dynamique en volume en permettant la création de volumes de stockage à la demande, ce qui évite aux administrateurs de cluster d'avoir à préprovisionner le stockage. - Le site Azure Disk CSI driver vous permet de créer et de monter des PV Azure Disk.
5.10.2. À propos du CSI
Les fournisseurs de stockage ont traditionnellement fourni des pilotes de stockage dans le cadre de Kubernetes. Avec la mise en œuvre de l'interface de stockage des conteneurs (CSI), les fournisseurs tiers peuvent à la place fournir des plugins de stockage à l'aide d'une interface standard sans jamais avoir à modifier le code de base de Kubernetes.
Les opérateurs CSI offrent aux utilisateurs d'OpenShift Container Platform des options de stockage, telles que les instantanés de volume, qui ne sont pas possibles avec les plugins de volume dans l'arborescence.
OpenShift Container Platform utilise par défaut un plugin in-tree (non-CSI) pour provisionner le stockage Azure Disk.
Dans les prochaines versions d'OpenShift Container Platform, les volumes provisionnés à l'aide des plugins in-tree existants sont prévus pour une migration vers leur pilote CSI équivalent. La migration automatique CSI devrait être transparente. La migration ne modifie pas la façon dont vous utilisez tous les objets API existants, tels que les volumes persistants, les réclamations de volumes persistants et les classes de stockage. Pour plus d'informations sur la migration, voir Migration automatique CSI.
Après la migration complète, les plugins in-tree seront éventuellement supprimés dans les versions ultérieures d'OpenShift Container Platform.
5.10.3. Création d'une classe de stockage avec un type de compte de stockage
Les classes de stockage sont utilisées pour différencier et délimiter les niveaux de stockage et les utilisations. En définissant une classe de stockage, vous pouvez obtenir des volumes persistants provisionnés dynamiquement.
Lors de la création d'une classe de stockage, vous pouvez désigner le type de compte de stockage. Cela correspond au niveau SKU de votre compte de stockage Azure. Les options valides sont Standard_LRS
, Premium_LRS
, StandardSSD_LRS
, UltraSSD_LRS
, Premium_ZRS
et StandardSSD_ZRS
. Pour plus d'informations sur la recherche de votre niveau d'UGS Azure, voir Types d'UGS.
ZRS a des limitations régionales. Pour plus d'informations sur ces limitations, voir Limitations de ZRS.
Conditions préalables
- Accès à un cluster OpenShift Container Platform avec des droits d'administrateur
Procédure
Procédez comme suit pour créer une classe de stockage avec un type de compte de stockage.
Créez une classe de stockage désignant le type de compte de stockage à l'aide d'un fichier YAML similaire au suivant :
$ oc create -f - << EOF apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: <storage-class> 1 provisioner: disk.csi.azure.com parameters: skuName: <storage-class-account-type> 2 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true EOF
Assurez-vous que la classe de stockage a été créée en dressant la liste des classes de stockage :
$ oc get storageclass
Exemple de sortie
$ oc get storageclass NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE azurefile-csi file.csi.azure.com Delete Immediate true 68m managed-csi (default) disk.csi.azure.com Delete WaitForFirstConsumer true 68m sc-prem-zrs disk.csi.azure.com Delete WaitForFirstConsumer true 4m25s 1
- 1
- Nouvelle classe de stockage avec type de compte de stockage.
5.10.4. Ensembles de machines qui déploient des machines avec des ultra-disques utilisant des PVC
Vous pouvez créer un jeu de machines fonctionnant sur Azure qui déploie des machines avec des ultra-disques. Les disques ultra sont des systèmes de stockage haute performance destinés à être utilisés avec les charges de travail les plus exigeantes.
Le plugin in-tree et le pilote CSI prennent tous deux en charge l'utilisation des PVC pour activer les ultra-disques. Vous pouvez également déployer des machines avec des ultra-disques en tant que disques de données sans créer de PVC.
Ressources supplémentaires
5.10.4.1. Création de machines avec ultra-disques à l'aide de jeux de machines
Vous pouvez déployer des machines avec des ultra-disques sur Azure en modifiant votre fichier YAML de configuration des machines.
Conditions préalables
- Disposer d'un cluster Microsoft Azure existant.
Procédure
Copiez une ressource personnalisée (CR) Azure
MachineSet
existante et modifiez-la en exécutant la commande suivante :oc edit machineset <machine-set-name> $ oc edit machineset <machine-set-name>
où
<machine-set-name>
est l'ensemble de machines que vous voulez provisionner avec des ultra-disques.Ajouter les lignes suivantes aux endroits indiqués :
apiVersion: machine.openshift.io/v1beta1 kind: MachineSet spec: template: spec: metadata: labels: disk: ultrassd 1 providerSpec: value: ultraSSDCapability: Enabled 2
Créez un jeu de machines à l'aide de la configuration mise à jour en exécutant la commande suivante :
oc create -f <machine-set-name>.yaml
Créez une classe de stockage contenant la définition YAML suivante :
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: ultra-disk-sc 1 parameters: cachingMode: None diskIopsReadWrite: "2000" 2 diskMbpsReadWrite: "320" 3 kind: managed skuname: UltraSSD_LRS provisioner: disk.csi.azure.com 4 reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer 5
- 1
- Indiquez le nom de la classe de stockage. Cette procédure utilise
ultra-disk-sc
pour cette valeur. - 2
- Spécifiez le nombre d'IOPS pour la classe de stockage.
- 3
- Spécifiez le débit en MBps pour la classe de stockage.
- 4
- Pour Azure Kubernetes Service (AKS) version 1.21 ou ultérieure, utilisez
disk.csi.azure.com
. Pour les versions antérieures d'AKS, utilisezkubernetes.io/azure-disk
. - 5
- Facultatif : Ce paramètre permet d'attendre la création du module qui utilisera le disque.
Créez une revendication de volume persistant (PVC) pour référencer la classe de stockage
ultra-disk-sc
qui contient la définition YAML suivante :apiVersion: v1 kind: PersistentVolumeClaim metadata: name: ultra-disk 1 spec: accessModes: - ReadWriteOnce storageClassName: ultra-disk-sc 2 resources: requests: storage: 4Gi 3
Créez un pod qui contient la définition YAML suivante :
apiVersion: v1 kind: Pod metadata: name: nginx-ultra spec: nodeSelector: disk: ultrassd 1 containers: - name: nginx-ultra image: alpine:latest command: - "sleep" - "infinity" volumeMounts: - mountPath: "/mnt/azure" name: volume volumes: - name: volume persistentVolumeClaim: claimName: ultra-disk 2
Vérification
Validez la création des machines en exécutant la commande suivante :
$ oc get machines
Les machines doivent être dans l'état
Running
.Pour une machine en cours d'exécution et à laquelle un nœud est attaché, validez la partition en exécutant la commande suivante :
$ oc debug node/<node-name> -- chroot /host lsblk
Dans cette commande,
oc debug node/<node-name>
démarre un shell de débogage sur le nœud<node-name>
et transmet une commande à--
. La commande passéechroot /host
permet d'accéder aux binaires du système d'exploitation hôte sous-jacent, etlsblk
montre les périphériques de bloc attachés à la machine du système d'exploitation hôte.
Prochaines étapes
Pour utiliser un ultra disque à partir d'un pod, créez une charge de travail qui utilise le point de montage. Créez un fichier YAML similaire à l'exemple suivant :
apiVersion: v1 kind: Pod metadata: name: ssd-benchmark1 spec: containers: - name: ssd-benchmark1 image: nginx ports: - containerPort: 80 name: "http-server" volumeMounts: - name: lun0p1 mountPath: "/tmp" volumes: - name: lun0p1 hostPath: path: /var/lib/lun0p1 type: DirectoryOrCreate nodeSelector: disktype: ultrassd
5.10.4.2. Ressources de dépannage pour les ensembles de machines qui activent les ultra-disques
Utilisez les informations de cette section pour comprendre et résoudre les problèmes que vous pourriez rencontrer.
5.10.4.2.1. Impossible de monter une revendication de volume persistant soutenue par un ultra disque
En cas de problème lors du montage d'une revendication de volume persistant soutenue par un ultra disque, le pod reste bloqué à l'état ContainerCreating
et une alerte est déclenchée.
Par exemple, si le paramètre additionalCapabilities.ultraSSDEnabled
n'est pas défini sur la machine qui soutient le nœud qui héberge le module, le message d'erreur suivant apparaît :
StorageAccountType UltraSSD_LRS can be used only when additionalCapabilities.ultraSSDEnabled is set.
Pour résoudre ce problème, décrivez le pod en exécutant la commande suivante :
oc -n <stuck_pod_namespace> describe pod <stuck_pod_name>