ファイル・ストレージ・サービスでのPVCのプロビジョニング

File Storageサービスを使用してPVCをプロビジョニングする場合、保存中の暗号化とは無関係に、転送中暗号化を指定します。

File Storageサービスは、デフォルトでOracle管理暗号化キーを使用して、保存時に常にデータを暗号化します。ただし、Vaultサービスで自分を管理している独自のマスター暗号化キーを使用して保存中の暗号化を指定するオプションがあります。保存時の暗号化を指定する方法は、PVCをプロビジョニングするかどうかによって異なります。

• CSIボリューム・プラグインによって動的に作成される新しいファイル・システム(新しいファイル・システムでの保存データの暗号化を参照)
• 手動で作成した既存のファイル・システム(既存のファイル・システムでの保存データの暗号化を参照)

保存データを暗号化するために独自のマスター暗号化キーを管理する場合は、次のことを行う必要があります。

• Vaultで適切なマスター暗号化キーを作成します(または、そのようなキーのOCIDを取得します)。キーの管理を参照してください。
• マスター暗号化キーへのアクセス権を付与するポリシーを作成します。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためのユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。

File Storageサービスは、オプションで転送中のデータを暗号化できます。転送中暗号化を指定すると、保存中のデータがOracle管理キーを使用して暗号化されるか、ユーザー管理キーを使用して暗号化されるかに関係なく、転送中のデータは常にOracle管理であるTLS (Transport Layer Security)証明書を使用して暗号化されます。転送中暗号化は、TLS v. 1.2暗号化を使用して、インスタンスとマウントされたファイル・システム間で転送されるデータを保護します。転送中暗号化およびファイル・ストレージ・サービスの詳細は、転送中TLS暗号化の使用を参照してください。転送中暗号化の指定方法は、PVCをプロビジョニングするかどうかによって異なります。

• CSIボリューム・プラグインによって動的に作成される新しいファイル・システム(新しいファイル・システムでの転送中のデータの暗号化を参照)
• 手動で作成した既存のファイル・システム(既存のファイル・システムでの転送中のデータの暗号化を参照)

File Storageサービスを使用してPVCをプロビジョニングする場合、転送中暗号化は、ワーカー・ノードをホストしているコンピュート・インスタンスがOracle Linux 7およびOracle Linux 8を実行している場合にのみサポートされます。

ファイル・ストレージ・サービスのCSIボリューム・プラグインによって動的に作成された新しいファイル・システムにPVCを動的にプロビジョニングするには:

1. (オプション)ファイル・ストレージ・サービスにマウント・ターゲットを作成します。マウント・ターゲットの作成を参照してください。

   CSIボリューム・プラグインでは、新しいファイル・システムを作成するには、アクティブなマウント・ターゲット(つまり、IPアドレスが割り当てられたマウント・ターゲット)が必要です。マウント・ターゲットを事前に作成しない場合は、ストレージ・クラスの定義時にCSIボリューム・プラグインが新しいマウント・ターゲットを作成するサブネットを指定します。

2. fss.csi.oracleclould.comプロビジョナを使用する新しいストレージ・クラスを定義します。
   1. マニフェスト・ファイル(たとえば、fss-dyn-st-class.yamlという名前のファイル)を作成し、新しいストレージ・クラスの名前を指定し、必須パラメータとオプション・パラメータの値を指定します。

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

      ここでは:

      • name: <storage-class-name>: 必須。ストレージ・クラスに選択した名前。
      • availabilityDomain: <ad-name>: 必須。新しいファイル・システムを作成する可用性ドメインの名前(および既存のマウント・ターゲットOCIDが指定されていない場合、新しいマウント・ターゲットを作成する可用性ドメインの名前)。たとえば、US-ASHBURN-AD-1です。使用する可用性ドメイン名を確認するには、oci iam availability-domain list CLIコマンドを実行します(または、ListAvailabilityDomains操作を使用します)。詳細は、テナンシのアベイラビリティ・ドメイン名を参照してください。
      • mountTargetOcid: <mt-ocid> | mountTargetSubnetOcid: <mt-subnet-ocid>: 必須。既存のアクティブ・マウント・ターゲット(mountTargetOcid: <mt-ocid>)のOCID、または新しいマウント・ターゲットを作成するサブネットのOCID (mountTargetSubnetOcid: <mt-subnet-ocid>)。mountTargetOcidまたはmountTargetSubnetOcidのいずれかを指定します。ストレージ・クラス定義でmountTargetOcidとmountTargetSubnetOcidの両方を指定すると、mountTargetOcidで指定された既存のマウント・ターゲットが使用され、mountTargetSubnetOcidは無視されます。例:
        • mountTargetSubnetOcid: ocid1.subnet.oc1.iad.aaaaaaaa2xpk______zva
        • mountTargetOcid: ocid1.mounttarget.oc1.iad.aaaaaaaa4np______fuy
      • compartmentOcid: <compartment-ocid>: オプション。新しいファイル・システム(および既存のマウント・ターゲットOCIDが指定されていない場合は、新しいマウント・ターゲット)が属するコンパートメントのOCID。指定しない場合、デフォルトでクラスタと同じコンパートメントに設定されます。たとえば、compartmentOcid: ocid1.compartment.oc1..aaaaaaaay______t6qです。
      • kmsKeyOcid: <key-ocid>: オプション。保存データの暗号化に使用する、管理するマスター暗号化キーのOCID。指定しない場合、データはOracleによって管理される暗号化キーを使用して保存時に暗号化されます。新しいファイル・システムでの保存データの暗号化を参照してください。たとえば、kmsKeyOcid: ocid1.key.oc1.iad.anntl______usjhです。
      • exportPath: <path>: オプション。マウント・ターゲット内のファイル・システムを一意に識別するエクスポート内のパス。このエクスポート・パスの先頭にはスラッシュ(/)を付ける必要があり、その後にゼロ個以上のスラッシュ区切り要素を続けます。たとえば、/FileSystem1です。詳細は、ファイル・システム内のパスを参照してください。

        ストレージ・クラス定義にexportPath: <path>を含める場合は、すでに存在するパス(パスとして、または既存のパスのサブパスとして)を指定しないでください。すでに存在するパスを指定すると、同じマウント・ターゲットを持つ複数のファイル・システムに同じエクスポート・パスを指定できないため、エラーが返されます。したがって、ストレージ・クラス定義にexportPath: <path>を含める場合は、このストレージ・クラス定義を使用して1つのファイル・システムを作成します。

        ストレージ・クラス定義にexportPath: <path>を含めない場合、パスはデフォルトで、CSIボリューム・プラグインによって作成されたファイル・システムの表示名になります(/csi-fss-から開始)。

      • exportOptions: "[{<options-in-json-format>}]"オプション。NFSクライアントがマウント・ターゲットに接続するときに付与されるアクセス・レベルを指定する、エクスポート内の一連のパラメータ(有効なJSON形式)。エクスポート内のNFSエクスポート・オプション・エントリでは、単一のIPアドレスまたはCIDRブロック範囲に対するアクセス権を定義します。詳細は、NFSエクスポートおよびエクスポート・オプションの作業を参照してください。指定しない場合、次のデフォルトが使用されます。

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

      • encryptInTransit: "true"|"false": オプション。転送中のデータを暗号化するかどうかを示します。"true"を指定する場合は、「新規ファイル・システムでの転送中のデータの暗号化」で説明されている設定ステップを完了してください。指定しなかった場合は、デフォルトで"false"に設定されます。たとえば、encryptInTransit: "true"です。
      • oci.oraclecloud.com/initial-defined-tags-override: '{"<tag-namespace>": {"<tag-key>": "<tag-value>"}}'オプション。新しいファイル・システムの定義済タグを指定します。たとえば、oci.oraclecloud.com/initial-defined-tags-override: '{"Operations": {"CostCenter": "42"}}'です。

        あるコンパートメントに属するタグ・ネームスペースの定義済タグを別のコンパートメントに属するファイルシステム・リソースに適用するには、クラスタでタグ・ネームスペースを使用できるようにするポリシー・ステートメントを含める必要があります。クラスタおよびタグ・ネームスペースが異なるコンパートメントにある場合の追加のIAMポリシーを参照してください。

      • oci.oraclecloud.com/initial-freeform-tags-override: '{"<tag-key>": "<tag-value>"}'オプション。新しいファイル・システムのフリーフォーム・タグを指定します。たとえば、oci.oraclecloud.com/initial-freeform-tags-override: '{"Department": "Finance"}'です。

      例:

      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. 次のように入力して、マニフェストファイルからストレージクラスを作成します。

      kubectl create -f <filename>

      例:

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

3. セキュリティ・ルールは、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リストのいずれかで、ストレージ・クラス定義で参照(または作成者)されたマウント・ターゲットと、クラスタのワーカー・ノードの両方に対して作成します。

   作成するセキュリティ・ルールは、次のシナリオに従って、マウント・ターゲットおよびワーカー・ノードの相対ネットワークの場所によって異なります:

   • シナリオB: 同じサブネット内のマウント・ターゲットとインスタンス
   • シナリオA: 異なるサブネットのマウント・ターゲットおよびインスタンス(推奨)

   これらのシナリオ、作成するセキュリティ・ルールおよび作成場所は、File Storageサービスのドキュメント(ファイル・ストレージのVCNセキュリティ・ルールの構成を参照)で詳しく説明されています。

4. 次のように、File Storageサービスの新しいファイル・システムによってプロビジョニングされるPVCを作成します。
   1. PVCを定義するマニフェスト・ファイルを作成します。

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

      ここでは:

      • name: <pvc-name>: 必須。たとえば、fss-dynamic-claimです。
      • storageClassName: "<storage-class-name>": 必須。前に定義したストレージクラスの名前。たとえば、fss-dyn-storageです。
      • accessModes: - ReadWriteMany: 必須。accessModes:にはReadWriteManyを指定する必要があります。
      • storage: 50Gi: 必須。Kubernetesでは、PVCマニフェストでstorage:の値を指定する必要があります。ただし、ファイル・ストレージ・サービスは、storage:に指定した値に関係なく、ファイル・システム・サイズの指定をサポートせず、デフォルト・サイズの新しいファイル・システムを作成します。

      たとえば、次のマニフェスト・ファイル(fss-dyn-claim.yamlという名前)は、fss-dyn-storageストレージ・クラスで定義されたファイル・システムによってプロビジョニングされるfss-dynamic-claimという名前のPVCを定義します。

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

   2. 次のように入力して、マニフェスト・ファイルからPVCを作成します。

      kubectl create -f <filename>

      例:

      kubectl create -f fss-dyn-claim.yaml

   新しいPVCが作成されます。CSIボリューム・プラグインは、新しい永続ボリューム(PV)と新しいファイル・システムをファイル・ストレージ・サービス(既存のマウント・ターゲットを指定しなかった場合は新しいマウント・ターゲットとともに)に作成します。

   新しいPVCは新しいPVに結合されます。データは、Oracleまたはユーザーが管理する暗号化キーを使用して、保存時に暗号化されます。

5. 次を入力して、PVCが新しい永続ボリュームにバインドされていることを確認します:

   kubectl get pvc

   前述のコマンドの出力で、PVCが正常にバインドされていることを確認します:

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

6. ポッドなどの他のオブジェクトを作成するときに、新しいPVCを使用します。たとえば、次のポッド定義から新しいポッドを作成できます:

   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. 前のステップの例で説明したように、新しいポッドを作成したら、次のように入力して、ポッドが新しいPVCを使用していることを確認できます。

   kubectl describe pod nginx

ファイル・ストレージ・サービスの既存のファイル・システムにPVCを作成するには(Oracle管理の暗号化キーを使用して保存データを暗号化します):

1. ファイル・ストレージ・サービスでマウント・ターゲットを含むファイル・システムを作成し、「Oracle管理キーを使用した暗号化」暗号化オプションを選択します。ファイル・システムの作成を参照してください。
2. セキュリティ・ルールは、ファイル・システムをエクスポートするマウント・ターゲットとクラスタのワーカー・ノードの両方について、ネットワーク・セキュリティ・グループ(推奨)またはセキュリティ・リストのいずれかで作成します。
   作成するセキュリティ・ルールは、次のシナリオに従って、マウント・ターゲットおよびワーカー・ノードの相対ネットワークの場所によって異なります:

   • シナリオB: 同じサブネット内のマウント・ターゲットとインスタンス
   • シナリオA: 異なるサブネットのマウント・ターゲットおよびインスタンス(推奨)

   これらのシナリオ、作成するセキュリティ・ルールおよび作成場所は、File Storageサービスのドキュメント(ファイル・ストレージのVCNセキュリティ・ルールの構成を参照)で詳しく説明されています。

3. 次のように、ファイル・ストレージ・サービスのファイル・システムでバックアップされたPVを作成します。

   1. PVを定義するマニフェスト・ファイルを作成し、csi:セクションで次のように設定します。

      • driverからfss.csi.oraclecloud.com
      • volumeHandleから<FileSystemOCID>:<MountTargetIP>:<path>
        ここでは:

        • <FileSystemOCID>は、ファイル・ストレージ・サービスで定義されたファイル・システムのOCIDです。
        • <MountTargetIP>は、マウント・ターゲットに割り当てられたIPアドレスです。
        • <path>は、マウント・ターゲットのIPアドレスに対するファイル・システムへのマウント・パスで、スラッシュで始まります。

        たとえば: ocid1.filesystem.oc1.iad.aaaa______j2xw:10.0.0.6:/FileSystem1

      たとえば、次のマニフェスト・ファイル(fss-pv.yamlという名前)は、ファイル・ストレージ・サービスのファイル・システムによってバックアップされるfss-pvというPVを定義します。

      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. 次のように入力して、マニフェスト・ファイルからPVを作成します。

      kubectl create -f <filename>

      例:

      kubectl create -f fss-pv.yaml

4. 次のように、作成したPVによってプロビジョニングされるPVCを作成します。
   1. PVCを定義するマニフェスト・ファイルを作成し、次のように設定します。
      • storageClassNameから""
      • volumeName: 作成したPVの名前(fss-pvなど)

      たとえば、次のマニフェスト・ファイル(fss-pvc.yamlという名前)は、fss-pvという名前のPVによってプロビジョニングされるfss-pvcという名前のPVCを定義します。

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

      requests: storage:要素はPVCのマニフェスト・ファイルに存在する必要があり、その値はPVのマニフェスト・ファイルのcapacity: storage:要素に指定された値と一致する必要があります。それ以外に、requests: storage:要素の値は無視されます。

   2. 次のように入力して、マニフェスト・ファイルからPVCを作成します。

      kubectl create -f <filename>

      例:

      kubectl create -f fss-pvc.yaml

PVCは、ファイル・ストレージ・サービス・ファイル・システムによってバックアップされたPVにバインドされます。データは、Oracleによって管理される暗号化キーを使用して、保存時に暗号化されます。