Provisionnement des demandes de volume persistant dans le service File Storage

Lorsque vous utilisez le service File Storage pour provisionner des demandes de volume persistant, vous indiquez le cryptage en transit indépendamment du cryptage au repos.

Le service File Storage crypte toujours les données inactives à l'aide de clés de cryptage gérées par Oracle par défaut. Toutefois, vous avez la possibilité d'indiquer le cryptage au repos à l'aide de vos propres clés de cryptage maître que vous gérez vous-même dans le service Vault. La procédure de spécification du cryptage au repos dépend du provisionnement ou non d'une demande de volume persistant sur :

• un nouveau système de fichiers créé dynamiquement par le module d'extension de volume CSI (reportez-vous à Cryptage de données inactives sur un nouveau système de fichiers)
• un système de fichiers existant que vous avez créé manuellement (reportez-vous à la section Encrypting Data At Rest on an Existing File System)

Pour gérer vos propres clés de cryptage maître afin de crypter les données inactives, vous devez :

• 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

Le service File Storage peut éventuellement crypter les données en transit. Si vous indiquez un cryptage en transit, les données en transit sont cryptées à l'aide d'un certificat TLS (Transport Layer Security) toujours géré par Oracle, que les données inactives soient cryptées à l'aide de clés gérées par Oracle ou à l'aide de clés gérées par l'utilisateur. Le cryptage en transit sécurise les données transférées entre les instances et les systèmes de fichiers montés à l'aide du cryptage TLS version 1.2. Pour plus d'informations sur le cryptage en transit et le service File Storage, reportez-vous à Utilisation du cryptage TLS en transit. Le mode de spécification du cryptage en transit dépend du provisionnement ou non d'une demande de volume persistant sur :

• un nouveau système de fichiers créé dynamiquement par le module d'extension de volume CSI (reportez-vous à Cryptage de données en transit sur un nouveau système de fichiers)
• un système de fichiers existant que vous avez créé manuellement (reportez-vous à Cryptage de données en transit sur un système de fichiers existant)

Lorsque vous utilisez le service File Storage pour provisionner des demandes de volume persistant, le cryptage en transit est pris en charge uniquement lorsque les instances de calcul hébergeant des noeuds de processus actif exécutent Oracle Linux 7 et Oracle Linux 8.

Pour provisionner dynamiquement une demande de volume persistant sur un nouveau système de fichiers créé dynamiquement par le module d'extension de volume CSI dans le service File Storage, procédez comme suit :

1. (Facultatif) Créez une cible de montage dans le service File Storage. Reportez-vous à Création d'une cible de montage.

   Le module d'extension de volume CSI requiert une cible de montage active (c'est-à-dire une cible de montage avec une adresse IP affectée) pour créer un système de fichiers. Si vous ne créez pas de cible de montage à l'avance, indiquez le sous-réseau dans lequel le module d'extension de volume CSI doit créer une cible de montage lorsque vous définissez la classe de stockage.

2. Définissez une nouvelle classe de stockage qui utilise le provisionneur fss.csi.oraclecloud.com :
   1. Créez un fichier manifeste (par exemple, dans un fichier nommé fss-dyn-st-class.yaml), indiquez le nom de la nouvelle classe de stockage et indiquez les valeurs des paramètres obligatoires et facultatifs :

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: <storage-class-name>
      provisioner: fss.csi.oraclecloud.com
      parameters:
        availabilityDomain: <ad-name>
        mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>
        compartmentOcid: <compartment-ocid>
        kmsKeyOcid: <key-ocid>
        exportPath: <path>
        exportOptions: "[{<options-in-json-format>}]"
        encryptInTransit: "true"|"false"
        oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}'
        oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}'

      où :

      • name: <storage-class-name> : requis. Nom de votre choix pour la classe de stockage.
      • availabilityDomain: <ad-name> : requis. Nom du domaine de disponibilité dans lequel créer le système de fichiers (et dans lequel créer la cible de montage, si aucun OCID de cible de montage existant n'est indiqué). Par exemple, US-ASHBURN-AD-1. Pour connaître le nom de domaine de disponibilité à utiliser, exécutez la commande de l'interface de ligne de commande oci iam availability-domain list (ou utilisez l'opération ListAvailabilityDomains). Pour plus d'informations, reportez-vous à Noms de domaine de disponibilité de votre location.
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid> : requis. OCID d'une cible de montage active existante (mountTargetOcid: <mt-ocid>) ou OCID d'un sous-réseau dans lequel créer une cible de montage (mountTargetSubnetOcid: <mt-subnet-ocid>). Indiquez mountTargetOcid ou mountTargetSubnetOcid. Si vous indiquez mountTargetOcid et mountTargetSubnetOcid dans la définition de classe de stockage, la cible de montage existante indiquée par mountTargetOcid est utilisée et mountTargetSubnetOcid est ignoré. Par exemple :
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid> : facultatif. OCID du compartiment auquel le nouveau système de fichiers (et la nouvelle cible de montage, si aucun OCID de cible de montage existant n'est indiqué) doit appartenir. S'il n'est pas indiqué, il s'agit par défaut du même compartiment que le cluster. Par exemple, compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
      • kmsKeyOcid: <key-ocid> : facultatif. OCID d'une clé de cryptage maître que vous gérez, avec laquelle crypter les données inactives. Si aucune valeur n'est indiquée, les données sont cryptées lorsqu'elles sont inactives à l'aide de clés de cryptage gérées par Oracle. Reportez-vous à la section Encrypting Data At Rest on a New File System. Par exemple, kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
      • exportPath: <path> : facultatif. Chemin d'un export qui identifie de manière unique le système de fichiers sur la cible de montage. Le chemin d'export doit commencer par une barre oblique (/) suivie d'une séquence d'éléments (de zéro à plusieurs) séparés par des barres obliques. Par exemple, /FileSystem1. Pour plus d'informations, reportez-vous à Chemins dans les systèmes de fichiers.

        Si vous incluez exportPath: <path> dans une définition de classe de stockage, n'indiquez pas de chemin (en tant que chemin ou sous-chemin d'un chemin existant) qui existe déjà. Si vous indiquez un chemin qui existe déjà, une erreur est renvoyée car plusieurs systèmes de fichiers avec la même cible de montage ne peuvent pas avoir le même chemin d'export. Par conséquent, si vous incluez exportPath: <path> dans la définition de classe de stockage, utilisez uniquement cette définition de classe de stockage pour créer un système de fichiers.

        Si vous n'incluez pas exportPath: <path> dans la définition de classe de stockage, le chemin est par défaut le nom d'affichage du système de fichiers créé par le module d'extension de volume CSI (en commençant par /csi-fss-).

      • exportOptions: "[{<options-in-json-format>}]" Facultatif. Ensemble de paramètres (au format JSON valide) dans l'export qui indique le niveau d'accès accordé aux clients NFS lorsqu'ils se connectent à une cible de montage. Au sein d'un export, une entrée d'options d'export NFS peut définir l'accès à une adresse IP unique ou à une plage de blocs CIDR. Pour plus d'informations, reportez-vous à Utilisation des exportations et des options d'export NFS. Si aucune valeur n'est indiquée, la valeur par défaut suivante est utilisée :

        exportOptions: "[{\"source\":\"0.0.0.0/0\",\"requirePrivilegedSourcePort\":false,\"access\":\"READ_WRITE\",\"identitySquash\":\"NONE\"}]"

      • encryptInTransit: "true"|"false" : facultatif. Indique si les données doivent être chiffrées en transit. Si vous indiquez "true", veillez à effectuer les étapes de configuration décrites à la section Cryptage de données en transit sur un nouveau système de fichiers. S'il n'est pas spécifié, la valeur par défaut est "false". Par exemple : encryptInTransit: "true".
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Facultatif. Spécifie une balise définie pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'

        Pour appliquer des balises définies à partir d'un espace de noms de balise appartenant à un compartiment à une ressource de système de fichiers appartenant à un autre compartiment, vous devez inclure une instruction de stratégie permettant au cluster d'utiliser l'espace de noms de balise. Reportez-vous à Stratégie IAM supplémentaire lorsqu'un cluster et un espace de noms de balise se trouvent dans des compartiments différents.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Facultatif. Spécifie une balise à format libre pour le nouveau système de fichiers. Par exemple, oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'

      Par exemple :

      kind: StorageClass
      apiVersion: storage.k8s.io/v1
      metadata:
        name: fss-dyn-storage
      provisioner: fss.csi.oraclecloud.com
      parameters:
        availabilityDomain: US-ASHBURN-AD-1
        mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
        kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
        exportPath: /FileSystem1
        exportOptions: "[{\"source\":\"0.0.0.0/0\",\"requirePrivilegedSourcePort\":false,\"access\":\"READ_WRITE\",\"identitySquash\":\"NONE\"}]"
        encryptInTransit: "true"

   2. Créez la classe de stockage à partir du fichier manifeste en saisissant ce qui suit :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-dyn-st-class.yaml

3. Créez des règles de sécurité dans un groupe de sécurité réseau (recommandé) ou une liste de sécurité pour la cible de montage référencée dans la définition de classe de stockage (ou créée par) et pour les noeuds de processus actif du cluster.

   Les règles de sécurité à créer dépendent des emplacements réseau relatifs de la cible de montage et des noeuds de processus actif, selon les scénarios suivants :

   • Scénario B : cible de montage et instance dans le même sous-réseau
   • Scénario A : cible de montage et instance dans des sous-réseaux différents (recommandé)

   Ces scénarios, les règles de sécurité à créer et l'emplacement où les créer, sont entièrement décrits dans la documentation du service File Storage (reportez-vous à Configuration des règles de sécurité VCN pour File Storage).

4. Créez une demande de volume persistant à provisionner par le nouveau système de fichiers dans le service File Storage, comme suit :
   1. Créez un fichier manifeste pour définir la demande de volume persistant :

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: <pvc-name>
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: "<storage-class-name>"
        resources:
          requests:
            storage: 50Gi

      où :

      • name: <pvc-name> : requis. Par exemple, fss-dynamic-claim
      • storageClassName: "<storage-class-name>" : obligatoire. Nom de la classe de stockage que vous avez définie précédemment. Par exemple, fss-dyn-storage.
      • accessModes: - ReadWriteMany : requis. accessModes: doit indiquer ReadWriteMany.
      • storage: 50Gi : requis. Kubernetes requiert que vous indiquiez une valeur pour storage: dans le manifeste de demande de volume persistant. Cependant, le service File Storage ne prend pas en charge la spécification d'une taille de système de fichiers et crée un système de fichiers avec une taille par défaut, quelle que soit la valeur indiquée pour storage:.

      Par exemple, le fichier manifeste suivant (nommé fss-dyn-claim.yaml) définit une demande de volume persistant nommée fss-dynamic-claim provisionnée par le système de fichiers défini dans la classe de stockage fss-dyn-storage :

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: fss-dynamic-claim
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: "fss-dyn-storage"
        resources:
          requests:
            storage: 50Gi

   2. Créez la demande de volume persistant à partir du fichier manifeste en saisissant la commande suivante :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-dyn-claim.yaml

   Un nouveau PVC est créé. Le module d'extension de volume CSI crée un volume persistant et un système de fichiers dans le service File Storage (ainsi qu'une nouvelle cible de montage si vous n'avez pas indiqué de cible de montage existante).

   Le nouveau PVC est lié au nouveau PV. Les données sont cryptées lorsqu'elles sont inactives à l'aide de clés de cryptage gérées par Oracle ou par vous.

5. Vérifiez que la PVC a été liée au nouveau volume persistant en entrant :

   kubectl get pvc

   La sortie de la commande ci-dessus confirme que la demande persistante a été liée avec succès :

   			
   NAME                STATUS    VOLUME                 CAPACITY   ACCESSMODES   STORAGECLASS      AGE
   fss-dynamic-claim   Bound     csi-fss-<unique_ID>    50Gi       RWX           fss-dyn-storage   4m

6. Utilisez la nouvelle PVC 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 :

   apiVersion: v1
   kind: Pod
   metadata:
     name: fss-dynamic-app
   spec:
     containers:
       - name: nginx
         image: nginx:latest
         ports:
           - name: http
             containerPort: 80
         volumeMounts:
           - name: persistent-storage
             mountPath: /usr/share/nginx/html
     volumes:
     - name: persistent-storage
       persistentVolumeClaim:
         claimName: fss-dynamic-claim

7. Après avoir créé un pod comme décrit dans l'exemple de l'étape précédente, vous pouvez vérifier que le pod utilise la nouvelle demande de volume persistant en saisissant ce qui suit :

   kubectl describe pod nginx

Pour créer une demande de volume persistant sur un système de fichiers existant dans le service File Storage (à l'aide de clés de cryptage gérées par Oracle pour crypter les données inactives), procédez comme suit :

1. Créez un système de fichiers avec une cible de montage dans le service File Storage, en sélectionnant l'option de cryptage Crypter à l'aide des clés gérées par Oracle. Reportez-vous à Création d'un système de fichiers.
2. Créez des règles de sécurité dans un groupe de sécurité réseau (recommandé) ou une liste de sécurité à la fois pour la cible de montage qui exporte le système de fichiers et pour les noeuds de processus actif du cluster.
   Les règles de sécurité à créer dépendent des emplacements réseau relatifs de la cible de montage et des noeuds de processus actif, selon les scénarios suivants :

   • Scénario B : cible de montage et instance dans le même sous-réseau
   • Scénario A : cible de montage et instance dans des sous-réseaux différents (recommandé)

   Ces scénarios, les règles de sécurité à créer et l'emplacement où les créer, sont entièrement décrits dans la documentation du service File Storage (reportez-vous à Configuration des règles de sécurité VCN pour File Storage).

3. Créez un PV soutenu par le système de fichiers dans le service File Storage comme suit :

   1. Créez un fichier manifeste pour définir une valeur PV et, dans la section csi:, définissez les éléments suivants :

      • driver à fss.csi.oraclecloud.com
      • volumeHandle à <FileSystemOCID>:<MountTargetIP>:<path>
        où :

        • <FileSystemOCID> est l'OCID du système de fichiers défini dans le service File Storage.
        • <MountTargetIP> est l'adresse IP affectée à la cible de montage.
        • <path> est le chemin de montage vers le système de fichiers par rapport à l'adresse IP de la cible de montage, en commençant par une barre oblique.

        Par exemple : ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      Par exemple, le fichier manifeste suivant (nommé fss-pv.yaml) définit une PV nommée fss-pv soutenue par un système de fichiers dans le service File Storage :

      apiVersion: v1
      kind: PersistentVolume
      metadata:
        name: fss-pv
      spec:
        capacity:
          storage: 50Gi
        volumeMode: Filesystem
        accessModes:
          - ReadWriteMany
        persistentVolumeReclaimPolicy: Retain
        csi:
          driver: fss.csi.oraclecloud.com
          volumeHandle: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

   2. Créez le fichier PV à partir du fichier manifeste en saisissant ce qui suit :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-pv.yaml

4. Créez une PVC provisionnée par la PV que vous avez créée, comme suit :
   1. Créez un fichier manifeste pour définir la demande de volume persistant et définir les éléments suivants :
      • De storageClassName à "". Vous devez indiquer une valeur vide pour storageClassName, même si la classe de stockage n'est pas applicable dans le cas du provisionnement statique du stockage persistant. Si vous n'indiquez pas de valeur vide pour storageClassName, la classe de stockage par défaut (oci-bv) est utilisée, ce qui entraîne une erreur.
      • volumeName pour le nom de la PV que vous avez créée (par exemple, fss-pv)

      Par exemple, le fichier manifeste suivant (nommé fss-pvc.yaml) définit une demande de volume persistant nommée fss-pvc provisionnée par une demande de volume persistant nommée fss-pv :

      apiVersion: v1
      kind: PersistentVolumeClaim
      metadata:
        name: fss-pvc
      spec:
        accessModes:
          - ReadWriteMany
        storageClassName: ""
        resources:
          requests:
            storage: 50Gi
        volumeName: fss-pv

      L'élément requests: storage: doit être présent dans le fichier manifeste de la demande de volume persistant et sa valeur doit correspondre à la valeur spécifiée pour l'élément capacity: storage: dans le fichier manifeste de la demande de volume persistant. En dehors de cela, la valeur de l'élément requests: storage: est ignorée.

   2. Créez la demande de volume persistant à partir du fichier manifeste en saisissant la commande suivante :

      kubectl create -f <filename>

      Par exemple :

      kubectl create -f fss-pvc.yaml

La demande de volume persistant est liée à la demande de modification soutenue par le système de fichiers du service File Storage. Les données sont cryptées lorsqu'elles sont inactives à l'aide de clés de cryptage gérées par Oracle.