Rechercher

4.4. Stockage persistant à l'aide de Cinder

download PDF

OpenShift Container Platform prend en charge OpenStack Cinder. Une certaine familiarité avec Kubernetes et OpenStack est supposée.

Les volumes Cinder peuvent être provisionnés dynamiquement. Les volumes persistants ne sont pas liés à un projet ou à un espace de noms unique ; 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 Cinder.

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.

Ressources supplémentaires

  • Pour plus d'informations sur la façon dont OpenStack Block Storage assure la gestion du stockage en bloc persistant pour les disques durs virtuels, voir OpenStack Cinder.

4.4.1. Approvisionnement manuel avec Cinder

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

Conditions préalables

  • OpenShift Container Platform configuré pour Red Hat OpenStack Platform (RHOSP)
  • Volume de cendres ID

4.4.1.1. Création du volume persistant

Vous devez définir votre volume persistant (PV) dans une définition d'objet avant de le créer dans OpenShift Container Platform :

Procédure

  1. Enregistrez votre définition d'objet dans un fichier.

    cinder-persistentvolume.yaml

    apiVersion: "v1"
    kind: "PersistentVolume"
    metadata:
      name: "pv0001" 1
    spec:
      capacity:
        storage: "5Gi" 2
      accessModes:
        - "ReadWriteOnce"
      cinder: 3
        fsType: "ext3" 4
        volumeID: "f37a03aa-6212-4c62-a805-9ce139fab180" 5

    1
    Le nom du volume utilisé par les réclamations de volumes persistants ou les pods.
    2
    La quantité de stockage allouée à ce volume.
    3
    Indique cinder pour les volumes Cinder de Red Hat OpenStack Platform (RHOSP).
    4
    Le système de fichiers qui est créé lorsque le volume est monté pour la première fois.
    5
    Le volume Cinder à utiliser.
    Important

    Ne modifiez pas la valeur du paramètre fstype après le formatage et l'approvisionnement du volume. La modification de cette valeur peut entraîner une perte de données et une défaillance du pod.

  2. Créez le fichier de définition d'objet que vous avez enregistré à l'étape précédente.

    $ oc create -f cinder-persistentvolume.yaml

4.4.1.2. Formatage de volumes persistants

Vous pouvez utiliser des volumes Cinder non formatés comme PV car OpenShift Container Platform les formate avant la première utilisation.

Avant qu'OpenShift Container Platform ne monte le volume et ne le transmette à un conteneur, le système vérifie qu'il contient un système de fichiers tel que spécifié par le paramètre fsType dans la définition du PV. 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é.

4.4.1.3. Sécurité des volumes Cinder

Si vous utilisez des PV Cinder dans votre application, configurez la sécurité pour leurs configurations de déploiement.

Conditions préalables

  • Il faut créer un CCN qui utilise la stratégie fsGroup appropriée.

Procédure

  1. Créez un compte de service et ajoutez-le au SCC :

    oc create serviceaccount <service_account> $ oc create serviceaccount <service_account>
    $ oc adm policy add-scc-to-user <new_scc> -z <service_account> -n <project>
  2. Dans la configuration du déploiement de votre application, indiquez le nom du compte de service et securityContext:

    apiVersion: v1
    kind: ReplicationController
    metadata:
      name: frontend-1
    spec:
      replicas: 1  1
      selector:    2
        name: frontend
      template:    3
        metadata:
          labels:  4
            name: frontend 5
        spec:
          containers:
          - image: openshift/hello-openshift
            name: helloworld
            ports:
            - containerPort: 8080
              protocol: TCP
          restartPolicy: Always
          serviceAccountName: <service_account> 6
          securityContext:
            fsGroup: 7777 7
    1
    Le nombre de copies du module à exécuter.
    2
    Le sélecteur d'étiquettes du module à exécuter.
    3
    Un modèle pour le module que le contrôleur crée.
    4
    Les étiquettes sur le pod. Elles doivent inclure les étiquettes du sélecteur d'étiquettes.
    5
    La longueur maximale du nom après expansion des paramètres est de 63 caractères.
    6
    Spécifie le compte de service que vous avez créé.
    7
    Spécifie une adresse fsGroup pour les pods.
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.