28.12. 既存のレガシーストレージに対するストレージクラスの使用
28.12.1. 概要 リンクのコピーリンクがクリップボードにコピーされました!
この例では、レガシーデータボリュームが存在し、cluster-admin
または storage-admin
がそのボリュームを特定のプロジェクトで使用できるようにする必要があります。StorageClass を使用すると、他のユーザーおよびプロジェクトがこのボリュームへのアクセスを要求から取得する可能性が低くなります。これは、要求には完全一致する StorageClass 名の値が必要になるためです。また、この例では動的なプロビジョニングも無効にしています。この例では以下の要件を満たしていることを前提としています。
- OpenShift Container Platform、GCE、および永続ディスクについてある程度理解している。
- OpenShift Container Platform が GCE を使用するように適切に設定されている。
28.12.1.1. シナリオ 1: レガシーデータを含む既存の永続ボリュームに StorageClass をリンクさせる リンクのコピーリンクがクリップボードにコピーされました!
cluster-admin
または storage-admin
として、過去の財務データ用の StorageClass を定義し、作成します。
例28.23 StorageClass の finance-history オブジェクトの定義
この定義を YAML ファイル (finance-history-storageclass.yaml
) に保存して、StorageClass を作成します。
cluster-admin
ユーザーまたは storage-admin
ユーザーは、適切な StorageClass 名を適切なユーザー、グループ、およびプロジェクトに送る必要があります。
StorageClass が存在します。cluster-admin
または storage-admin
は StorageClass で使用するための永続ボリューム (PV) を作成することができます。(動的にプロビジョニングされない) GCE および新しい GCE ディスク (gce-pv.yaml
) に接続される 永続ボリューム を使用して、手動でプロビジョニングされたディスクを作成します。
例28.24 財務履歴の PV オブジェクト
cluster-admin
または storage-admin
として、PV を作成し、これを表示します。
pv-finance-history
が Available で、いつでも利用可能であることに留意してください。
ユーザーとして、Persistent Volume Claim (永続ボリューム要求、PVC) を YAML ファイルとして作成し、以下のように適切な StorageClass 名を指定します。
例28.25 finance-history オブジェクト定義の要求
- 1
- StorageClass 名。 完全一致している必要があります。 そうでない場合には、削除されるか、または名前が一致する別の StorageClass が作成されるまで要求が非バインドの状態になります。
PVC と PV を作成および表示して、バインドされているか確認します。
同じクラスター内の StorageClass を、レガシーデータ (動的プロビジョニングなし) および 動的プロビジョニング の両方に対して使用することができます。