28.11.3. 시나리오 2: 클러스터에 대한 기본 StorageClass 동작을 활성화하는 방법
이 예에서 cluster-admin 또는 storage-admin 은 클레임에 StorageClass 를 암시적으로 지정하지 않는 다른 모든 사용자와 프로젝트에 기본 스토리지 클래스를 활성화합니다. 이는 클러스터 전체에서 특수 StorageClass 를 설정하거나 통신할 필요 없이 cluster -admin이 스토리지 볼륨을 쉽게 관리하는 데 유용합니다.
-admin 또는 storage
이 예제는 28.11.2절. “시나리오 1: 두 가지 유형의 스토리지 클래스를 사용하는 기본 동적 프로비저닝 ” 를 기반으로 빌드됩니다. cluster-admin 또는 storage-admin 은 기본 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)에 저장한 다음 StorageClasses를 생성합니다.
# 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
- 1
- 이 PV는 기본 StorageClass 의 기본 동적 볼륨에 바인딩되었습니다.
- 2
- 이 PV는 빠른 스토리지 클래스 와 함께 28.11.2절. “시나리오 1: 두 가지 유형의 스토리지 클래스를 사용하는 기본 동적 프로비저닝 ” 의 첫 번째 PVC에 바인딩되었습니다.
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. Claim 오브젝트 정의
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 가 활성화되므로 수동으로 생성된 영구 볼륨이 위의 클레임에 의해 바인딩되고 새 동적 프로비저닝 볼륨이 바인딩되지 않도록 하려면 기본 StorageClass 에 PV를 생성해야 합니다.
이 시스템에서 기본 StorageClass 가 활성화되어 있으므로 수동으로 생성된 영구 볼륨의 기본 StorageClass 에서 PV를 생성하여 위의 클레임에 바인딩되고 클레임에 바인딩된 새 동적 프로비저닝 볼륨이 없어야 합니다.
이 문제를 해결하려면 cluster-admin 또는 storage-admin 사용자가 다른 GCE 디스크를 생성하거나 첫 번째 수동 PV를 삭제하고 필요한 경우 StorageClass 이름(pv-manual-gce2.yaml)을 할당하는 PV 오브젝트 정의를 사용해야 합니다.
예 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
- 이전에 생성된 일반 스토리지 클래스 의 이름입니다.
오브젝트 정의 파일을 실행합니다.
# 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
기본적으로 동적으로 프로비저닝된 모든 볼륨의 RECLAIMPOLICICICY of Delete 가 있습니다. PVC가 동적으로 PV에 바인딩되면 GCE 볼륨이 삭제되고 모든 데이터가 손실됩니다. 그러나 수동으로 생성된 PV에는 기본 Re CLAIMPOLICICY 가 Retain 이 있습니다.
