ABOUT ME

    -

    Today
    -
    Yesterday
    -
    Total
    -
    • [Kubernetes] 스토리지 - PersistentVolume(PV), PersistentVolumeClaim(PVC), StorageClass(SC)
      공부/쿠버네티스&헬름 2025. 1. 31. 22:03

      PersistentVolume 하위 시스템은 사용자와 관리자에게 스토리지가 어떻게 제공되는지에 대한 세부 사항을 스토리지가 어떻게 사용되는지로부터 추상화하는 API를 제공합니다. 이를 위해 두 가지 새로운 API 리소스인 PersistentVolume과 PersistentVolumeClaim을 도입합니다.

      PersistentVolume(PV)은 관리자가 프로비저닝했거나 Storage Class를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지 조각입니다. 노드가 클러스터 리소스인 것처럼 클러스터의 리소스입니다. PV는 Volumes와 같은 볼륨 플러그인이지만 PV를 사용하는 개별 Pod의 수명 주기와 독립적인 수명 주기를 갖습니다. 이 API 객체는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현의 세부 사항을 캡처합니다.

      PersistentVolumeClaim(PVC)은 사용자가 스토리지에 대한 요청입니다. 파드와 유사합니다. 파드는 노드 리소스를 사용하고 PVC는 PV 리소스를 사용합니다. 파드는 특정 수준의 리소스(CPU 및 메모리)를 요청할 수 있습니다. 클레임은 특정 크기 및 접근 모드(예: ReadWriteOnce, ReadOnlyMany, ReadWriteMany 또는 ReadWriteOncePod로 마운트 가능, AccessModes 참조)를 요청할 수 있습니다.

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

      볼륨 및 클레임의 수명 주기

      PV는 클러스터의 리소스입니다. PVC는 이러한 리소스에 대한 요청이며 리소스에 대한 클레임 확인 역할도 합니다. PV와 PVC 간의 상호 작용은 이 수명 주기를 따릅니다

      Provisioning

      Static

      클러스터 관리자는 여러 PV를 생성합니다. PV는 클러스터 사용자가 사용할 수 있는 실제 스토리지의 세부 정보를 담고 있습니다.

      클러스터 관리자가 직접 PV를 생성합니다.

      Dynamic

      사용자의 PVC 요청에 따라 StorageClass를 기반으로 PV를 자동으로 생성하는 기능입니다. 동적 프로비저닝이 필요한 이유로 사용자가 필요한 스토리지를 미리 알 수 없는 경우, 다양한 유형의 스토리지를 유연하게 사용해야 하는 경우, 관리자가 모든 PV를 미리 생성하고 관리하는 부담을 줄이는 경우 때문입니다.

      동적 프로비저닝 과정은 다음과 같습니다.

      1. 관리자: StorageClass를 생성하여 PV의 유형과 속성을 정의합니다.
      2. 사용자: PVC를 생성하여 원하는 스토리지 크기와 StorageClass를 지정합니다.
      3. 쿠버네티스: 사용자의 PVC 요청과 일치하는 StorageClass를 찾아 PV를 동적으로 생성하고 PVC에 바인딩합니다.
      4. 사용자: Pod에서 PVC를 볼륨으로 마운트하여 스토리지를 사용합니다.

      PVC에서 storage class를 ""로 지정하면 동적 프로비저닝을 비활성화합니다. 즉, 미리 생성된 정적 PV만 사용할 수 있습니다. 클러스터 관리자는 API 서버에서 DefaultStorageClass 어드미션 컨트롤러를 활성화해야 동적 프로비저닝을 사용할 수 있습니다.

      Binding

      사용자는 필요한 스토리지를 요청하기 위해 특정 크기와 접근 모드를 지정하여 PersistentVolumeClaim(PVC)을 생성합니다.

      쿠버네티스 컨트롤 플레인의 컨트롤 루프는 이러한 PVC 요청을 감시하고 요청에 맞는 PersistentVolume(PV)을 찾아 PVC와 바인딩합니다. 만약 PVC에 맞는 PV가 없다면 컨트롤 루프는 PVC가 원하는 스토리지를 동적으로 프로비저닝하여 바인딩합니다.

      이때, 동적으로 프로비저닝된 PV는 해당 PVC에만 바인딩됩니다. 즉, PV와 PVC의 바인딩은 독점적이며 일대일 관계를 가집니다. 만약 일치하는 PV가 없다면 PVC는 바인딩되지 않은 상태로 대기하며, 추후 일치하는 PV가 생성되면 해당 PV와 바인딩됩니다.

      PVC는 요청한 크기보다 같거나 큰 PV에만 바인딩될 수 있습니다. 요청한 크기보다 작은 PV에는 바인딩될 수 없습니다.

      Using

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

      일단 사용자가 클레임을 가지고 해당 클레임이 바운드되면, 바운드된 PV는 사용자가 필요로 하는 한 사용자의 소유가 됩니다. 사용자는 파드의 volumes 블록에 persistentVolumeClaim 섹션을 포함시켜 Pod를 예약하고 클레임된 PV에 접근합니다.

      사용 중인 스토리지 객체 보호 기능의 목적은 파드에서 활발하게 사용 중인 PersistentVolumeClaim(PVC)과 PVC에 바운드된 PersistentVolume(PV)이 시스템에서 제거되지 않도록 하는 것입니다. 이러한 제거는 데이터 손실을 초래할 수 있습니다.

      Reclaiming

      사용자가 볼륨 사용을 마치면 해당 PVC 객체를 삭제하여 스토리지를 반환할 수 있습니다. PersistentVolume의 회수 정책은 PVC가 삭제된 후, 즉 볼륨이 더 이상 사용되지 않을 때 클러스터가 해당 볼륨을 어떻게 처리할지 정의합니다. 현재 지원되는 회수 정책은 유지(Retain), 재활용(Recycle), 삭제(Delete) 세 가지입니다.

      Retain

      Retain 정책은 사용자가 스토리지를 수동으로 관리할 수 있도록 합니다. PVC가 삭제되어도 PV는 남아있고 "해제됨" 상태가 되지만, 이전 사용자의 데이터가 남아있어 즉시 재사용할 수 없습니다. 관리자는 다음 절차를 통해 PV를 재활용할 수 있습니다.

      1. PV를 삭제합니다. 이때, 실제 스토리지(예: 클라우드 스토리지)는 삭제되지 않고 그대로 유지됩니다.
      2. 스토리지에 남아있는 이전 사용자 데이터를 수동으로 삭제합니다.
      3. (필요한 경우) 스토리지를 수동으로 삭제합니다.
      4. 동일한 스토리지를 재사용하려면, 해당 스토리지를 가리키는 새로운 PV를 생성합니다.

      Delete

      Delete 정책을 사용하는 경우, PVC 삭제 시 해당 PV와 실제 스토리지(예: 클라우드 스토리지)가 모두 삭제됩니다. 동적으로 프로비저닝된 PV는 StorageClass에 정의된 회수 정책을 따르며, 기본적으로 삭제 정책이 적용됩니다. 따라서, 관리자는 사용자의 요구에 맞게 StorageClass를 설정해야 합니다. 만약 StorageClass 설정이 적절하지 않다면, PV 생성 후 회수 정책을 변경해야 합니다 (자세한 내용은 "PersistentVolume의 회수 정책 변경" 참조).

      Recycle

      Recycle은 반환된 PV를 다시 사용하게끔 하는 옵션인데 동적 프로비저닝을 사용한다면 PV를 PVC 요청이 있을때마다 생성하므로 재활용 필요가 없습니다.

      Persistent Volumes

      각 PV(PersistentVolume)는 볼륨의 사양과 상태를 나타내는 spec과 status를 포함합니다.

      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

      Capacity

      일반적으로 PV(PersistentVolume)는 특정 저장 용량을 갖습니다. 이는 Quantity 값인 PV의 capacity 속성을 사용하여 설정됩니다.

      현재 설정하거나 요청할 수 있는 유일한 리소스는 저장소 크기입니다. 향후에는 IOPS, 처리량 등과 같은 속성이 추가될 수 있습니다.

      Volume mode

      Kubernetes는 PersistentVolume에 대해 Filesystem과 Block 두 가지 volumeMode를 제공합니다. volumeMode는 선택적인 설정이며, 생략 시 기본값은 Filesystem입니다.

      • Filesystem 모드: 볼륨은 Pod 내의 디렉터리에 마운트됩니다. 기본적으로 이 모드에서는 Kubernetes가 필요한 경우 볼륨을 마운트하기 전에 파일 시스템을 생성합니다.
      • Block 모드: 볼륨은 파일 시스템 없이 Pod에 직접 블록 장치 형태로 제공됩니다. 이 모드는 애플리케이션이 볼륨에 최대한 빠르게 접근해야 하는 경우 유용하지만, 애플리케이션은 원시 블록 장치를 직접 처리할 수 있어야 합니다. volumeMode: Block 사용 예시는 "원시 블록 볼륨 지원" 문서에서 확인할 수 있습니다.

      Access Modes

      PersistentVolume은 해당 스토리지를 제공하는 서비스(예: 클라우드 스토리지, NFS 서버 등)가 지원하는 모든 방식으로 호스트에 마운트될 수 있습니다. 각 스토리지 제공자는 지원하는 기능이 다르기 때문에, 각 PV의 접근 모드는 해당 PV가 지원하는 모드로 제한됩니다. 예를 들어, NFS는 여러 클라이언트의 동시 읽기/쓰기를 지원할 수 있지만, 특정 NFS PV는 서버 설정에 따라 읽기 전용으로 제공될 수 있습니다. 따라서 각 PV는 해당 PV의 실제 접근 가능 모드를 명시합니다.

      • ReadWriteOnce(RWO): 볼륨은 단일 노드에서 읽기/쓰기 모드로 마운트될 수 있습니다. ReadWriteOnce 접근 모드를 사용하더라도 동일 노드에서 실행되는 여러 Pod가 해당 볼륨에 접근(읽기 또는 쓰기)할 수 있습니다. 단일 Pod 접근을 위해서는 ReadWriteOncePod를 사용해야 합니다.
        • PV가 노드 A에 떠있다면 노드 A에 있는 파드만 읽고 쓰기 가능
      • ReadOnlyMany(ROX): 볼륨은 여러 노드에서 읽기 전용으로 마운트될 수 있습니다.
      • ReadWriteMany(RWX): 볼륨은 여러 노드에서 읽기/쓰기 모드로 마운트될 수 있습니다.
      • ReadWriteOncePod(RWOP): 볼륨은 단일 Pod에서 읽기/쓰기 모드로 마운트될 수 있습니다. 전체 클러스터에서 단 하나의 Pod만 해당 PVC를 읽거나 쓸 수 있도록 하려면 ReadWriteOncePod 접근 모드를 사용하십시오.

      블록 스토리지의 경우 RWX가 지원되지 않은 경우가 있고 오브젝트 스토리지의 경우는 대부분 전부 지원합니다.

      Class

      PV는 StorageClass를 통해 클래스를 지정할 수 있습니다. storageClassName 속성을 사용하여 원하는 StorageClass 이름을 지정합니다. 특정 클래스의 PV는 해당 클래스를 요청하는 PVC에만 바인딩 가능합니다. storageClassName이 없는 PV는 어떤 클래스에도 속하지 않으며, 클래스 지정이 없는 PVC에만 바인딩될 수 있습니다. 과거에는 volume.beta.kubernetes.io/storage-class 어노테이션으로 StorageClass를 지정했지만, 현재는 storageClassName 속성을 사용하는 것이 권장됩니다. 이전 어노테이션은 곧 사용 중단될 예정입니다.

      PersistentVolumeClaims

      각 PVC(PersistentVolumeClaim)는 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

      클레임은 특정 접근 모드로 스토리지를 요청할 때 볼륨과 동일한 규칙을 따릅니다.

      • Persistent Volumes의 Access Modes와 동일

      Volume Modes

      클레임은 볼륨을 파일 시스템 또는 블록 장치로 소비하는지 여부를 나타내기 위해 볼륨과 동일한 규칙을 사용합니다.

      • Persistent Volumes의 Volume Modes와 동일

      Volume Name

      클레임은 volumeName 필드를 사용하여 특정 PersistentVolume에 명시적으로 바인딩할 수 있습니다. volumeName을 설정하지 않은 상태로 두어 Kubernetes가 클레임에 맞는 새 PersistentVolume을 설정하도록 요청할 수도 있습니다. 지정된 PV가 이미 다른 PVC에 바인딩되어 있는 경우 바인딩은 보류 상태로 유지됩니다.

      Resources

      파드와 마찬가지로 클레임도 특정 양의 리소스를 요청할 수 있습니다. 이 경우 요청은 스토리지를 위한 것입니다. 동일한 리소스 모델이 볼륨과 클레임 모두에 적용됩니다.

      Selector

      클레임은 label selector를 지정하여 볼륨 집합을 추가로 필터링할 수 있습니다. label이 selector와 일치하는 볼륨만 클레임에 바인딩될 수 있습니다. selector는 다음 두 필드로 구성될 수 있습니다.

      • matchLabels - 볼륨에는 이 값을 가진 label이 있어야 합니다.
      • matchExpressions - 키, 값 목록 및 키와 값을 관련시키는 연산자를 지정하여 만든 요구 사항 목록입니다. 유효한 연산자에는 In, NotIn, Exists 및 DoesNotExist가 포함됩니다.

      matchLabels와 matchExpressions의 모든 요구 사항은 AND 연산으로 결합됩니다. 즉, 일치하려면 모든 요구 사항을 충족해야 합니다.

      Class

      클레임은 storageClassName 속성을 사용하여 특정 StorageClass의 이름을 지정하여 요청할 수 있습니다. 요청된 클래스의 PV, 즉 PVC와 동일한 storageClassName을 가진 PV만 PVC에 바인딩될 수 있습니다.

      PVC가 반드시 클래스를 요청해야 하는 것은 아닙니다. storageClassName이 ""로 설정된 PVC는 항상 클래스가 없는 PV를 요청하는 것으로 해석되므로 클래스가 없는 PV(어노테이션이 없거나 ""로 설정된 어노테이션)에만 바인딩될 수 있습니다. storageClassName이 없는 PVC는 약간 다르며 DefaultStorageClass 어드미션 플러그인의 활성화 여부에 따라 클러스터에서 다르게 처리됩니다.

      어드미션 플러그인이 활성화된 경우 관리자는 기본 StorageClass를 지정할 수 있습니다. storageClassName이 없는 모든 PVC는 해당 기본값의 PV에만 바인딩될 수 있습니다. 기본 StorageClass 지정은 StorageClass 객체에서 storageclass.kubernetes.io/is-default-class 어노테이션을 true로 설정하여 수행됩니다. 관리자가 기본값을 지정하지 않으면 클러스터는 어드미션 플러그인이 비활성화된 것처럼 PVC 생성을 처리합니다. 둘 이상의 기본 StorageClass가 지정된 경우 PVC가 동적으로 프로비저닝될 때 가장 최근의 기본값이 사용됩니다.

      어드미션 플러그인이 비활성화된 경우 기본 StorageClass의 개념이 없습니다. storageClassName이 ""로 설정된 모든 PVC는 storageClassName이 ""로 설정된 PV에만 바인딩될 수 있습니다. 그러나 storageClassName이 누락된 PVC는 나중에 기본 StorageClass를 사용할 수 있게 되면 업데이트될 수 있습니다. PVC가 업데이트되면 더 이상 storageClassName이 ""로 설정된 PV에 바인딩되지 않습니다.

      PVC가 StorageClass를 요청하는 것 외에 selector를 지정하는 경우 요구 사항은 AND 연산으로 결합됩니다. 즉, 요청된 클래스와 요청된 label을 가진 PV만 PVC에 바인딩될 수 있습니다.

      과거에는 storageClassName 속성 대신 volume.beta.kubernetes.io/storage-class 어노테이션이 사용되었습니다. 이 어노테이션은 아직 작동하지만, 향후 Kubernetes 릴리스에서는 지원되지 않을 예정입니다.

      볼륨에 클레임하기

      파드는 클레임을 볼륨으로 사용하여 스토리지에 접근합니다. 클레임은 해당 클레임을 사용하는 파드와 동일한 네임스페이스에 존재해야 합니다. 클러스터는 파드의 네임스페이스에서 클레임을 찾고 이를 사용하여 클레임을 지원하는 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

      네임스페이스에 대한 참고 사항

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

      StorageClass

      PV(PersistentVolume)와 PVC(PersistentVolumeClaim)는 Kubernetes에서 스토리지를 관리하는 핵심적인 개념이지만 한계를 가지고 있습니다. 이러한 한계를 해결하기 위해 StorageClass가 도입되었습니다.

      PV, PVC만 사용할 때의 한계점

      정적 프로비저닝의 불편함

      관리자는 사용자가 PVC를 요청할 때마다 해당 PVC에 맞는 PV를 미리 생성해야 합니다. 다양한 스토리지 유형, 성능, 정책 등을 고려하여 PV를 수동으로 생성하고 관리하는 것은 번거롭고 효율성이 떨어집니다. 사용자가 필요한 스토리지를 즉시 확보하기 어렵고, 관리자의 개입 없이는 새로운 스토리지를 사용할 수 없습니다.

      유연성 부족

      사용자는 미리 정의된 PV 중에서 자신의 PVC 요구사항에 맞는 PV를 선택해야 합니다. 다양한 스토리지 옵션 (예: 스토리지 유형, 성능, 정책)을 사용자가 직접 선택하고 구성하기 어렵습니다.

      StorageClass를 통한 해결

      StorageClass는 위와 같은 한계점을 해결하기 위해 도입된 개념입니다. StorageClass는 다음과 같은 기능을 제공합니다.

      동적 프로비저닝

      • 사용자가 PVC를 생성할 때 StorageClass를 지정하면 Kubernetes가 해당 StorageClass에 정의된 설정에 따라 PV를 동적으로 프로비저닝합니다. 그러므로 관리자는 더 이상 PVC마다 PV를 미리 생성할 필요가 없습니다. 사용자는 필요한 스토리지를 즉시 확보할 수 있으며, 스토리지 프로비저닝 과정이 자동화되어 효율성을 높입니다.

      다양한 스토리지 옵션 제공

      • StorageClass를 통해 다양한 스토리지 유형, 성능, 정책 등을 정의할 수 있습니다. 사용자는 PVC를 생성할 때 원하는 StorageClass를 선택하여 자신의 요구사항에 맞는 스토리지를 간편하게 사용할 수 있습니다. 관리자는 여러 개의 StorageClass를 정의하여 다양한 스토리지 옵션을 제공할 수 있습니다.

      예시

      PV, PVC만 사용하는 경우

      1. 관리자는 SSD 스토리지를 위한 PV 10개, HDD 스토리지를 위한 PV 5개를 미리 생성합니다.
      2. 사용자는 10GiB의 SSD 스토리지가 필요한 경우, SSD 스토리지를 위한 PV 중 하나를 선택하여 PVC를 생성합니다.
      3. 만약 15GiB의 SSD 스토리지가 필요한 사용자가 있다면, 관리자가 15GiB SSD 스토리지를 위한 PV를 새로 생성할 때까지 기다려야 합니다.

      StorageClass를 사용하는 경우

      1. 관리자는 "ssd" StorageClass와 "hdd" StorageClass를 정의합니다. "ssd" StorageClass는 SSD 스토리지를 프로비저닝하고, "hdd" StorageClass는 HDD 스토리지를 프로비저닝합니다.
      2. 사용자는 10GiB의 SSD 스토리지가 필요한 경우, "ssd" StorageClass를 지정하여 PVC를 생성합니다. Kubernetes는 "ssd" StorageClass에 정의된 설정에 따라 10GiB SSD 스토리지를 동적으로 프로비저닝하여 PVC에 바인딩합니다.
      3. 15GiB의 SSD 스토리지가 필요한 사용자도 "ssd" StorageClass를 지정하여 PVC를 생성하면 Kubernetes가 15GiB SSD 스토리지를 동적으로 프로비저닝하여 제공합니다.

      StorageClass를 사용하면 사용자는 필요할 때마다 원하는 스토리지 유형과 크기를 요청할 수 있으며, 관리자는 스토리지 관리에 대한 부담을 줄일 수 있습니다

      정리

      PersistentVolume (PV) - 관리자 영역

      역할

      • 클러스터의 스토리지 자원을 추상화하여 관리합니다.
      • 다양한 스토리지 유형 (Local Volume, AWS EBS, Azure Disk, NFS 등)을 지원하며, 클러스터 전반에서 사용 가능한 스토리지 풀을 구성합니다.
      • 노드와 마찬가지로 클러스터의 리소스로 취급되며, Pod의 수명 주기와는 독립적인 별도의 수명 주기를 가집니다.

      주요 특징

      • 관리자가 다양한 스토리지 클래스를 사용하여 동적으로 할당하거나, 미리 프로비저닝하여 생성할 수 있습니다.
      • 다양한 스토리지 플러그인을 지원하여 확장성이 뛰어납니다.
      • 파드가 PV를 직접 사용하는 것이 아니라 PVC를 통해 PV에 접근합니다.

      PersistentVolumeClaim (PVC) - 사용자 영역

      역할

      • 사용자가 필요한 스토리지를 요청하는 단위입니다.
      • 파드가 노드의 리소스를 사용하는 것처럼 PVC는 PV의 리소스를 사용합니다.
      • 파드는 PVC를 볼륨으로 마운트하여 스토리지를 사용합니다.

      주요 특징

      • 사용자는 PVC를 통해 필요한 크기와 접근 모드 (ReadWriteOnce, ReadOnlyMany, ReadWriteMany 등)를 지정하여 스토리지를 요청합니다.
      • PVC는 특정 PV에 bind되어 스토리지를 할당받습니다.
      • 파드는 PVC를 볼륨으로 마운트하여 실제 스토리지를 사용합니다

      StorageClass - 관리자 영역

      역할

      • PV의 동적 프로비저닝을 위한 템플릿 역할을 합니다.
      • 스토리지 유형, 성능, 정책 등을 정의하여 PV 생성을 자동화합니다.
      • 관리자는 StorageClass를 미리 정의하여 사용자가 PVC를 생성할 때 원하는 스토리지를 선택할 수 있도록 합니다.

      주요 특징

      • 사용자는 PVC를 생성할 때 원하는 StorageClass를 지정하여 해당 클래스에 정의된 스토리지 속성을 가진 PV를 할당받을 수 있습니다.
      • StorageClass를 사용하면 PV를 미리 생성해두는 대신 필요에 따라 동적으로 프로비저닝할 수 있어 효율적인 스토리지 관리가 가능합니다.

      PV는 클러스터 관리자가 준비한 스토리지 자원이고, PVC는 사용자가 필요한 스토리지를 요청하는 단위입니다. StorageClass는 PV의 동적 프로비저닝을 위한 템플릿입니다. 이들은 다음과 같은 과정을 통해 연결됩니다.

      1. 관리자: PV를 생성하거나 StorageClass를 정의합니다. StorageClass는 PV의 유형, 성능, 정책 등을 정의합니다.
      2. 사용자: PVC를 생성하여 원하는 스토리지 크기, 접근 모드, StorageClass를 요청합니다.
      3. 쿠버네티스: PVC의 요구사항에 맞는 PV를 찾습니다.
        1. StorageClass를 지정한 경우: 해당 StorageClass에 정의된 속성에 맞는 PV를 동적으로 프로비저닝합니다.
        2. StorageClass를 지정하지 않은 경우: 미리 생성된 PV 중에서 요구사항에 맞는 PV를 찾습니다.
      4. 쿠버네티스: PVC를 PV에 바인딩합니다.
      5. 파드: Pod에서 PVC를 볼륨으로 마운트하여 스토리지를 사용합니다.

      레퍼런스

      https://kubernetes.io/docs/concepts/storage/persistent-volumes/

      https://kubernetes.io/docs/concepts/storage/storage-classes/

      https://kubernetes.io/docs/concepts/storage/storage-classes/

      저작자표시

      관련글 관련글 더보기

      댓글

    티스토리툴바