Chapitre 5. Utilisation de l'interface de stockage des conteneurs (CSI)
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.
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.
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
VolumeSnapshotetVolumeSnapshotContentet est responsable de la création et de la suppression de l'objetVolumeSnapshotContent. -
Le conteneur resizer est un conteneur sidecar qui surveille les mises à jour de
PersistentVolumeClaimet déclenche des opérationsControllerExpandVolumecontre un point de terminaison CSI si vous demandez plus d'espace de stockage sur l'objetPersistentVolumeClaim. -
Un conteneur d'attachement CSI externe traduit les appels
attachetdetachd'OpenShift Container Platform en appelsControllerPublishetControllerUnpublishrespectifs au pilote CSI. -
Un conteneur externe de provisionneur CSI qui traduit les appels
provisionetdeleted'OpenShift Container Platform en appelsCreateVolumeetDeleteVolumeau 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.
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.
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-nodefonctionnant sur le nœud. Le processusopenshift-nodeexé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.
| Pilote CSI | Instantanés de volumes CSI | Clonage CSI | Redimensionnement 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.
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
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.
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.
