저장소 클래스

저장소 클래스 (Storage Classes)

이 문서는 쿠버네티스의 StorageClass 개념을 설명해요. 볼륨과 영구 볼륨에 익숙하다고 가정해요.

StorageClass는 관리자가 제공하는 저장소의 클래스를 설명하는 방법을 제공해요. 서로 다른 클래스는 서비스 품질(QoS) 수준, 백업 정책, 또는 클러스터 관리자가 결정한 임의의 정책에 매핑될 수 있어요. 쿠버네티스 자체는 클래스가 무엇을 나타내는지에 대해 특정 의견을 갖고 있지 않아요.

저장소 클래스의 쿠버네티스 개념은 일부 다른 저장소 시스템 설계의 "프로파일"과 유사해요.

출처: 문서

본문

StorageClass 객체

각 StorageClass는 provisioner, parameters, reclaimPolicy 필드를 포함하며, 이들은 그 클래스에 속한 PersistentVolume이 PersistentVolumeClaim(PVC)을 충족하기 위해 동적으로 프로비저닝되어야 할 때 사용돼요.

StorageClass 객체의 이름은 의미가 있으며, 사용자가 특정 클래스를 요청하는 방식이에요. 관리자는 StorageClass 객체를 처음 만들 때 클래스의 이름과 다른 파라미터를 설정해요.

관리자는 특정 클래스를 요청하지 않는 어떤 PVC에도 적용되는 기본 StorageClass를 지정할 수 있어요. 자세한 내용은 PersistentVolumeClaim 개념을 참고하세요.

StorageClass의 예시는 다음과 같아요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: low-latency
  annotations:
    storageclass.kubernetes.io/is-default-class: "false"
provisioner: csi-driver.example-vendor.example
reclaimPolicy: Retain # 기본값은 Delete
allowVolumeExpansion: true
mountOptions:
- discard # 이것은 블록 저장소 계층에서 UNMAP / TRIM을 활성화할 수 있음
volumeBindingMode: WaitForFirstConsumer
parameters:
  guaranteedReadWriteLatency: "true" # 제공자별

기본 StorageClass (Default StorageClass)

StorageClass를 클러스터의 기본으로 표시할 수 있어요. 기본 StorageClass 설정에 대한 지침은 '기본 StorageClass 변경'을 참고하세요.

PVC가 storageClassName을 지정하지 않으면 기본 StorageClass가 사용돼요.

클러스터의 둘 이상의 StorageClass에 storageclass.kubernetes.io/is-default-class 어노테이션을 true로 설정하고 storageClassName이 설정되지 않은 PersistentVolumeClaim을 만들면, 쿠버네티스는 가장 최근에 생성된 기본 StorageClass를 사용해요.

참고:

새 PVC에 대해 storageClassName을 지정하지 않고 PersistentVolumeClaim을 만들 수 있으며, 클러스터에 기본 StorageClass가 없을 때도 그렇게 할 수 있어요. 이 경우 새 PVC는 정의한 대로 만들어지고, 기본이 사용 가능해질 때까지 그 PVC의 storageClassName은 설정되지 않은 채로 남아요.

기본 StorageClass가 없는 클러스터를 가질 수 있어요. 어떤 StorageClass도 기본으로 표시하지 않으면(그리고 클라우드 제공자가 설정해 주지 않았다면), 쿠버네티스는 그 기본값이 필요한 PersistentVolumeClaim에 대해 그 기본값 적용을 할 수 없어요.

기본 StorageClass가 사용 가능해지면(또는 사용 가능해질 때), 제어 플레인은 storageClassName이 없는 기존 PVC를 식별해요. storageClassName 값이 비어 있거나 이 키가 없는 PVC의 경우, 제어 플레인은 새 기본 StorageClass와 일치하도록 storageClassName을 설정하도록 그 PVC를 업데이트해요. storageClassName이 ""인 기존 PVC가 있고 기본 StorageClass를 구성하면, 그 PVC는 업데이트되지 않아요.

(기본 StorageClass가 있는 동안) storageClassName이 ""로 설정된 PV에 계속 바인딩하려면, 관련 PVC의 storageClassName을 ""로 설정해야 해요.

프로비저너 (Provisioner)

각 StorageClass에는 PV를 프로비저닝할 때 사용할 볼륨 플러그인을 결정하는 프로비저너가 있어요. 이 필드는 반드시 지정해야 해요.

볼륨 플러그인	내부 프로비저너	구성 예시
AzureFile	✓	Azure File
CephFS	-	-
FC	-	-
FlexVolume	-	-
iSCSI	-	-
Local	-	Local
NFS	-	NFS
PortworxVolume	✓	Portworx Volume
RBD	-	Ceph RBD
VsphereVolume	✓	vSphere

여기에 나열된 "내부" 프로비저너만 지정해야 하는 것은 아니에요(그 이름은 "kubernetes.io" 접두사가 붙고 쿠버네티스와 함께 제공돼요). 쿠버네티스가 정의한 사양을 따르는 독립 프로그램인 외부 프로비저너를 실행하고 지정할 수도 있어요. 외부 프로비저너의 작성자는 코드가 어디에 살지, 어떻게 배포될지, 어떻게 실행돼야 하는지, 어떤 볼륨 플러그인(Flex 포함)을 사용할지 등을 완전히 재량으로 결정할 수 있어요. kubernetes-sigs/sig-storage-lib-external-provisioner 저장소는 사양의 대부분을 구현하는 외부 프로비저너 작성용 라이브러리를 보관해요. 일부 외부 프로비저너는 kubernetes-sigs/sig-storage-lib-external-provisioner 저장소에 나열돼 있어요.

예를 들어 NFS는 내부 프로비저너를 제공하지 않지만, 외부 프로비저너를 사용할 수 있어요. 서드파티 저장소 공급업체가 자체 외부 프로비저너를 제공하는 경우도 있어요.

회수 정책 (Reclaim policy)

StorageClass가 동적으로 만든 PersistentVolume은 그 클래스의 reclaimPolicy 필드에 지정된 회수 정책을 가지며, 이는 Delete 또는 Retain일 수 있어요. StorageClass 객체가 생성될 때 reclaimPolicy가 지정되지 않으면 Delete로 기본 설정돼요.

수동으로 만들어 StorageClass로 관리되는 PersistentVolume은 생성 시 할당된 회수 정책을 가져요.

볼륨 확장 (Volume expansion)

PersistentVolume을 확장 가능하도록 구성할 수 있어요. 이를 통해 해당 PVC 객체를 편집해 새롭고 더 큰 저장소 양을 요청해 볼륨 크기를 조정할 수 있어요.

다음 볼륨 유형은 기반 StorageClass에 allowVolumeExpansion 필드가 true로 설정되어 있을 때 볼륨 확장을 지원해요.

볼륨 유형	볼륨 확장에 필요한 쿠버네티스 버전
Azure File	1.11
CSI	1.24
FlexVolume	1.13
Portworx	1.11
rbd	1.11

참고:

마운트 옵션 (Mount options)

StorageClass가 동적으로 만든 PersistentVolume은 그 클래스의 mountOptions 필드에 지정된 마운트 옵션을 가져요.

볼륨 플러그인이 마운트 옵션을 지원하지 않는데 마운트 옵션이 지정되면 프로비저닝이 실패해요. 마운트 옵션은 클래스나 PV에서 검증되지 않아요. 마운트 옵션이 유효하지 않으면 PV 마운트가 실패해요.

볼륨 바인딩 모드 (Volume binding mode)

volumeBindingMode 필드는 볼륨 바인딩과 동적 프로비저닝이 언제 발생해야 하는지를 제어해요. 설정되지 않으면 기본으로 Immediate 모드가 사용돼요.

Immediate 모드는 PersistentVolumeClaim이 생성되면 볼륨 바인딩과 동적 프로비저닝이 발생함을 나타내요. 토폴로지가 제약되어 있고 클러스터의 모든 노드에서 전역적으로 접근할 수 없는 저장소 백엔드의 경우, PersistentVolume은 파드의 스케줄링 요구 사항에 대한 지식 없이 바인딩되거나 프로비저닝돼요. 이로 인해 스케줄링할 수 없는 파드가 발생할 수 있어요.

클러스터 관리자는 PersistentVolumeClaim을 사용하는 파드가 생성될 때까지 PersistentVolume의 바인딩과 프로비저닝을 지연하는 WaitForFirstConsumer 모드를 지정해 이 문제를 해결할 수 있어요. PersistentVolume은 파드의 스케줄링 제약이 지정하는 토폴로지에 맞춰 선택되거나 프로비저닝돼요. 여기에는 리소스 요구 사항, 노드 셀렉터, 파드 어피니티 및 안티-어피니티, 테인트와 톨러레이션이 포함되지만 이에 국한되지는 않아요.

다음 플러그인은 동적 프로비저닝과 함께 WaitForFirstConsumer를 지원해요.

CSI 볼륨(특정 CSI 드라이버가 이를 지원하는 경우)

다음 플러그인은 미리 생성된 PersistentVolume 바인딩과 함께 WaitForFirstConsumer를 지원해요.

CSI 볼륨(특정 CSI 드라이버가 이를 지원하는 경우)
local

참고:

WaitForFirstConsumer를 사용하기로 선택했다면, 파드 스펙에서 nodeName을 사용해 노드 어피니티를 지정하지 마세요. 이 경우 nodeName을 사용하면 스케줄러가 우회되고 PVC가 pending 상태로 남게 돼요.

대신 kubernetes.io/hostname에 대한 노드 셀렉터를 사용할 수 있어요.

apiVersion: v1
kind: Pod
metadata:
  name: task-pv-pod
spec:
  nodeSelector:
    kubernetes.io/hostname: kube-01
  volumes:
    - name: task-pv-storage
      persistentVolumeClaim:
        claimName: task-pv-claim
  containers:
    - name: task-pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: task-pv-storage

허용 토폴로지 (Allowed topologies)

클러스터 운영자가 WaitForFirstConsumer 볼륨 바인딩 모드를 지정하면, 대부분의 상황에서 프로비저닝을 특정 토폴로지로 제한할 필요가 더 이상 없어요. 하지만 여전히 필요하다면 allowedTopologies를 지정할 수 있어요.

이 예시는 프로비저닝된 볼륨의 토폴로지를 특정 존으로 제한하는 방법을 보여 주며, 지원되는 플러그인의 zone과 zones 파라미터의 대체품으로 사용해야 해요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: example.com/example
parameters:
  type: pd-standard
volumeBindingMode: WaitForFirstConsumer
allowedTopologies:
- matchLabelExpressions:
  - key: topology.kubernetes.io/zone
    values:
    - us-central-1a
    - us-central-1b

파라미터 (Parameters)

StorageClass에는 그 저장소 클래스에 속한 볼륨을 설명하는 parameters가 있어요. provisioner에 따라 허용되는 파라미터가 다를 수 있어요. 파라미터가 생략되면 일부 기본값이 사용돼요.

StorageClass에 대해 정의할 수 있는 파라미터는 최대 512개예요. 키와 값을 포함한 parameters 객체의 총 길이는 256 KiB를 초과할 수 없어요.

AWS EBS

쿠버네티스 1.37에는 awsElasticBlockStore 볼륨 유형이 포함되지 않아요.

AWSElasticBlockStore 트리 내 저장소 드라이버는 쿠버네티스 v1.19 릴리스에서 폐기되었고, v1.27 릴리스에서 완전히 제거됐어요.

쿠버네티스 프로젝트는 대신 AWS EBS 트리 외 저장소 드라이버를 사용할 것을 권장해요.

다음은 AWS EBS CSI 드라이버용 StorageClass 예시예요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: ebs-sc
provisioner: ebs.csi.aws.com
volumeBindingMode: WaitForFirstConsumer
parameters:
  csi.storage.k8s.io/fstype: xfs
  type: io1
  iopsPerGB: "50"
  encrypted: "true"
  tagSpecification_1: "key1=value1"
  tagSpecification_2: "key2=value2"
allowedTopologies:
- matchLabelExpressions:
  - key: topology.ebs.csi.aws.com/zone
    values:
    - us-east-2c

tagSpecification: 이 접두사가 있는 태그는 동적으로 프로비저닝된 EBS 볼륨에 적용돼요.

AWS EFS

AWS EFS 저장소를 구성하려면 트리 외 AWS_EFS_CSI_DRIVER를 사용할 수 있어요.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: efs-sc
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-92107410
  directoryPerms: "700"

provisioningMode: Amazon EFS가 프로비저닝할 볼륨의 유형. 현재는 액세스 포인트 기반 프로비저닝(efs-ap)만 지원됨.
fileSystemId: 액세스 포인트가 생성되는 파일시스템.
directoryPerms: 액세스 포인트가 만든 루트 디렉터리의 디렉터리 권한.

자세한 내용은 AWS_EFS_CSI_Driver 동적 프로비저닝 문서를 참조하세요.

NFS

NFS 저장소를 구성하려면 트리 내 드라이버 또는 쿠버네티스용 NFS CSI 드라이버(권장)를 사용할 수 있어요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-nfs
provisioner: example.com/external-nfs
parameters:
  server: nfs-server.example.com
  path: /share
  readOnly: "false"

server: NFS 서버의 호스트 이름 또는 IP 주소.
path: NFS 서버가 내보내는 경로.
readOnly: 저장소가 읽기 전용으로 마운트될지 여부를 나타내는 플래그(기본 false).

쿠버네티스는 내부 NFS 프로비저너를 포함하지 않아요. NFS용 StorageClass를 만들려면 외부 프로비저너를 사용해야 해요. 예시는 다음과 같아요.

NFS Ganesha 서버 및 외부 프로비저너
NFS subdir 외부 프로비저너

vSphere

vSphere 저장소 클래스에는 두 가지 유형의 프로비저너가 있어요.

CSI 프로비저너: csi.vsphere.vmware.com
vCP 프로비저너: kubernetes.io/vsphere-volume

트리 내 프로비저너는 폐기됐어요. CSI 프로비저너에 대한 자세한 내용은 Kubernetes vSphere CSI Driver 및 vSphereVolume CSI 마이그레이션을 참고하세요.

CSI 프로비저너

vSphere CSI StorageClass 프로비저너는 Tanzu Kubernetes 클러스터와 함께 동작해요. 예시는 vSphere CSI 저장소를 참조하세요.

vCP 프로비저너

다음 예시는 VMware Cloud Provider(vCP) StorageClass 프로비저너를 사용해요.

사용자 지정 디스크 형식으로 StorageClass 만들기.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
  diskformat: zeroedthick

diskformat: thin, zeroedthick, eagerzeroedthick. 기본값: "thin".

사용자 지정 데이터스토어에 디스크 형식으로 StorageClass 만들기.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/vsphere-volume
parameters:
  diskformat: zeroedthick
  datastore: VSANDatastore

datastore: 사용자는 StorageClass에서 데이터스토어를 지정할 수도 있어요. 볼륨은 StorageClass에 지정된 데이터스토어(이 경우 VSANDatastore)에 생성돼요. 이 필드는 선택적이에요. 데이터스토어가 지정되지 않으면 vSphere Cloud Provider를 초기화하는 데 사용된 vSphere 구성 파일에 지정된 데이터스토어에 볼륨이 생성돼요.

Kubernetes 안에서의 Storage Policy Management
- 기존 vCenter SPBM 정책 사용하기. vSphere 저장소 관리의 가장 중요한 기능 중 하나는 정책 기반 관리예요. SPBM(Storage Policy Based Management)은 광범위한 데이터 서비스와 저장소 솔루션에 걸쳐 단일 통합 제어 플레인을 제공하는 저장소 정책 프레임워크예요. SPBM은 vSphere 관리자가 용량 계획, 차별화된 서비스 수준, 용량 헤드룸 관리 같은 선행 저장소 프로비저닝 문제를 극복할 수 있게 해줘요. SPBM 정책은 storagePolicyName 파라미터를 사용해 StorageClass에 지정할 수 있어요.
- Kubernetes 안의 Virtual SAN 정책 지원. Vsphere Infrastructure(VI) 관리자는 동적 볼륨 프로비저닝 중에 사용자 지정 Virtual SAN 저장소 기능을 지정할 수 있어요. 이제 동적 볼륨 프로비저닝 중 성능과 가용성 같은 저장소 요구 사항을 저장소 기능 형태로 정의할 수 있어요. 저장소 기능 요구 사항은 Virtual SAN 정책으로 변환된 다음, 영구 볼륨(가상 디스크)이 생성될 때 Virtual SAN 계층으로 전달돼요. 가상 디스크는 요구 사항을 충족하기 위해 Virtual SAN 데이터스토어에 분산돼요. 영구 볼륨 관리를 위한 저장소 정책 사용 방법에 대한 자세한 내용은 볼륨의 동적 프로비저닝을 위한 Storage Policy Based Management를 참조하세요.

Ceph RBD (폐기됨)

참고:

이 기능 상태는 쿠버네티스 v1.28부터 폐기됨(Deprecated)입니다.

이 Ceph RBD의 내부 프로비저너는 폐기됐어요. CephFS RBD CSI 드라이버를 사용하세요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: fast
provisioner: kubernetes.io/rbd # 이 프로비저너는 폐기됨
parameters:
  monitors: 198.19.254.105:6789
  adminId: kube
  adminSecretName: ceph-secret
  adminSecretNamespace: kube-system
  pool: kube
  userId: kube
  userSecretName: ceph-secret-user
  userSecretNamespace: default
  fsType: ext4
  imageFormat: "2"
  imageFeatures: "layering"

monitors: Ceph 모니터, 쉼표로 구분. 이 파라미터는 필수.
adminId: 풀에서 이미지를 만들 수 있는 Ceph 클라이언트 ID. 기본값은 "admin".
adminSecretName: adminId용 Secret 이름. 이 파라미터는 필수. 제공된 secret은 유형이 "kubernetes.io/rbd"여야 함.
adminSecretNamespace: adminSecretName의 네임스페이스. 기본값은 "default".
pool: Ceph RBD 풀. 기본값은 "rbd".
userId: RBD 이미지를 매핑하는 데 사용되는 Ceph 클라이언트 ID. 기본값은 adminId와 같음.
userSecretName: userId가 RBD 이미지를 매핑하기 위한 Ceph Secret의 이름. PVC와 같은 네임스페이스에 존재해야 함. 이 파라미터는 필수. 제공된 secret은 유형이 "kubernetes.io/rbd"여야 함. 예를 들어 다음과 같이 만들어짐:

kubectl create secret generic ceph-secret --type="kubernetes.io/rbd" \
  --from-literal=key='QVFEQ1pMdFhPUnQrSmhBQUFYaERWNHJsZ3BsMmNjcDR6RFZST0E9PQ==' \
  --namespace=kube-system

userSecretNamespace: userSecretName의 네임스페이스.
fsType: kubernetes가 지원하는 fsType. 기본값은 "ext4".
imageFormat: Ceph RBD 이미지 형식, "1" 또는 "2". 기본값은 "2".
imageFeatures: 이 파라미터는 선택적이며 imageFormat을 "2"로 설정한 경우에만 사용해야 함. 현재 지원되는 기능은 layering뿐. 기본값은 ""이며 어떤 기능도 켜지지 않음.

Azure Disk

쿠버네티스 1.37에는 azureDisk 볼륨 유형이 포함되지 않아요.

azureDisk 트리 내 저장소 드라이버는 쿠버네티스 v1.19 릴리스에서 폐기되었고, v1.27 릴리스에서 완전히 제거됐어요.

쿠버네티스 프로젝트는 Azure Disk 서드파티 저장소 드라이버를 사용할 것을 권장해요.

Azure File (폐기됨)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: azurefile
provisioner: kubernetes.io/azure-file
parameters:
  skuName: Standard_LRS
  location: eastus
  storageAccount: azure_storage_account_name # 예시 값

skuName: Azure 저장소 계정 SKU 계층. 기본값은 비어 있음.
location: Azure 저장소 계정 위치. 기본값은 비어 있음.
storageAccount: Azure 저장소 계정 이름. 기본값은 비어 있음. 저장소 계정이 제공되지 않으면, 리소스 그룹과 연결된 모든 저장소 계정이 검색되어 skuName과 location과 일치하는 것을 찾음. 저장소 계정이 제공되면 클러스터와 같은 리소스 그룹에 있어야 하며 skuName과 location은 무시됨.
secretNamespace: Azure 저장소 계정 이름과 키를 포함하는 secret의 네임스페이스. 기본값은 파드와 같음.
secretName: Azure 저장소 계정 이름과 키를 포함하는 secret의 이름. 기본값은 azure-storage-account--secret.
readOnly: 저장소가 읽기 전용으로 마운트될지 여부를 나타내는 플래그. 기본값은 false로 읽기/쓰기 마운트를 의미함. 이 설정은 VolumeMounts의 ReadOnly 설정에도 영향을 줌.

저장소 프로비저닝 중에 마운트 자격 증명을 위해 secretName이 명명한 secret이 생성돼요. 클러스터가 RBAC와 Controller Roles를 모두 활성화했다면 clusterrole system:controller:persistent-volume-binder에 대한 리소스 secret의 create 권한을 추가하세요.

멀티 테넌시 컨텍스트에서 secretNamespace 값을 명시적으로 설정하는 것을 강력히 권장해요. 그렇지 않으면 저장소 계정 자격 증명을 다른 사용자가 읽을 수 있어요.

Portworx 볼륨 (폐기됨)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: portworx-io-priority-high
provisioner: kubernetes.io/portworx-volume # 이 프로비저너는 폐기됨
parameters:
  repl: "1"
  snap_interval: "70"
  priority_io: "high"

fs: 레이아웃될 파일시스템: none/xfs/ext4 (기본값: ext4).
block_size: Kbytes 단위의 블록 크기 (기본값: 32).
repl: 복제 계수 1..3 형태로 제공되는 동기 복제 수(기본값: 1). 여기서는 문자열이 기대됩니다. 즉 "1"이며 1이 아닙니다.
priority_io: 볼륨이 더 높은 성능에서 생성될지 더 낮은 우선순위 저장소에서 생성될지 결정함. high/medium/low (기본값: low).
snap_interval: 스냅샷을 트리거할 분 단위의 시계/시간 간격. 스냅샷은 이전 스냅샷과의 차이에 기반한 증분이므로, 0은 스냅샷을 비활성화함(기본값: 0). 여기서는 문자열이 기대됩니다. 즉 "70"이며 70이 아닙니다.
aggregation_level: 볼륨이 분산될 청크 수를 지정. 0은 비집계 볼륨을 나타냄(기본값: 0). 여기서는 문자열이 기대됩니다. 즉 "0"이며 0이 아닙니다.
ephemeral: 볼륨이 언마운트 후 정리되어야 하는지 지속되어야 하는지 지정. emptyDir 사용 사례는 이 값을 true로, Cassandra 같은 데이터베이스의 영구 볼륨 사용 사례는 false로 설정할 수 있음. true/false (기본 false). 여기서는 문자열이 기대됩니다. 즉 "true"이며 true가 아닙니다.

Local

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner # 이 StorageClass가 자동 프로비저닝을 지원하지 않음을 나타냄
volumeBindingMode: WaitForFirstConsumer

Local 볼륨은 쿠버네티스 1.37에서 동적 프로비저닝을 지원하지 않아요. 하지만 파드가 실제로 적절한 노드에 스케줄링될 때까지 볼륨 바인딩을 지연하려면 여전히 StorageClass를 만들어야 해요. 이는 WaitForFirstConsumer 볼륨 바인딩 모드로 지정돼요.

볼륨 바인딩을 지연하면 스케줄러가 PersistentVolumeClaim에 대한 적절한 PersistentVolume을 선택할 때 파드의 모든 스케줄링 제약을 고려할 수 있어요.

저장소 클래스