ブロック・ボリューム・サービスでのPVCのプロビジョニング

oci-bvストレージ・クラスの定義(provisioner: blockvolume.csi.oraclecloud.com)で指定されたCSIプラグインを使用して、ブロック・ボリュームを動的にプロビジョニングできます。たとえば、クラスタ管理者がPVCリクエストに一致する適切なPVを作成していないとします。

PVCはcsi-bvs-pvc.yamlというファイルに定義します。例:

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

次のコマンドを入力して、csi-bvs-pvc.yamlファイルからPVCを作成します:

kubectl create -f  csi-bvs-pvc.yaml

前述のコマンドの出力では、PVCの作成が確認されます:

persistentvolumeclaim "mynginxclaim" created

kubectl get pvcを実行して、PVCが作成されたことを確認します:

kubectl get pvc

前述のコマンドの出力に、PVCの現在のステータスが表示されます:

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

PVCのステータスはPendingです。これは、oci-bvストレージ・クラスの定義にvolumeBindingMode: WaitForFirstConsumerが含まれているためです。

ポッドなどの他のオブジェクトを作成するときに、このPVCを使用できます。たとえば、次のポッド定義から新しいポッドを作成できます。このポッド定義は、/dataでポッドによってマウントされるmynginxclaim PVCをnginxボリュームとして使用するようにシステムに指示します。

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

新しいポッドを作成したら、次のように入力してPVCが新しい永続ボリュームにバインドされていることを確認できます:

kubectl get pvc

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

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

次のように入力して、ポッドが新しい永続ボリューム要求を使用していることを確認できます:

kubectl describe pod nginx

Prometheusなどのメトリック集計ツールを使用して、新しい永続ボリュームの容量統計を表示できます。

Kubernetesボリューム・スナップショットは、ストレージ・システム上の永続ボリュームのスナップショットです。ボリューム・スナップショットを使用して、新しい永続ボリュームをプロビジョニングできます。Kubernetesボリューム・スナップショットの詳細は、Kubernetesドキュメントのボリューム・スナップショットを参照してください。

CSIボリューム・プラグインを使用して、クラスタをブロック・ボリューム・サービス内のブロック・ボリュームに接続する場合、ブロック・ボリューム・バックアップを使用してKubernetesボリューム・スナップショットをプロビジョニングできます。ボリューム・スナップショットを使用して新しいブロック・ボリュームを作成し、ブロック・ボリューム・バックアップからのデータを事前に移入できます。ブロック・ボリューム・サービスでのブロック・ボリューム・バックアップの詳細は、ブロック・ボリューム・バックアップの概要を参照してください。

CSIボリューム・プラグインを使用すると、次の2つの方法のいずれかでボリューム・スナップショットをプロビジョニングできます。

• 動的に:永続ボリュームをプロビジョニングするブロック・ボリュームのバックアップの作成をリクエストできます。VolumeSnapshotオブジェクトを使用して永続ボリューム要求を指定し、VolumeSnapshotClassオブジェクトを使用してブロック・ボリューム・バックアップの作成に使用するパラメータを指定します。動的にプロビジョニングされるボリューム・スナップショットは、動的ボリューム・スナップショットとも呼ばれます。動的にプロビジョニングされるボリューム・スナップショットの作成を参照してください。
• 静的: VolumeSnapshotContentオブジェクトを使用して、既存のブロック・ボリューム・バックアップの詳細を指定できます。静的にプロビジョニングされたボリューム・スナップショットは、静的ボリューム・スナップショット、および事前にプロビジョニングされたボリューム・スナップショットとも呼ばれます。静的にプロビジョニングされたボリューム・スナップショットの作成

動的にプロビジョニングされるボリューム・スナップショットを作成すると、ソース・ブロック・ボリュームに適用されたものと同じフリーフォーム・タグおよび定義済タグがブロック・ボリューム・バックアップに適用されます。ただし、パラメータを使用して、ブロック・ボリューム・バックアップに追加タグを適用できます(ブロック・ボリューム・バックアップのタグ付けを参照)。

Kubernetes Engineによって作成されたクラスタで使用するボリューム・スナップショットを作成する前に満たす前提条件が多数あります。ボリューム・スナップショットを作成するための前提条件を参照してください。

ボリューム・スナップショットを作成および使用する場合は、次の点に注意してください:

• ボリューム・スナップショットを作成できるのは、CSIボリューム・プラグインを使用する場合のみです(つまり、FlexVolumeボリューム・プラグインを使用する場合、ボリューム・スナップショットを作成できません)。
• 動的ボリューム・バックアップの場合、CSIボリューム・プラグインは、クラスタと同じコンパートメントに動的ボリューム・スナップショットをプロビジョニングするために、新しいブロック・ボリューム・バックアップを作成します。静的ボリューム・スナップショットの場合、クラスタがその他のコンパートメントにアクセスできるようにするための適切なポリシー・ステートメントが存在していれば、静的ボリューム・スナップショットをプロビジョニングするブロック・ボリューム・バックアップは、クラスタとは異なるコンパートメントに配置できます(ボリューム・スナップショットを作成するための前提条件を参照)。
• CSIボリュームプラグインを使用して、既存のボリュームにデータを再移入することはできません。つまり、永続ボリューム要求のマニフェストで指定されたボリューム・スナップショットを変更することによって、既存の永続ボリュームのデータを以前の状態にリストア(元に戻す)することはできません。CSIボリュームプラグインは、新しいボリュームにデータを移入する場合にのみ使用できます。
• ブロック・ボリューム・バックアップを作成すると(動的ボリューム・スナップショットの作成時など)、ブロック・ボリュームの作成時に使用された暗号化キーがブロック・ボリューム・バックアップの作成にも使用されます。ブロック・ボリューム・バックアップの作成時に新しい暗号化キーを指定することはできません。そのため、ブロック・ボリューム・バックアップでは、バックアップするブロック・ボリュームと同じ暗号化が使用されます。
• ボリューム・スナップショットによってプロビジョニングされた永続ボリュームに指定されたサイズは、スナップショットの作成元のボリュームのサイズより小さくできません。
• CSIボリューム・プラグインが、ボリューム・スナップショットによってプロビジョニングされた永続ボリュームをバックアップするために新しいブロック・ボリュームを作成する場合、ブロック・ボリュームの配置は、ボリューム作成リクエストのトポロジ要件によって異なります。たとえば、CSIボリューム・プラグインが永続ボリューム要求を使用するポッドのブロック・ボリュームを作成する場合、ブロック・ボリュームはポッドが実行されているワーカー・ノードと同じ可用性ドメインに作成されます。
• ネームスペース間スナップショットはサポートされていません。
• クラスタ内のVolumeSnapshotおよびVolumeSnapshotContentオブジェクトの数が増えると、etcdでかなりの領域が消費され、予期しないクラスタ動作が発生する可能性があります。クラスタを正常に保つために、不要になったVolumeSnapshotおよびVolumeSnapshotContentオブジェクトを定期的にクリーン・アップするパージ・メカニズムを実装することをお薦めします。

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

Kubernetesクローンは、ストレージ・システム上の既存の永続ボリュームと完全に重複したものです。既存の永続ボリュームをクローニングして、新しい永続ボリューム・クレームをプロビジョニングできます。新しい永続ボリュームには、ソース永続ボリュームからのデータのコピーが含まれますが、ソース永続ボリュームからは独立しています。ボリューム・クローンを使用すると、本番環境に影響を与えずに、構成変更を迅速にテストできます。Kubernetesクローンの詳細は、KubernetesドキュメントのCSIボリュームのクローニングを参照してください。

ブロック・ボリューム・サービスでは、ブロック・ボリュームをクローニングして、ソース・ブロック・ボリュームのデータが事前に移入された新しいブロック・ボリュームを作成できます。ブロック・ボリューム・サービスでのブロック・ボリュームのクローニングの詳細は、ブロック・ボリュームのクローニングを参照してください。

CSIボリューム・プラグインを使用して、クラスタをブロック・ボリューム・サービスのブロック・ボリュームに接続する場合、既存のブロック・ボリュームからクローニングされた新しいブロック・ボリュームを使用して、別の既存のPVCをプロビジョニングできます。CSIボリューム・プラグインで新しいPVCの既存のブロック・ボリュームをクローニングするように指定するには、既存のPVCを新しいPVCのデータソースとして指定します。

新しいPVCは他のPVCと同じ方法で使用でき、データソースとして指定された既存のPVCとは完全に分離されています。同様に、新しいブロック・ボリュームと、そのクローニング元の既存のブロック・ボリュームは、まったく別のリソースであり、互いに独立して更新、クローニング、スナップショットの作成および削除が可能です。

ソース・ブロック・ボリュームがクローニングされ、新しいブロック・ボリュームが作成されると(通常は数秒以内)、新しいブロック・ボリュームの状態が「使用可能」になります。その時点でソース・ブロック・ボリュームに存在するすべてのデータは、新しいブロック・ボリュームにコピーされます(後続の変更はコピーされません)。ただし、データはバックグラウンドでコピーされます。ブロック・ボリュームのサイズによっては最大30分かかる場合があります(たとえば、1TBのブロック・ボリュームのコピーには最大15分かかる場合があります)。したがって、エラーやデータ破損の可能性を回避するために、新しいPVCは、すべてのデータがコピーされるまで保留状態になります。すべてのデータがコピーされると、新しいPVCは新しいブロック・ボリュームによってプロビジョニングされたPVにバインドされ、新しいPVCは「使用可能」の状態になります。

既存の永続ボリューム要求をすでにプロビジョニングしているブロック・ボリュームをクローニングして、新しい永続ボリューム要求をプロビジョニングする前に満たす前提条件が多数あります。新しいPVCをプロビジョニングするための既存のブロック・ボリュームのクローニングの前提条件を参照してください。

ブロック・ボリュームをクローニングして新しいPVCをプロビジョニングする場合は、次の点に注意してください。

• CSIボリューム・プラグインは、ソース・ブロック・ボリュームと同じ可用性ドメイン、リージョンおよびテナンシに新しいブロック・ボリュームを作成します。
• CSIボリューム・プラグインによって作成された新しいブロック・ボリュームは、その状態が「使用可能」になるとすぐにクローニングできます。
• ボリューム作成リクエストにおけるトポロジ要件は無視されます。たとえば、CSIボリューム・プラグインが、永続ボリューム要求を使用するポッドのブロック・ボリュームをクローニングする場合、新しいブロック・ボリュームは、ポッドが実行されているワーカー・ノードと同じ可用性ドメインに作成されます。
• CSIボリューム・プラグインを使用して、FlexVolumeボリューム・プラグインによって作成されたブロック・ボリュームをクローニングすることはできません。
• クローニングの進行中は、ソースPVCを削除できません。同様に、ソース・ブロック・ボリュームからクローニングされたブロック・ボリュームにデータがコピーされている間は、ソース・ブロック・ボリュームを削除できません。
• 名前空間間クローニングはサポートされていません。新しいPVCとソースPVCの両方が同じネームスペース内にある必要があります。
• 新しいPVCのストレージクラスを明示的に指定する必要はありません。新しいPVCのストレージ・クラスを明示的に指定した場合、指定するストレージ・クラスは、ソースPVCに指定されたストレージ・クラスとは異なる場合があります。新しいPVCのストレージクラスを指定しない場合は、デフォルトのストレージクラスが使用されます。

たとえば、csi-myclonepvc.yamlというファイルにmy-clone-pvcという名前の永続ボリューム要求を定義します。my-clone-pvc永続ボリューム要求は、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

永続ボリューム要求を作成します:

kubectl create -f csi-myclonepvc.yaml

永続ボリューム・クレームは、ポッドなどの他のオブジェクトを定義するときに使用できます。たとえば、次のポッド定義は、/sample-volumeでポッドによってマウントされるmy-clone-pvc永続ボリューム要求をnginxボリュームとして使用するようにシステムに指示します。

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

新しいポッドを作成すると、my-clone-pvc永続ボリューム要求は、my-source-pvc永続ボリューム要求をプロビジョニングするブロック・ボリュームからクローニングされたブロック・ボリュームによってプロビジョニングされた新しい永続ボリュームにバインドされます。

FlexVolumeボリューム・プラグインで使用するために、既存のブロック・ボリュームまたはブロック・ボリューム・バックアップからPVCを作成できます。たとえば、クラスタ管理者が、新しい永続ボリューム要求のプロビジョニング時に使用するブロック・ボリューム・バックアップを作成した場合です。このようなブロック・ボリューム・バックアップには、ポッドなどの他のオブジェクトで使用できるデータが付属している場合があります。

PVCはflex-pvcfrombackup.yamlというファイルに定義します。volume.beta.kubernetes.io/oci-volume-source注釈要素を使用すると、FlexVolumeボリューム・プラグインを使用して新しい永続ボリューム要求をプロビジョニングするときに使用するブロック・ボリュームのソースを指定できます。注釈の値として、ブロック・ボリュームまたはブロック・ボリューム・バックアップのOCIDを指定できます。この例では、クラスタ管理者が作成したブロック・ボリューム・バックアップのOCIDを指定します。例:

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

flex-pvcfrombackup.yamlファイルには、FlexVolumeボリューム・プラグインの場合にのみ適用可能なmatchLabels要素が含まれていることに注意してください。

次のコマンドを入力して、flex-pvcfrombackup.yamlファイルからPVCを作成します:

kubectl create -f flex-pvcfrombackup.yaml

前述のコマンドの出力では、PVCの作成が確認されます:

persistentvolumeclaim "myvolume" created

次のように入力して、PVCが作成され、ボリューム・バックアップから作成された新しい永続ボリュームにバインドされたことを確認します:

kubectl get pvc

前述のコマンドの出力に、PVCの現在のステータスが表示されます:

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

ポッドなどの他のオブジェクトを定義するときに、ボリューム・バックアップから作成された新しい永続ボリュームを使用できます。たとえば、次のポッド定義は、/dataでポッドによってマウントされるmyvolume PVCをnginxボリュームとして使用するようにシステムに指示します。

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

新しいポッドを作成したら、次のように入力して、そのポッドが実行され、新しい永続ボリューム要求を使用していることを確認できます:

kubectl describe pod nginx

Oracle Cloud Infrastructure Block Volumeサービスは、256ビット暗号化によるAdvanced Encryption Standard (AES)アルゴリズムを使用して、保存されているすべてのブロック・ボリュームおよびボリューム・バックアップを常に暗号化します。デフォルトでは、すべてのボリュームとそのバックアップは、Oracle提供の暗号化キーを使用して暗号化されます。ボリュームがバックアップからクローニングまたはリストアされるたびに、ボリュームに新しい一意の暗号化キーが割り当てられます。

Vaultサービスを使用して所有および管理するキーを使用して、すべてのボリュームとそのバックアップを暗号化することもできます。詳細は、キー管理を参照してください。ボールト・サービスを使用するようにボリュームを構成していない場合、または後でボリュームへのキーの割当てを解除した場合、ブロック・ボリューム・サービスではかわりにOracle提供の暗号化キーが使用されます。これは、保存中暗号化と準仮想化転送中暗号化の両方に適用されます。

インスタンスとブロック・ボリュームの間を移動するすべてのデータは、高度にセキュアな内部ネットワークを介して転送されます。インスタンスとブロック・ボリュームの間を移動するデータの暗号化に関連して特定のコンプライアンス要件がある場合のために、ブロック・ボリューム・サービスには、仮想マシン(VM)インスタンス上の準仮想化ボリューム・アタッチメントに対して転送中暗号化を有効にするオプションが用意されています。一部のベア・メタル・シェイプでは、インスタンスのiSCSIでアタッチされたブロック・ボリュームの転送中暗号化がサポートされています。

ブロック・ボリュームの暗号化および転送中暗号化のサポートの詳細は、ブロック・ボリュームの暗号化を参照してください。

Kubernetes PVCがBlock Volumeサービスによってバックアップされる場合、次を指定してブロック・ボリュームの暗号化方法を選択します:

• 使用するマスター暗号化キー。Kubernetesストレージ・クラスの定義でkms-key-idプロパティを設定します。Vaultサービスでマスター暗号化キーのOCIDを指定できます。
• Kubernetesストレージ・クラスの定義のattachment-typeプロパティをiscsiまたはparavirtualizedのいずれかに設定することで、ブロック・ボリュームがコンピュート・インスタンスにアタッチされる方法。
• 転送中暗号化がクラスタ内の各ノード・プールに対して有効になっているかどうかは、ノード・プールのisPvEncryptionInTransitEnabledプロパティ(コンソールのCLI、APIまたはノード・プールの「転送中暗号化の使用」オプションを使用)を設定して行います。

指定した設定の相互作用によって、次の表に示すように、ブロック・ボリュームの暗号化方法が決まります。

マスター暗号化キーを自分で管理するクラスタを作成する前に、次のことを行う必要があります。

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

Vaultサービスでのキー・ローテーションの詳細は、Vaultキーのローテーションを参照してください。

CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com)を使用してPVCを作成する場合は、ボリューム・サイズをオンラインで拡張できます。これにより、アプリケーションを特定の量のストレージで最初にデプロイし、その後、停止時間なしで使用可能なストレージを増やすことが可能になります。

ストレージ・リクエストの増加をサポートする場合は、PVCに指定したストレージ・クラスの定義でallowVolumeExpansion: trueを設定します。例:

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

CSIボリューム・プラグインのデフォルトのoci-bvストレージ・クラスには、デフォルトでallowVolumeExpansion: trueがあります。

ボリュームのサイズを拡張するには、PVCマニフェストを編集してボリュームサイズを更新してから、マニフェストを適用します。次にディスクが再スキャンされ、オペレーティング・システムが拡張ボリューム・サイズ(数分かかる場合があります)を識別できるようになると、増加したストレージがPVCを使用してポッドで自動的に使用可能になります。ポッドを再起動する必要はありません。

次のコマンドを入力して、PVCが新しく拡大されたブロック・ボリュームにバインドされていることを確認します:

kubectl get pvc <pvc_name> -o yaml

次の点に注意してください:

• ボリューム拡張は、Kubernetes 1.19以降を実行しているクラスタでサポートされています。
• CSIボリューム・プラグインのデフォルトのoci-bvストレージ・クラスは、Kubernetes 1.19以降を実行しているクラスタでallowVolumeExpansion: trueを使用して構成されます。Kubernetes 1.19以降を実行している既存のクラスタ内のoci-bvストレージ・クラスの定義は、allowVolumeExpansion: trueを設定するために自動的に編集されます。
• ブロック・ボリュームのサイズは小さくできません。指定できる値は、ブロック・ボリュームの現在のサイズより大きい値のみです。PVCマニフェストを更新して、以前に要求したよりも少ないストレージを要求すると、ストレージ要求は失敗します。
• ブロック・ボリューム・サービスでのブロック・ボリューム・サイズの増加の詳細は、ボリュームのサイズ変更を参照してください。特に、ブロック・ボリュームのサイズ変更前にバックアップを作成することをお薦めします。

ブロック・ボリューム・サービス内のブロック・ボリュームは、予想されるワークロードI/O要件に従って、様々なレベルのパフォーマンスに構成できます。ブロック・ボリューム・パフォーマンスは、ボリューム・パフォーマンス・ユニット(VPU)で表されます。次のような多数のパフォーマンス・レベルを使用できます。

• 低コスト(0 VPU)
• バランス(10 VPU)
• より高いパフォーマンス(20 VPU)
• Ultra High Performance(30個のVPUと120個のVPU)

デフォルトでは、ブロック・ボリュームはバランス・パフォーマンス・レベル(10 VPU)に構成されます。様々なブロック・ボリューム・パフォーマンス・レベルの詳細は、ブロック・ボリューム・パフォーマンス・レベルを参照してください。

CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com)を使用してPVCを定義する場合、予想されるワークロードに適した別のブロック・ボリューム・パフォーマンス・レベルをストレージ・クラス定義で指定できます。

その後、PVCをバッキングするブロック・ボリュームのパフォーマンス・レベルを変更することはできません。かわりに、新しいストレージ・クラスを定義し、必要に応じてパフォーマンス・レベルを設定し、その新しいストレージ・クラスによってプロビジョニングされる新しいPVCを作成する必要があります。

Block Volumeサービスのブロック・ボリュームは、様々なタイプのファイル・システムに対して構成できます。使用するもっとも適切なファイルシステムは、予想されるファイルサイズと処理されるファイル数によって異なります。次のような多数のファイル・システム・タイプを使用できます。

• ext3: ext3ファイル・システム・タイプには、信頼性と可用性を向上させるためにジャーナル機能が含まれています。電源障害または制御不能なシステムシャットダウンのあとの整合性チェックは不要です。
• ext4: ext3機能に加えて、ext4ファイル・システム・タイプは、エクステント(連続物理ブロック)、事前割当て、遅延割当て、ファイル・システム・チェックの高速化、より堅牢なジャーナル、およびその他の拡張をサポートしています。
• XFS: XFSファイル・システムは、高性能のジャーナル・ファイル・システム・タイプであり、ファイル・システムが多数のストレージ・デバイスにまたがる場合でも、I/Oスレッド、ファイル・システム帯域幅、ファイルおよびファイル・システム・サイズに高いスケーラビリティを提供します。

ext3およびext4ファイル・システムは、通常、単一の読取り/書込みスレッドおよび小さいファイルを使用するアプリケーションに適しています。一方、XFSファイル・システムは、通常、複数の読取り/書込みスレッドおよび大きいファイルを持つアプリケーションに適しています。

CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com)を使用してPVCを作成する場合、予想されるワークロードに適したブロック・ボリュームのファイル・システム・タイプを指定できます。

デフォルトでは、ブロック・ボリュームはext4ファイル・システムで構成されます。ext4ファイル・システムが予想されるワークロードに最適なファイル・システムでない場合は、ストレージ・クラス定義で代替ファイル・システム・タイプを指定できます。

ext3またはXFSファイル・システムでブロック・ボリュームによってバックアップされたPVCを作成するには、次のようにカスタム・ストレージ・クラス定義でfstypeパラメータを設定します。

• ext3の場合は、csi.storage.k8s.io/fstype: ext3を設定します。
• XFSの場合は、csi.storage.k8s.io/fstype: xfsを設定します。

たとえば、ext3ファイル・システムでブロック・ボリュームによってバックアップされたPVCを作成するには:

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

oci-bv-ext3ストレージ・クラスによってプロビジョニングされたPVCのマニフェストを作成し、ストレージのリクエストを含めます。たとえば、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

csi-bvs-PVC-fstype.yamlファイルからPVCを作成するには、次のコマンドを入力します:

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

PVCを作成したら、ポッドなどの他のオブジェクトを作成するときに使用できます。たとえば、次のポッド定義から新しいポッドを作成できます。このポッド定義は、/dataでポッドによってマウントされるoci-bv-claim-ext3 PVCをnginxボリュームとして使用するようにシステムに指示します。

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

新しいポッドを作成したら、次のように入力してPVCが新しい永続ボリュームにバインドされていることを確認できます:

kubectl get pvc

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

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

次のように入力して、ポッドが新しい永続ボリューム要求を使用していることを確認できます:

kubectl describe pod nginx

その後、PVCをバッキングするブロック・ボリュームのファイル・システムを変更することはできません。かわりに、新しいストレージ・クラスを定義し、必要に応じてファイル・システムを設定し、その新しいストレージ・クラスによってプロビジョニングされる新しいPVCを作成する必要があります。

CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com)を使用してクラスタをブロック・ボリューム・サービス内のブロック・ボリュームに接続する場合、PVCを、RAWブロック・ボリュームとして構成されたブロック・ボリュームによってプロビジョニングされるPVにバインドできます。ブロック・ボリュームがマウントされたファイル・システムとしてではなくRAWブロック・ボリュームとして構成されている場合、そのブロック・ボリュームによってプロビジョニングされたPVは、クラスタで実行されているコンテナのブロック・デバイスとして表示されます。その結果、コンテナ内で実行中のアプリケーションは、アタッチされたブロック・ボリュームにブロック・デバイスとしてアクセスでき、ファイル・システムを介してデバイスにアクセスすることによるパフォーマンス・オーバーヘッドが発生しません。このオーバーヘッドは、ダイレクト・ブロック・デバイス・アクセスの利点を享受するパフォーマンスに敏感なアプリケーション(データベースなど)にとって特に重要な場合があります。

PVCをRAWブロック・ボリュームとしてバッキングするブロック・ボリュームを構成するには、PVCマニフェストで volumeMode: Blockを指定します。指定しない場合、volumeMode: Filesystemが想定され、ブロック・ボリュームはデフォルトでext4ファイル・システムで構成されます。

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

csi-bvs-PVC-raw.yamlファイルからPVCを作成するには、次のコマンドを入力します:

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

PVCを作成したら、ポッドなどの他のオブジェクトを作成するときに使用できます。たとえば、次のポッド定義から新しいポッドを作成できます。このポッド定義は、コンテナが/dev/blockでアクセスできるraw-volume-testコンテナのストレージ・ボリュームとしてPVC-raw-block-volume PVCを使用するようにシステムに指示します。

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

新しいポッドを作成したら、次のように入力してPVCが新しい永続ボリュームにバインドされていることを確認できます:

kubectl get pvc

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

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

次のように入力して、ポッドが新しい永続ボリューム要求を使用していることを確認できます:

kubectl describe pod raw-volume-test-pod

PVCをバックアップするブロック・ボリュームをRAWブロック・ボリュームとして構成するか、マウントされたファイル・システムとして構成するかは、後で変更できません。かわりに、新しいPVCを作成し、PVCマニフェストでvolumeMode:を適切に設定する必要があります。

また、RAWブロック・ボリュームはUltra High Performanceブロック・ボリュームではサポートされていません。