28.11.3. シナリオ 2: クラスターにおけるデフォルトの StorageClass の動作を有効にする方法
この例では、cluster-admin または storage-admin により、StorageClass を要求に暗黙的に指定していない他のすべてのユーザーおよびプロジェクトについてデフォルトのストレージクラスが有効になります。この方法は、特化した StorageClasses をクラスター全体に設定し、伝達することなしに cluster-admin または storage-admin がストレージボリュームを容易に管理できるようにする場合に役に立ちます。
以下の例は 「シナリオ 1: 2 種類の StorageClass を持つ基本的な動的プロビジョニング」 を基づいて作成されています。cluster-admin または storage-admin は、デフォルトの StorageClass として指定するための別の StorageClass を作成します。
例28.18 デフォルトの StorageClass オブジェクトの定義
kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: generic 1 annotations: storageclass.kubernetes.io/is-default-class: "true" 2 provisioner: kubernetes.io/gce-pd parameters: type: pd-standard zone: us-east1-d
cluster-admin または storage-admin として、この定義を YAML ファイル (generic-gce.yaml) に保存し、StorageClass を作成します。
# oc create -f generic-gce.yaml storageclass "generic" created # oc get storageclass NAME TYPE generic kubernetes.io/gce-pd fast kubernetes.io/gce-pd slow kubernetes.io/gce-pd
通常ユーザーとして、StorageClass の要件なしに新規の要求定義を作成し、これをファイル (generic-pvc.yaml) に保存します。
例28.19 デフォルトのストレージ要求オブジェクトの定義
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-engineering2
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi以下のように実行し、要求がバインドされていることをチェックします。
# oc create -f generic-pvc.yaml
persistentvolumeclaim "pvc-engineering2" created
3s
# oc get pvc
NAME STATUS VOLUME CAPACITY ACCESSMODES AGE
pvc-engineering Bound pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX 41m
pvc-engineering2 Bound pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX 7s 1- 1
pvc-engineering2は、デフォルトで、動的にプロビジョニングされたボリュームにバインドされます。
cluster-admin または storage-admin として、ここまでに定義した永続ボリュームを表示します。
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 5m 1 pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 46m 2
GCE を使用して (動的にプロビジョニングされるのではなく) 手動でプロビジョニングされるディスクを作成します。次に、新規の GCE ディスク (pv-manual-gce.yaml) に接続する 永続ボリューム を作成します。
例28.20 手動の PV オブジェクトの定義
apiVersion: v1 kind: PersistentVolume metadata: name: pv-manual-gce spec: capacity: storage: 35Gi accessModes: - ReadWriteMany gcePersistentDisk: readOnly: false pdName: the-newly-created-gce-PD fsType: ext4
オブジェクト定義ファイルを実行します。
# oc create -f pv-manual-gce.yaml
ここでもう一度 PV を表示します。pv-manual-gce ボリュームが Available になっていることに留意してください。
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pv-manual-gce 35Gi RWX Retain Available 4s pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 12m pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 53m
今度は generic-pvc.yaml PVC 定義と同一の別の要求を作成しますが、名前を変更し、ストレージクラス名は設定しません。
例28.21 要求オブジェクトの定義
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-engineering3
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 15Giこのインスタンスではデフォルトの StorageClass が有効になっているため、手動で作成された PV は要求のリクエストを満たしません。ユーザーは動的にプロビジョニングされた新規の永続ボリュームを受け取ります。
# oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE pvc-engineering Bound pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX 1h pvc-engineering2 Bound pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX 19m pvc-engineering3 Bound pvc-6fa8e73b-8c00-11e6-9962-42010af00004 15Gi RWX 6s
デフォルトの StorageClass がこのシステムで有効になっているため、手動で作成された永続ボリュームを前述の要求によってバインドし、動的にプロビジョニングされた新規ボリュームがバインドされないようにするには、PV をデフォルトの StorageClass で作成しておく必要があります。
デフォルトの StorageClass がこのシステムで有効になっているため、手動で作成された永続ボリュームを前述の要求によってバインドし、動的にプロビジョニングされた新規ボリュームをバインドしないようにするためには、PV をデフォルトの StorageClass で作成しておく必要があります。
これを解決するには、cluster-admin ユーザーまたは storage-admin ユーザーは、別の GCE ディスクを作成するか、または必要に応じて最初の手動の PV を削除し、StorageClass 名を割り当てる PV オブジェクト定義 (pv-manual-gce2.yaml) を使用することのみが必要になります。
例28.22 デフォルトの StorageClass 名を持つ手動 PV の仕様
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-manual-gce2
spec:
capacity:
storage: 35Gi
accessModes:
- ReadWriteMany
gcePersistentDisk:
readOnly: false
pdName: the-newly-created-gce-PD
fsType: ext4
storageClassName: generic 1- 1
- 先に作成した汎用 の StorageClass の名前。
オブジェクト定義ファイルを実行します。
# oc create -f pv-manual-gce2.yaml
PV を一覧表示します。
# oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pv-manual-gce 35Gi RWX Retain Available 4s 1 pv-manual-gce2 35Gi RWX Retain Bound rh-eng/pvc-engineering3 4s 2 pvc-a9f70544-8bfd-11e6-9962-42010af00004 5Gi RWX Delete Bound rh-eng/pvc-engineering2 12m pvc-ba4612ce-8b4d-11e6-9962-42010af00004 5Gi RWO Delete Bound mytest/gce-dyn-claim1 21h pvc-e9b4fef7-8bf7-11e6-9962-42010af00004 10Gi RWX Delete Bound rh-eng/pvc-engineering 53m
動的にプロビジョニングされたすべてのボリュームの RECLAIMPOLICY がデフォルトで Delete である点に注目してください。PV に動的にバインドされた PVC が削除されると、GCE ボリュームが削除され、すべてのデータが消失します。ただし、手動で作成された PV の RECLAIMPOLICY はデフォルトで Retain です。
