4.4. Stockage persistant à l'aide de Cinder
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.
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
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.
ImportantNe 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.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
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>
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.