Rechercher

Chapitre 5. Utilisation de l'interface de stockage des conteneurs (CSI)

download PDF

5.1. Configuration des volumes CSI

L'interface de stockage des conteneurs (CSI) permet à OpenShift Container Platform de consommer du stockage à partir de backends de stockage qui implémentent l'interface CSI en tant que stockage persistant.

Note

OpenShift Container Platform 4.12 supporte la version 1.6.0 de la spécification CSI.

5.1.1. Architecture CSI

Les pilotes CSI sont généralement livrés sous forme d'images de conteneurs. Ces conteneurs ne savent pas où s'exécute OpenShift Container Platform. Pour utiliser un back-end de stockage compatible CSI dans OpenShift Container Platform, l'administrateur du cluster doit déployer plusieurs composants qui servent de pont entre OpenShift Container Platform et le pilote de stockage.

Le diagramme suivant fournit une vue d'ensemble des composants fonctionnant dans les pods du cluster OpenShift Container Platform.

Architecture of CSI components

Il est possible d'exécuter plusieurs pilotes CSI pour différents backends de stockage. Chaque pilote a besoin de son propre déploiement de contrôleurs externes et d'un démon configuré avec le pilote et le registraire CSI.

5.1.1.1. Contrôleurs CSI externes

Les contrôleurs CSI externes sont des déploiements qui mettent en place un ou plusieurs pods avec cinq conteneurs :

  • Le conteneur snapshotter surveille les objets VolumeSnapshot et VolumeSnapshotContent et est responsable de la création et de la suppression de l'objet VolumeSnapshotContent.
  • Le conteneur resizer est un conteneur sidecar qui surveille les mises à jour de PersistentVolumeClaim et déclenche des opérations ControllerExpandVolume contre un point de terminaison CSI si vous demandez plus d'espace de stockage sur l'objet PersistentVolumeClaim.
  • Un conteneur d'attachement CSI externe traduit les appels attach et detach d'OpenShift Container Platform en appels ControllerPublish et ControllerUnpublish respectifs au pilote CSI.
  • Un conteneur externe de provisionneur CSI qui traduit les appels provision et delete d'OpenShift Container Platform en appels CreateVolume et DeleteVolume au pilote CSI.
  • Un conteneur de pilote CSI.

Les conteneurs CSI attacher et CSI provisioner communiquent avec le conteneur CSI driver en utilisant des UNIX Domain Sockets, garantissant qu'aucune communication CSI ne quitte le pod. Le pilote CSI n'est pas accessible depuis l'extérieur du module.

Note

Les opérations attach, detach, provision et delete nécessitent généralement que le pilote CSI utilise des informations d'identification pour le backend de stockage. Exécuter les pods du contrôleur CSI sur des nœuds d'infrastructure afin que les informations d'identification ne soient jamais divulguées aux processus utilisateurs, même en cas de violation catastrophique de la sécurité sur un nœud de calcul.

Note

L'attacheur externe doit également être exécuté pour les pilotes CSI qui ne prennent pas en charge les opérations attach ou detach de tiers. L'attacheur externe n'émettra aucune opération ControllerPublish ou ControllerUnpublish vers le pilote CSI. Cependant, il doit toujours être exécuté pour mettre en œuvre l'API d'attachement OpenShift Container Platform nécessaire.

5.1.1.2. Jeu de démons pour les pilotes CSI

Le jeu de démons du pilote CSI exécute un pod sur chaque nœud qui permet à OpenShift Container Platform de monter le stockage fourni par le pilote CSI sur le nœud et de l'utiliser dans les charges de travail utilisateur (pods) en tant que volumes persistants (PV). Le pod avec le pilote CSI installé contient les conteneurs suivants :

  • Un registraire de pilote CSI, qui enregistre le pilote CSI dans le service openshift-node fonctionnant sur le nœud. Le processus openshift-node exécuté sur le nœud se connecte alors directement au pilote CSI en utilisant la socket de domaine UNIX disponible sur le nœud.
  • Un conducteur de CSI.

Le pilote CSI déployé sur le nœud devrait avoir le moins d'informations d'identification possible pour le back-end de stockage. OpenShift Container Platform n'utilisera que l'ensemble des appels CSI du plugin du nœud, tels que NodePublish/NodeUnpublish et NodeStage/NodeUnstage, si ces appels sont mis en œuvre.

5.1.2. Pilotes CSI pris en charge par OpenShift Container Platform

OpenShift Container Platform installe certains pilotes CSI par défaut, offrant aux utilisateurs des options de stockage qui ne sont pas possibles avec les plugins de volume dans l'arborescence.

Pour créer des volumes persistants provisionnés par CSI qui se montent sur ces ressources de stockage prises en charge, OpenShift Container Platform installe par défaut l'opérateur de pilote CSI nécessaire, le pilote CSI et la classe de stockage requise. Pour plus de détails sur l'espace de noms par défaut de l'opérateur et du pilote, voir la documentation de l'opérateur de pilote CSI spécifique.

Le tableau suivant décrit les pilotes CSI installés avec OpenShift Container Platform et les fonctionnalités CSI qu'ils prennent en charge, telles que les instantanés de volume, le clonage et le redimensionnement.

Tableau 5.1. Pilotes et fonctionnalités CSI pris en charge dans OpenShift Container Platform
Pilote CSIInstantanés de volumes CSIClonage CSIRedimensionnement de l'ICS

Disque AliCloud

 ✅

 -

 ✅

AWS EBS

 ✅

 -

 ✅

AWS EFS

 -

 -

 -

Disque persistant (PD) de Google Compute Platform (GCP)

 ✅

 -

 ✅

Dépôt de fichiers GCP

 ✅

 -

 ✅

IBM VPC Block

 ✅[3]

 -

 ✅[3]

Disque Microsoft Azure

 ✅

 ✅

 ✅

Microsoft Azure Stack Hub

 ✅

 ✅

 ✅

Fichier Microsoft Azure

 -

 -

 ✅

OpenStack Cinder

 ✅

 ✅

 ✅

OpenShift Data Foundation

 ✅

 ✅

 ✅

OpenStack Manille

 ✅

 -

 -

Red Hat Virtualization (oVirt)

 -

 -

 ✅

VMware vSphere

 ✅[1]

 -

 ✅[2]

1.

  • Nécessite la version 7.0 Update 3 de vSphere ou une version ultérieure pour vCenter Server et ESXi.
  • Ne prend pas en charge les volumes de partage de fichiers.

2.

  • Extension de volume hors ligne : la version minimale requise de vSphere est 6.7 Update 3 P06
  • Extension de volume en ligne : la version minimale requise de vSphere est 7.0 Update 2.

3.

  • Ne prend pas en charge les instantanés hors ligne ou le redimensionnement. Le volume doit être attaché à un pod en cours d'exécution.
Important

Si votre pilote CSI ne figure pas dans le tableau précédent, vous devez suivre les instructions d'installation fournies par votre fournisseur de stockage CSI pour utiliser les fonctions CSI prises en charge.

5.1.3. Provisionnement dynamique

Le provisionnement dynamique du stockage persistant dépend des capacités du pilote CSI et du back-end de stockage sous-jacent. Le fournisseur du pilote CSI devrait documenter la façon de créer une classe de stockage dans OpenShift Container Platform et les paramètres disponibles pour la configuration.

La classe de stockage créée peut être configurée pour permettre le provisionnement dynamique.

Procédure

  • Créez une classe de stockage par défaut qui garantit que tous les PVC qui ne nécessitent pas de classe de stockage particulière sont approvisionnés par le pilote CSI installé.

    # oc create -f - << EOF
    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: <storage-class> 1
      annotations:
        storageclass.kubernetes.io/is-default-class: "true"
    provisioner: <provisioner-name> 2
    parameters:
    EOF
    1
    Le nom de la classe de stockage qui sera créée.
    2
    Le nom du pilote CSI qui a été installé.

5.1.4. Exemple d'utilisation du pilote CSI

L'exemple suivant installe un modèle MySQL par défaut sans aucune modification du modèle.

Conditions préalables

  • Le pilote CSI a été déployé.
  • Une classe de stockage a été créée pour le provisionnement dynamique.

Procédure

  • Créer le modèle MySQL :

    # oc new-app mysql-persistent

    Exemple de sortie

    --> Deploying template "openshift/mysql-persistent" to project default
    ...

    # oc get pvc

    Exemple de sortie

    NAME              STATUS    VOLUME                                   CAPACITY
    ACCESS MODES   STORAGECLASS   AGE
    mysql             Bound     kubernetes-dynamic-pv-3271ffcb4e1811e8   1Gi
    RWO            cinder         3s

5.1.5. Populateurs de volume

Les créateurs de volumes utilisent le champ datasource dans une demande de volume persistant (PVC) pour créer des volumes pré-remplis.

La population de volume est actuellement activée et prise en charge en tant que fonctionnalité d'aperçu technologique. Cependant, OpenShift Container Platform n'est pas livré avec des populateurs de volume.

Important

Les populateurs de volume sont une fonctionnalité d'aperçu technologique uniquement. Les fonctionnalités de l'aperçu technologique ne sont pas prises en charge par les accords de niveau de service (SLA) de production de Red Hat et peuvent ne pas être complètes sur le plan fonctionnel. Red Hat ne recommande pas leur utilisation en production. Ces fonctionnalités offrent un accès anticipé aux fonctionnalités des produits à venir, ce qui permet aux clients de tester les fonctionnalités et de fournir un retour d'information pendant le processus de développement.

Pour plus d'informations sur la portée de l'assistance des fonctionnalités de l'aperçu technologique de Red Hat, voir Portée de l'assistance des fonctionnalités de l'aperçu technologique.

Pour plus d'informations sur les populateurs de volume, voir Populateurs de volume Kubernetes.

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.