ブロック・ボリューム・サービスでのPVCのプロビジョニング
ブロック・ボリューム・サービスからボリュームをアタッチして、Kubernetesエンジン(OKE)を使用して作成したクラスタに対して永続ボリューム要求をプロビジョニングする方法をご紹介します。
- 新機能はCSIボリューム・プラグインにのみ追加され、FlexVolumeボリューム・プラグインには追加されません(Kubernetes開発者によるFlexVolumeボリューム・プラグインの保守は続けられます)。
- CSIボリューム・プラグインは、ベースとなるオペレーティング・システムおよびルート・ファイル・システムの依存関係にアクセスする必要はありません。
アップストリームKubernetesプロジェクトは、Kubernetesバージョン1.23でFlexVolumeボリューム・プラグインを非推奨にしています。機能の削除は、Kubernetesの非推奨ポリシーのガイドラインに準拠します。
既存のワークロードをFlexVolumeボリューム・プラグインからCSIボリューム・プラグインに移行することをお薦めします。移行手順については、「FlexVolumeボリューム・プラグインからCSIボリューム・プラグインへの移行」を参照してください。
PVCに指定されたStorageClassは、ブロック・ボリューム・サービス・ボリュームへの接続に使用するボリューム・プラグインを制御します。デフォルトでは、2つのストレージ・クラスが定義されています。CSIボリューム・プラグインの場合はoci-bv
、FlexVolumeプラグインの場合はoci
です。storageClassName
の値を、PVCを定義するYMLファイルで明示的に指定しない場合は、クラスタのデフォルトのストレージ・クラスが使用されます。クラスタのデフォルト・ストレージ・クラスは、次のように、クラスタの作成時に指定されたKubernetesバージョンに従って最初に設定されます:
- Kubernetesエンジンによって作成され、Kubernetesバージョン1.24 (以降)を実行するために作成されたクラスタでは、
oci-bv
ストレージ・クラスは最初はデフォルトとして設定されます。oci-bv
ストレージ・クラスは、CSIボリューム・プラグインで使用されます。 - Kubernetesエンジンによって作成され、Kubernetesバージョン1.23 (またはそれ以前)を実行するために作成されたクラスタでは、
oci
ストレージ・クラスは最初はデフォルトとして設定されます。oci
ストレージ・クラスは、FlexVolumeボリューム・プラグインによって使用されます。
Kubernetesエンジンによって最初に作成され、Kubernetesバージョン1.23 (またはそれ以前)を実行し、その後Kubernetesバージョン1.24 (またはそれ以降)にアップグレードされたクラスタでは、アップグレード・プロセス中にデフォルトのストレージ・クラスは変更されません。そのため、アップグレード前にデフォルトのストレージ・クラスがoci
であった場合、アップグレード後もデフォルトのストレージ・クラスはoci
のままになります。
oci
のかわりにoci-bv
を、Kubernetesバージョン1.23 (またはそれ以前)からKubernetesバージョン1.24 (またはそれ以降)にアップグレードしたクラスタのデフォルト・ストレージ・クラスにする場合は、次のようにデフォルトのストレージ・クラスを変更します:
- 次のように入力して、
oci
がデフォルトの記憶域クラスでないことを指定します。kubectl patch storageclass oci -p '{"metadata": {"annotations": {"storageclass.beta.kubernetes.io/is-default-class":"false"}}}'
- 次のように入力して、
oci-bv
がデフォルトの記憶域クラスであることを指定します。kubectl patch storageclass oci-bv -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class":"true"}}}'
CSIボリューム・プラグインの場合、CSIトポロジ機能により、ワーカー・ノードとボリュームが同じ可用性ドメインに配置されます。FlexVolumeボリューム・プラグインの場合、matchLabels
要素を使用して、永続ボリューム要求がプロビジョニングされる可用性ドメインを選択できます。CSIボリューム・プラグインではmatchLabels
要素を使用しないことに注意してください。
使用するボリューム・プラグインに関係なく、クラスタがワーカー・ノードとは異なるコンパートメントにある場合は、追加のポリシーを作成してブロック・ボリューム・サービス・ボリュームへのアクセスを有効にする必要があります。この状況は、ノード・プールに指定されたサブネットがクラスタの異なるコンパートメントに属している場合に発生します。ワーカー・ノードがブロック・ボリューム・サービス・ボリュームにアクセスできるようにするには、次の両方のポリシー・ステートメントを使用して追加のポリシーを作成します:
ALLOW any-user to manage volumes in TENANCY where request.principal.type = 'cluster'
ALLOW any-user to manage volume-attachments in TENANCY where request.principal.type = 'cluster'
永続ボリューム要求のプロビジョニング時にブロック・ボリューム・サービスへの接続に使用するボリューム・プラグインを明示的に指定するには、PVCを定義するyamlファイルでstorageClassName
の値を指定します:
- CSIボリューム・プラグインを使用するには、
storageClassName: "oci-bv"
を指定します - FlexVolumeボリューム・プラグインを使用するには、
storageClassName: "oci"
を指定します
次の点に注意してください:
- PVCがリクエスト可能な永続ストレージの最小量は、50ギガバイトです。リクエストが50ギガバイト未満の場合、リクエストは50ギガバイトに切り上げられます。
- PVCがリクエストできる永続ストレージの量を増やすことができるようにするには、PVCに指定されたストレージ・クラスの定義で
allowVolumeExpansion: true
を設定します。ブロック・ボリュームの拡張を参照してください。 - クラスタの作成時に、オプションで、永続ボリューム要求(PVC)の定義時に作成されるブロック・ボリュームに適用するタグを定義できます。タグ付けを使用すると、コンパートメント間で異なるリソースをグループ化でき、独自のメタデータでリソースに注釈を付けることもできます。「ブロック・ボリュームへのタグの適用」を参照してください。
- CSIボリューム・プラグインを使用して新しいブロック・ボリュームにPVCを作成したら、次のようなメトリック集計ツール(Prometheusなど)を使用してブロック・ボリュームの容量統計を表示できます。
kubelet_volume_stats_available_bytes
kubelet_volume_stats_capacity_bytes
kubelet_volume_stats_inodes
kubelet_volume_stats_inodes_free
kubelet_volume_stats_inodes_used
kubelet_volume_stats_used_bytes
CSIボリューム・プラグインを使用したブロック・ボリュームでの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などのメトリック集計ツールを使用して、新しい永続ボリュームの容量統計を表示できます。
CSIボリューム・プラグインを使用したブロック・ボリューム・バックアップからのボリューム・スナップショットの作成 🔗
Kubernetesボリューム・スナップショットは、ストレージ・システム上の永続ボリュームのスナップショットです。ボリューム・スナップショットを使用して、新しい永続ボリュームをプロビジョニングできます。Kubernetesボリューム・スナップショットの詳細は、Kubernetesドキュメントのボリューム・スナップショットを参照してください。
CSIボリューム・プラグインを使用して、クラスタをブロック・ボリューム・サービス内のブロック・ボリュームに接続する場合、ブロック・ボリューム・バックアップを使用してKubernetesボリューム・スナップショットをプロビジョニングできます。ボリューム・スナップショットを使用して新しいブロック・ボリュームを作成し、ブロック・ボリューム・バックアップからのデータを事前に移入できます。ブロック・ボリューム・サービスでのブロック・ボリューム・バックアップの詳細は、ブロック・ボリューム・バックアップの概要を参照してください。
CSIボリューム・プラグインを使用すると、次の2つの方法のいずれかでボリューム・スナップショットをプロビジョニングできます。
- 動的に:永続ボリュームをプロビジョニングするブロック・ボリュームのバックアップの作成をリクエストできます。
VolumeSnapshot
オブジェクトを使用して永続ボリューム要求を指定し、VolumeSnapshotClass
オブジェクトを使用してブロック・ボリューム・バックアップの作成に使用するパラメータを指定します。動的にプロビジョニングされるボリューム・スナップショットは、動的ボリューム・スナップショットとも呼ばれます。動的にプロビジョニングされるボリューム・スナップショットの作成を参照してください。 - 静的:
VolumeSnapshotContent
オブジェクトを使用して、既存のブロック・ボリューム・バックアップの詳細を指定できます。静的にプロビジョニングされたボリューム・スナップショットは、静的ボリューム・スナップショット、および事前にプロビジョニングされたボリューム・スナップショットとも呼ばれます。静的にプロビジョニングされたボリューム・スナップショットの作成
動的にプロビジョニングされるボリューム・スナップショットを作成すると、ソース・ブロック・ボリュームに適用されたものと同じフリーフォーム・タグおよび定義済タグがブロック・ボリューム・バックアップに適用されます。ただし、パラメータを使用して、ブロック・ボリューム・バックアップに追加タグを適用できます(ブロック・ボリューム・バックアップのタグ付けを参照)。
Kubernetes Engineによって作成されたクラスタで使用するボリューム・スナップショットを作成する前に満たす前提条件が多数あります。ボリューム・スナップショットを作成するための前提条件を参照してください。
ボリューム・スナップショットを作成および使用する場合は、次の点に注意してください:
- ボリューム・スナップショットを作成できるのは、CSIボリューム・プラグインを使用する場合のみです(つまり、FlexVolumeボリューム・プラグインを使用する場合、ボリューム・スナップショットを作成できません)。
- 動的ボリューム・バックアップの場合、CSIボリューム・プラグインは、クラスタと同じコンパートメントに動的ボリューム・スナップショットをプロビジョニングするために、新しいブロック・ボリューム・バックアップを作成します。静的ボリューム・スナップショットの場合、クラスタがその他のコンパートメントにアクセスできるようにするための適切なポリシー・ステートメントが存在していれば、静的ボリューム・スナップショットをプロビジョニングするブロック・ボリューム・バックアップは、クラスタとは異なるコンパートメントに配置できます(ボリューム・スナップショットを作成するための前提条件を参照)。
- CSIボリュームプラグインを使用して、既存のボリュームにデータを再移入することはできません。つまり、永続ボリューム要求のマニフェストで指定されたボリューム・スナップショットを変更することによって、既存の永続ボリュームのデータを以前の状態にリストア(元に戻す)することはできません。CSIボリュームプラグインは、新しいボリュームにデータを移入する場合にのみ使用できます。
- ブロック・ボリューム・バックアップを作成すると(動的ボリューム・スナップショットの作成時など)、ブロック・ボリュームの作成時に使用された暗号化キーがブロック・ボリューム・バックアップの作成にも使用されます。ブロック・ボリューム・バックアップの作成時に新しい暗号化キーを指定することはできません。そのため、ブロック・ボリューム・バックアップでは、バックアップするブロック・ボリュームと同じ暗号化が使用されます。
- ボリューム・スナップショットによってプロビジョニングされた永続ボリュームに指定されたサイズは、スナップショットの作成元のボリュームのサイズより小さくできません。
- CSIボリューム・プラグインが、ボリューム・スナップショットによってプロビジョニングされた永続ボリュームをバックアップするために新しいブロック・ボリュームを作成する場合、ブロック・ボリュームの配置は、ボリューム作成リクエストのトポロジ要件によって異なります。たとえば、CSIボリューム・プラグインが永続ボリューム要求を使用するポッドのブロック・ボリュームを作成する場合、ブロック・ボリュームはポッドが実行されているワーカー・ノードと同じ可用性ドメインに作成されます。
- ネームスペース間スナップショットはサポートされていません。
- クラスタ内の
VolumeSnapshot
およびVolumeSnapshotContent
オブジェクトの数が増えると、etcdでかなりの領域が消費され、予期しないクラスタ動作が発生する可能性があります。クラスタを正常に保つために、不要になったVolumeSnapshot
およびVolumeSnapshotContent
オブジェクトを定期的にクリーン・アップするパージ・メカニズムを実装することをお薦めします。
ボリューム・スナップショットを作成するための前提条件 🔗
Kubernetes Engineによって作成されたクラスタで使用するボリューム・スナップショットを作成するには:
- クラスタのコントロール・プレーン・ノードで、Kubernetesバージョン1.24以上が実行されている必要があります
- クラスタのワーカー・ノードは、x86ベースまたはArmベースのプロセッサ・コンピュート・シェイプを使用している必要があります
- クラスタのワーカー・ノードは、Oracle Linux 7またはOracle Linux 8またはUbuntuを実行している必要があります。
VolumeSnapshot
、VolumeSnapshotContent
およびVolumeSnapshotClass
オブジェクトは、コアKubernetes APIの一部ではありません。したがって、CSIボリュームプラグインを使用してボリュームスナップショットを作成する前に、次のコマンドを実行して、必要なCRD (カスタムリソース定義)ファイルをクラスタにインストールする必要があります。
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'
動的にプロビジョニングされるボリューム・スナップショットの作成 🔗
永続ボリューム要求をプロビジョニングするブロック・ボリュームのバックアップを作成してボリューム・スナップショットを動的にプロビジョニングするには、最初に、作成するブロック・ボリューム・バックアップのタイプを指定するVolumeSnapshotClass
オブジェクトを定義します。VolumeSnapshotClass
オブジェクトを作成したら、VolumeSnapshotClass
を使用するVolumeSnapshot
オブジェクトを定義します。VolumeSnapshot
オブジェクトを使用して、バックアップするブロック・ボリュームによってプロビジョニングされる永続ボリューム要求を指定します。
動的にプロビジョニングされるボリューム・スナップショットを作成すると、Kubernetes Engineによって
VolumeSnapshotContent
オブジェクトが作成されます。動的にプロビジョニングされるボリューム・スナップショットを作成する場合は、Kubernetes Engineが作成するVolumeSnapshotContent
オブジェクトを変更したり、独自のVolumeSnapshotContent
オブジェクトを作成したりしないでください。たとえば、ブロック・ボリュームによってプロビジョニングされるcsi-mypvctobackup.yamlというファイルに、sample-pvcという名前の永続ボリューム要求を定義します。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: sample-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: "oci-bv"
resources:
requests:
storage: 50Gi
永続ボリューム要求を作成します:
kubectl create -f csi-mypvctobackup.yaml
永続ボリューム・クレームは、ポッドなどの他のオブジェクトを定義するときに使用できます。たとえば、次のポッド定義は、/sample-volumeでポッドによってマウントされるsample-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: sample-pvc
新しいポッドを作成すると、永続ボリュームのクレームは、ブロック・ボリュームによってプロビジョニングされた新しい永続ボリュームにバインドされます。
永続ボリューム要求をプロビジョニングするブロック・ボリュームのバックアップを作成する準備として、csi-mysnapshotclass.yamlというファイルにmy-snapclassという名前のVolumeSnapshotClass
オブジェクトを定義して、ブロック・ボリューム・バックアップのパラメータを設定します。
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
name: my-snapclass
driver: blockvolume.csi.oraclecloud.com
parameters:
backupType: full
deletionPolicy: Delete
ここでは:
driver: blockvolume.csi.oraclecloud.com
は、VolumeSnapshot
オブジェクトをプロビジョニングするためのCSIボリューム・プラグインを指定します。parameters.backupType: full
は、ブロック・ボリュームの作成以降のすべての変更をブロック・ボリューム・バックアップに含めることを指定します。incremental
を指定すると、前回のバックアップ以降の変更のみを含むバックアップが作成されます。データ・リカバリの目的では、増分バックアップと完全バックアップの機能的な違いがないことに注意してください。ボリューム・バックアップ・タイプを参照してください。deletionPolicy: Delete
は、関連付けられたVolumeSnapshot
オブジェクトが削除された場合のブロック・ボリューム・バックアップの処理を指定します。関連するVolumeSnapshot
オブジェクトが削除された場合にブロック・ボリュームのバックアップを保持するには、Retain
を指定します。
デフォルトでは、ソース・ブロック・ボリュームに適用されたものと同じフリーフォーム・タグおよび定義済タグがブロック・ボリューム・バックアップに適用されます。ただし、パラメータを使用して、ブロック・ボリューム・バックアップに追加タグを適用できます(ブロック・ボリューム・バックアップのタグ付けを参照)。
VolumeSnapshotClass
オブジェクトを作成します。
kubectl create -f csi-mysnapshotclass.yaml
永続ボリューム要求をプロビジョニングするブロック・ボリュームのバックアップを作成するには、csi-mysnapshot.yamlというファイルでVolumeSnapshot
オブジェクトをmy-snapshotとして定義します。
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: my-snapshot
namespace: default
spec:
volumeSnapshotClassName: my-snapclass
source:
persistentVolumeClaimName: sample-pvc
volumeSnapshotClassName: my-snapclass
は、ブロック・ボリューム・バックアップの作成時に使用するパラメータを取得するVolumeSnapshotClass
オブジェクトとしてmy-snapclass
を指定します。VolumeSnapshot
オブジェクトを作成した後は、volumeSnapshotClassName
を変更できないことに注意してください(新しいVolumeSnapshot
オブジェクトを作成する必要があります)。persistentVolumeClaimName: sample-pvc
は、ブロック・ボリューム・バックアップを作成するブロック・ボリュームに基づく永続ボリューム要求としてsample-pvc
を指定します。VolumeSnapshot
オブジェクトの作成後はソースを変更できないことに注意してください(新しいVolumeSnapshot
オブジェクトを作成する必要があります)。
VolumeSnapshot
オブジェクトを作成します。
kubectl create -f csi-mysnapshot.yaml
VolumeSnapshot
オブジェクトは、新しいブロック・ボリューム・バックアップによって作成およびプロビジョニングされます。ボリューム・スナップショットを使用して、新しい永続ボリュームをプロビジョニングできます(ボリューム・スナップショットを使用した新しいボリュームのプロビジョニングを参照)。
静的にプロビジョニングされたボリューム・スナップショットの作成 🔗
既存のブロック・ボリュームのバックアップからボリューム・スナップショットを静的にプロビジョニングするには、最初にブロック・ボリュームのバックアップを作成します(ブロック・ボリュームの手動バックアップの作成を参照)。
ブロック・ボリューム・バックアップを作成したら、VolumeSnapshotContent
オブジェクトを定義し、既存のブロック・ボリューム・バックアップの詳細(OCIDを含む)を指定します。その後、VolumeSnapshot
オブジェクトを定義し、既存のブロック・ボリューム・バックアップの詳細を提供するVolumeSnapshotContent
オブジェクトを指定できます。
たとえば、csi-mystaticsnapshotcontent.yamlというファイルで、VolumeSnapshotContent
オブジェクトをmy-static-snapshot-contentとして定義します。
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
deletionPolicy: Retain
は、関連付けられたVolumeSnapshot
オブジェクトが削除された場合のブロック・ボリューム・バックアップの処理を指定します。関連するVolumeSnapshot
オブジェクトが削除された場合にブロック・ボリューム・バックアップを削除するには、Delete
を指定します。driver: blockvolume.csi.oraclecloud.com
は、CSIボリューム・プラグインを使用してVolumeSnapshot
オブジェクトをプロビジョニングすることを指定します。snapshotHandle: ocid1.volumebackup.oc1.iad.aaaaaa______xbd
は、既存のブロック・ボリューム・バックアップのOCIDを指定します。volumeSnapshotRef.name: my-static-snapshot
は、既存のブロック・ボリューム・バックアップからプロビジョニングされる対応するVolumeSnapshot
オブジェクトの名前を指定します。このフィールドは必須です。VolumeSnapshotContent
オブジェクトを作成する場合、VolumeSnapshot
オブジェクトが存在する必要はありません。namespace: default
は、既存のブロック・ボリューム・バックアップからプロビジョニングされる対応するVolumeSnapshot
オブジェクトを含むネームスペースを指定します。このフィールドは必須です。
VolumeSnapshotContent
オブジェクトを作成します。
kubectl create -f csi-mystaticsnapshotcontent.yaml
csi-mystaticsnapshot.yamlというファイルで、静的にプロビジョニングされたVolumeSnapshot
オブジェクトをmy-static-snapshotとして定義します。
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: my-static-snapshot
spec:
source:
volumeSnapshotContentName: my-static-snapshot-content
VolumeSnapshotContentName: my-static-snapshot-content
は、以前に作成したVolumeSnapshotContent
オブジェクトの名前を指定します。VolumeSnapshot
オブジェクトの作成後はソースを変更できないことに注意してください(新しいVolumeSnapshot
オブジェクトを作成する必要があります)。
VolumeSnapshot
オブジェクトを作成します。
kubectl create -f csi-mystaticsnapshot.yaml
VolumeSnapshot
オブジェクトが作成され、VolumeSnapshotContent
オブジェクトで指定されたブロック・ボリューム・バックアップによってプロビジョニングされます。ボリューム・スナップショットを使用して、新しい永続ボリュームをプロビジョニングできます(ボリューム・スナップショットを使用した新しいボリュームのプロビジョニングを参照)。
ボリューム・スナップショットを使用した新しいボリュームのプロビジョニング 🔗
動的にプロビジョニングされたボリューム・スナップショットまたは静的にプロビジョニングされたボリューム・スナップショットを作成したら、新しい永続ボリュームをプロビジョニングする永続ボリューム要求のデータソースとしてボリューム・スナップショットを指定できます。
たとえば、psi-mypvcfromsnapshot.yamlというファイルにpvc-fromsnapshotという永続ボリューム要求を定義し、test-snapshotというボリューム・スナップショットによってプロビジョニングします。
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
ここでは:
datasource.name: test-snapshot
は、永続ボリュームのデータ・ソースとして使用するVolumeSnapshot
オブジェクトの名前としてtest-snapshotを指定します。datasource.apiGroup: snapshot.storage.k8s.io
は、使用するKubernetesスナップショット・ストレージAPIのバージョンを指定します。
永続ボリューム要求を作成します:
kubectl create -f csi-mypvcfromsnapshot.yaml
永続ボリューム要求を使用して別のオブジェクト(ポッドなど)をプロビジョニングすると、永続ボリュームが作成され、指定したVolumeSnapshot
オブジェクトを使用して基礎となるブロック・ボリュームが移入されます。たとえば、次のポッド定義から新しいポッドを作成できます。このポッド定義は、/dataでポッドによってマウントされるPVC-fromsnapshot PVCをnginxボリュームとして使用するようにシステムに指示します。
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
新しいポッドを作成すると、永続ボリューム要求は、VolumeSnapshot
オブジェクトによって移入された新しいブロック・ボリュームによってプロビジョニングされた新しい永続ボリュームにバインドされます。
ブロック・ボリューム・バックアップのタグ付け 🔗
CSIボリューム・プラグインを使用して動的にプロビジョニングされるボリューム・スナップショットを作成すると、ソース・ブロック・ボリュームに適用されたものと同じフリーフォーム・タグおよび定義済タグもブロック・ボリューム・バックアップに適用されます。
新しいブロック・ボリューム・バックアップに追加のフリーフォーム・タグを適用するには、VolumeSnapshotClassマニフェスト・ファイルのパラメータ・セクションに次のパラメータを含めます:
oci.oraclecloud.com/freeform-tags: '{"<first-tag-key>":","<first-tag-value>","<second-tag-key>":"<second-tag-value>"...}'
新しいブロック・ボリューム・バックアップに追加の定義済タグを適用するには、VolumeSnapshotClassマニフェスト・ファイルのパラメータ・セクションに次のパラメータを含めます:
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
CSIボリューム・プラグインを使用した既存のブロック・ボリュームのクローニングによるPVCの作成 🔗
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のストレージクラスを指定しない場合は、デフォルトのストレージクラスが使用されます。
既存のブロック・ボリュームをクローニングして新しいPVCをプロビジョニングするための前提条件 🔗
既存の永続ボリューム・クレームをすでにプロビジョニングしているブロック・ボリュームをクローニングして、新しい永続ボリューム・クレームをプロビジョニングするには:
- クラスタのコントロール・プレーン・ノードでは、Kubernetesバージョン1.25以降が実行されている必要があります。
- クラスタのワーカー・ノードは、x86ベースまたはArmベースのプロセッサ・コンピュート・シェイプを使用している必要があります。
- クラスタのワーカー・ノードでは、Oracle Linux 7、Oracle Linux 8またはUbuntuが実行されている必要があります。
- 新しいPVCのデータソースとして指定する既存のPVCは、次のことを行う必要があります。
- ブロック・ボリュームによってプロビジョニングされたPVにすでにバインドされています。
- 「使用可能」の状態にします。
- 新しいブロック・ボリュームのサイズは、クローニング元のソース・ブロック・ボリュームと同じか、それより大きい必要があります。ソース・ブロック・ボリュームより大きい新しいPVCのストレージ値を指定すると、それに応じて新しいブロック・ボリュームのサイズが変更されます。クローニングするブロック・ボリュームより小さい、またはソースPVCのストレージ値より小さい新しいPVCには、ストレージ値を指定できません。
- 新しいブロック・ボリュームに指定するファイル・システム・タイプは、クローニング元のソース・ブロック・ボリュームのファイル・システム・タイプと同じである必要があります(ブロック・ボリュームのファイル・システム・タイプの指定を参照)。
新しいPVCをプロビジョニングするための既存のブロック・ボリュームのクローニング
既存の永続ボリューム要求をすでにプロビジョニングしているブロック・ボリュームをクローニングして新しい永続ボリューム要求をプロビジョニングするには、既存の永続ボリューム要求を新しい永続ボリューム要求のdataSource
として指定します。
たとえば、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永続ボリューム要求をプロビジョニングするブロック・ボリュームからクローニングされたブロック・ボリュームによってプロビジョニングされた新しい永続ボリュームにバインドされます。
クローニングされたブロック・ボリュームのタグ付け
CSIボリューム・プラグインを使用して、別の永続ボリューム要求をプロビジョニングするブロック・ボリュームをクローニングして永続ボリュームをプロビジョニングすると、ソース・ブロック・ボリュームに適用されたものと同じフリーフォーム・タグおよび定義済タグも新しいブロック・ボリュームに適用されます。CSIボリューム・プラグインでは、新しいブロック・ボリュームに追加タグは適用されません。
FlexVolumeボリューム・プラグインを使用した既存のブロック・ボリュームまたはバックアップからの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
このトピックのFlexVolumeの例では、PVCは、topology.kubernetes.io/zone
ラベルを使用してアッシュバーン・リージョンの可用性ドメイン内のストレージをリクエストします。このラベル(および指定する可用性ドメイン名)の使用の詳細は、topology.kubernetes.io/zoneを参照してください。
Block Volume Serviceによる静止中および転送中のデータの暗号化 🔗
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またはノード・プールの「転送中暗号化の使用」オプションを使用)を設定して行います。
指定した設定の相互作用によって、次の表に示すように、ブロック・ボリュームの暗号化方法が決まります。
ノード・プールのisPvEncryptionInTransitEnabled プロパティを次のように設定します。 |
ストレージのclass kms-key-id プロパティは、次のように設定されます。 |
ストレージ・クラスのattachment-type プロパティを次のように設定します。 |
保存データは暗号化されますか。 | 転送データは暗号化されますか。 | ノート |
---|---|---|---|---|---|
true |
Vault内のキーのOCID | paravirtualized |
はい(ユーザー管理キー) | はい(ユーザー管理キー) | |
true |
Vault内のキーのOCID | iscsi |
エラー | エラー | isPvEncryptionInTransitEnabled がTrue に設定されている場合、attachment-type プロパティをparavirtualized に設定する必要があるため、PVをプロビジョニングできません。 |
true |
設定されていません | paravirtualized |
はい(Oracle管理キー) | はい(Oracle管理キー) | |
true |
設定されていません | iscsi |
エラー | エラー | isPvEncryptionInTransitEnabled がTrue に設定されている場合、attachment-type プロパティをparavirtualized に設定する必要があるため、PVをプロビジョニングできません。 |
false |
Vault内のキーのOCID | paravirtualized |
はい(ユーザー管理キー) | いいえ | |
false |
Vault内のキーのOCID | iscsi |
はい(ユーザー管理キー) | いいえ | |
false |
設定されていません | paravirtualized |
はい(Oracle管理キー) | いいえ | |
false |
設定されていません | iscsi |
はい(Oracle管理キー) | いいえ |
マスター暗号化キーを自分で管理するクラスタを作成する前に、次のことを行う必要があります。
- Vaultで適切なマスター暗号化キーを作成します(または、そのようなキーのOCIDを取得します)。キーの管理を参照してください。
- マスター暗号化キーへのアクセス権を付与するポリシーを作成します。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためのユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。
Vaultサービスでのキー・ローテーションの詳細は、Vaultキーのローテーションを参照してください。
例: デフォルトのOracle管理キーを使用した保存中および転送中暗号化を有効にするストレージ・クラスの構成 🔗
ブロック・ボリュームにPVCをプロビジョニングするには、保存中(およびオプションで転送中)のデータを暗号化するためにOracleによって管理されるマスター暗号化キーを使用して、ストレージ・クラスを定義し、次のように設定します。
provisioner:
からblockvolume.csi.oraclecloud.com
-
attachment-type
からparavirtualized
例:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: bv-encrypted-storage-class
provisioner: blockvolume.csi.oraclecloud.com
parameters:
attachment-type: "paravirtualized"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
その後、作成したストレージ・クラスによってプロビジョニングされるPVCを作成できます。
ストレージ・クラスを定義してPVCを作成したら、各ノード・プールのisPvEncryptionInTransitEnabled
プロパティをtrue
に設定します(コンソールでCLI、APIまたはノード・プールの「転送中暗号化の使用」オプションを使用)。転送中データの暗号化は、一部の状況でのみサポートされます(ブロック・ボリューム・サービスによる保存中のデータおよび転送中のデータの暗号化を参照)。
例: 管理するキーを使用した保存中および転送中の暗号化を有効にするためのストレージ・クラスの構成 🔗
保存されている(およびオプションで転送中の)データを暗号化するためにユーザーが管理するマスター暗号化キーを使用して、ブロック・ボリュームにPVCをプロビジョニングするには、次のことが必要です:
- Vaultで適切なマスター暗号化キーを作成します(または、そのようなキーのOCIDを取得します)。キーの管理を参照してください。
- マスター暗号化キーへのアクセス権を付与するポリシーを作成します。ブート・ボリューム、ブロック・ボリュームまたはファイル・システム(あるいはその両方)を暗号化するためのユーザー管理暗号化キーにアクセスするポリシーの作成を参照してください。
適切なマスター暗号化キーおよびポリシーを作成したら、ストレージ・クラスを定義し、次のように設定します。
provisioner:
からblockvolume.csi.oraclecloud.com
attachment-type
からparavirtualized
kms-key-id
: データの暗号化に使用するVaultサービスのマスター暗号化キーのOCID
例:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: bv-user-encrypted-storage-class
provisioner: blockvolume.csi.oraclecloud.com
parameters:
attachment-type: "paravirtualized"
kms-key-id: "ocid1.key.oc1.iad.anntl______usjh"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
その後、作成したストレージ・クラスによってプロビジョニングされるPVCを作成できます。
ストレージ・クラスを定義してPVCを作成したら、各ノード・プールのisPvEncryptionInTransitEnabled
プロパティをtrue
に設定します(コンソールでCLI、APIまたはノード・プールの「転送中暗号化の使用」オプションを使用)。転送中データの暗号化は、一部の状況でのみサポートされます(ブロック・ボリューム・サービスによる保存中のデータおよび転送中のデータの暗号化を参照)。
ブロック・ボリュームの拡張 🔗
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マニフェストを更新して、以前に要求したよりも少ないストレージを要求すると、ストレージ要求は失敗します。
- ブロック・ボリューム・サービスでのブロック・ボリューム・サイズの増加の詳細は、ボリュームのサイズ変更を参照してください。特に、ブロック・ボリュームのサイズ変更前にバックアップを作成することをお薦めします。
例: ブロック・ボリューム拡張を有効にするためのストレージ・クラスの構成 🔗
oci-bv
ストレージ・クラスによってプロビジョニングされたPVCのマニフェストを編集し、ストレージのリクエストを含めます。たとえば、最初に、csi-bvs-PVC-exp.yamlというファイルで、PVCに対して100 GBのストレージをリクエストするようにstorage: 100Gi
を設定できます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
storageClassName: oci-bv
resources:
requests:
storage: 100Gi
volumeName: pvc-bv1
csi-bvs-PVC-exp.yamlファイルからPVCを作成するには、次のコマンドを入力します:
kubectl apply -f csi-bvs-pvc-exp.yaml
その後、PVCで使用可能なストレージの量を増やす必要がある場合があります。たとえば、マニフェストを変更し、storage: 200Gi
を設定できます。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
storageClassName: oci-bv
resources:
requests:
storage: 200Gi
volumeName: pvc-bv1
マニフェストを適用すると、PVCをプロビジョニングするPVが200 GBに増加します。マニフェスト更新によってブロック・ボリューム・サービスがトリガーされ、既存のブロック・ボリュームのサイズが200 GBに増加します。ディスクが次に再スキャンされると(数分かかることがあります)、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を作成する必要があります。
低コスト(0 VPU)、バランス(10 VPU)、および高パフォーマンス(20 VPU)のパフォーマンス・レベルを備えたPVCの作成 🔗
「低コスト」、「バランス」または「高パフォーマンス」パフォーマンス・レベルでブロック・ボリュームによってバックアップされたPVCを作成するには、ストレージ・クラス定義で次のようにvpusPerGB
を設定します:
- 低コスト・パフォーマンス・レベルでは、
vpusPerGB: "0"
を設定します - バランス・パフォーマンス・レベルの場合は、
vpusPerGB: "10"
を設定します - より高いパフォーマンス・パフォーマンス・レベルの場合は、
vpusPerGB: "20"
を設定します
例:
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: oci-high
provisioner: blockvolume.csi.oraclecloud.com
parameters:
vpusPerGB: "20"
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
vpusPerGB
の値は、0、10または20である必要があります。他の値はサポートされません。
oci-high
ストレージ・クラスによってプロビジョニングされたPVCのマニフェストを作成し、ストレージのリクエストを含めます。たとえば、csi-bvs-pvc-perf.yamlというファイルでは、次のようになります。
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: oci-pvc-high
spec:
storageClassName: oci-high
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
csi-bvs-PVC-perf.yamlファイルからPVCを作成するには、次のコマンドを入力します:
kubectl apply -f csi-bvs-pvc-perf.yaml
PVCを作成したら、ポッドなどの他のオブジェクトを作成するときに使用できます。たとえば、次のポッド定義から新しいポッドを作成できます。このポッド定義は、oci-pvc-high
PVCを使用するようにシステムに指示します。
apiVersion: v1
kind: Pod
metadata:
name: pod-high
spec:
containers:
- name: app
image: busybox:latest
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: oci-pvc-high
ポッドを作成すると、新しいブロック・ボリュームがBlock Volumeサービスで作成され、PVCがバックアップされます。新しいブロック・ボリュームには、oci-high
ストレージ・クラス定義で指定したパフォーマンス・レベルがあります。
Ultra-High Performance(30~120VPU)レベルでのPVCの作成 🔗
Ultra High Performanceレベルでブロック・ボリュームによってバックアップされたPVCを作成するには、いくつかのステップを完了する必要があります。この項のステップの詳細は説明されていますが、要約すると、次のことが必要です。
- サポートされているシェイプのワーカー・ノードを含むノード・プールを作成します。
- ブロック・ボリュームをiSCSIアタッチメントとしてコンピュート・インスタンスにアタッチする場合は、ワーカー・ノードをホストしているインスタンスでブロック・ボリューム管理プラグインをインストールして有効にします。
- ストレージ・クラス定義を作成し、ストレージ・クラス定義の
vpusPerGB
を30から120の値に設定します。 - ストレージクラスによってプロビジョニングされたPVCを作成し、ストレージのリクエストを含めます。
適切なPVCを作成したら、Ultra High Performanceブロック・ボリュームを使用するポッドを定義し、Ultra High Performanceブロック・ボリュームをサポートするノードにポッドをスケジュールできます。
Ultra High Performance特性を提供するには、マルチパス対応のアタッチメントを使用して、ワーカー・ノードをホストするコンピュート・インスタンスにUltra High Performanceブロック・ボリュームをアタッチする必要があります。ただし、インスタンスにアタッチされている最初のUltra High Performanceブロック・ボリュームのみが、マルチパス対応アタッチメントでアタッチされます。その結果、インスタンスにアタッチされた最初のUltra High Performanceブロック・ボリュームのみがUltra High Performance特性を持ちます。
クラスタで複数のUltra High Performanceブロック・ボリュームを使用する場合は、Ultra High Performanceブロック・ボリュームと同じ数のノードを作成します。これは、Ultra High Performanceブロック・ボリュームがある場合と同じです。
Ultra High Performanceレベルでブロック・ボリュームによってバックアップされたPVCを作成するには:
- ノード・プールを作成する手順(「管理対象ノード・プールの作成」を参照)に従って、次を指定します:
- Kubernetes Engineでサポートされ、Ultra High Performanceレベルもサポートするベア・メタル(BM)または仮想マシン(VM)シェイプを指定します。
Ultra High Performanceブロック・ボリュームには、マルチパス対応アタッチメントをサポートするシェイプが必要です。また、ノード・プール内のワーカー・ノードを準仮想化アタッチメントとしてホストするコンピュート・インスタンスにブロック・ボリュームをアタッチする場合、VM.Standard.E4も注意してください。サポートされるシェイプはフレックス・シェイプのみです。
以下を参照してください。
- Kubernetesエンジンでサポートされているシェイプについては、管理対象ノードおよび仮想ノードでサポートされているシェイプを参照してください
- Ultra High Performanceレベルをサポートするシェイプのインスタンス・シェイプのパフォーマンス詳細。
- ノード・プール内のすべてのワーカー・ノードに追加するラベルを指定して、ワーカー・ノードがUltra High Performanceレベルをサポートすることを示します。たとえば、
uhp: supported
です。
- Kubernetes Engineでサポートされ、Ultra High Performanceレベルもサポートするベア・メタル(BM)または仮想マシン(VM)シェイプを指定します。
- ノード・プールのワーカー・ノードをiSCSIアタッチメントとしてホストするコンピュート・インスタンスにUltra High Performanceブロック・ボリュームをアタッチする場合は、インスタンスでブロック・ボリューム管理プラグインをインストールして有効化します。
コンソールやCLIの使用など、ブロック・ボリューム管理プラグインをインストールして有効化するには様々な方法があります。または、次のようなカスタムcloud-initスクリプトを指定して、ブロック・ボリューム管理プラグインをインストールして有効化することもできます。
#!/bin/bash curl --fail -H "Authorization: Bearer Oracle" -L0 http://169.254.169.254/opc/v2/instance/metadata/oke_init_script | base64 --decode >/var/run/oke-init.sh bash /var/run/oke-init.sh echo "Installing oci cli package" sudo yum install -y python36-oci-cli echo "Completed oci cli package" instance_id=$(curl -H "Authorization: Bearer Oracle" -L http://169.254.169.254/opc/v2/instance/id) echo "Instance Id : $instance_id" echo "Updating compute instance agent config." oci compute instance update --instance-id $instance_id --force --agent-config '{ "is-agent-disabled": false, "plugins-config": [ {"name": "Block Volume Management", "desiredState": "ENABLED" } ] }' --auth instance_principal echo "Update completed for instance agent config."
ブロック・ボリューム管理プラグインをインストールおよび有効化する場合は、次の点に注意してください:
- コンピュート・インスタンスにパブリックIPアドレスがあるか、VCNにサービス・ゲートウェイがあるため、Block Volume ManagementプラグインはOracleサービスに接続できる必要があります。
- ブロック・ボリューム管理プラグインが、マルチパス対応iSCSIアタッチメントのiSCSI設定の結果をレポートできるように、権限を構成する必要があります。
詳細は次を参照してください。
- ブロック・ボリューム管理プラグインについて、「ブロック・ボリューム管理プラグインの有効化」を参照してください。
- カスタムのcloud-initスクリプトの作成については、カスタムのcloud-init初期化スクリプトを使用した管理対象ノードの設定を参照してください。
- Ultra High Performanceパフォーマンス・レベルでブロック・ボリュームのストレージ・クラス定義を作成し、ストレージ・クラス定義で
vpusPerGB
を30から120の値に設定します。例:
apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: oci-uhp-sc provisioner: blockvolume.csi.oraclecloud.com parameters: vpusPerGB: "30" attachment-type: "iscsi" reclaimPolicy: Delete volumeBindingMode: WaitForFirstConsumer allowVolumeExpansion: true
-
作成したストレージクラスによってプロビジョニングされたPVCを作成し、次のようにストレージのリクエストを含めます。
-
PVCのマニフェストを作成します。
たとえば、csi-bvs-pvc-uhp.yamlというファイルでは、次のようになります。
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: uhp-claim spec: storageClassName: "oci-uhp-sc" accessModes: - ReadWriteOnce resources: requests: storage: 50Gi
- マニフェスト・ファイルからPVCを作成します。
たとえば、次のように入力します:
kubectl apply -f csi-bvs-pvc-uhp.yaml
-
PVCを作成したら、ポッドなどの他のオブジェクトを作成するときに使用できます。たとえば、次のポッド定義から新しいポッドを作成できます:
apiVersion: v1
kind: Pod
metadata:
name: pod-uhp
labels:
uhp-pod: "true"
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchExpressions:
- key: uhp-pod
operator: In
values:
- "true"
topologyKey: kubernetes.io/hostname
containers:
- name: app
image: iad.ocir.io/odx-oke/oke-public/busybox:latest
command: ["/bin/sh"]
args: ["-c", "while true; do echo $(date -u) >> /data/out.txt; sleep 5; done"]
volumeMounts:
- name: persistent-storage
mountPath: /data
volumes:
- name: persistent-storage
persistentVolumeClaim:
claimName: uhp-claim
nodeSelector:
uhp: supported
この例では、次を指定しました。
- Ultra High Performanceブロック・ボリュームを使用していることを示すポッドのラベル。この例では、
uhp-pod: "true"
- ポッド・ラベルを使用して、Ultra High Performanceブロック・ボリュームを使用するポッドが1つのみ確実に1つのワーカー・ノードで実行されるようにするアンチアフィニティ・ルール。
- ノード・セレクタ。ノード・プール・ラベルから導出された特定のラベルを持つワーカー・ノードでのみポッドが実行されるようにします。この例では、
uhp: supported
- Ultra High Performanceブロック・ボリュームに支えられたPVC。この例では、
claimName: uhp-claim
定義に基づいてポッドを作成すると、ポッドは、Ultra High Performanceのパフォーマンス・レベルに適したシェイプを持つインスタンスでホストされているワーカー・ノードで実行されます。PVCをバックアップするために、新しいブロック・ボリュームがBlock Volumeサービスに作成されます。新しいブロック・ボリュームには、ストレージ・クラス定義で指定したUltra High Performanceパフォーマンス・レベルがあります。
ブロック・ボリュームのファイル・システム・タイプの指定 🔗
Block Volumeサービスのブロック・ボリュームは、様々なタイプのファイル・システムに対して構成できます。使用するもっとも適切なファイルシステムは、予想されるファイルサイズと処理されるファイル数によって異なります。次のような多数のファイル・システム・タイプを使用できます。
- ext3: ext3ファイル・システム・タイプには、信頼性と可用性を向上させるためにジャーナル機能が含まれています。電源障害または制御不能なシステムシャットダウンのあとの整合性チェックは不要です。
- ext4: ext3機能に加えて、ext4ファイル・システム・タイプは、エクステント(連続物理ブロック)、事前割当て、遅延割当て、ファイル・システム・チェックの高速化、より堅牢なジャーナル、およびその他の拡張をサポートしています。
- XFS: XFSファイル・システムは、高性能のジャーナル・ファイル・システム・タイプであり、ファイル・システムが多数のストレージ・デバイスにまたがる場合でも、I/Oスレッド、ファイル・システム帯域幅、ファイルおよびファイル・システム・サイズに高いスケーラビリティを提供します。
ext3およびext4ファイル・システムは、通常、単一の読取り/書込みスレッドおよび小さいファイルを使用するアプリケーションに適しています。一方、XFSファイル・システムは、通常、複数の読取り/書込みスレッドおよび大きいファイルを持つアプリケーションに適しています。
CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com
)を使用してPVCを作成する場合、予想されるワークロードに適したブロック・ボリュームのファイル・システム・タイプを指定できます。
ブロック・ボリュームは、デフォルトでext4ファイル・システムで構成されます。ext4ファイル・システムが予想されるワークロードに適している場合、このトピックの残りの部分で説明するように、ストレージ・クラス定義でファイル・システム・タイプを明示的に指定する必要はありません。
デフォルトでは、ブロック・ボリュームは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を作成する必要があります。
RAWブロック・ボリュームの指定 🔗
CSIボリューム・プラグイン(provisioner: blockvolume.csi.oraclecloud.com
)を使用してクラスタをブロック・ボリューム・サービス内のブロック・ボリュームに接続する場合、PVCを、RAWブロック・ボリュームとして構成されたブロック・ボリュームによってプロビジョニングされるPVにバインドできます。ブロック・ボリュームがマウントされたファイル・システムとしてではなくRAWブロック・ボリュームとして構成されている場合、そのブロック・ボリュームによってプロビジョニングされたPVは、クラスタで実行されているコンテナのブロック・デバイスとして表示されます。その結果、コンテナ内で実行中のアプリケーションは、アタッチされたブロック・ボリュームにブロック・デバイスとしてアクセスでき、ファイル・システムを介してデバイスにアクセスすることによるパフォーマンス・オーバーヘッドが発生しません。このオーバーヘッドは、ダイレクト・ブロック・デバイス・アクセスの利点を享受するパフォーマンスに敏感なアプリケーション(データベースなど)にとって特に重要な場合があります。
PVCをRAWブロック・ボリュームとしてバッキングするブロック・ボリュームを構成するには、PVCマニフェストで volumeMode: Block
を指定します。指定しない場合、volumeMode: Filesystem
が想定され、ブロック・ボリュームはデフォルトでext4ファイル・システムで構成されます。
oci-bv
ストレージ・クラスによってプロビジョニングされたPVCのマニフェストを作成し、ストレージのリクエストを含めて、マニフェストに volumeMode: Block
を指定します。たとえば、csi-bvs-pvc-raw.yamlというファイルでは、次のようになります。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ブロック・ボリュームではサポートされていません。