Rechercher

4.2. Stockage persistant avec Azure

download PDF

OpenShift Container Platform prend en charge les volumes de disques Microsoft Azure. Vous pouvez approvisionner votre cluster OpenShift Container Platform avec un stockage persistant en utilisant Azure. Une certaine familiarité avec Kubernetes et Azure est supposée. Le cadre de volume persistant de Kubernetes permet aux administrateurs de provisionner un cluster avec un stockage persistant et donne aux utilisateurs un moyen de demander ces ressources sans avoir aucune connaissance de l'infrastructure sous-jacente. Les volumes Azure Disk peuvent être approvisionnés de manière dynamique. Les volumes persistants ne sont pas liés à un seul projet ou à un seul espace de noms ; ils peuvent être partagés à travers le cluster OpenShift Container Platform. Les demandes de volumes persistants sont spécifiques à un projet ou à un espace de noms et peuvent être demandées par les utilisateurs.

Important

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 futures versions d'OpenShift Container Platform.

Important

La haute disponibilité du stockage dans l'infrastructure est laissée au fournisseur de stockage sous-jacent.

Ressources supplémentaires

4.2.1. Création de la classe de stockage Azure

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, les utilisateurs peuvent obtenir des volumes persistants provisionnés dynamiquement.

Procédure

  1. Dans la console OpenShift Container Platform, cliquez sur Storage Storage Classes.
  2. Dans l'aperçu de la classe de stockage, cliquez sur Create Storage Class.
  3. Définissez les options souhaitées sur la page qui s'affiche.

    1. Entrez un nom pour référencer la classe de stockage.
    2. Saisissez une description facultative.
    3. Sélectionnez la politique de récupération.
    4. Sélectionnez kubernetes.io/azure-disk dans la liste déroulante.

      1. Saisissez le type de compte de stockage. Cela correspond au niveau SKU de votre compte de stockage Azure. Les options valides sont Premium_LRS, Standard_LRS, StandardSSD_LRS et UltraSSD_LRS.
      2. Saisissez le type de compte. Les options valables sont shared, dedicated, et managed.

        Important

        Red Hat ne prend en charge que l'utilisation de kind: Managed dans la classe de stockage.

        Avec Shared et Dedicated, Azure crée des disques non gérés, tandis qu'OpenShift Container Platform crée un disque géré pour les disques du système d'exploitation de la machine (racine). Mais comme Azure Disk ne permet pas l'utilisation de disques gérés et non gérés sur un nœud, les disques non gérés créés avec Shared ou Dedicated ne peuvent pas être attachés aux nœuds d'OpenShift Container Platform.

    5. Saisissez des paramètres supplémentaires pour la classe de stockage si vous le souhaitez.
  4. Cliquez sur Create pour créer la classe de stockage.

Ressources supplémentaires

4.2.2. Création de la revendication de volume persistant

Conditions préalables

Le stockage doit exister dans l'infrastructure sous-jacente avant de pouvoir être monté en tant que volume dans OpenShift Container Platform.

Procédure

  1. Dans la console OpenShift Container Platform, cliquez sur Storage Persistent Volume Claims.
  2. Dans l'aperçu des réclamations relatives aux volumes persistants, cliquez sur Create Persistent Volume Claim.
  3. Définissez les options souhaitées sur la page qui s'affiche.

    1. Sélectionnez la classe de stockage précédemment créée dans le menu déroulant.
    2. Saisissez un nom unique pour la créance de stockage.
    3. Sélectionner le mode d'accès. Cette sélection détermine l'accès à la lecture et à l'écriture pour l'unité de stockage.
    4. Définir la taille de la demande de stockage.
  4. Cliquez sur Create pour créer la demande de volume persistant et générer un volume persistant.

4.2.3. Format du volume

Avant que OpenShift Container Platform ne monte le volume et ne le transmette à un conteneur, il vérifie qu'il contient un système de fichiers tel que spécifié par le paramètre fsType dans la définition du volume persistant. Si le périphérique n'est pas formaté avec le système de fichiers, toutes les données du périphérique sont effacées et le périphérique est automatiquement formaté avec le système de fichiers donné.

Cela permet d'utiliser des volumes Azure non formatés comme volumes persistants, car OpenShift Container Platform les formate avant la première utilisation.

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

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

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

    <machine-set-name> est l'ensemble de machines que vous voulez provisionner avec des ultra-disques.

  2. 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
    1
    Indiquez une étiquette à utiliser pour sélectionner un nœud créé par ce jeu de machines. Cette procédure utilise disk.ultrassd pour cette valeur.
    2
    Ces lignes permettent l'utilisation d'ultra-disques.
  3. 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
  4. 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, utilisez kubernetes.io/azure-disk.
    5
    Facultatif : Ce paramètre permet d'attendre la création du module qui utilisera le disque.
  5. 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
    1
    Indiquez le nom du PVC. Cette procédure utilise ultra-disk pour cette valeur.
    2
    Ce PVC fait référence à la classe de stockage ultra-disk-sc.
    3
    Spécifiez la taille de la classe de stockage. La valeur minimale est 4Gi.
  6. 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
    1
    Indiquez l'étiquette du jeu de machines qui permet l'utilisation d'ultra-disques. Cette procédure utilise disk.ultrassd pour cette valeur.
    2
    Ce pod fait référence au PVC ultra-disk.

Vérification

  1. Validez la création des machines en exécutant la commande suivante :

    $ oc get machines

    Les machines doivent être dans l'état Running.

  2. 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ée chroot /host permet d'accéder aux binaires du système d'exploitation hôte sous-jacent, et lsblk 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

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

4.2.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>
Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.