Provisionnement des demandes de volume persistant dans le service Block Volume

Vous pouvez provisionner un volume de blocs de façon dynamique à l'aide du module d'extension CSI indiqué par la définition de la classe de stockage oci-bv (provisioner: blockvolume.csi.oraclecloud.com). Par exemple, si l'administrateur de cluster n'a créé aucun volume persistant correspondant à la demande.

Définissez une demande de volume persistant dans un fichier appelé 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 demande 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 demande de volume persistant :

persistentvolumeclaim "mynginxclaim" created

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

kubectl get pvc

La sortie de la commande ci-dessus indique le statut en cours de la demande 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 demande de volume persistant lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un pod à partir de la définition de pod suivante, qui indique au système d'utiliser la demande de volume persistant mynginxclaim comme volume nginx, monté par le pod dans /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 pod, vous pouvez vérifier que la demande de volume persistant a été liée à un nouveau volume persistant en saisissant la commande suivante :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la demande 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 demande de volume persistant en saisissant ce qui suit :

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, reportez-vous à Instantanés de volume dans la documentation Kubernetes.

Lorsque vous utilisez le module d'extension de volume CSI pour connecter des clusters à des volumes de blocs dans le service Block Volume, vous pouvez utiliser des sauvegardes de volume de blocs pour provisionner des clichés de volume Kubernetes. Vous pouvez utiliser un cliché de volume pour créer un volume de blocs et le préremplir avec les données de la sauvegarde de volume de blocs. Pour plus d'informations sur les sauvegardes de volume de blocs dans le service Block Volume, reportez-vous à Présentation des sauvegardes de volume de blocs.

Vous pouvez utiliser le module d'extension de volume CSI pour provisionner un instantané de volume de l'une des deux manières suivantes :

• Dynamiquement : vous pouvez demander la création d'une sauvegarde du volume de blocs provisionnant un volume persistant. Vous indiquez la demande de volume persistant à l'aide de l'objet VolumeSnapshot et les paramètres à utiliser pour créer la sauvegarde de volume de blocs à l'aide de l'objet VolumeSnapshotClass. Les instantanés de volume provisionnés dynamiquement sont également appelés instantanés de volume dynamiques. Reportez-vous à Création d'instantanés de volume provisionnés dynamiquement.
• Statiquement : vous pouvez fournir des détails sur une sauvegarde de volume de blocs existante à l'aide de l'objet VolumeSnapshotContent. Les instantanés de volume provisionnés de manière statique sont également appelés instantanés de volume statiques et instantanés de volume pré-provisionnés. Création d'instantanés de volume provisionnés de manière statique

Lorsque vous créez un cliché de volume provisionné dynamiquement, les mêmes balises à format libre et les mêmes balises définies qui ont été appliquées au volume de blocs source sont appliquées à la sauvegarde de volume de blocs. Toutefois, vous pouvez utiliser des paramètres pour appliquer des balises supplémentaires à la sauvegarde de volume de blocs (reportez-vous à Balisage des sauvegardes de volume de blocs).

Vous devez respecter un certain nombre de prérequis avant de créer des clichés de volume à utiliser avec les clusters créés par Kubernetes Engine. Reportez-vous à Prérequis pour la création de clichés de volume.

Tenez compte des points suivants lors de la création et de l'utilisation d'instantanés de volume :

• Vous pouvez uniquement créer des instantanés de volume lorsque vous utilisez le module d'extension de volume CSI (c'est-à-dire que vous ne pouvez pas créer des instantanés de volume lorsque vous utilisez le module d'extension de volume FlexVolume).
• Dans le cas de sauvegardes de volume dynamiques, le module d'extension de volume CSI crée une sauvegarde de volume de blocs pour provisionner un cliché de volume dynamique dans le même compartiment que le cluster. Dans le cas des clichés de volume statique, la sauvegarde de volume de blocs provisionnant un cliché de volume statique peut se trouver dans un autre compartiment que le cluster, à condition que des instructions de stratégie appropriées existent pour permettre au cluster d'accéder à cet autre compartiment (reportez-vous à Prérequis pour la création de clichés de volume).
• Vous ne pouvez pas utiliser le module d'extension de volume CSI pour remplir à nouveau 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 dans un état antérieur en modifiant l'instantané de volume spécifié dans le manifeste de la réclamation de volume persistant. Vous pouvez uniquement utiliser le module d'extension de volume CSI pour remplir un nouveau volume avec des données.
• Lorsque vous créez une sauvegarde de volume de blocs (par exemple, lors de la création d'un cliché de volume dynamique), la clé de cryptage utilisée lors de la création du volume de blocs est également utilisée pour créer la sauvegarde de volume de blocs. Vous ne pouvez pas indiquer de nouvelle clé de cryptage lors de la création d'une sauvegarde de volume de blocs. La sauvegarde de volume de blocs utilise donc le même cryptage que le volume de 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 d'origine à partir duquel l'instantané a été créé.
• Lorsque le module d'extension de volume CSI crée un volume de blocs pour sauvegarder un volume persistant provisionné par un instantané de volume, le placement du volume de blocs dépend des exigences de topologie de la demande de création de volume. Par exemple, si le module d'extension de volume CSI crée un volume de blocs pour un pod qui utilise une demande de volume persistant, le volume de blocs est créé dans le même domaine de disponibilité que le noeud de processus actif sur lequel le pod est exécuté.
• Les instantanés inter-espaces de noms ne sont pas pris en charge.
• Au fur et à mesure que le nombre d'objets VolumeSnapshot et VolumeSnapshotContent dans un cluster augmente, ils peuvent consommer un espace important dans etcd, ce qui peut entraîner un comportement inattendu du cluster. Pour maintenir le cluster en bon état, nous vous recommandons d'implémenter un mécanisme de purge afin de 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 Kubernetes est un doublon exact d'un volume persistant existant sur un système de stockage. Vous pouvez cloner un volume persistant existant pour provisionner une nouvelle demande 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 impact sur un environnement de production. Pour plus d'informations sur les clones Kubernetes, reportez-vous à Clonage de volume CSI dans la documentation Kubernetes.

Dans le service Block Volume, vous pouvez cloner un volume de blocs pour créer un volume de blocs prérempli avec des données du volume de blocs source. Pour plus d'informations sur le clonage de volumes de blocs dans le service Block Volume, reportez-vous à Clonage d'un volume de blocs.

Lorsque vous utilisez le module d'extension de volume CSI pour connecter des clusters à des volumes de blocs dans le service Block Volume, vous pouvez provisionner une nouvelle demande de volume persistant avec un nouveau volume de blocs cloné à partir d'un volume de blocs existant provisionnant une autre demande de volume persistant existante. Pour indiquer que vous voulez que le module d'extension de volume CSI clone le volume de blocs existant pour la nouvelle demande de volume persistant, indiquez la demande de volume persistant existante comme source de données pour la nouvelle demande de volume persistant.

Le nouveau PVC peut être utilisé de la même manière que tout autre PVC, et est entièrement séparé du PVC existant spécifié comme source de données. De même, le nouveau volume de blocs et le volume de blocs existant à partir duquel il est cloné sont des ressources entièrement distinctes. Ils peuvent être mis à jour, clonés, instantanés et supprimés indépendamment l'un de l'autre.

Dès que le volume de blocs source a été cloné et qu'un nouveau volume de blocs a été créé (généralement dans quelques secondes), le nouveau volume de blocs a l'état Disponible. Toutes les données présentes dans le volume de blocs source à ce moment-là sont copiées dans le nouveau volume de blocs (aucune modification ultérieure n'est copiée). Cependant, la copie des données en arrière-plan peut prendre jusqu'à trente minutes en fonction de la taille du volume de blocs (par exemple, la copie d'un volume de blocs de 1 To peut prendre jusqu'à quinze minutes). Par conséquent, pour éviter tout risque d'erreur ou d'altération des données, le nouveau PVC a l'état En attente jusqu'à ce que toutes les données aient été copiées. Une fois toutes les données copiées, la nouvelle demande de volume persistant est liée à la demande de volume persistant provisionnée par le nouveau volume de blocs et la nouvelle demande de volume persistant présente l'état Disponible.

Un certain nombre de prérequis doivent être respectés avant de provisionner une nouvelle demande de volume persistant en clonant le volume de blocs qui provisionne déjà une demande de volume persistant existante. Reportez-vous à Prérequis pour le clonage d'un volume de blocs existant afin de provisionner une nouvelle demande de volume persistant.

Lors du clonage d'un volume de blocs pour provisionner une nouvelle demande de volume persistant, tenez compte des points suivants :

• Le module d'extension de volume CSI crée le volume de blocs dans le même domaine de disponibilité, la même région et la même location que le volume de blocs source.
• Le nouveau volume de blocs créé par le module d'extension de volume CSI peut lui-même être cloné dès qu'il a l'état Disponible.
• Les exigences de topologie d'une demande de création de volume sont ignorées. Par exemple, si le module d'extension de volume CSI clone un volume de blocs pour un pod qui utilise une demande de volume persistant, le nouveau volume de blocs est créé dans le même domaine de disponibilité que le noeud de processus actif sur lequel le pod est exécuté.
• Vous ne pouvez pas utiliser le module d'extension de volume CSI pour cloner des volumes de blocs créés par le module d'extension de volume FlexVolume.
• Vous ne pouvez pas supprimer la demande de volume persistant source lorsque le clonage est en cours. De même, vous ne pouvez pas supprimer un volume de blocs source lorsque des données sont copiées vers un volume de blocs qui en a été cloné.
• Le clonage d'espaces de noms croisés n'est pas pris en charge. La nouvelle demande de volume persistant et la demande 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 demande de volume persistant. Si vous spécifiez explicitement une classe de stockage pour la nouvelle demande 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 demande de volume persistant source. Si vous n'indiquez pas de classe de stockage pour la nouvelle demande de volume persistant, la classe de stockage par défaut est utilisée.

Par exemple, vous définissez une demande de volume persistant nommée my-clone-pvc dans un fichier appelé csi-myclonepvc.yaml. La demande de volume persistant my-clone-pvc est provisionnée par un volume de blocs créé en clonant le volume de blocs qui provisionne la demande 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 la demande de volume persistant :

kubectl create -f csi-myclonepvc.yaml

Vous pouvez utiliser la demande de volume persistant lors de la définition d'autres objets, tels que des pods. Par exemple, la définition de pod suivante indique au système d'utiliser la demande de volume persistant my-clone-pvc comme volume nginx, monté par le pod dans /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

Une fois le pod créé, la demande de volume persistant my-clone-pvc est liée à un nouveau volume persistant provisionné par un volume de blocs qui a été cloné à partir du volume de blocs provisionnant la demande de volume persistant my-source-pvc.

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

Définissez une PVC dans un fichier appelé flex-pvcfrombackup.yaml. Utilisez l'élément d'annotation volume.beta.kubernetes.io/oci-volume-source pour indiquer la source du volume de blocs à utiliser lors du provisionnement d'une nouvelle demande de volume persistant à l'aide du module d'extension de volume FlexVolume. Vous pouvez indiquer l'OCID d'un volume de blocs ou d'une sauvegarde de volume de blocs comme valeur de l'annotation. Dans cet exemple, indiquez l'OCID de la sauvegarde de volume de blocs créée par l'administrateur de cluster. 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

Le fichier flex-pvcfrombackup.yaml inclut l'élément matchLabels, qui n'est applicable que dans le cas du module d'extension de volume FlexVolume.

Entrez la commande suivante pour créer la demande 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 demande de volume persistant :

persistentvolumeclaim "myvolume" created

Vérifiez que la demande de volume persistant a été créée et liée à un volume persistant créé à partir de la sauvegarde de volume en saisissant la commande suivante :

kubectl get pvc

La sortie de la commande ci-dessus indique le statut en cours de la demande 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 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 indique au système d'utiliser la demande de volume persistant myvolume comme volume nginx, monté par le pod dans /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 pod, vous pouvez vérifier qu'il est en cours d'exécution et qu'il utilise la nouvelle demande de volume persistant en saisissant la commande suivante :

kubectl describe pod nginx

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

Vous avez la possibilité de crypter tous vos volumes et leurs sauvegardes à l'aide des clés que vous possédez et gérez à l'aide du service Vault. Pour plus d'informations, reportez-vous à Key Management. Si vous ne configurez pas un volume pour qu'il utilise le service Vault ou si vous annulez ultérieurement l'affectation d'une clé au volume, le service Block Volume utilise à la place la clé de cryptage fournie par Oracle. Ceci s'applique au cryptage au repos et au cryptage en transit paravirtualisé.

Toutes les données déplacées entre l'instance et le volume de blocs sont transférées via un réseau interne hautement sécurisé. Si vous avez des exigences de conformité spécifiques liées au cryptage des données pendant leur déplacement entre l'instance et le volume de blocs, le service Block Volume fournit une option d'activation du cryptage en transit pour les attachements de volume paravirtualisés sur les instances de machine virtuelle. Certaines formes Bare Metal prennent en charge le cryptage en transit pour les volumes de blocs attachés iSCSI de l'instance.

Pour plus d'informations sur le cryptage de volume de blocs et sur la prise en charge du cryptage en transit, reportez-vous à Cryptage de volume de blocs.

Lorsque les demandes de volume persistant Kubernetes sont soutenues par le service Block Volume, vous choisissez le mode de cryptage des volumes de blocs en indiquant les éléments suivants :

• Clé de cryptage maître à utiliser, en définissant la propriété kms-key-id dans la définition de la classe de stockage Kubernetes. Vous pouvez indiquer l'OCID d'une clé de cryptage maître dans le service Vault.
• Mode d'attachement du volume de blocs à l'instance de calcul, en définissant la propriété attachment-type dans la définition de la classe de stockage Kubernetes sur iscsi ou paravirtualized.
• Indique si le cryptage en transit est activé pour chaque pool de noeuds d'un cluster, en définissant la propriété isPvEncryptionInTransitEnabled du pool de noeuds (à l'aide de l'interface de ligne de commande, de l'API ou de l'option Utiliser le cryptage en transit : du pool de noeuds dans la console).

L'interaction des paramètres que vous indiquez détermine le mode de cryptage des volumes de blocs, comme indiqué dans le tableau suivant :

Pour pouvoir créer un cluster pour lequel vous voulez gérer vous-même la clé de cryptage maître, vous devez effectuer les opérations suivantes :

• Créez une clé de cryptage maître appropriée dans Vault (ou obtenez l'OCID d'une telle clé). Reportez-vous à Gestion des clés.
• Créez une stratégie accordant l'accès à la clé de cryptage maître. Reportez-vous à Création d'une stratégie pour accéder aux clés de cryptage gérées par l'utilisateur pour le cryptage de volumes d'initialisation, de volumes de blocs et/ou de systèmes de fichiers

Pour plus d'informations sur la rotation des clés dans le service Vault, reportez-vous à Rotation d'une clé Vault.

Lorsqu'une demande de volume persistant est créée à l'aide du module d'extension de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez étendre la taille de volume en ligne. Ce faisant, vous pouvez déployer initialement 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 indiquez pour la demande 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 du module d'extension de volume CSI comporte allowVolumeExpansion: true par défaut.

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

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

kubectl get pvc <pvc_name> -o yaml

Tenez compte des éléments suivants :

• L'extension de volume est prise en charge dans les clusters exécutant Kubernetes 1.19 ou une version ultérieure.
• La classe de stockage oci-bv par défaut du module d'extension de volume CSI est configurée avec allowVolumeExpansion: true dans les clusters exécutant Kubernetes 1.19 ou une version ultérieure. Les définitions des classes de stockage oci-bv dans les clusters existants 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 de blocs. Vous pouvez uniquement indiquer une valeur plus élevée que la taille actuelle du volume de blocs. Si vous mettez à jour un manifeste PVC pour demander moins de stockage que ce qui avait été demandé précédemment, la demande de stockage échoue.
• Pour plus d'informations sur l'augmentation de la taille des volumes de blocs dans le service Block Volume, reportez-vous à Redimensionnement d'un volume. Notez en particulier la recommandation de créer une sauvegarde avant de redimensionner un volume de blocs.

Les volumes de blocs dans le service Block Volume peuvent être configurés pour différents niveaux de performances, en fonction des exigences d'E/S de charge de travail attendues. Les performances de volume de blocs sont exprimées en unités de performance de volume (VPU). Plusieurs niveaux de performances sont disponibles, notamment :

• Réduction des coûts (0 VPU)
• Equilibré (10 VPU)
• Performances supérieures (20 VPU)
• Performances très élevées (entre 30 VPU et 120 VPU)

Par défaut, les volumes de blocs sont configurés pour le niveau de performances Equilibré (10 VPU). Pour plus d'informations sur les différents niveaux de performances de volume de blocs, reportez-vous à Niveaux de performances de volume de blocs.

Lorsque vous définissez une demande de volume persistant à l'aide du module d'extension de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez indiquer dans la définition de classe de stockage un niveau de performances de volume de blocs différent adapté à la charge globale attendue.

Vous ne pouvez pas modifier ultérieurement le niveau de performances d'un volume de blocs soutenant une demande de volume persistant. Au lieu de cela, vous devez définir une nouvelle classe de stockage, définir le niveau de performances requis et créer une nouvelle PVC provisionnée par cette nouvelle classe de stockage.

Les volumes de blocs dans le service Block Volume 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èmes de fichiers sont disponibles, notamment :

• ext3 : le type de système de fichiers ext3 inclut des fonctionnalités 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 ne sont pas nécessaires.
• ext4 : en plus des fonctionnalités ext3, le type de système de fichiers ext4 prend en charge les extents (blocs physiques contigus), la pré-allocation, l'allocation retardé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 à hautes performances, qui offre une évolutivité élevée pour les threads d'E/S, la bande passante du système de fichiers, la taille des fichiers et des systèmes 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 un seul thread de lecture/écriture et de petits fichiers. En revanche, le système de fichiers XFS est généralement considéré comme mieux adapté aux applications qui disposent de plusieurs threads de lecture/écriture et de fichiers plus volumineux.

Lorsqu'une demande de volume persistant est créée à l'aide du module d'extension de volume CSI (provisioner: blockvolume.csi.oraclecloud.com), vous pouvez indiquer pour le volume de blocs un type de système de fichiers approprié à la charge globale attendue.

Par défaut, les volumes de 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 globale attendue, vous pouvez indiquer un autre type de système de fichiers dans la définition de la classe de stockage.

Pour créer une demande de volume persistant soutenue par un volume de blocs avec un système de fichiers ext3 ou XFS, définissez le paramètre fstype dans la définition de 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 demande de volume persistant soutenue par un volume de blocs avec un système de fichiers ext3, procédez comme suit :

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 demande de volume persistant provisionnée par la classe de stockage oci-bv-ext3 et incluez une demande de stockage. Par exemple, dans un fichier appelé 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

Une fois la PVC créée, vous pouvez l'utiliser lors de la création d'autres objets, tels que des pods. Par exemple, vous pouvez créer un pod à partir de la définition de pod suivante, qui indique au système d'utiliser la PVC oci-bv-claim-ext3 comme volume nginx, monté par le pod dans /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 pod, vous pouvez vérifier que la demande de volume persistant a été liée à un nouveau volume persistant en saisissant la commande suivante :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la demande 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 demande de volume persistant en saisissant ce qui suit :

kubectl describe pod nginx

Vous ne pouvez pas modifier ultérieurement le système de fichiers d'un volume de blocs soutenant une demande de volume persistant. Au lieu de cela, vous devez définir une nouvelle classe de stockage, définir le système de fichiers comme requis et créer une nouvelle PVC provisionnée par cette nouvelle classe de stockage.

Lorsque vous utilisez le module d'extension de volume CSI (provisioner: blockvolume.csi.oraclecloud.com) pour connecter des clusters à des volumes de blocs dans le service Block Volume, vous pouvez lier une demande de volume persistant à une valeur PV provisionnée par un volume de blocs configuré en tant que volume de blocs brut. Lorsqu'un volume de blocs a été configuré en tant que volume de blocs brut, plutôt qu'en tant que système de fichiers monté, un PV provisionné par ce volume de blocs apparaît en tant qu'unité de blocs pour les conteneurs exécutés sur un cluster. Par conséquent, les applications en cours d'exécution dans le conteneur peuvent accéder au volume de blocs attaché en tant qu'unité de blocs, sans les surcharges de performances dues à l'accès à l'unité via 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 unités de blocs.

Pour configurer le volume de blocs qui soutient une demande de volume persistant en tant que volume de blocs brut, spécifiez volumeMode: Block dans le manifeste de demande de volume persistant. S'il n'est pas indiqué, volumeMode: Filesystem est supposé et les volumes de 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 demande de volume persistant à 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 pod à partir de la définition de pod suivante, qui indique au système d'utiliser la demande de volume persistant PVC-raw-block-volume comme volume de stockage pour le conteneur de test de volume brut, 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 pod, vous pouvez vérifier que la demande de volume persistant a été liée à un nouveau volume persistant en saisissant la commande suivante :

kubectl get pvc

La sortie de la commande ci-dessus confirme que la demande 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 demande de volume persistant en saisissant ce qui suit :

kubectl describe pod raw-volume-test-pod

Vous ne pouvez pas modifier ultérieurement si le volume de blocs qui soutient une demande de volume persistant est configuré en tant que volume de blocs brut ou en tant que système de fichiers monté. Au lieu de cela, vous devez créer une demande de volume persistant et définir volumeMode: de manière appropriée dans le manifeste de demande de volume persistant.