Provisionnement de revendications de volume persistant dans le service de volumes par blocs

Vous pouvez provisionner dynamiquement un volume par blocs à l'aide du plugiciel CSI spécifié par la définition de la classe de stockage oci-bv (provisioner: blockvolume.csi.oraclecloud.com). Par exemple, si l'administrateur de grappe n'a créé aucun volume persistant approprié correspondant à la demande de PVC.

La revendication de volume persistant est définie dans un fichier nommé csi-bvs-pvc.yaml. Par exemple :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mynginxclaim
spec:
  storageClassName: "oci-bv"
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Entrez la commande suivante pour créer la revendication de volume persistant à partir du fichier csi-bvs-pvc.yaml :

kubectl create -f  csi-bvs-pvc.yaml

La sortie de la commande ci-dessus confirme la création de la revendication de volume persistant :

persistentvolumeclaim "mynginxclaim" created

Vérifiez que la revendication de volume persistant a été créée en exécutant kubectl get pvc :

kubectl get pvc

La sortie de la commande ci-dessus montre l'état courant de la revendication de volume persistant :

		
NAME               STATUS   VOLUME   CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Pending                                    oci-bv         4m

La PVC a le statut Pending car la définition de la classe de stockage oci-bv inclut volumeBindingMode: WaitForFirstConsumer.

Vous pouvez utiliser cette revendication de volume persistant lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un nouveau pod à partir de la définition de pod suivante, qui demande au système d'utiliser la revendication de volume persistant mynginxclaim en tant que volume nginx, monté par le pod sur /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: mynginxclaim

Après avoir créé le nouveau pod, vous pouvez vérifier que la revendication de volume persistant a été liée à un nouveau volume persistant en entrant :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la revendication de volume persistant a été liée :

			
NAME               STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
mynginxclaim       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv         4m

Vous pouvez vérifier que le pod utilise la nouvelle revendication de volume persistant en entrant :

kubectl describe pod nginx

Vous pouvez afficher les statistiques de capacité du nouveau volume persistant à l'aide d'un outil d'agrégation de mesures tel que Prometheus.

Un instantané de volume Kubernetes est un instantané d'un volume persistant sur un système de stockage. Vous pouvez utiliser un instantané de volume pour provisionner un nouveau volume persistant. Pour plus d'informations sur les instantanés de volume Kubernetes, voir Instantanés de volume dans la documentation sur Kubernetes.

Lorsque vous utilisez le plugiciel de volume CSI pour connecter des grappes à des volumes par blocs dans le service de volume par blocs, vous pouvez utiliser des sauvegardes de volume par blocs pour provisionner des instantanés de volume Kubernetes. Vous pouvez utiliser un instantané de volume pour créer un nouveau volume par blocs et le préalimenter avec des données provenant de la sauvegarde de volume par blocs. Pour plus d'informations sur les sauvegardes de volume par blocs dans le service de volume par blocs, voir Aperçu des sauvegardes de volume par blocs.

Vous pouvez utiliser le plugiciel de volume CSI pour provisionner un instantané de volume de l'une des deux façons suivantes :

• Dynamiquement : Vous pouvez demander la création d'une sauvegarde du provisionnement d'un volume par blocs persistant. Vous spécifiez la revendication de volume persistant à l'aide de l'objet VolumeSnapshot et vous spécifiez les paramètres à utiliser pour créer la sauvegarde de volume par blocs à l'aide de l'objet VolumeSnapshotClass. Les instantanés de volume provisionnés dynamiquement sont également appelés instantanés de volume dynamiques. Voir Création d'instantanés de volume provisionnés dynamiquement.
• Statiquement : Vous pouvez fournir les détails d'une sauvegarde de volume par blocs existante à l'aide de l'objet VolumeSnapshotContent. Les instantanés de volume provisionnés statiquement sont également appelés instantanés de volume statique, et instantanés de volume préprovisionnés. Création d'instantanés de volume provisionnés statiquement

Lorsque vous créez un instantané de volume provisionné dynamiquement, les mêmes marqueurs à structure libre et marqueurs définis qui ont été appliqués au volume par blocs source sont appliqués à la sauvegarde du volume par blocs. Toutefois, vous pouvez utiliser des paramètres pour appliquer des marqueurs supplémentaires à la sauvegarde de volume par blocs (voir Marquage des sauvegardes de volume par blocs).

Il existe un certain nombre de préalables à respecter avant de créer des instantanés de volume à utiliser avec les grappes créées par le moteur Kubernetes. Voir Préalables à la création d'instantanés de volume.

Notez ce qui suit lors de la création et de l'utilisation d'instantanés de volume :

• Vous ne pouvez créer des instantanés de volume que lorsque vous utilisez le plugiciel de volume CSI (c'est-à-dire que vous ne pouvez pas créer d'instantanés de volume lorsque vous utilisez le plugiciel de volume FlexVolume).
• Dans le cas des sauvegardes de volume dynamiques, le plugiciel de volume CSI crée une nouvelle sauvegarde de volume par blocs pour provisionner un instantané de volume dynamique dans le même compartiment que la grappe. Dans le cas d'instantanés de volume statiques, le provisionnement d'un instantané de volume statique par la sauvegarde du volume par blocs peut se trouver dans un compartiment différent de celui de la grappe, à condition que des énoncés de politique appropriés existent pour permettre à la grappe d'accéder à cet autre compartiment (voir Préalables à la création d'instantanés de volume).
• Vous ne pouvez pas utiliser le plugiciel de volume CSI pour recharger un volume existant avec des données. En d'autres termes, vous ne pouvez pas restaurer (rétablir) les données d'un volume persistant existant à un état antérieur en modifiant l'instantané de volume spécifié dans le manifeste de la revendication de volume persistant. Vous ne pouvez utiliser le plugiciel de volume CSI que pour alimenter un nouveau volume avec des données.
• Lorsque vous créez une sauvegarde de volume par blocs (par exemple, lors de la création d'un instantané de volume dynamique), la clé de chiffrement utilisée lors de la création du volume par blocs est également utilisée pour créer la sauvegarde de volume par blocs. Vous ne pouvez pas spécifier une nouvelle clé de chiffrement lors de la création d'une sauvegarde de volume par blocs. La sauvegarde de volume par blocs utilise donc le même chiffrement que le volume par blocs qu'elle sauvegarde.
• La taille spécifiée pour un volume persistant provisionné par un instantané de volume ne doit pas être inférieure à la taille du volume initial à partir duquel l'instantané a été créé.
• Lorsque le plugiciel de volume CSI crée un nouveau volume par blocs pour sauvegarder un volume persistant provisionné par un instantané de volume, le positionnement du volume par blocs dépend des exigences de topologie de la demande de création de volume. Par exemple, si le plugiciel de volume CSI crée un volume par blocs pour un pod qui utilise une revendication de volume persistant, le volume par blocs est créé dans le même domaine de disponibilité que le noeud de travail sur lequel le pod est exécuté.
• Les instantanés inter-espaces de noms ne sont pas pris en charge.
• À mesure que le nombre d'objets VolumeSnapshot et VolumeSnapshotContent dans une grappe augmente, ils peuvent consommer de l'espace important dans etcd, ce qui peut entraîner un comportement de grappe inattendu. Pour que la grappe reste saine, nous vous recommandons de mettre en oeuvre un mécanisme d'épuration pour nettoyer régulièrement les objets VolumeSnapshot et VolumeSnapshotContent qui ne sont plus requis.

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml

kubectl apply -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml

ALLOW any-user to manage volume-backups in compartment <compartment-name> where request.principal.type = 'cluster'
ALLOW any-user to use volumes in compartment <compartment-name> where request.principal.type = 'cluster'

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: sample-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: "oci-bv"
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvctobackup.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: sample-pvc

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
deletionPolicy: Delete

kubectl create -f csi-mysnapshotclass.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-snapshot
  namespace: default
spec:
  volumeSnapshotClassName: my-snapclass
  source:
    persistentVolumeClaimName: sample-pvc

kubectl create -f csi-mysnapshot.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotContent
metadata:
  name: my-static-snapshot-content
spec:
  deletionPolicy: Retain
  driver: blockvolume.csi.oraclecloud.com
  source:
    snapshotHandle: ocid1.volumebackup.oc1.iad.aaaaaa______xbd
  volumeSnapshotRef:
    name: my-static-snapshot
    namespace: default

kubectl create -f csi-mystaticsnapshotcontent.yaml

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: my-static-snapshot
spec:
  source:
    volumeSnapshotContentName: my-static-snapshot-content

kubectl create -f csi-mystaticsnapshot.yaml

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fromsnapshot
  namespace: default
spec:
  storageClassName: oci-bv
  dataSource:
    name: test-snapshot
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

kubectl create -f csi-mypvcfromsnapshot.yaml

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod-restore
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /data
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: pvc-fromsnapshot

oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'

oci.oraclecloud.com/defined-tags: '{"<tag-namespace>": {"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}}'

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
  backupType: full
  oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'
deletionPolicy: Delete

Un clone de Kubernetes est un double exact d'un volume persistant existant sur un système de stockage. Vous pouvez cloner un volume persistant existant pour provisionner une nouvelle revendication de volume persistant. Le nouveau volume persistant contient une copie des données du volume persistant source, mais il est indépendant du volume persistant source. Vous pouvez utiliser des clones de volume pour tester rapidement les modifications de configuration, sans aucune incidence sur un environnement de production. Pour plus d'informations sur les clones Kubernetes, voir Clonage de volume CSI dans la documentation sur Kubernetes.

Dans le service de volume par blocs, vous pouvez cloner un volume par blocs pour créer un nouveau volume par blocs préalimenté avec des données du volume par blocs source. Pour plus d'informations sur le clonage de volumes par blocs dans le service de volume par blocs, voir Clonage d'un volume par blocs.

Lorsque vous utilisez le plugiciel de volume CSI pour connecter des grappes aux volumes par blocs du service de volume par blocs, vous pouvez provisionner une nouvelle revendication de volume persistant avec un nouveau volume par blocs qui a été cloné à partir d'un volume par blocs existant provisionnant une autre revendication de volume persistant existante. Pour indiquer que vous voulez que le plugiciel de volume CSI clone le volume par blocs existant pour la nouvelle revendication de volume persistant, vous spécifiez la revendication de volume persistant existante comme source de données pour la nouvelle revendication de volume persistant.

La nouvelle revendication de volume persistant peut être utilisée de la même manière que n'importe quelle autre revendication de volume persistant et est entièrement distincte de la revendication de volume persistant existante spécifiée comme source de données. De même, le nouveau volume par blocs et le volume par blocs existant à partir duquel il est cloné sont des ressources entièrement distinctes qui peuvent être mises à jour, clonées, instantanées et supprimées indépendamment l'une de l'autre.

Dès que le volume par blocs source a été cloné et qu'un nouveau volume par blocs a été créé (généralement en quelques secondes), le nouveau volume par blocs a l'état Disponible. Toutes les données présentes dans le volume par blocs source à ce moment sont copiées vers le nouveau volume par blocs (aucune modification ultérieure n'est copiée). Toutefois, les données sont copiées en arrière-plan, ce qui peut prendre jusqu'à trente minutes en fonction de la taille du volume par blocs (par exemple, la copie d'un volume par blocs de 1 To peut prendre jusqu'à quinze minutes). Par conséquent, pour éviter la possibilité d'erreurs ou de corruption de données, la nouvelle revendication de volume persistant a l'état En attente jusqu'à ce que toutes les données aient été copiées. Lorsque toutes les données ont été copiées, la nouvelle revendication de volume persistant est liée à la valeur actualisée provisionnée par le nouveau volume par blocs et la nouvelle revendication de volume persistant a l'état Disponible.

Il existe un certain nombre de préalables à respecter avant de provisionner une nouvelle revendication de volume persistant en clonant le volume par blocs qui provisionne déjà une revendication de volume persistant existante. Voir Préalables au clonage d'un volume par blocs existant pour provisionner une nouvelle revendication de volume persistant.

Notez ce qui suit lors du clonage d'un volume par blocs pour provisionner une nouvelle revendication de volume persistant :

• Le plugiciel de volume CSI crée le nouveau volume par blocs dans le même domaine de disponibilité, la même région et la même location que le volume par blocs source.
• Le nouveau volume par blocs créé par le plugiciel de volume CSI peut lui-même être cloné dès qu'il a l'état Disponible.
• Toutes les exigences de topologie dans une demande de création de volume sont ignorées. Par exemple, si le plugiciel de volume CSI clone un volume par blocs pour un pod qui utilise une revendication de volume persistant, le nouveau volume par blocs est créé dans le même domaine de disponibilité que le noeud de travail sur lequel le pod est exécuté.
• Vous ne pouvez pas utiliser le plugiciel de volume CSI pour cloner des volumes par blocs créés par le plugiciel de volume FlexVolume.
• Vous ne pouvez pas supprimer la revendication de volume persistant source lorsque le clonage est en cours. De même, vous ne pouvez pas supprimer un volume par blocs source lorsque des données sont copiées vers un volume par blocs qui a été cloné à partir de celui-ci.
• Le clonage inter-espaces de noms n'est pas pris en charge. La nouvelle revendication de volume persistant et la revendication de volume persistant source doivent toutes deux se trouver dans le même espace de noms.
• Vous n'avez pas besoin de spécifier explicitement une classe de stockage pour la nouvelle revendication de volume persistant. Si vous spécifiez explicitement une classe de stockage pour la nouvelle revendication de volume persistant, la classe de stockage que vous spécifiez peut être différente de la classe de stockage spécifiée pour la revendication de volume persistant source. Si vous ne spécifiez pas de classe de stockage pour la nouvelle revendication de volume persistant, la classe de stockage par défaut est utilisée.

Par exemple, vous définissez une revendication de volume persistant nommée my-clone-pvc dans un fichier nommé csi-myclonepvc.yaml. La revendication de volume persistant my-clone-pvc est provisionnée par un volume par blocs créé par clonage du volume par blocs qui provisionne la revendication de volume persistant my-source-pvc :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-clone-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: custom-clone-storage-class
  resources:
    requests:
      storage: 50Gi
  dataSource:
    kind: PersistentVolumeClaim
    name: my-source-pvc

Créez une revendication de volume persistant :

kubectl create -f csi-myclonepvc.yaml

Vous pouvez utiliser la revendication de volume persistant lors de la définition d'autres objets, tels que des pods. Par exemple, la définition de pod suivante demande au système d'utiliser la revendication de volume persistant my-clone-pvc en tant que volume nginx, monté par le pod sur /sample-volume.

apiVersion: v1
kind: Pod
metadata:
  name: sample-pod
spec:
  containers:
    - name: sample-nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: sample-volume
  volumes:
  - name: sample-volume
    persistentVolumeClaim:
      claimName: my-clone-pvc

Après avoir créé le nouveau pod, la revendication de volume persistant my-clone-pvc est liée à un nouveau volume persistant provisionné par un volume par blocs qui a été cloné à partir du provisionnement du volume par blocs de la revendication de volume persistant my-source-pvc.

Vous pouvez créer une revendication de volume persistant à partir d'un volume par blocs existant ou d'une sauvegarde de volume par blocs pour une utilisation par le plugiciel de volume FlexVolume. Par exemple, si l'administrateur de grappe a créé une sauvegarde de volume par blocs à utiliser lors du provisionnement d'une nouvelle revendication de volume persistant. Une telle sauvegarde de volume par blocs peut être fournie avec des données prêtes à être utilisées par d'autres objets tels que des pods.

La PVC est définie dans un fichier nommé flex-pvcfrombackup.yaml. Vous utilisez l'élément d'annotation volume.beta.kubernetes.io/oci-volume-source pour spécifier la source du volume par blocs à utiliser lors du provisionnement d'une nouvelle revendication de volume persistant à l'aide du plugiciel de volume FlexVolume. Vous pouvez spécifier l'OCID d'un volume par blocs ou d'une sauvegarde de volume par blocs en tant que valeur de l'annotation. Dans cet exemple, vous spécifiez l'OCID de la sauvegarde de volume par blocs créée par l'administrateur de la grappe. Par exemple :

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myvolume
  annotations:
    volume.beta.kubernetes.io/oci-volume-source: ocid1.volumebackup.oc1.iad.abuw...
spec:
  selector:
    matchLabels:
      topology.kubernetes.io/zone: US-ASHBURN-AD-1
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Notez que le fichier flex-pvcfrombackup.yaml comprend l'élément matchLabels, qui n'est applicable que dans le cas du plugiciel de volume FlexVolume.

Entrez la commande suivante pour créer la revendication de volume persistant à partir du fichier flex-pvcfrombackup.yaml :

kubectl create -f flex-pvcfrombackup.yaml

La sortie de la commande ci-dessus confirme la création de la revendication de volume persistant :

persistentvolumeclaim "myvolume" created

Vérifiez que la revendication de volume persistant a été créée et liée à un nouveau volume persistant créé à partir de la sauvegarde de volume en entrant :

kubectl get pvc

La sortie de la commande ci-dessus montre l'état courant de la revendication de volume persistant :

			
NAME           STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS   AGE
myvolume       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci            4m

Vous pouvez utiliser le nouveau volume persistant créé à partir de la sauvegarde de volume lors de la définition d'autres objets, tels que des pods. Par exemple, la définition de pod suivante demande au système d'utiliser la revendication de volume persistant myvolume en tant que volume nginx, monté par le pod sur /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: myvolume

Après avoir créé le nouveau pod, vous pouvez vérifier qu'il est en cours d'exécution et qu'il utilise la nouvelle revendication de volume persistant en entrant :

kubectl describe pod nginx

Le service Oracle Cloud Infrastructure Block Volume chiffre toujours tous les volumes par blocs et toutes les sauvegardes de volume au repos à l'aide de l'algorithme Avancé de chiffrement standard (AES) avec un chiffrement de 256 bits. Par défaut, tous les volumes et leurs sauvegardes sont chiffrés au moyen des clés de chiffrement fournies par Oracle. Chaque fois qu'un volume est cloné ou restauré à partir d'une sauvegarde, une nouvelle clé de chiffrement unique lui est affectée.

Vous avez la possibilité de chiffrer tous vos volumes et leurs sauvegardes à l'aide de clés que vous possédez et gérez au moyen du service de chambre forte. Pour plus d'informations, voir Gestion des clés. Si vous ne configurez pas un volume pour l'utilisation du service de chambre forte ou que vous dissociez ultérieurement une clé du volume, le service de volumes par blocs utilise à la place la clé de chiffrement fournie par Oracle. Cela s'applique à la fois au chiffrement au repos et en transit paravirtualisé.

Toutes les données transmises entre l'instance et le volume par blocs passent par un réseau interne très sécurisé. Si vous avez des exigences de conformité spécifiques relatives au chiffrement des données lors du transfert entre l'instance et le volume par blocs, le service Volumes par blocs permet d'activer le chiffrement en transit pour les attachements de volume paravirtualisés dans les instances de machine virtuelle. Certaines formes sans système d'exploitation prennent en charge le chiffrement en transit pour les volumes par blocs attachés iSCSI de l'instance.

Pour plus d'informations sur le chiffrement des volumes par blocs et sur la prise en charge du chiffrement en transit, voir Chiffrement des volumes par blocs.

Lorsque les PVC Kubernetes sont soutenus par le service de volume par blocs, vous choisissez comment les volumes par blocs sont chiffrés en spécifiant :

• Clé de chiffrement principale à utiliser, en définissant la propriété kms-key-id dans la définition de la classe de stockage Kubernetes. Vous pouvez spécifier l'OCID d'une clé de chiffrement principale dans le service de chambre forte.
• Comment le volume par blocs est attaché à l'instance de calcul, en réglant la propriété attachment-type dans la définition de la classe de stockage Kubernetes à iscsi ou à paravirtualized.
• Indique si le chiffrement en transit est activé pour chaque groupe de noeuds d'une grappe, en définissant la propriété isPvEncryptionInTransitEnabled du groupe de noeuds (à l'aide de l'interface de ligne de commande, de l'API ou de l'option Utiliser le chiffrement en transit : du groupe de noeuds dans la console).

L'interaction des paramètres que vous spécifiez détermine comment les volumes par blocs sont chiffrés, comme indiqué dans le tableau :

Avant de créer une grappe pour laquelle vous voulez gérer vous-même la clé de chiffrement principale, vous devez :

• Créez une clé de chiffrement principale appropriée dans la chambre forte (ou obtenez l'OCID d'une telle clé). Voir Gestion des clés.
• Créez une politique accordant l'accès à la clé de chiffrement principale. Voir Créer une politique pour accéder aux clés de chiffrement gérées par l'utilisateur pour chiffrer les volumes de démarrage, les volumes par blocs ou les systèmes de fichiers.

Pour plus d'informations sur la rotation des clés dans le service de chambre forte, voir Rotation d'une clé de chambre forte.

Lorsqu'une revendication de volume persistant est créée à l'aide du plugiciel de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez étendre la taille du volume en ligne. Ainsi, vous pouvez d'abord déployer des applications avec une certaine quantité de stockage, puis augmenter le stockage disponible sans aucun temps d'arrêt.

Si vous voulez prendre en charge les augmentations de demande de stockage, définissez allowVolumeExpansion: true dans la définition de la classe de stockage que vous spécifiez pour la revendication de volume persistant. Par exemple :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: my-bv
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  attachment-type: "paravirtualized"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true

La classe de stockage oci-bv par défaut pour le plugiciel de volume CSI comporte allowVolumeExpansion: true par défaut.

Pour développer la taille d'un volume, modifiez le manifeste en PVC et mettez à jour la taille du volume, puis appliquez le manifeste. Lorsque le disque est ensuite balayé pour permettre au système d'exploitation d'identifier la taille de volume étendue (ce qui peut prendre quelques minutes), l'espace de stockage augmenté est automatiquement disponible pour les pods utilisant la revendication de volume persistant. Il n'est pas nécessaire de redémarrer les pods.

Entrez la commande suivante pour confirmer que la revendication de volume persistant a été liée à un volume par blocs nouvellement agrandi :

kubectl get pvc <pvc_name> -o yaml

Notez ce qui suit :

• L'extension de volume est prise en charge dans les grappes exécutant Kubernetes version 1.19 ou ultérieure.
• La classe de stockage oci-bv par défaut pour le plugiciel de volume CSI est configurée avec allowVolumeExpansion: true dans les grappes exécutant Kubernetes 1.19 ou une version ultérieure. Les définitions des classes de stockage oci-bv dans les grappes existantes exécutant Kubernetes 1.19 ou une version ultérieure sont automatiquement modifiées pour définir allowVolumeExpansion: true.
• Vous ne pouvez pas réduire la taille d'un volume par blocs. Vous ne pouvez spécifier qu'une valeur supérieure à la taille courante du volume par blocs. Si vous mettez à jour un manifeste de PVC pour demander moins de stockage que précédemment demandé, la demande de stockage échoue.
• Pour plus d'informations sur l'augmentation de la taille des volumes par blocs dans le service de volume par blocs, voir Redimensionnement d'un volume. En particulier, il est recommandé de créer une sauvegarde avant de redimensionner un volume par blocs.

Les volumes par blocs du service de volume par blocs peuvent être configurés pour différents niveaux de performance, en fonction des exigences d'E/S de charge de travail attendues. La performance des volumes par blocs est exprimée en unités de performance de volume (VPU). Plusieurs niveaux de performance sont disponibles, notamment :

• Coût réduit (0 UPV)
• Équilibre (10 UPV)
• Performance élevée (20 UPV)
• Ultra-haute performance (entre 30 UPV et 120 UPV)

Par défaut, les volumes par blocs sont configurés pour le niveau de performance Équilibre (10 UPV). Pour plus d'informations sur les différents niveaux de performance des volumes par blocs, voir Niveaux de performance des volumes par blocs.

Lorsque vous définissez une revendication de volume persistant à l'aide du plugiciel de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez spécifier un niveau de performance de volume par blocs différent dans la définition de la classe de stockage, qui convient à la charge de travail attendue.

Notez que vous ne pouvez pas modifier ultérieurement le niveau de performance d'un volume par blocs prenant en charge une revendication de volume persistant. Vous devez plutôt définir une nouvelle classe de stockage, définir le niveau de performance requis et créer une nouvelle revendication de volume persistant provisionnée par cette nouvelle classe de stockage.

Les volumes par blocs du service de volume par blocs peuvent être configurés pour différents types de système de fichiers. Le système de fichiers le plus approprié à utiliser dépend (entre autres) de la taille de fichier attendue et du nombre de fichiers à traiter. Plusieurs types de système de fichiers sont disponibles, notamment :

• ext3 : Le type de système de fichiers ext3 inclut des fonctions de journalisation pour améliorer la fiabilité et la disponibilité. Les contrôles de cohérence après une panne de courant ou un arrêt non contrôlé du système sont inutiles.
• ext4 : En plus des fonctions ext3, le type de système de fichiers ext4 prend en charge les extents (blocs physiques contigus), la pré-affectation, l'affectation différée, la vérification plus rapide du système de fichiers, la journalisation plus robuste et d'autres améliorations.
• XFS : Le système de fichiers XFS est un type de système de fichiers de journalisation haute performance, qui offre une grande évolutivité pour les unités d'exécution d'E/S, la bande passante du système de fichiers, la taille des fichiers et du système de fichiers, même lorsque le système de fichiers couvre de nombreux périphériques de stockage.

Les systèmes de fichiers ext3 et ext4 sont généralement considérés comme mieux adaptés aux applications qui utilisent une seule unité d'exécution de lecture/écriture et de petits fichiers. Alors que, le système de fichiers XFS est généralement considéré comme mieux adapté pour les applications qui ont plusieurs threads de lecture/écriture et des fichiers plus volumineux.

Lorsqu'une revendication de volume persistant est créée à l'aide du plugiciel de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez spécifier un type de système de fichiers pour le volume par blocs approprié pour la charge de travail attendue.

Par défaut, les volumes par blocs sont configurés avec un système de fichiers ext4. Si le système de fichiers ext4 n'est pas le système de fichiers le plus approprié pour la charge de travail attendue, vous pouvez spécifier un autre type de système de fichiers dans la définition de la classe de stockage.

Pour créer une revendication de volume persistant soutenue par un volume par blocs avec un système de fichiers ext3 ou XFS, définissez le paramètre fstype dans la définition de la classe de stockage personnalisée comme suit :

• pour ext3, définissez csi.storage.k8s.io/fstype: ext3
• pour XFS, définissez csi.storage.k8s.io/fstype: xfs

Par exemple, pour créer une revendication de volume persistant soutenue par un volume par blocs avec un système de fichiers ext3 :

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: oci-bv-ext3
provisioner: blockvolume.csi.oraclecloud.com
parameters:
  csi.storage.k8s.io/fstype: ext3
reclaimPolicy: Retain
allowVolumeExpansion: true
volumeBindingMode: WaitForConsumer

Créez un manifeste pour une revendication de volume persistant provisionnée par la classe de stockage oci-bv-ext3 et incluez une demande de stockage. Par exemple, dans un fichier nommé csi-bvs-pvc-fstype.yaml :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: oci-bv-claim-ext3
spec:
  storageClassName: oci-bv-ext3
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi

Entrez la commande suivante pour créer la PVC à partir du fichier csi-bvs-PVC-fstype.yaml :

kubectl apply -f csi-bvs-pvc-fstype.yaml

Après avoir créé la PVC, vous pouvez l'utiliser lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un nouveau pod à partir de la définition de pod suivante, qui demande au système d'utiliser la PVC oci-bv-claim-ext3 en tant que volume nginx, monté par le pod sur /data.

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
    - name: nginx
      image: nginx:latest
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: oci-bv-claim-ext3

Après avoir créé le nouveau pod, vous pouvez vérifier que la revendication de volume persistant a été liée à un nouveau volume persistant en entrant :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la revendication de volume persistant a été liée :

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
oci-bv-claim-ext3       Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv-ext3         4m

Vous pouvez vérifier que le pod utilise la nouvelle revendication de volume persistant en entrant :

kubectl describe pod nginx

Notez que vous ne pouvez pas modifier ultérieurement le système de fichiers d'un volume par blocs prenant en charge une revendication de volume persistant. Vous devez plutôt définir une nouvelle classe de stockage, définir le système de fichiers comme requis et créer une nouvelle revendication de volume persistant provisionnée par cette nouvelle classe de stockage.

Lorsque vous utilisez le plugiciel de volume CSI (provisioner: blockvolume.csi.oraclecloud.com) pour connecter des grappes à des volumes par blocs dans le service de volume par blocs, vous pouvez lier une revendication de volume persistant à une valeur ajoutée provisionnée par un volume par blocs configuré en tant que volume par blocs brut. Lorsqu'un volume par blocs a été configuré en tant que volume par blocs brut, plutôt qu'en tant que système de fichiers monté, une réserve de disponibilité provisionnée par ce volume par blocs s'affiche en tant que périphérique par blocs pour les conteneurs s'exécutant sur une grappe. Par conséquent, les applications qui s'exécutent à l'intérieur du conteneur peuvent accéder au volume par blocs attaché en tant que périphérique par blocs, sans la surcharge de performances causée par l'accès au périphérique au moyen d'un système de fichiers. Cette surcharge peut être particulièrement importante pour les applications sensibles aux performances (telles que les bases de données) qui bénéficient d'un accès direct aux périphériques de traitement par blocs.

Pour configurer le volume par blocs qui sauvegarde une revendication de volume persistant en tant que volume par blocs brut, spécifiez volumeMode: Block dans le manifeste de revendication de volume persistant. Notez que si elle n'est pas spécifiée, volumeMode: Filesystem est supposé et les volumes par blocs sont configurés avec un système de fichiers ext4 par défaut.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-raw-block-volume
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 50Gi
  storageClassName: oci-bv
  volumeMode: Block

Entrez la commande suivante pour créer la PVC à partir du fichier csi-bvs-PVC-raw.yaml :

kubectl apply -f csi-bvs-pvc-raw.yaml

Après avoir créé la PVC, vous pouvez l'utiliser lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un nouveau pod à partir de la définition de pod suivante, qui indique au système d'utiliser la revendication de volume persistant PVC-raw-block-volume comme volume de stockage pour le conteneur raw-volume-test, auquel le conteneur peut accéder à l'adresse /dev/block :

apiVersion: v1
kind: Pod
metadata:
  name: raw-volume-test-pod
spec:
  containers:
  - name: raw-volume-test
    image: centos
    command: ["/bin/sh"]
    volumeDevices:
    - name: raw-volume
      devicePath: /dev/block
  volumes:
  - name: raw-volume
    persistentVolumeClaim:
      claimName: pvc-raw-block-volume

Après avoir créé le nouveau pod, vous pouvez vérifier que la revendication de volume persistant a été liée à un nouveau volume persistant en entrant :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la revendication de volume persistant a été liée :

			
NAME                    STATUS    VOLUME                               CAPACITY   ACCESSMODES   STORAGECLASS        AGE
pvc-raw-block-volume    Bound     ocid1.volume.oc1.iad.<unique_ID>     50Gi       RWO           oci-bv              4m

Vous pouvez vérifier que le pod utilise la nouvelle revendication de volume persistant en entrant :

kubectl describe pod raw-volume-test-pod

Notez que vous ne pouvez pas modifier ultérieurement si le volume par blocs prenant en charge une revendication de volume persistant est configuré en tant que volume par blocs brut ou en tant que système de fichiers monté. À la place, vous devez créer une nouvelle revendication de volume persistant et définir volumeMode: de manière appropriée dans le manifeste de revendication de volume persistant.