3.3. Volumes persistants
Chaque PV contient un spec et un status, qui sont les spécifications et l'état du volume, par exemple :
PersistentVolume exemple de définition d'objet
apiVersion: v1 kind: PersistentVolume metadata: name: pv0001 1 spec: capacity: storage: 5Gi 2 accessModes: - ReadWriteOnce 3 persistentVolumeReclaimPolicy: Retain 4 ... status: ...
3.3.1. Types de PV
OpenShift Container Platform prend en charge les plugins de volumes persistants suivants :
- Disque AliCloud
- AWS Elastic Block Store (EBS)
- AWS Elastic File Store (EFS)
- Disque Azure
- Fichier Azure
- Cendres
- Fibre Channel
- Disque persistant GCP
- Dépôt de fichiers GCP
- IBM VPC Block
- Chemin d'accès
- iSCSI
- Volume local
- NFS
- OpenStack Manille
- Red Hat OpenShift Data Foundation
- VMware vSphere
3.3.2. Capacité
En général, un volume persistant (PV) a une capacité de stockage spécifique. Celle-ci est définie à l'aide de l'attribut capacity du PV.
Actuellement, la capacité de stockage est la seule ressource qui peut être définie ou demandée. À l'avenir, les attributs pourront inclure l'IOPS, le débit, etc.
3.3.3. Modes d'accès
Un volume persistant peut être monté sur un hôte de n'importe quelle manière prise en charge par le fournisseur de ressources. Les fournisseurs ont des capacités différentes et les modes d'accès de chaque PV sont définis en fonction des modes spécifiques pris en charge par ce volume particulier. Par exemple, NFS peut prendre en charge plusieurs clients en lecture-écriture, mais un PV NFS spécifique peut être exporté sur le serveur en lecture seule. Chaque PV dispose de son propre ensemble de modes d'accès décrivant ses capacités spécifiques.
Les demandes sont associées à des volumes dont les modes d'accès sont similaires. Les deux seuls critères de correspondance sont les modes d'accès et la taille. Les modes d'accès d'une demande représentent une requête. Par conséquent, il se peut que l'on vous accorde plus, mais jamais moins. Par exemple, si une requête demande RWO, mais que le seul volume disponible est un PV NFS (RWO ROX RWX), la requête correspondra alors à NFS parce qu'il prend en charge RWO.
Les correspondances directes sont toujours tentées en premier. Les modes du volume doivent correspondre ou contenir plus de modes que ce que vous avez demandé. La taille doit être supérieure ou égale à celle attendue. Si deux types de volumes, tels que NFS et iSCSI, disposent du même ensemble de modes d'accès, l'un ou l'autre peut correspondre à une demande avec ces modes. Il n'y a pas d'ordre entre les types de volumes et il n'y a aucun moyen de choisir un type plutôt qu'un autre.
Tous les volumes présentant les mêmes modes sont regroupés, puis triés par taille, du plus petit au plus grand. Le relieur récupère le groupe dont les modes correspondent et itère sur chacun d'entre eux, par ordre de taille, jusqu'à ce qu'une taille corresponde.
Le tableau suivant énumère les modes d'accès :
| Mode d'accès | Abréviation CLI | Description |
|---|---|---|
| ReadWriteOnce |
| Le volume peut être monté en lecture-écriture par un seul nœud. |
| ReadOnlyMany |
| Le volume peut être monté en lecture seule par de nombreux nœuds. |
| Lecture/écriture/nombre |
| Le volume peut être monté en lecture-écriture par de nombreux nœuds. |
Les modes d'accès aux volumes sont des descripteurs des capacités des volumes. Il ne s'agit pas de contraintes imposées. Le fournisseur de stockage est responsable des erreurs d'exécution résultant d'une utilisation non valide de la ressource.
Par exemple, NFS propose le mode d'accès ReadWriteOnce. Vous devez marquer les revendications comme read-only si vous voulez utiliser la capacité ROX du volume. Les erreurs dans le fournisseur apparaissent au moment de l'exécution comme des erreurs de montage.
les volumes iSCSI et Fibre Channel ne disposent actuellement d'aucun mécanisme de clôture. Vous devez vous assurer que les volumes ne sont utilisés que par un seul nœud à la fois. Dans certaines situations, comme la vidange d'un nœud, les volumes peuvent être utilisés simultanément par deux nœuds. Avant de vider le nœud, assurez-vous d'abord que les pods qui utilisent ces volumes sont supprimés.
| Plugin de volume | ReadWriteOnce [1] | ReadOnlyMany | Lecture/écriture/nombre |
|---|---|---|---|
| Disque AliCloud |
✅ |
- |
- |
| AWS EBS [2] |
✅ |
- |
- |
| AWS EFS |
✅ |
✅ |
✅ |
| Fichier Azure |
✅ |
✅ |
✅ |
| Disque Azure |
✅ |
- |
- |
| Cendres |
✅ |
- |
- |
| Fibre Channel |
✅ |
✅ |
- |
| Disque persistant GCP |
✅ |
- |
- |
| Dépôt de fichiers GCP |
✅ |
✅ |
✅ |
| Chemin d'accès |
✅ |
- |
- |
| Disque IBM VPC |
✅ |
- |
- |
| iSCSI |
✅ |
✅ |
- |
| Volume local |
✅ |
- |
- |
| NFS |
✅ |
✅ |
✅ |
| OpenStack Manille |
- |
- |
✅ |
| Red Hat OpenShift Data Foundation |
✅ |
- |
✅ |
| VMware vSphere |
✅ |
- |
✅ [3] |
- Les volumes ReadWriteOnce (RWO) ne peuvent pas être montés sur plusieurs nœuds. Si un nœud tombe en panne, le système n'autorise pas le montage du volume RWO attaché sur un nouveau nœud, car il est déjà affecté au nœud en panne. Si vous obtenez un message d'erreur d'attachement multiple, forcez la suppression du pod sur un nœud arrêté ou en panne afin d'éviter toute perte de données dans les charges de travail critiques, par exemple lorsque des volumes dynamiques persistants sont attachés.
- Utilisez une stratégie de déploiement par recréation pour les pods qui dépendent d'AWS EBS.
-
Si l'environnement vSphere sous-jacent prend en charge le service de fichiers vSAN, l'opérateur vSphere Container Storage Interface (CSI) Driver Operator installé par OpenShift Container Platform prend en charge le provisionnement des volumes ReadWriteMany (RWX). Si le service de fichiers vSAN n'est pas configuré et que vous demandez RWX, le volume n'est pas créé et une erreur est consignée. Pour plus d'informations, voir "Using Container Storage Interface"
"VMware vSphere CSI Driver Operator".
3.3.4. Phase
Les volumes peuvent être trouvés dans l'une des phases suivantes :
| Phase | Description |
|---|---|
| Disponible | Une ressource libre qui n'est pas encore liée à une demande. |
| Liaison | Le volume est relié à une réclamation. |
| Libéré | La demande a été supprimée, mais la ressource n'a pas encore été récupérée par le cluster. |
| Échec | La récupération automatique du volume a échoué. |
Vous pouvez afficher le nom du PVC lié à la PV en exécutant la commande suivante
$ oc get pv <pv-claim>
3.3.4.1. Options de montage
Vous pouvez spécifier des options de montage lors du montage d'un PV en utilisant l'attribut mountOptions.
Par exemple :
Exemple d'options de montage
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0001
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
mountOptions: 1
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2
persistentVolumeReclaimPolicy: Retain
claimRef:
name: claim1
namespace: default
- 1
- Les options de montage spécifiées sont utilisées lors du montage du PV sur le disque.
Les types de PV suivants prennent en charge les options de montage :
- AWS Elastic Block Store (EBS)
- Disque Azure
- Fichier Azure
- Cendres
- Disque persistant de la CME
- iSCSI
- Volume local
- NFS
- Red Hat OpenShift Data Foundation (Ceph RBD uniquement)
- VMware vSphere
Les PV Fibre Channel et HostPath ne prennent pas en charge les options de montage.
Ressources supplémentaires
