영구 볼륨

영구 볼륨 (Persistent Volumes)

이 문서는 Kubernetes의 영구 볼륨을 설명해요. 볼륨, StorageClass, VolumeAttributesClass에 대한 친숙함이 권장돼요.

출처: 문서

본문

소개 (Introduction)

스토리지 관리는 컴퓨트 인스턴스 관리와는 다른 문제예요. PersistentVolume 하위 시스템은 스토리지가 제공되는 방식의 세부 사항을 소비되는 방식에서 추상화하는 API를 사용자와 관리자에게 제공해요. 이를 위해 두 개의 새 API 리소스인 PersistentVolume과 PersistentVolumeClaim을 도입해요.

PersistentVolume(PV)은 관리자가 프로비저닝했거나 StorageClass를 사용해 동적으로 프로비저닝된 클러스터의 스토리지 조각이에요. 노드가 클러스터 리소스인 것처럼 클러스터의 리소스예요. PV는 볼륨과 같은 볼륨 플러그인이지만, PV를 사용하는 개별 파드와 독립적인 수명주기를 가져요. 이 API 객체는 NFS, iSCSI, 또는 클라우드 프로바이더별 스토리지 시스템이든 스토리지 구현의 세부 사항을 담아요.

PersistentVolumeClaim(PVC)은 사용자의 스토리지 요청이에요. 파드와 유사해요. 파드는 노드 리소스를 소비하고 PVC는 PV 리소스를 소비해요. 파드는 특정 수준의 리소스(CPU와 메모리)를 요청할 수 있어요. 클레임은 특정 크기와 접근 모드를 요청할 수 있어요(예: ReadWriteOnce, ReadOnlyMany, ReadWriteMany 또는 ReadWriteOncePod로 마운트될 수 있음, #접근-모드 참고).

PersistentVolumeClaim은 사용자가 추상적 스토리지 리소스를 소비하게 하지만, 사용자는 종종 다른 문제에 대해 성능 같은 다양한 속성을 가진 PersistentVolume이 필요해요. 클러스터 관리자는 크기와 접근 모드 이상으로 다른 여러 방식으로 다른 PersistentVolume을 제공할 수 있어야 하며, 사용자에게 그 볼륨이 어떻게 구현되는지에 대한 세부 사항을 노출하지 않아야 해요. 이러한 요구에는 StorageClass 리소스가 있어요.

동작하는 예시가 있는 상세 연습을 참고해요.

볼륨과 클레임의 수명주기 (Lifecycle of a volume and claim)

PV는 클러스터의 리소스예요. PVC는 그 리소스에 대한 요청이며 리소스에 대한 클레임 확인으로도 작동해요. PV와 PVC 사이의 상호작용은 다음 수명주기를 따라요:

프로비저닝 (#provisioning)

PV가 프로비저닝될 수 있는 방법은 정적 또는 동적 두 가지가 있어요.

정적 (#static)

클러스터 관리자가 여러 PV를 만들어요. 그것들은 클러스터 사용자가 사용할 수 있는 실제 스토리지의 세부 사항을 담아요. 그것들은 Kubernetes API에 존재하며 소비가 가능해요.

동적 (#dynamic)

관리자가 만든 정적 PV 중 어떤 것도 사용자의 PersistentVolumeClaim과 일치하지 않으면 클러스터는 PVC를 위해 특별히 볼륨을 동적으로 프로비저닝하려고 시도할 수 있어요. 이 프로비저닝은 StorageClass에 기반해요: PVC가 스토리지 클래스를 요청해야 하고 관리자가 동적 프로비저닝이 일어나도록 그 클래스를 만들고 구성했어야 해요. "" 클래스를 요청하는 클레임은 스스로에 대한 동적 프로비저닝을 사실상 비활성화해요.

스토리지 클래스 기반 동적 스토리지 프로비저닝을 활성화하려면 클러스터 관리자가 API 서버에서 DefaultStorageClass admission 컨트롤러(/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)를 활성화해야 해요. 이것은 예를 들어 DefaultStorageClass가 API 서버 컴포넌트의 --enable-admission-plugins 플래그 값의 쉼표로 구분된 순서 목록에 있는지 확인해 수행할 수 있어요. API 서버 명령줄 플래그에 대한 더 많은 정보는 kube-apiserver(/docs/reference/command-line-tools-reference/kube-apiserver/) 문서를 확인해요.

바인딩 (#binding)

사용자는 특정 양의 스토리지를 요청하고 특정 접근 모드를 가진 PersistentVolumeClaim을 만들거나(동적 프로비저닝의 경우에는 이미 만들었음) 컨트롤 플레인의 컨트롤 루프가 새 PVC를 감시하고 일치하는 PV를 찾아(가능하면) 그것들을 함께 바인딩해요. PV가 새 PVC를 위해 동적으로 프로비저닝되었다면 루프는 항상 그 PV를 PVC에 바인딩해요. 그렇지 않으면 사용자는 항상 최소한 요청한 것을 얻지만 볼륨은 요청된 것을 초과할 수 있어요. 일단 바인딩되면 PersistentVolumeClaim 바인딩은 어떻게 바인딩되었든 배타적이에요. PVC에서 PV로의 바인딩은 PersistentVolume과 PersistentVolumeClaim 사이의 양방향 바인딩인 ClaimRef를 사용하는 일대일 매핑이에요.

일치하는 볼륨이 존재하지 않으면 클레임은 무기한 바인딩되지 않은 상태로 유지돼요. 일치하는 볼륨이 사용 가능해지면 클레임이 바인딩돼요. 예를 들어 많은 50Gi PV가 프로비저닝된 클러스터는 100Gi를 요청하는 PVC와 일치하지 않아요. PVC는 100Gi PV가 클러스터에 추가될 때 바인딩될 수 있어요.

사용 (#using)

파드는 클레임을 볼륨으로 사용해요. 클러스터는 클레임을 검사해 바인딩된 볼륨을 찾고 그 볼륨을 파드에 마운트해요. 여러 접근 모드를 지원하는 볼륨의 경우 사용자는 파드에서 클레임을 볼륨으로 사용할 때 원하는 모드를 지정해요.

사용자가 클레임을 가지고 그 클레임이 바인딩되면 바인딩된 PV는 필요한 동안 사용자에게 속해요. 사용자는 파드의 volumes 블록에 persistentVolumeClaim 섹션을 포함해 파드를 스케줄링하고 클레임된 PV에 접근해요. 자세한 내용은 클레임을 볼륨으로 사용을 참고해요.

사용 중 스토리지 객체 보호 (#storage-object-in-use-protection)

Storage Object in Use Protection 기능의 목적은 파드가 활발히 사용하는 PersistentVolumeClaim(PVC)과 PVC에 바인딩된 PersistentVolume(PV)이 시스템에서 제거되지 않도록 보장하는 것이에요. 그렇게 되면 데이터 손실이 발생할 수 있기 때문이에요.

파드가 활발히 사용하는 PVC를 사용자가 삭제하면 PVC가 즉시 제거되지 않아요. PVC 제거는 더 이상 어떤 파드도 PVC를 활발히 사용하지 않을 때까지 연기돼요. 또한 관리자가 PVC에 바인딩된 PV를 삭제하면 PV가 즉시 제거되지 않아요. PV 제거는 더 이상 PVC에 바인딩되지 않을 때까지 연기돼요.

PVC의 status가 Terminating이고 Finalizers 목록에 kubernetes.io/pvc-protection이 포함되면 PVC가 보호되는 것을 볼 수 있어요:

kubectl describe pvc hostpath
Name:          hostpath
Namespace:     default
StorageClass:  example-hostpath
Status:        Terminating
Volume:
Labels:        <none>
Annotations:   volume.beta.kubernetes.io/storage-class=example-hostpath
               volume.beta.kubernetes.io/storage-provisioner=example.com/hostpath
Finalizers:    [kubernetes.io/pvc-protection]
...

PV의 status가 Terminating이고 Finalizers 목록에 kubernetes.io/pv-protection도 포함되면 PV가 보호되는 것을 볼 수 있어요:

kubectl describe pv task-pv-volume
Name:            task-pv-volume
Labels:          type=local
Annotations:     <none>
Finalizers:      [kubernetes.io/pv-protection]
StorageClass:    standard
Status:          Terminating
Claim:
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        1Gi
Message:
Source:
    Type:          HostPath (bare host directory volume)
    Path:          /tmp/data
    HostPathType:
Events:            <none>

회수 (Reclaiming)

사용자가 볼륨 사용을 마치면 리소스의 회수를 가능하게 하는 API에서 PVC 객체를 삭제할 수 있어요. PersistentVolume의 회수 정책은 클레임이 해제된 후 볼륨으로 무엇을 할지 클러스터에 알려줘요. 현재 볼륨은 Retained, Recycled 또는 Deleted될 수 있어요.

보존 (Retain)

Retain 회수 정책은 리소스의 수동 회수를 허용해요. PersistentVolumeClaim이 삭제되면 PersistentVolume은 여전히 존재하고 볼륨은 "released"로 간주돼요. 하지만 이전 청구자의 데이터가 볼륨에 남아 있으므로 아직 다른 클레임에 사용할 수 없어요. 관리자는 다음 단계로 볼륨을 수동으로 회수할 수 있어요.

  • PersistentVolume을 삭제해요. 외부 인프라의 관련 스토리지 자산은 PV가 삭제된 후에도 여전히 존재해요.
  • 관련 스토리지 자산의 데이터를 그에 따라 수동으로 정리해요.
  • 관련 스토리지 자산을 수동으로 삭제해요.

같은 스토리지 자산을 재사용하려면 같은 스토리지 자산 정의로 새 PersistentVolume을 만들어요.

삭제 (Delete)

Delete 회수 정책을 지원하는 볼륨 플러그인의 경우 삭제는 Kubernetes에서 PersistentVolume 객체와 외부 인프라의 관련 스토리지 자산을 모두 제거해요. 동적으로 프로비저닝된 볼륨은 기본값이 Delete인 #회수-정책인 그들의 StorageClass의 회수 정책을 상속해요. 관리자는 사용자의 기대에 따라 StorageClass를 구성해야 해요. 그렇지 않으면 PV가 생성된 후 편집하거나 패치해야 해요. PersistentVolume의 회수 정책 변경을 참고해요.

재활용 (Recycle)

Recycle 회수 정책은 기본 볼륨 플러그인이 지원하면 볼륨에 기본 스크럽(rm -rf /thevolume/*)을 수행하고 새 클레임에 다시 사용 가능하게 해요.

그러나 관리자는 Kubernetes 컨트롤러 매니저 명령줄 인자를 사용해 아래 예시에 표시된 것처럼 volumes 사양을 포함해야 하는 커스텀 recycler 파드 템플릿을 구성할 수 있어요:

apiVersion: v1
kind: Pod
metadata:
  name: pv-recycler
  namespace: default
spec:
  restartPolicy: Never
  volumes:
  - name: vol
    hostPath:
      path: /any/path/it/will/be/replaced
  containers:
  - name: pv-recycler
    image: "registry.k8s.io/busybox"
    command: ["/bin/sh", "-c", "test -e /scrub && rm -rf /scrub/..?* /scrub/.[!.]* /scrub/*  && test -z \"$(ls -A /scrub)\" || exit 1"]
    volumeMounts:
    - name: vol
      mountPath: /scrub

하지만 커스텀 recycler 파드 템플릿의 volumes 부분에 지정된 특정 경로는 재활용되는 볼륨의 특정 경로로 대체돼요.

PersistentVolume 삭제 보호 finalizer (#persistentvolume-deletion-protection-finalizer)

이것은 Kubernetes의 안정적인 기능이며 1.33 릴리스부터 그래왔어요. 더 이상 이 기능을 토글할 수 없어요(관련 기능 게이트가 제거됨).

PersistentVolume에 finalizer를 추가해 Delete 회수 정책을 가진 PersistentVolume이 백킹 스토리지가 삭제된 후에만 삭제되도록 보장할 수 있어요.

finalizer external-provisioner.volume.kubernetes.io/finalizer(v1.31에서 도입)는 동적으로 프로비저닝된 CSI 볼륨과 정적으로 프로비저닝된 CSI 볼륨 모두에 추가돼요.

finalizer kubernetes.io/pv-controller(v1.31에서 도입)는 동적으로 프로비저닝된 in-tree 플러그인 볼륨에 추가되고 정적으로 프로비저닝된 in-tree 플러그인 볼륨에는 건너뛰어져요.

다음은 동적으로 프로비저닝된 in-tree 플러그인 볼륨의 예시예요:

kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Name:            pvc-74a498d6-3929-47e8-8c02-078c1ece4d78
Labels:          <none>
Annotations:     kubernetes.io/createdby: vsphere-volume-dynamic-provisioner
                 pv.kubernetes.io/bound-by-controller: yes
                 pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume
Finalizers:      [kubernetes.io/pv-protection kubernetes.io/pv-controller]
StorageClass:    vcp-sc
Status:          Bound
Claim:           default/vcp-pvc-1
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        1Gi
Node Affinity:   <none>
Message:
Source:
    Type:               vSphereVolume (a Persistent Disk resource in vSphere)
    VolumePath:         [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk
    FSType:             ext4
    StoragePolicyName:  vSAN Default Storage Policy
Events:                 <none>

finalizer external-provisioner.volume.kubernetes.io/finalizer는 CSI 볼륨에 추가돼요. 다음은 예시예요:

Name:            pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d
Labels:          <none>
Annotations:     pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com
Finalizers:      [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer]
StorageClass:    fast
Status:          Bound
Claim:           demo-app/nginx-logs
Reclaim Policy:  Delete
Access Modes:    RWO
VolumeMode:      Filesystem
Capacity:        200Mi
Node Affinity:   <none>
Message:
Source:
    Type:              CSI (a Container Storage Interface (CSI) volume source)
    Driver:            csi.vsphere.vmware.com
    FSType:            ext4
    VolumeHandle:      44830fa8-79b4-406b-8b58-621ba25353fd
    ReadOnly:          false
    VolumeAttributes:      storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com
                           type=vSphere CNS Block Volume
Events:                <none>

특정 in-tree 볼륨 플러그인에 대해 CSIMigration{provider} 기능 플래그가 활성화되면 kubernetes.io/pv-controller finalizer가 external-provisioner.volume.kubernetes.io/finalizer finalizer로 대체돼요.

finalizer는 PV의 회수 정책이 Delete이면 스토리지 백엔드에서 볼륨이 삭제된 후에만 PV 객체가 제거되도록 보장해요. 이것은 또한 PV와 PVC의 삭제 순서와 관계없이 볼륨이 스토리지 백엔드에서 삭제되도록 보장해요.

PersistentVolume 예약 (#reserving-a-persistentvolume)

컨트롤 플레인은 PersistentVolumeClaim을 클러스터의 일치하는 PersistentVolume(#binding)에 바인딩할 수 있어요. 하지만 PVC가 특정 PV에 바인딩되기를 원한다면 그것들을 사전 바인딩해야 해요.

PersistentVolumeClaim에서 PersistentVolume을 지정함으로써 그 특정 PV와 PVC 사이의 바인딩을 선언해요. PersistentVolume이 존재하고 claimRef 필드를 통해 PersistentVolumeClaim을 예약하지 않았다면 PersistentVolume과 PersistentVolumeClaim이 바인딩돼요.

바인딩은 노드 어피니티를 포함한 일부 볼륨 일치 기준과 관계없이 일어나요. 컨트롤 플레인은 여전히 스토리지 클래스, 접근 모드, 요청된 스토리지 크기가 유효한지 확인해요.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: foo-pvc
  namespace: foo
spec:
  storageClassName: "" # Empty string must be explicitly set otherwise default StorageClass will be set
  volumeName: foo-pv
  ...

이 방법은 PersistentVolume에 대한 어떤 바인딩 특권을 보장하지 않아요. 다른 PersistentVolumeClaim이 여러분이 지정한 PV를 사용할 수 있다면 먼저 그 스토리지 볼륨을 예약해야 해요. 다른 PVC가 그것에 바인딩할 수 없도록 PV의 claimRef 필드에 관련 PersistentVolumeClaim을 지정해요.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: foo-pv
spec:
  storageClassName: ""
  claimRef:
    name: foo-pvc
    namespace: foo
  ...

이것은 persistentVolumeReclaimPolicy가 Retain으로 설정된 PersistentVolume을 소비하려는 경우, 기존 PV를 재사용하는 경우를 포함해 유용해요.

PersistentVolumeClaim 확장 (#expanding-persistent-volumes-claims)

PersistentVolumeClaim(PVC) 확장 지원은 기본적으로 활성화돼요. 다음 유형의 볼륨을 확장할 수 있어요:

  • csi (일부 CSI 마이그레이션 볼륨 유형 포함)
  • flexVolume (deprecated)
  • portworxVolume (deprecated)

해당 스토리지 클래스의 allowVolumeExpansion 필드가 true로 설정된 경우에만 PVC를 확장할 수 있어요.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: example-vol-default
provisioner: vendor-name.example/magicstorage
parameters:
  resturl: "http://192.168.10.100:8080"
  restuser: ""
  secretNamespace: ""
  secretName: ""
allowVolumeExpansion: true

PVC에 더 큰 볼륨을 요청하려면 PVC 객체를 편집하고 더 큰 크기를 지정해요. 이것은 기본 PersistentVolume을 백킹하는 볼륨의 확장을 트리거해요. 클레임을 충족시키기 위해 새 PersistentVolume이 생성되지는 않아요. 대신 기존 볼륨이 크기 조정돼요.

크기를 조정하거나 축소하는 것은 위험할 수 있어요. 데이터 손실을 방지하기 위해 작업을 수행하기 전에 볼륨을 백업하세요.

CSI 볼륨 확장 (#csi-volume-expansion)

CSI 볼륨 확장 지원은 기본적으로 활성화되어 있지만 특정 CSI 드라이버가 볼륨 확장을 지원해야 해요. 자세한 내용은 특정 CSI 드라이버의 문서를 참고해요.

파일 시스템을 포함하는 볼륨 크기 조정 (#resizing-a-volume-containing-a-file-system)

파일 시스템을 포함하는 볼륨은 파일 시스템이 XFS, Ext3 또는 Ext4인 경우에만 크기를 조정할 수 있어요.

볼륨이 파일 시스템을 포함할 때 새 파드가 PersistentVolumeClaim을 ReadWrite 모드로 사용할 때만 파일 시스템이 크기 조정돼요. 파일 시스템 확장은 파드가 시작될 때 또는 파드가 실행 중이고 기본 파일 시스템이 온라인 확장을 지원할 때 수행돼요.

FlexVolumes(Kubernetes v1.23부터 deprecated)는 드라이버가 RequiresFSResize 기능을 true로 구성하면 크기 조정을 허용해요. FlexVolume은 파드 재시작 시 크기 조정할 수 있어요.

사용 중인 PersistentVolumeClaim 크기 조정 (#resizing-an-in-use-persistentvolumeclaim)

이 경우 기존 PVC를 사용하는 파드나 배포를 삭제하고 다시 만들 필요가 없어요. 사용 중인 PVC는 파일 시스템이 확장되자마자 자동으로 그 파드에 사용 가능해져요. 이 기능은 파드나 배포가 사용하지 않는 PVC에는 영향이 없어요. 확장이 완료되기 전에 PVC를 사용하는 파드를 만들어야 해요.

다른 볼륨 유형과 유사하게 FlexVolume 볼륨도 파드가 사용 중일 때 확장될 수 있어요.

FlexVolume은 deprecated된 볼륨 유형이며 CSI로 마이그레이션하는 것을 고려해야 해요.

볼륨 확장 시 실패에서 복구 (#recovering-from-failure-when-expanding-volumes)

사용자가 기본 스토리지 시스템이 충족할 수 없는 너무 큰 새 크기를 지정하면 PVC 확장이 사용자나 클러스터 관리자가 어떤 조치를 취할 때까지 계속 재시도돼요. 이것은 바람직하지 않을 수 있으므로 Kubernetes는 그러한 실패에서 복구하는 다음 방법을 제공해요.

  • 클러스터 관리자 접근으로 수동으로
  • 더 작은 크기로 확장을 요청함으로써

기본 스토리지 확장이 실패하면 클러스터 관리자가 PersistentVolumeClaim(PVC) 상태를 수동으로 복구하고 크기 조정 요청을 취소할 수 있어요. 그렇지 않으면 크기 조정 요청이 관리자 개입 없이 컨트롤러에 의해 계속 재시도돼요.

  • PersistentVolumeClaim(PVC)에 바인딩된 PersistentVolume(PV)을 Retain 회수 정책으로 표시해요.
  • PVC를 삭제해요. PV가 Retain 회수 정책을 가지므로 PVC를 다시 만들 때 데이터를 잃지 않아요.
  • 새 PVC가 바인딩될 수 있도록 PV 사양에서 claimRef 항목을 삭제해요. 이것은 PV를 Available로 만들어야 해요.
  • PV보다 작은 크기로 PVC를 다시 만들고 PVC의 volumeName 필드를 PV의 이름으로 설정해요. 이것은 새 PVC를 기존 PV에 바인딩해야 해요.
  • PV의 회수 정책을 복원하는 것을 잊지 마세요.

PVC에 대해 확장이 실패했다면 이전에 요청한 값보다 작은 크기로 확장을 재시도할 수 있어요. 더 작은 제안 크기로 새 확장 시도를 요청하려면 그 PVC의 .spec.resources를 편집하고 이전에 시도한 값보다 작은 값을 선택해요.

이것은 더 높은 값으로의 확장이 용량 제약으로 인해 성공하지 못한 경우 유용해요. 그런 일이 발생했거나 발생할 수 있다고 의심되면 기본 스토리지 프로바이더의 용량 한도 내에 있는 크기를 지정해 확장을 재시도할 수 있어요. .status.allocatedResourceStatuses와 PVC의 이벤트를 보면 크기 조정 작업의 상태를 모니터링할 수 있어요.

이전에 요청한 것보다 적은 스토리지 양을 지정할 수는 있지만, 새 값은 여전히 .status.capacity보다 높아야 한다는 점을 유의해요. Kubernetes는 PVC를 현재 크기보다 작게 줄이는 것을 지원하지 않아요.

영구 볼륨의 유형 (Types of Persistent Volumes)

PersistentVolume 유형은 플러그인으로 구현돼요. Kubernetes는 현재 다음 플러그인을 지원해요:

  • csi - Container Storage Interface (CSI)
  • fc - Fibre Channel (FC) 스토리지
  • hostPath - HostPath 볼륨 (단일 노드 테스트 전용; 다중 노드 클러스터에서는 작동하지 않음; local 볼륨 사용 고려)
  • iscsi - iSCSI (SCSI over IP) 스토리지
  • local - 노드에 마운트된 로컬 스토리지 디바이스
  • nfs - Network File System (NFS) 스토리지

다음 유형의 PersistentVolume은 deprecated되었지만 여전히 사용 가능해요. flexVolume, cephfs, rbd를 제외한 이러한 볼륨 유형을 사용한다면 해당 CSI 드라이버를 설치해주세요.

  • awsElasticBlockStore - AWS Elastic Block Store (EBS) (v1.23부터 기본적으로 마이그레이션 켜짐)
  • azureDisk - Azure Disk (v1.23부터 기본적으로 마이그레이션 켜짐)
  • azureFile - Azure File (v1.24부터 기본적으로 마이그레이션 켜짐)
  • cinder - Cinder (OpenStack 블록 스토리지) (v1.21부터 기본적으로 마이그레이션 켜짐)
  • flexVolume - FlexVolume (v1.23부터 deprecated, 마이그레이션 계획도 지원 제거 계획도 없음)
  • gcePersistentDisk - GCE Persistent Disk (v1.23부터 기본적으로 마이그레이션 켜짐)
  • portworxVolume - Portworx 볼륨 (v1.31부터 기본적으로 마이그레이션 켜짐)
  • vsphereVolume - vSphere VMDK 볼륨 (v1.25부터 기본적으로 마이그레이션 켜짐)

이전 Kubernetes 버전은 또한 다음 in-tree PersistentVolume 유형을 지원했어요:

  • cephfs (v1.31부터 사용 불가)
  • flocker - Flocker 스토리지 (v1.25부터 사용 불가)
  • glusterfs - GlusterFS 스토리지 (v1.26부터 사용 불가)
  • photonPersistentDisk - Photon 컨트롤러 영구 디스크 (v1.15부터 사용 불가)
  • quobyte - Quobyte 볼륨 (v1.25부터 사용 불가)
  • rbd - Rados Block Device (RBD) 볼륨 (v1.31부터 사용 불가)
  • scaleIO - ScaleIO 볼륨 (v1.21부터 사용 불가)
  • storageos - StorageOS 볼륨 (v1.25부터 사용 불가)

영구 볼륨 (Persistent Volumes)

각 PV는 볼륨의 사양과 상태인 spec과 status를 포함해요. PersistentVolume 객체의 이름은 유효한 DNS 하위 도메인 이름이어야 해요.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv0003
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /tmp
    server: 172.17.0.2

호스트 유형을 명시적으로 지정하려면 hostPath 유형은 __와 같은 것으로 처리되므로 표시된 대로 type 필드가 생략되면 유형 없는 hostPath가 생성된다는 점을 유의해요.

용량 (#capacity)

일반적으로 PV는 특정 스토리지 용량을 가질 거예요. 이것은 수량(Quantity) 값인 PV의 capacity 속성으로 설정돼요.

현재 스토리지 크기는 설정하거나 요청할 수 있는 유일한 리소스예요. 향후 속성에는 IOPS, 처리량 등이 포함될 수 있어요.

볼륨 모드 (#volume-mode)

Kubernetes는 PersistentVolume의 volumeModes: Filesystem과 Block 두 가지를 지원해요.

volumeMode는 선택적 API 매개변수예요. volumeMode 매개변수가 생략되면 사용되는 기본 모드는 Filesystem이에요.

volumeMode: Filesystem인 볼륨은 디렉터리에 파드에 마운트돼요. 볼륨이 블록 디바이스에 의해 백킹되고 디바이스가 비어 있으면 Kubernetes는 처음 마운트하기 전에 디바이스에 파일 시스템을 만들어요.

volumeMode의 값을 Block으로 설정해 볼륨을 원시 블록 디바이스로 사용할 수 있어요. 그러한 볼륨은 파일 시스템 없이 블록 디바이스로 파드에 제공돼요. 이 모드는 파드와 볼륨 사이에 파일 시스템 계층 없이 파드에 볼륨에 접근할 수 있는 가장 빠른 가능한 방법을 제공하는 데 유용해요. 반면 파드에서 실행되는 애플리케이션은 원시 블록 디바이스를 처리하는 방법을 알아야 해요.

파드에서 volumeMode: Block인 볼륨을 사용하는 방법의 예시는 원시 블록 볼륨 지원을 참고해요.

접근 모드 (#access-modes)

PersistentVolume은 리소스 프로바이더가 지원하는 어떤 방식으로든 호스트에 마운트될 수 있어요. 아래 표에 표시된 것처럼 프로바이더는 서로 다른 기능을 가지며 각 PV의 접근 모드는 그 특정 볼륨이 지원하는 특정 모드로 설정돼요. 예를 들어 NFS는 여러 읽기/쓰기 클라이언트를 지원할 수 있지만 특정 NFS PV는 서버에서 읽기 전용으로 내보내질 수 있어요. 각 PV는 그 특정 PV의 기능을 설명하는 자체 접근 모드 집합을 얻어요.

접근 모드는 다음과 같아요:

  • ReadWriteOnce: 볼륨이 단일 노드에 의해 읽기-쓰기로 마운트될 수 있음. ReadWriteOnce 접근 모드는 파드가 같은 노드에서 실행될 때 여전히 여러 파드가 그 볼륨에 접근(읽거나 쓰는 것)할 수 있게 해줌. 단일 파드 접근의 경우 ReadWriteOncePod를 참고.
  • ReadOnlyMany: 볼륨이 많은 노드에 의해 읽기 전용으로 마운트될 수 있음.
  • ReadWriteMany: 볼륨이 많은 노드에 의해 읽기-쓰기로 마운트될 수 있음.
  • ReadWriteOncePod: 기능 상태: Kubernetes v1.29부터 Stable. 볼륨이 단일 파드에 의해 읽기-쓰기로 마운트될 수 있음. 전체 클러스터에서 오직 하나의 파드만 그 PVC를 읽거나 쓸 수 있음을 보장하려면 ReadWriteOncePod 접근 모드를 사용해요.

ReadWriteOncePod 접근 모드는 CSI 볼륨과 Kubernetes 버전 1.22+에서만 지원돼요. 이 기능을 사용하려면 다음 CSI sidecar(https://kubernetes-csi.github.io/docs/sidecar-containers.html)를 이 버전 이상으로 업데이트해야 해요:

CLI에서 접근 모드는 다음으로 축약돼요:

  • RWO - ReadWriteOnce
  • ROX - ReadOnlyMany
  • RWX - ReadWriteMany
  • RWOP - ReadWriteOncePod

중요! 볼륨은 많은 것을 지원하더라도 한 번에 하나의 접근 모드로만 마운트될 수 있어요.

볼륨 플러그인 ReadWriteOnce ReadOnlyMany ReadWriteMany ReadWriteOncePod
AzureFile ✓ ✓ ✓ -
CephFS ✓ ✓ ✓ -
CSI 드라이버에 따라 다름 드라이버에 따라 다름 드라이버에 따라 다름 드라이버에 따라 다름
FC ✓ ✓ - -
FlexVolume ✓ ✓ 드라이버에 따라 다름 -
HostPath ✓ - - -
iSCSI ✓ ✓ - -
NFS ✓ ✓ ✓ -
RBD ✓ ✓ - -
VsphereVolume ✓ - - (파드가 공동 배치될 때 동작) -
PortworxVolume ✓ - ✓ -

클래스 (#class)

PV는 storageClassName 속성을 StorageClass의 이름으로 설정해 지정되는 클래스를 가질 수 있어요. 특정 클래스의 PV는 그 클래스를 요청하는 PVC에만 바인딩될 수 있어요. storageClassName이 없는 PV는 클래스가 없으며 특정 클래스를 요청하지 않는 PVC에만 바인딩될 수 있어요.

과거에는 storageClassName 속성 대신 volume.beta.kubernetes.io/storage-class 어노테이션이 사용됐어요. 이 어노테이션은 여전히 동작하지만 향후 Kubernetes 릴리스에서 완전히 deprecated될 거예요.

회수 정책 (#reclaim-policy)

현재 회수 정책은 다음과 같아요:

  • Retain -- 수동 회수
  • Recycle -- 기본 스크럽(rm -rf /thevolume/*)
  • Delete -- 볼륨 삭제

Kubernetes 1.37의 경우 nfs와 hostPath 볼륨 유형만 재활용을 지원해요.

마운트 옵션 (#mount-options)

Kubernetes 관리자는 Persistent Volume이 노드에 마운트될 때 추가 마운트 옵션을 지정할 수 있어요.

다음 볼륨 유형이 마운트 옵션을 지원해요:

  • csi (CSI 마이그레이션 볼륨 유형 포함)
  • iscsi
  • nfs

마운트 옵션은 검증되지 않아요. 마운트 옵션이 유효하지 않으면 마운트가 실패해요.

과거에는 mountOptions 속성 대신 volume.beta.kubernetes.io/mount-options 어노테이션이 사용됐어요. 이 어노테이션은 여전히 동작하지만 향후 Kubernetes 릴리스에서 완전히 deprecated될 거예요.

노드 어피니티 (#node-affinity)

PV는 이 볼륨이 접근될 수 있는 노드를 제한하는 제약을 정의하는 노드 어피니티를 지정할 수 있어요. PV를 사용하는 파드는 노드 어피니티가 선택한 노드에만 스케줄링될 거예요. 노드 어피니티를 지정하려면 PV의 .spec에서 nodeAffinity를 설정해요. PersistentVolume API 참조에 이 필드에 대한 자세한 내용이 있어요.

노드 어피니티 업데이트 (#updates-to-node-affinity)

클러스터에서 MutablePVNodeAffinity 기능 게이트가 활성화되어 있으면 PersistentVolume의 .spec.nodeAffinity 필드는 변경 가능해요. 이것은 클러스터 관리자나 외부 스토리지 컨트롤러가 실행 중인 파드를 중단하지 않고 데이터가 마이그레이션될 때 PersistentVolume의 노드 어피니티를 업데이트할 수 있게 해줘요.

노드 어피니티를 업데이트할 때 새 노드 어피니티가 여전히 볼륨이 현재 사용 중인 노드와 일치하는지 확인해야 해요. 새 어피니티를 위반하는 파드의 경우 이미 실행 중이면 계속 실행될 수 있어요. 하지만 Kubernetes는 이 구성을 지원하지 않아요. 위반하는 파드를 곧 종료해야 해요. 메모리 내 캐싱 때문에 업데이트 후 생성된 파드는 잠시 동안 여전히 이전 노드 어피니티에 따라 스케줄링될 수 있어요.

이 기능을 사용하려면 다음 컴포넌트에서 MutablePVNodeAffinity 기능 게이트를 활성화해야 해요:

  • kube-apiserver
  • kubelet

단계 (#phase)

PersistentVolume은 다음 단계 중 하나가 될 거예요:

  • Available: 아직 클레임에 바인딩되지 않은 자유 리소스
  • Bound: 볼륨이 클레임에 바인딩됨
  • Released: 클레임이 삭제되었지만 관련 스토리지 리소스가 아직 클러스터에 의해 회수되지 않음
  • Failed: 볼륨이 (자동) 회수에 실패함

kubectl describe persistentvolume <name>을 사용해 PV에 바인딩된 PVC의 이름을 볼 수 있어요.

단계 전환 타임스탬프 (#phase-transition-timestamp)

이것은 Kubernetes의 안정적인 기능이며 1.31 릴리스부터 그래왔어요. 더 이상 이 기능을 토글할 수 없어요(관련 기능 게이트가 제거됨).

PersistentVolume의 .status 필드는 알파 lastPhaseTransitionTime 필드를 포함할 수 있어요. 이 필드는 볼륨이 마지막으로 단계를 전환한 시점의 타임스탬프를 기록해요. 새로 생성된 볼륨의 경우 단계는 Pending으로 설정되고 lastPhaseTransitionTime은 현재 시간으로 설정돼요.

PersistentVolumeClaim (#persistentvolumeclaims)

각 PVC는 클레임의 사양과 상태인 spec과 status를 포함해요. PersistentVolumeClaim 객체의 이름은 유효한 DNS 하위 도메인 이름이어야 해요.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 8Gi
  storageClassName: slow
  selector:
    matchLabels:
      release: "stable"
    matchExpressions:
      - {key: environment, operator: In, values: [dev]}

접근 모드 (#access-modes-1)

클레임은 특정 접근 모드로 스토리지를 요청할 때 #접근-모드와 같은 규칙을 사용해요.

볼륨 모드 (#volume-modes)

클레임은 #볼륨-모드와 같은 규칙을 사용해 볼륨을 파일 시스템 또는 블록 디바이스로 소비함을 나타내요.

볼륨 이름 (#volume-name)

클레임은 volumeName 필드를 사용해 특정 PersistentVolume에 명시적으로 바인딩할 수 있어요. 또한 volumeName을 설정하지 않고 두어 Kubernetes가 클레임과 일치하는 새 PersistentVolume을 설정하기를 원한다는 것을 나타낼 수 있어요.

지정된 PV가 이미 다른 PVC에 바인딩되어 있다면 바인딩이 pending 상태에 갇힐 거예요.

리소스 (#resources)

클레임은 파드처럼 특정 양의 리소스를 요청할 수 있어요. 이 경우 요청은 스토리지예요. 같은 리소스 모델이 볼륨과 클레임 모두에 적용돼요.

스토리지 크기 대신 리소스 제한을 지정하는 것은 지원되지 않는다는 점을 유의해요.

셀렉터 (#selector)

클레임은 레이블 셀렉터를 지정해 볼륨 집합을 추가로 필터링할 수 있어요. 레이블이 셀렉터와 일치하는 볼륨만 클레임에 바인딩될 수 있어요. 셀렉터는 두 필드로 구성될 수 있어요:

  • matchLabels - 볼륨이 이 값을 가진 레이블을 가져야 함
  • matchExpressions - 키, 값 목록, 키와 값을 연결하는 연산자를 지정해 만들어진 요구 사항 목록. 유효한 연산자는 In, NotIn, Exists, DoesNotExist를 포함해요.

matchLabels와 matchExpressions 모두의 모든 요구 사항은 함께 AND 연산돼요 - 일치하려면 모두 충족되어야 해요.

클래스 (#class-1)

클레임은 storageClassName 속성을 사용해 StorageClass의 이름을 지정해 특정 클래스를 요청할 수 있어요. 요청된 클래스의 PV, 즉 PVC와 같은 storageClassName을 가진 것만 PVC에 바인딩될 수 있어요.

PVC는 클래스를 반드시 요청할 필요는 없어요. storageClassName이 ""로 설정된 PVC는 항상 클래스가 없는 PV를 요청하는 것으로 해석되므로 클래스가 없는 PV(어노테이션이 없거나 ""로 설정된 것)에만 바인딩될 수 있어요. storageClassName이 없는 PVC는 정확히 같지는 않으며 DefaultStorageClass admission 플러그인이 켜져 있는지에 따라 클러스터가 다르게 처리해요.

  • admission 플러그인이 켜져 있으면 관리자가 기본 StorageClass를 지정할 수 있어요. storageClassName이 없는 모든 PVC는 그 기본값의 PV에만 바인딩될 수 있어요. 기본 StorageClass 지정은 StorageClass 객체에 storageclass.kubernetes.io/is-default-class 어노테이션을 true로 설정해 수행돼요. 관리자가 기본값을 지정하지 않으면 클러스터는 admission 플러그인이 꺼진 것처럼 PVC 생성을 처리해요. 둘 이상의 기본 StorageClass가 지정되면 PVC가 동적으로 프로비저닝될 때 가장 새로운 기본값이 사용돼요.
  • admission 플러그인이 꺼져 있으면 기본 StorageClass의 개념이 없어요. storageClassName이 ""로 설정된 모든 PVC는 storageClassName도 ""로 설정된 PV에만 바인딩될 수 있어요. 하지만 storageClassName이 빠진 PVC는 나중에 기본 StorageClass가 사용 가능해지면 업데이트될 수 있어요. PVC가 업데이트되면 더 이상 storageClassName도 ""로 설정된 PV에 바인딩되지 않아요.

자세한 내용은 소급 기본 StorageClass 할당을 참고해요.

설치 방법에 따라 기본 StorageClass가 설치 중에 애드온 매니저에 의해 Kubernetes 클러스터에 배포될 수 있어요.

PVC가 StorageClass 요청에 더해 셀렉터를 지정하면 요구 사항이 함께 AND 연산돼요: 요청된 클래스의 요청된 레이블을 가진 PV만 PVC에 바인딩될 수 있어요.

과거에는 storageClassName 속성 대신 volume.beta.kubernetes.io/storage-class 어노테이션이 사용됐어요. 이 어노테이션은 여전히 동작하지만 향후 Kubernetes 릴리스에서 지원되지 않을 거예요.

소급 기본 StorageClass 할당 (#retroactive-default-storageclass-assignment)

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

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

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

이 동작은 관리자가 먼저 이전 것을 제거한 다음 다른 것을 만들거나 설정함으로써 기본 StorageClass를 변경하는 데 도움이 돼요. 기본값이 없는 이 짧은 창은 그때 생성된 storageClassName이 없는 PVC에 기본값이 없게 하지만, 소급 기본 StorageClass 할당 덕분에 이 기본값 변경 방식은 안전해요.

사용되지 않는 PVC 추적 (#unused-pvc-tracking)

활성화되면 PVC 보호 컨트롤러가 각 PersistentVolumeClaim에 Unused 조건(/docs/concepts/workloads/pods/pod-lifecycle/#pod-conditions)을 추가해 그것이 현재 어떤 비종료 파드에 의해 참조되는지 나타내요.

조건은 두 상태가 있어요:

  • status가 "True"인 Unused (reason NoPodsUsingPVC): 어떤 비종료 파드도 이 PVC를 참조하지 않음. lastTransitionTime은 PVC가 사용되지 않게 된 시점을 기록함.
  • status가 "False"인 Unused (reason PodUsingPVC): 최소 하나의 비종료 파드가 현재 이 PVC를 참조함. lastTransitionTime은 PVC가 사용되기 시작한 시점을 기록함.

파드의 phase가 Succeeded 또는 Failed가 아니면 비종료로 간주돼요. 이것은 Pending 파드(아직 스케줄링되지 않은 것도)가 PVC를 사용하는 것으로 간주됨을 의미해요.

Unused 조건의 lastTransitionTime은 클러스터 관리자, 모니터링 도구, 외부 컨트롤러가 오랫동안 사용되지 않은 PVC를 식별하는 데 사용할 수 있어요. 예를 들어 30일 이상 사용되지 않은 모든 PVC를 찾으려면 status가 "True"이고 lastTransitionTime이 30일보다 오래된 Unused 조건이 있는 PVC를 쿼리할 수 있어요.

클레임을 볼륨으로 사용 (Claims As Volumes)

파드는 클레임을 볼륨으로 사용해 스토리지에 접근해요. 클레임은 파드와 같은 네임스페이스에 존재해야 해요. 클러스터는 파드의 네임스페이스에서 클레임을 찾고 그것을 사용해 클레임을 백킹하는 PersistentVolume을 얻어요. 그런 다음 볼륨이 호스트에 그리고 파드에 마운트돼요.

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim

네임스페이스에 관한 참고 사항 (#a-note-on-namespaces)

PersistentVolume 바인딩은 배타적이며, PersistentVolumeClaim은 네임스페이스화된 객체이므로 "Many" 모드(ROX, RWX)로 클레임을 마운트하는 것은 하나의 네임스페이스 내에서만 가능해요.

PersistentVolumes typed hostPath (#persistentvolumes-typed-hostpath)

hostPath PersistentVolume은 노드의 파일이나 디렉터리를 사용해 네트워크 연결 스토리지를 에뮬레이션해요. hostPath 유형 볼륨의 예시를 참고해요.

원시 블록 볼륨 지원 (#raw-block-volume-support)

다음 볼륨 플러그인은 적용 가능한 곳에서 동적 프로비저닝을 포함해 원시 블록 볼륨을 지원해요:

  • CSI (일부 CSI 마이그레이션 볼륨 유형 포함)
  • FC (Fibre Channel)
  • iSCSI
  • Local 볼륨

원시 블록 볼륨을 사용하는 PersistentVolume (#persistent-volume-using-a-raw-block-volume)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: block-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  persistentVolumeReclaimPolicy: Retain
  fc:
    targetWWNs: ["50060e801049cfd1"]
    lun: 0
    readOnly: false

원시 블록 볼륨을 요청하는 PersistentVolumeClaim (#persistent-volume-claim-requesting-a-raw-block-volume)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: block-pvc
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Block
  resources:
    requests:
      storage: 10Gi

컨테이너에 원시 블록 디바이스 경로를 추가하는 파드 사양 (#pod-specification-adding-raw-block-device-path-in-container)

apiVersion: v1
kind: Pod
metadata:
  name: pod-with-block-volume
spec:
  containers:
    - name: fc
      image: fedora:26
      command: ["/bin/sh", "-c"]
      args: [ "tail -f /dev/null" ]
      volumeDevices:
        - name: data
          devicePath: /dev/xvda
  volumes:
    - name: data
      persistentVolumeClaim:
        claimName: block-pvc

블록 볼륨 바인딩 (#binding-block-volumes)

사용자가 PersistentVolumeClaim spec의 volumeMode 필드로 이것을 나타냄으로써 원시 블록 볼륨을 요청하면 바인딩 규칙은 이 모드를 spec의 일부로 고려하지 않았던 이전 릴리스와 약간 다르다. 원시 블록 디바이스를 요청하기 위해 사용자와 관리자가 지정할 수 있는 가능한 조합의 표가 나열되어 있다. 표는 조합이 주어졌을 때 볼륨이 바인딩되는지 여부를 나타낸다: 정적으로 프로비저닝된 볼륨에 대한 볼륨 바인딩 매트릭스:

PV volumeMode PVC volumeMode 결과
unspecified unspecified BIND
unspecified Block NO BIND
unspecified Filesystem BIND
Block unspecified NO BIND
Block Block BIND
Block Filesystem NO BIND
Filesystem Filesystem BIND
Filesystem Block NO BIND
Filesystem unspecified BIND

스테틱 프로비저닝 볼륨만 위 절에 해당한다는 점을 유의해요 (동적으로 프로비저닝된 볼륨은 항상 PVC의 volumeMode와 일치합니다).

볼륨 스냅샷과 스냅샷에서 볼륨 복원 지원 (#volume-snapshot-and-restore-volume-from-snapshot-support)

볼륨 스냅샷은 out-of-tree CSI 볼륨 플러그인만 지원해요. 자세한 내용은 볼륨 스냅샷을 참고해요. in-tree 볼륨 플러그인은 deprecated되었어요. deprecated된 볼륨 플러그인에 대해 볼륨 플러그인 FAQ에서 읽을 수 있어요.

볼륨 스냅샷에서 PersistentVolumeClaim 만들기 (#create-persistent-volume-claim-from-volume-snapshot)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: restore-pvc
spec:
  storageClassName: csi-hostpath-sc
  dataSource:
    name: new-snapshot-test
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

볼륨 복제 (Volume Cloning)

볼륨 복제는 CSI 볼륨 플러그인에서만 사용 가능해요.

기존 PVC에서 PersistentVolumeClaim 만들기 (#create-persistent-volume-claim-from-an-existing-pvc)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cloned-pvc
spec:
  storageClassName: my-csi-plugin
  dataSource:
    name: existing-src-pvc-name
    kind: PersistentVolumeClaim
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

볼륨 채우기와 데이터 소스 (#volume-populators-and-data-sources)

볼륨 복제와 스냅샷 복원은 내장 데이터 소스에서 새 볼륨을 미리 채워요. 볼륨 채우기는 이 메커니즘을 확장해 PersistentVolumeClaim이 dataSourceRef 필드를 통해 참조되는 다른 종류의 소스(커스텀 리소스)에서 미리 채워질 수 있게 해요:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: populated-pvc
spec:
  dataSourceRef:
    name: example-name
    kind: ExampleDataSource
    apiGroup: example.storage.k8s.io
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi

네임스페이스 간 데이터 소스를 포함한 자세한 내용은 볼륨 채우기와 데이터 소스를 참고해요.

이식 가능한 구성 작성 (Writing Portable Configuration)

광범위한 클러스터에서 실행되는 구성 템플릿이나 예시를 작성하고 영구 스토리지가 필요하다면 다음 패턴을 사용하는 것이 권장돼요:

  • PersistentVolumeClaim 객체를 구성 묶음에 (Deployments, ConfigMaps 등과 함께) 포함해요.
  • 구성을 인스턴스화하는 사용자가 PersistentVolume을 만들 권한이 없을 수 있으므로 구성에 PersistentVolume 객체를 포함하지 마세요.
  • 템플릿을 인스턴스화할 때 사용자에게 스토리지 클래스 이름을 제공할 옵션을 주세요. 사용자가 스토리지 클래스 이름을 제공하면 그 값을 persistentVolumeClaim.storageClassName 필드에 넣어요. 이것은 클러스터에 관리자가 활성화한 StorageClass가 있으면 PVC가 올바른 스토리지 클래스와 일치하게 해요. 사용자가 스토리지 클래스 이름을 제공하지 않으면 persistentVolumeClaim.storageClassName 필드를 nil로 두세요. 이것은 클러스터의 기본 StorageClass로 사용자에게 PV가 자동으로 프로비저닝되게 해요. 많은 클러스터 환경에 기본 StorageClass가 설치되어 있거나 관리자가 자체 기본 StorageClass를 만들 수 있어요.
  • 도구에서 시간이 지난 후에도 바인딩되지 않는 PVC를 감시하고 사용자에게 이를 알려주세요. 이것은 클러스터에 동적 스토리지 지원이 없거나(그 경우 사용자가 일치하는 PV를 만들어야 함) 클러스터에 스토리지 시스템이 없음을(그 경우 사용자가 PVC를 요구하는 구성을 배포할 수 없음) 나타낼 수 있기 때문이에요.

다음 단계 (What's next)

API 참조 (#reference)

이 페이지에 설명된 API에 대해 읽어보세요:

더 알아보기 (Learn more)