4.4. ボリュームおよび要求のライフサイクル
PV はクラスターのリソースです。PVC はそれらのリソースの要求であり、リソースに対する要求チェックとして機能します。PV と PVC 間の相互作用には以下のライフサイクルが設定されます。
4.4.1. ストレージのプロビジョニング
PVC で定義される開発者からの要求に対応し、クラスター管理者はストレージおよび一致する PV をプロビジョニングする 1 つ以上の動的プロビジョナーを設定します。
4.4.2. 要求のバインド
PVC の作成時に、ストレージの特定容量の要求、必要なアクセスモードの指定のほか、ストレージクラスを作成してストレージの記述や分類を行います。マスターのコントロールループは新規 PVC の有無を監視し、新規 PVC を適切な PV にバインドします。適切な PV がない場合は、ストレージクラスのプロビジョナーが PV を作成します。
すべての PV のサイズが PVC サイズを超える可能性があります。これは、手動でプロビジョニングされる PV に特に当てはまります。超過を最小限に抑えるために、MicroShift は他のすべての基準に一致する最小の PV にバインドします。
要求は、一致するボリュームが存在しないか、ストレージクラスを提供するいずれの利用可能なプロビジョナーで作成されない場合は、無期限でバインドされないままになります。要求は、一致するボリュームが利用可能になるとバインドされます。たとえば、多数の手動でプロビジョニングされた 50Gi ボリュームを持つクラスターは 100Gi を要求する PVC に一致しません。PVC は 100Gi PV がクラスターに追加されるとバインドされます。
4.4.3. Pod および要求した PV の使用
Pod は要求をボリュームとして使用します。クラスターは要求を検査して、バインドされたボリュームを検索し、Pod にそのボリュームをマウントします。複数のアクセスモードをサポートするボリュームの場合は、要求を Pod のボリュームとして使用する際に適用するモードを指定する必要があります。
要求が存在し、その要求がバインドされている場合は、バインドされた PV を必要な期間保持できます。Pod のスケジュールおよび要求された PV のアクセスは、persistentVolumeClaim を Pod のボリュームブロックに組み込んで実行できます。
ファイル数が多い永続ボリュームを Pod に割り当てる場合、それらの Pod は失敗するか、起動に時間がかかる場合があります。詳細は、When using Persistent Volumes with high file counts in OpenShift, why do pods fail to start or take an excessive amount of time to achieve "Ready" state? を参照してください。
4.4.4. 永続ボリュームの解放
ボリュームの処理が終了したら、API から PVC オブジェクトを削除できます。これにより、リソースを回収できるようになります。ボリュームは要求の削除時に解放 (リリース) されたものとみなされますが、別の要求で利用できる状態にはなりません。以前の要求側に関連するデータはボリューム上に残るため、ポリシーに基づいて処理される必要があります。
4.4.5. 永続ボリュームの回収ポリシー
永続ボリュームの回収ポリシーは、クラスターに対してリリース後のボリュームの処理方法を指示します。ボリュームの回収ポリシーは、Retain、Recycle または Delete のいずれかにすることができます。
-
Retain回収ポリシーは、サポートするボリュームプラグインのリソースの手動による回収を許可します。 -
Recycle回収ポリシーは、ボリュームがその要求からリリースされると、バインドされていない永続ボリュームのプールにボリュームをリサイクルします。
Recycle 再利用ポリシーは、MicroShift 4 で非推奨になりました。動的プロビジョニングは、同等またはそれ以上の機能で推奨されます。
-
Delete回収ポリシーは、MicroShift のPersistentVolumeオブジェクトと、Amazon Elastic Block Store (Amazon EBS)または VMware vSphere などの外部インフラストラクチャーの関連するストレージアセットの両方を削除します。
動的にプロビジョニングされたボリュームは常に削除されます。
4.4.6. 永続ボリュームの手動回収
永続ボリューム要求 (PVC) が削除されると、基礎となる論理ボリュームは reclaimPolicy に従って処理されます。
手順
クラスター管理者として PV を手動で回収するには、以下を実行します。
PV を削除します。
$ oc delete pv <pv-name>
AWS EBS、GCE PD、Azure Disk、Cinder ボリュームなどの外部インフラストラクチャーの関連するストレージアセットは、PV の削除後も引き続き存在します。
- 関連するストレージアセットのデータをクリーンアップします。
- 関連するストレージアセットを削除します。または、同じストレージアセットを再利用するには、ストレージアセットの定義で新規 PV を作成します。
回収される PV が別の PVC で使用できるようになります。
4.4.7. 永続ボリュームの回収ポリシーの変更
永続ボリュームの回収ポリシーを変更するには、以下を実行します。
クラスターの永続ボリュームをリスト表示します。
$ oc get pv
出力例
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim3 manual 3s
永続ボリュームの 1 つを選択し、その回収ポリシーを変更します。
$ oc patch pv <your-pv-name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'選択した永続ボリュームに正しいポリシーがあることを確認します。
$ oc get pv
出力例
NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-b6efd8da-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim1 manual 10s pvc-b95650f8-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Delete Bound default/claim2 manual 6s pvc-bb3ca71d-b7b5-11e6-9d58-0ed433a7dd94 4Gi RWO Retain Bound default/claim3 manual 3s
上記の出力では、要求
default/claim3にバインドされたボリュームにRetain回収ポリシーが含まれるようになりました。ユーザーが要求default/claim3を削除しても、ボリュームは自動的に削除されません。
