3.4. Demandes de volume persistantes
Chaque objet PersistentVolumeClaim contient un spec et un status, qui correspondent à la spécification et à l'état de la revendication de volume persistant (PVC), par exemple :
PersistentVolumeClaim exemple de définition d'objet
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim 1 spec: accessModes: - ReadWriteOnce 2 resources: requests: storage: 8Gi 3 storageClassName: gold 4 status: ...
3.4.1. Classes de stockage
Les revendications peuvent éventuellement demander une classe de stockage spécifique en spécifiant le nom de la classe de stockage dans l'attribut storageClassName. Seuls les PV de la classe demandée, ceux qui ont le même storageClassName que le PVC, peuvent être liés au PVC. L'administrateur de cluster peut configurer des provisionneurs dynamiques pour desservir une ou plusieurs classes de stockage. L'administrateur de cluster peut créer un PV à la demande qui correspond aux spécifications du PVC.
L'opérateur de stockage en cluster peut installer une classe de stockage par défaut en fonction de la plate-forme utilisée. Cette classe de stockage est détenue et contrôlée par l'opérateur. Elle ne peut pas être supprimée ou modifiée au-delà de la définition des annotations et des étiquettes. Si vous souhaitez un comportement différent, vous devez définir une classe de stockage personnalisée.
L'administrateur du cluster peut également définir une classe de stockage par défaut pour tous les PVC. Lorsqu'une classe de stockage par défaut est configurée, le PVC doit demander explicitement des annotations StorageClass ou storageClassName définies sur "" pour être lié à un PV sans classe de stockage.
Si plusieurs classes de stockage sont marquées comme étant par défaut, un PVC ne peut être créé que si l'adresse storageClassName est explicitement spécifiée. Par conséquent, une seule classe de stockage doit être définie par défaut.
3.4.2. Modes d'accès
Les revendications utilisent les mêmes conventions que les volumes pour demander un stockage avec des modes d'accès spécifiques.
3.4.3. Ressources
Les demandes, telles que les pods, peuvent demander des quantités spécifiques d'une ressource. Dans ce cas, il s'agit d'une demande de stockage. Le même modèle de ressource s'applique aux volumes et aux demandes.
3.4.4. Réclamations en volume
Les pods accèdent au stockage en utilisant la revendication comme un volume. Les revendications doivent exister dans le même espace de noms que le module qui les utilise. Le cluster trouve la revendication dans l'espace de noms du module et l'utilise pour obtenir le site PersistentVolume qui soutient la revendication. Le volume est monté sur l'hôte et dans le module, par exemple :
Monter le volume sur l'hôte et dans le pod exemple
kind: Pod
apiVersion: v1
metadata:
name: mypod
spec:
containers:
- name: myfrontend
image: dockerfile/nginx
volumeMounts:
- mountPath: "/var/www/html" 1
name: mypd 2
volumes:
- name: mypd
persistentVolumeClaim:
claimName: myclaim 3
- 1
- Chemin d'accès pour monter le volume à l'intérieur du module.
- 2
- Nom du volume à monter. Ne montez pas sur la racine du conteneur,
/, ni sur un chemin identique sur l'hôte et le conteneur. Cela peut corrompre votre système hôte si le conteneur est suffisamment privilégié, comme l'hôte/dev/ptsfiles. Vous pouvez monter l'hôte en toute sécurité en utilisant/host. - 3
- Nom du PVC, qui existe dans le même espace de noms, à utiliser.
