Persistent Volume Claims (PVCs) im File Storage-Service bereitstellen

Wenn Sie den File Storage-Service zum Provisioning von PVCs verwenden, geben Sie die Verschlüsselung während der Übertragung unabhängig von der Data-at-Rest-Verschlüsselung an.

Der File Storage-Service verschlüsselt Daten im Ruhezustand immer mit von Oracle verwalteten Verschlüsselungsschlüsseln. Sie haben jedoch die Möglichkeit, die Verschlüsselung im Ruhezustand mit Ihren eigenen Masterverschlüsselungsschlüsseln anzugeben, die Sie selbst im Vault-Service verwalten. Wie Sie die Data-at-Rest-Verschlüsselung angeben, hängt davon ab, ob Sie ein PVC bereitstellen:

• ein neues Dateisystem, das dynamisch vom CSI-Volume-Plug-in erstellt wird (siehe Data At Rest auf einem neuen Dateisystem verschlüsseln)
• ein vorhandenes Dateisystem, das Sie manuell erstellt haben (siehe Data At Rest auf einem vorhandenen Dateisystem verschlüsseln)

Wenn Sie Ihre eigenen Masterverschlüsselungsschlüssel verwalten möchten, um Daten im Ruhezustand zu verschlüsseln, müssen Sie:

• Erstellen Sie einen geeigneten Master-Verschlüsselungsschlüssel in Vault (oder rufen Sie die OCID eines solchen Schlüssels ab). Siehe Schlüssel verwalten.
• Erstellen Sie eine Policy, die Zugriff auf den Masterverschlüsselungsschlüssel erteilt. Siehe Policy zum Zugriff auf benutzerverwaltete Verschlüsselungsschlüssel zum Verschlüsseln von Boot-Volumes, Block-Volumes und/oder Dateisystemen erstellen.

Der File Storage-Service kann Daten während der Übertragung optional verschlüsseln. Wenn Sie Verschlüsselung während der Übertragung angeben, werden Daten während der Übertragung mit einem TLS-(Transport Layer Security-)Zertifikat verschlüsselt, das immer von Oracle verwaltet wird, unabhängig davon, ob Daten im Ruhezustand mit von Oracle verwalteten Schlüsseln oder mit benutzerverwalteten Schlüsseln verschlüsselt werden. Die Verschlüsselung während der Übertragung sichert die Daten, die zwischen Instanzen und gemounteten Dateisystemen mit TLS v. 1.2-Verschlüsselung übertragen werden. Weitere Informationen zur Verschlüsselung während der Übertragung und zum File Storage-Service finden Sie unter TLS-Verschlüsselung während der Übertragung verwenden. Wie Sie die Verschlüsselung während der Übertragung angeben, hängt davon ab, ob Sie ein PVC bereitstellen:

• ein neues Dateisystem, das dynamisch vom CSI-Volume-Plug-in erstellt wird (siehe In Transit befindliche Daten in einem neuen Dateisystem verschlüsseln)
• ein vorhandenes Dateisystem, das Sie manuell erstellt haben (siehe In Transit befindliche Daten in einem vorhandenen Dateisystem verschlüsseln)

Beachten Sie, dass bei Verwendung des File Storage-Service zum Provisioning von PVCs die Verschlüsselung während der Übertragung nur unterstützt wird, wenn die Compute-Instanzen, die Worker-Knoten hosten, Oracle Linux 7 und Oracle Linux 8 ausführen.

So stellen Sie ein PVC dynamisch in einem neuen Dateisystem bereit, das dynamisch vom CSI-Volume-Plug-in im File Storage-Service erstellt wird:

1. (Optional) Erstellen Sie ein Mountziel im File Storage-Service. Siehe Mountziel erstellen.

   Das CSI-Volume-Plug-in erfordert ein aktives Mountziel (d.h. ein Mountziel mit einer zugewiesenen IP-Adresse), um ein neues Dateisystem zu erstellen. Wenn Sie kein Mountziel im Voraus erstellen, geben Sie das Subnetz an, in dem das CSI-Volume-Plug-in beim Definieren der Speicherklasse ein neues Mountziel erstellen soll.

2. Definieren Sie eine neue Speicherklasse, die den Provisioning-Vorgang fss.csi.oraclecloud.com verwendet:
   1. Erstellen Sie eine Manifestdatei (Beispiel: in einer Datei mit dem Namen fss-dyn-st-class.yaml), geben Sie einen Namen für die neue Speicherklasse an, und geben Sie Werte für erforderliche und optionale Parameter an:

      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>"}'

      Hierbei gilt:

      • name: <storage-class-name>: Erforderlich. Ein Name Ihrer Wahl für die Speicherklasse.
      • availabilityDomain: <ad-name>: Erforderlich. Der Name der Availability-Domain, in der das neue Dateisystem erstellt werden soll (und in der das neue Mountziel erstellt werden soll, wenn keine vorhandene Mountziel-OCID angegeben ist). Beispiel: US-ASHBURN-AD-1. Um den zu verwendenden Availability-Domainnamen zu ermitteln, führen Sie den CLI-Befehl oci iam availability-domain list aus (oder verwenden Sie den Vorgang ListAvailabilityDomains). Weitere Informationen finden Sie unter Availability-Domainnamen Ihres Mandanten.
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>: Erforderlich. Entweder die OCID eines vorhandenen aktiven Mountziels (mountTargetOcid: <mt-ocid>) oder die OCID eines Subnetzes, in dem ein neues Mountziel erstellt werden soll (mountTargetSubnetOcid: <mt-subnet-ocid>). Geben Sie entweder mountTargetOcid oder mountTargetSubnetOcid an. Wenn Sie in der Speicherklassendefinition sowohl mountTargetOcid als auch mountTargetSubnetOcid angeben, wird das mit mountTargetOcid angegebene vorhandene Mountziel verwendet, und mountTargetSubnetOcid wird ignoriert. Beispiel:
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid>: Optional. Die OCID des Compartments, zu dem das neue Dateisystem (und das neue Mountziel, wenn keine vorhandene Mountziel-OCID angegeben ist) gehören soll. Wenn keine Angabe gemacht wird, wird standardmäßig dasselbe Compartment wie das Cluster verwendet. Beispiel: compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6q
      • kmsKeyOcid: <key-ocid>: Optional. Die OCID eines von Ihnen verwalteten Masterverschlüsselungsschlüssels, mit dem Daten im Ruhezustand verschlüsselt werden. Wenn keine Angabe gemacht wird, werden die Daten im Ruhezustand mit von Oracle verwalteten Verschlüsselungsschlüsseln verschlüsselt. Siehe Data At Rest auf einem neuen Dateisystem verschlüsseln. Beispiel: kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjh
      • exportPath: <path>: Optional. Der Pfad in einem Export, der das Dateisystem im Mount-Ziel eindeutig identifiziert. Der Exportpfad muss mit einem Schrägstrich (/) beginnen, gefolgt von einer Sequenz aus null oder mehr Elementen, die durch einen Schrägstrich voneinander getrennt sind. Beispiel: /FileSystem1. Weitere Informationen finden Sie unter Pfade in Dateisystemen.

        Wenn Sie exportPath: <path> in eine Speicherklassendefinition aufnehmen, geben Sie keinen Pfad (entweder als Pfad oder als Unterpfad eines vorhandenen Pfads) an, der bereits vorhanden ist. Wenn Sie einen bereits vorhandenen Pfad angeben, wird ein Fehler zurückgegeben, da mehrere Dateisysteme mit demselben Mountziel nicht denselben Exportpfad aufweisen können. Wenn Sie also exportPath: <path> in die Speicherklassendefinition aufnehmen, verwenden Sie diese Speicherklassendefinition nur, um ein Dateisystem zu erstellen.

        Wenn Sie exportPath: <path> nicht in die Speicherklassendefinition aufnehmen, wird standardmäßig der Anzeigename des Dateisystems verwendet, das vom CSI-Volume-Plug-in erstellt wurde (ab /csi-fss-).

      • exportOptions: "[{<options-in-json-format>}]" Optional. Eine Gruppe von Parametern (im gültigen JSON-Format) im Export, die die Zugriffsebene angibt, die NFS-Clients erteilt wird, wenn sie eine Verbindung zu einem Mountziel herstellen. Ein Eintrag für NFS-Exportoptionen innerhalb eines Exports definiert den Zugriff für eine einzelne IP-Adresse oder einen CIDR-Blockbereich. Weitere Informationen finden Sie unter Mit NFS-Exports und -Exportoptionen arbeiten. Wenn nicht angegeben, wird der folgende Standardwert verwendet:

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

      • encryptInTransit: "true"|"false": Optional. Gibt an, ob Daten während der Übertragung verschlüsselt werden. Wenn Sie "true" angeben, müssen Sie die Setupschritte ausführen, die unter In Transit befindliche Daten in einem neuen Dateisystem verschlüsseln beschrieben sind. Wenn keine Angabe gemacht wird, wird standardmäßig "false" verwendet. Beispiel: encryptInTransit: "true".
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}' Optional. Gibt ein definiertes Tag für das neue Dateisystem an. Beispiel: oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'

        Um definierte Tags aus einem Tag-Namespace, der zu einem Compartment gehört, auf eine Dateisystemressource anzuwenden, die zu einem anderen Compartment gehört, müssen Sie eine Policy-Anweisung aufnehmen, damit das Cluster den Tag-Namespace verwenden kann. Siehe Zusätzliche IAM-Policy, wenn sich ein Cluster und ein Tag-Namespace in verschiedenen Compartments befinden.

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}' Optional. Gibt ein Freiformtag für das neue Dateisystem an. Beispiel: oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'

      Beispiel:

      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. Erstellen Sie die Speicherklasse aus der Manifestdatei, indem Sie Folgendes eingeben:

      kubectl create -f <filename>

      Beispiel:

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

3. Erstellen Sie Sicherheitsregeln entweder in einer Netzwerksicherheitsgruppe (empfohlen) oder in einer Sicherheitsliste für das Mountziel, das in der Speicherklassendefinition referenziert (oder von dieser erstellt) wird, sowie für die Worker-Knoten des Clusters.

   Die zu erstellenden Sicherheitsregeln hängen von den relativen Netzwerkspeicherorten des Mountziels und der Worker-Knoten gemäß den folgenden Szenarios ab:

   • Szenario B: Mountziel und Instanz im selben Subnetz
   • Szenario A: Mount-Ziel und Instanz in verschiedenen Subnetzen (empfohlen)

   Diese Szenarios, die zu erstellenden Sicherheitsregeln und die Stelle, an der sie erstellt werden sollen, werden in der Dokumentation zum File Storage-Service ausführlich beschrieben (siehe VCN-Sicherheitsregeln für File Storage konfigurieren).

4. Erstellen Sie wie folgt ein PVC, das vom neuen Dateisystem im File Storage-Service bereitgestellt werden soll:
   1. Erstellen Sie eine Manifestdatei, um den PVC zu definieren:

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

      Hierbei gilt:

      • name: <pvc-name>: Erforderlich. Beispiel: fss-dynamic-claim
      • storageClassName: "<storage-class-name>": Erforderlich. Der Name der Speicherklasse, die Sie zuvor definiert haben. Beispiel: fss-dyn-storage.
      • accessModes: - ReadWriteMany: Erforderlich. Beachten Sie, dass accessModes: ReadWriteMany angeben muss.
      • storage: 50Gi: Erforderlich. Beachten Sie, dass Sie in Kubernetes einen Wert für storage: im PVC-Manifest angeben müssen. Der File Storage-Service unterstützt jedoch nicht die Angabe einer Dateisystemgröße und erstellt ein neues Dateisystem mit einer Standardgröße, unabhängig vom Wert, den Sie für storage: angeben.

      Beispiel: Die folgende Manifestdatei (mit dem Namen fss-dyn-claim.yaml) definiert einen PVC namens fss-dynamic-claim, der von dem Dateisystem bereitgestellt wird, das in der Speicherklasse fss-dyn-storage definiert ist:

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

   2. Erstellen Sie PVC aus der Manifestdatei, indem Sie Folgendes eingeben:

      kubectl create -f <filename>

      Beispiel:

      kubectl create -f fss-dyn-claim.yaml

   Ein neues PVC entsteht. Das CSI-Volume-Plug-in erstellt ein neues persistentes Volume (PV) und ein neues Dateisystem im File Storage-Service (zusammen mit einem neuen Mountziel, wenn Sie kein vorhandenes Mountziel angegeben haben).

   Das neue PVC ist an das neue PV gebunden. Daten werden im Ruhezustand mit Verschlüsselungsschlüsseln verschlüsselt, die entweder von Oracle oder von Ihnen verwaltet werden.

5. Prüfen Sie, ob der PVC an das neue Persistent Volume gebunden wurde, indem Sie Folgendes eingeben:

   kubectl get pvc

   Die Ausgabe des obigen Befehls bestätigt, dass der PVC erfolgreich gebunden wurde:

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

6. Verwenden Sie den neuen PVC beim Erstellen anderer Objekte, wie Pods. Beispiel: Sie können einen neuen Pod aus der folgenden Poddefinition erstellen:

   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. Nachdem Sie einen neuen Pod erstellt haben, wie im Beispiel im vorherigen Schritt beschrieben, können Sie prüfen, ob der Pod den neuen PVC verwendet, indem Sie Folgendes eingeben:

   kubectl describe pod nginx

So erstellen Sie einen PVC in einem vorhandenen Dateisystem im File Storage-Service (mit von Oracle verwalteten Verschlüsselungsschlüsseln zur Verschlüsselung von Data-at-Rest):

1. Erstellen Sie ein Dateisystem mit einem Mountziel im File Storage-Service, und wählen Sie die Verschlüsselungsoption Mit von Oracle verwalteten Schlüsseln verschlüsseln aus. Siehe Dateisystem erstellen.
2. Erstellen Sie Sicherheitsregeln entweder in einer Netzwerksicherheitsgruppe (empfohlen) oder in einer Sicherheitsliste für das Mountziel, das das Dateisystem exportiert, und für die Worker-Knoten des Clusters.
   Die zu erstellenden Sicherheitsregeln hängen von den relativen Netzwerkspeicherorten des Mountziels und der Worker-Knoten gemäß den folgenden Szenarios ab:

   • Szenario B: Mountziel und Instanz im selben Subnetz
   • Szenario A: Mount-Ziel und Instanz in verschiedenen Subnetzen (empfohlen)

   Diese Szenarios, die zu erstellenden Sicherheitsregeln und die Stelle, an der sie erstellt werden sollen, werden in der Dokumentation zum File Storage-Service ausführlich beschrieben (siehe VCN-Sicherheitsregeln für File Storage konfigurieren).

3. Erstellen Sie wie folgt eine vom Dateisystem im File Storage-Service unterstützte PV:

   1. Erstellen Sie eine Manifestdatei, um eine PV zu definieren, und legen Sie im Abschnitt csi: Folgendes fest:

      • driver bis fss.csi.oraclecloud.com
      • volumeHandle bis <FileSystemOCID>:<MountTargetIP>:<path>
        Hierbei gilt:

        • <FileSystemOCID> ist die OCID des im File Storage-Service definierten Dateisystems.
        • <MountTargetIP> ist die IP-Adresse, die dem Mountziel zugewiesen ist.
        • <path> ist der Mountpfad zum Dateisystem relativ zur IP-Adresse des Mountziels, beginnend mit einem Schrägstrich.

        Beispiel: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      Beispiel: Die folgende Manifestdatei (mit dem Namen fss-pv.yaml) definiert eine PV mit dem Namen fss-pv, die von einem Dateisystem im File Storage-Service gesichert wird:

      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. Erstellen Sie PV aus der Manifestdatei, indem Sie Folgendes eingeben:

      kubectl create -f <filename>

      Beispiel:

      kubectl create -f fss-pv.yaml

4. Erstellen Sie wie folgt einen PVC, der von der von Ihnen erstellten PV bereitgestellt wird:
   1. Erstellen Sie eine Manifestdatei, um den PVC zu definieren und festzulegen:
      • storageClassName bis "". Beachten Sie, dass Sie einen leeren Wert für storageClassName angeben müssen, auch wenn die Speicherklasse beim statischen Provisioning des persistenten Speichers nicht anwendbar ist. Wenn Sie keinen leeren Wert für storageClassName angeben, wird die Standardspeicherklasse (oci-bv) verwendet, die einen Fehler verursacht.
      • volumeName für den Namen der erstellten PV (Beispiel: fss-pv)

      Beispiel: Die folgende Manifestdatei (mit dem Namen fss-pvc.yaml) definiert einen PVC namens fss-pvc, der von einem PV namens fss-pv bereitgestellt wird:

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

      Beachten Sie, dass das Element requests: storage: in der Manifestdatei des PVCs vorhanden sein muss und der Wert mit dem Wert übereinstimmen muss, der für das Element capacity: storage: in der Manifestdatei des PV angegeben ist. Ansonsten wird der Wert des Elements requests: storage: ignoriert.

   2. Erstellen Sie PVC aus der Manifestdatei, indem Sie Folgendes eingeben:

      kubectl create -f <filename>

      Beispiel:

      kubectl create -f fss-pvc.yaml

Das PVC ist an das PV gebunden, das vom File Storage Service-Dateisystem gesichert wird. Die Daten werden im Ruhezustand mit von Oracle verwalteten Verschlüsselungsschlüsseln verschlüsselt.