영속적 볼륨 클레임

퍼시스턴트 볼륨 클레임(PersistentVolumeClaim, PVC)은 쿠버네티스 사용자가 스토리지 리소스를 요청하는 선언적 API 오브젝트이다. 사용자는 파드가 필요로 하는 스토리지의 용량, 접근 방식, 성능 특성 등을 PVC 명세에 정의한다. PVC는 추상화된 스토리지 요청서 역할을 하여, 사용자가 실제 물리적 스토리지 인프라의 세부 사항을 알 필요 없이 스토리지를 소비할 수 있게 한다.

PVC는 일반적으로 다음과 같은 핵심 사양을 정의한다.

* 용량 (Storage): 요청하는 스토리지의 크기(예: 10Gi)를 지정한다.

* 액세스 모드 (Access Modes): 볼륨이 어떻게 마운트되어 사용될지 정의한다. 주요 모드로는 단일 노드 읽기-쓰기(ReadWriteOnce), 다수 노드 읽기 전용(ReadOnlyMany), 다수 노드 읽기-쓰기(ReadWriteMany) 등이 있다.

* 스토리지 클래스 (StorageClass): 요구하는 스토리지의 '클래스' 또는 프로비저닝 방식을 지정한다. 이는 성능, 백업 정책 등을 결정하는 프로파일이다.

PVC가 생성되면 쿠버네티스 컨트롤 플레인, 특히 퍼시스턴트볼륨 컨트롤러는 사용 가능한 퍼시스턴트 볼륨(PersistentVolume, PV) 리소스 중 PVC의 요구 사항을 만족하는 것을 찾아 양자를 바인딩한다. PV는 실제 스토리지 리소스(예: AWS EBS 볼륨, NFS 공유, 로컬 디스크)를 나타내는 클러스터 수준의 리소스이다. 이 매커니즘을 통해 사용자는 특정 디스크나 볼륨을 직접 관리하지 않고도 일관된 방식으로 스토리지를 할당받고 사용할 수 있다.

퍼시스턴트 볼륨(PV)은 클러스터에 의해 프로비저닝된 스토리지 자원 그 자체를 가리킨다. 이는 NFS, iSCSI와 같은 네트워크 스토리지 시스템이나 클라우드 제공자의 블록 스토리지, 로컬 스토리지 등 물리적 스토리지 자원을 추상화한 API 오브젝트이다. 반면, 퍼시스턴트 볼륨 클레임(PVC)은 사용자(또는 파드)가 PV에 대해 하는 스토리지 요청서이다. PVC는 필요한 스토리지의 용량, 접근 모드 등의 사양을 정의한다.

PV와 PVC의 관계는 전통적인 컴퓨팅 자원 할당 모델과 유사하다. PV는 클러스터 관리자가 미리 준비해 놓은 '스토리지 풀'에 속한 개별 디스크와 같다. PVC는 애플리케이션 개발자가 그 풀에서 특정 요구사항(예: 10Gi 용량, 읽기-쓰기 가능)을 명시하여 디스크를 '요청'하는 행위이다. 쿠버네티스 컨트롤 플레인, 정확히는 퍼시스턴트볼륨 컨트롤러는 사용자의 PVC와 사용 가능한 PV를 매칭시켜 바인딩한다. 이 매칭은 PVC에 명시된 스토리지 용량과 액세스 모드 등을 기준으로 이루어진다.

이 관계를 통해 스토리지 사용의 추상화 계층이 생성된다. 개발자는 복잡한 백엔드 스토리지 인프라의 세부 사항을 알 필요 없이, PVC라는 표준화된 인터페이스를 통해 스토리지를 요청하고 사용할 수 있다. 인프라 관리자는 다양한 종류의 스토리지를 PV로 생성해 관리하며, PVC 요청에 따라 적절한 스토리지를 동적으로 할당할 수 있다. PVC는 PV에 대한 '클레임'(요구권)을 나타내므로, 하나의 PV는 하나의 PVC에만 바인딩될 수 있다. 반면, 하나의 PVC는 하나의 PV에 바인딩된다.

PV와 PVC의 라이프사이클은 다음 단계를 따른다.

퍼시스턴트 볼륨 클레임(PVC)은 쿠버네티스에서 스토리지 리소스를 추상화하고 관리 효율성을 높이기 위해 도입된 핵심 메커니즘이다. PVC를 사용하는 주된 이유는 애플리케이션 개발자와 인프라 관리자의 책임을 명확히 분리하여, 각자가 스토리지의 세부 구현보다는 자신의 관심사에 집중할 수 있게 하기 위함이다. 개발자는 필요한 스토리지의 용량, 성능, 접근 모드와 같은 요구사항만 정의하면 되며, 실제로 어떤 스토리지 클래스나 물리적 디스크가 할당되는지는 신경 쓸 필요가 없다. 이는 애플리케이션 매니페스트를 특정 인프라 환경에 종속되지 않게 만들어 이식성을 크게 향상시킨다.

PVC는 스토리지 리소스의 동적이고 효율적인 프로비저닝을 가능하게 한다. 인프라 관리자가 미리 많은 수의 퍼시스턴트 볼륨(PV)을 생성해 놓지 않아도, 개발자가 PVC를 생성하는 시점에 요구 사항에 맞는 스토리지가 자동으로 할당되는 동적 프로비저닝을 지원한다. 이는 클라우드 환경에서 특히 유용하며, 필요할 때 즉시 스토리지를 확보하고 사용 후 반납하는 유연한 리소스 관리 모델을 실현한다. 결과적으로 스토리지 활용도를 최적화하고 관리 오버헤드를 줄일 수 있다.

또한 PVC는 상태 저장 애플리케이션의 데이터 지속성을 보장하는 데 필수적이다. 파드의 생명주기는 일시적이며, 파드가 재시작되거나 다른 노드로 이동하면 로컬에 저장된 데이터는 사라진다. PVC를 통해 파드 외부의 지속적 스토리지에 데이터를 저장하면, 파드의 스케줄링이나 장애와 무관하게 데이터를 안전하게 유지할 수 있다. 이는 데이터베이스, 파일 서버, 메시지 큐와 같은 상태 저장 워크로드를 쿠버네티스에서 안정적으로 운영하기 위한 토대를 제공한다.

마지막으로, PVC는 스토리지 정책과 생명주기를 체계적으로 관리할 수 있는 통제 지점을 제공한다. PVC를 통해 특정 액세스 모드(예: 단일 노드 읽기-쓰기, 다중 노드 읽기 전용 등)를 명시하거나, 데이터 보존 정책(삭제 시 보존 또는 삭제)을 설정할 수 있다. 이는 데이터의 무결성과 보안 요구사항을 충족시키는 동시에, 스토리지 비용을 관리하는 데도 도움이 된다.

PVC 매니페스트는 일반적으로 YAML 형식으로 작성되며, 사용자가 원하는 스토리지의 속성을 정의합니다. 주요 구성 요소로는 API 버전, 종류, 메타데이터, 그리고 스펙(명세)이 포함됩니다. 스펙은 PVC의 핵심 요구 사항을 기술하는 부분입니다.

스펙(spec) 내에는 다음과 같은 필드들이 정의됩니다.

* accessModes: 액세스 모드를 지정합니다. 예를 들어 ReadWriteOnce, ReadWriteMany 등이 있습니다.

* resources: 요청하는 스토리지의 양을 정의합니다. requests.storage 필드에 기가바이트(Gi) 또는 메가바이트(Mi) 단위로 용량을 명시합니다.

* storageClassName: 사용할 스토리지 클래스의 이름을 지정합니다. 이는 동적 프로비저닝 시 어떤 유형의 스토리지를 생성할지 결정합니다. 생략하거나 빈 문자열("")로 두면 클러스터의 기본 스토리지 클래스가 사용됩니다.

* selector: 정적 프로비저닝 시, 사전에 생성된 특정 퍼시스턴트 볼륨(PV)을 선택하기 위한 라벨 셀렉터를 정의합니다. matchLabels 또는 matchExpressions를 사용하여 PV를 필터링할 수 있습니다.

* volumeName: PVC를 클러스터 내 존재하는 특정 PV 이름에 직접 바인딩하고자 할 때 사용합니다. 이 필드를 사용하면 selector는 무시됩니다.

다음은 PVC 매니페스트의 간단한 예시입니다.

```yaml

apiVersion: v1

kind: PersistentVolumeClaim

metadata:

name: my-data-pvc

spec:

accessModes:

• ReadWriteOnce

resources:

requests:

storage: 10Gi

storageClassName: fast-ssd

```

이 매니페스트는 fast-ssd라는 스토리지 클래스를 통해 10GiB 용량의 스토리지를 요청하며, 단일 노드에서 읽기-쓰기 모드로 마운트될 수 있도록 정의합니다.

액세스 모드는 퍼시스턴트 볼륨 클레임(PVC)이 요청하는 스토리지에 대한 접근 방식을 정의합니다. 이는 PVC가 생성될 때 명시해야 하는 필수 사양 중 하나이며, 퍼시스턴트 볼륨(PV)의 실제 능력과 일치해야 바인딩이 성공합니다. 주로 단일 노드의 단일 파드 접근, 다중 노드의 읽기 전용 접근, 다중 노드의 읽기/쓰기 접근과 같은 시나리오를 구분합니다.

주요 액세스 모드는 다음과 같습니다.

이 모드들은 스토리지 공급자의 기술적 능력에 의해 제한됩니다. 예를 들어, 대부분의 블록 스토리지(예: AWS EBS, GCE PD)는 ReadWriteOnce 모드만 지원합니다. 반면, NFS나 일부 클라우드 파일 스토리지 서비스(예: AWS EFS, Azure Files)는 ReadWriteMany 모드를 지원하여 웹 서버 팜이나 콘텐츠 관리 시스템과 같은 공유 데이터가 필요한 애플리케이션에 적합합니다. 사용자는 애플리케이션의 요구 사항과 클러스터의 스토리지 인프라를 고려하여 적절한 액세스 모드를 선택해야 합니다.

스토리지 클래스는 퍼시스턴트 볼륨 클레임이 요청하는 스토리지의 '종류' 또는 '등급'을 정의하는 프로비저닝 방법이다. 사용자는 PVC 명세에서 특정 스토리지 클래스의 이름을 지정하여, 원하는 성능, 가용성, 비용 정책을 가진 스토리지를 동적으로 요청할 수 있다. 이는 클라우드 환경의 다양한 스토리지 옵션(예: 표준 HDD, 고성능 SSD, 로컬 SSD)이나 온프레미스 환경의 다른 스토리지 백엔드를 추상화하고 구분하는 역할을 한다.

스토리지 클래스의 핵심 구성 요소는 provisioner, parameters, reclaimPolicy이다. provisioner는 실제 볼륨을 생성할 스토리지 플러그인(예: kubernetes.io/aws-ebs, kubernetes.io/gce-pd, ceph.com/rbd)을 결정한다. parameters는 프로비저너에 따라 다르며, 디스크 유형, 존, 파일 시스템 타입 등의 상세 설정을 제공한다. reclaimPolicy는 PVC가 삭제된 후 연결된 PV를 어떻게 처리할지(Retain, Delete, Recycle) 정의한다.

클러스터 관리자는 애플리케이션 팀의 요구에 맞게 다양한 스토리지 클래스를 미리 정의할 수 있다. 일반적인 예시는 다음과 같다.

PVC에서 storageClassName 필드를 생략하거나 빈 문자열("")로 설정하면, 클러스터 관리자가 지정한 기본 스토리지 클래스가 사용된다. 이는 사용자가 복잡한 스토리지 인프라를 알 필요 없이 간단히 PVC를 생성할 수 있게 한다. 반면, 특정 요구사항이 있을 때는 명시적으로 스토리지 클래스를 지정하여, 애플리케이션에 적합한 스토리지 리소스를 보장받을 수 있다.

퍼시스턴트 볼륨 클레임을 퍼시스턴트 볼륨에 연결하는 방식은 크게 정적 프로비저닝과 동적 프로비저닝 두 가지로 나뉜다. 이 방식들은 클러스터 관리자가 스토리지 리소스를 관리하는 접근법과 사용자(개발자)의 편의성에 차이를 보인다.

정적 프로비저닝에서는 클러스터 관리자가 먼저 하나 이상의 PV를 미리 생성해 둔다. 이 PV들은 실제 물리적 스토리지나 클라우드 디스크와 같은 스토리지 자원을 반영하는 쿠버네티스 API 오브젝트이다. 사용자가 PVC를 생성하면, 쿠버네티스 컨트롤 플레인은 요청된 스토리지 크기, 액세스 모드 등의 조건을 만족하는 미리 생성된 PV를 찾아 PVC와 바인딩한다. 이 방식은 관리자가 스토리지 리소스를 직접 통제하고 할당할 수 있지만, 사용자의 요구가 다양해질수록 미리 모든 경우의 수에 대비한 PV를 준비해야 하는 부담이 있다.

반면 동적 프로비저닝은 사용자가 PVC를 생성할 때, 미리 생성된 PV 풀에서 찾는 대신, PVC 명세에 지정된 스토리지 클래스를 기반으로 새로운 PV를 자동으로 생성한다. 스토리지 클래스는 프로비저너, 파라미터, 리클레임 정책 등을 정의하여 어떤 종류의 스토리지를 어떻게 만들지에 대한 청사진 역할을 한다. 이 방식은 관리자가 미리 많은 PV를 준비할 필요가 없으며, 사용자의 요청에 따라 필요한 스토리지가 실시간으로 프로비저닝되므로 현대적인 클라우드 네이티브 환경에서 선호된다. 동적 프로비저닝이 활성화되면, 정적 프로비저닝으로 생성된 PV는 여전히 사용 가능하지만, 시스템은 일반적으로 동적 프로비저닝을 우선시한다.

PVC의 바인딩 프로세스는 사용자가 생성한 PVC 명세와 클러스터 내 사용 가능한 퍼시스턴트 볼륨 리소스를 연결하는 과정이다. 이 프로세스는 PVC의 요구 사항과 PV의 속성을 기반으로 일대일 매칭을 통해 이루어진다.

바인딩은 주로 PVC 명세의 spec 필드에 정의된 조건에 따라 진행된다. 주요 매칭 조건은 다음과 같다.

바인딩 방식은 정적 프로비저닝과 동적 프로비저닝에 따라 다르게 진행된다. 정적 프로비저닝에서는 관리자가 미리 생성해 둔 PV 풀에서 위의 조건을 만족하는 PV를 찾아 바인딩한다. 조건을 만족하는 PV가 없으면 PVC는 Pending 상태로 대기한다. 동적 프로비저닝에서는 조건을 만족하는 기존 PV가 없을 때, PVC에 지정된 스토리지 클래스와 프로비저너가 연동되어 새로운 PV를 자동으로 생성한 후 즉시 해당 PVC에 바인딩한다. 바인딩이 성공적으로 완료되면 PVC와 PV의 상태는 모두 Bound가 된다. 이때 바인딩은 배타적이며, 한 번 바인딩된 PV는 해당 PVC가 삭제되거나 바인딩을 해제하기 전까지 다른 PVC에서 사용할 수 없다.

PVC는 생성 후 사용 가능해지기까지 여러 상태를 거친다. 주요 상태는 다음과 같다.

이러한 상태 변화는 쿠버네티스 컨트롤 플레인의 퍼시스턴트볼륨 컨트롤러에 의해 관리된다. 사용자는 kubectl get pvc 명령을 통해 PVC의 현재 상태를 확인할 수 있다. Lost 상태의 PVC는 일반적으로 관리자의 개입이 필요하며, 바인딩된 PV를 복구할 수 없다면 해당 PVC를 삭제하고 새로 생성해야 한다.

파드는 볼륨을 통해 영속적 볼륨 클레임을 마운트하여 스토리지를 사용한다. 파드의 명세 파일(pod.yaml) 내 spec.volumes 항목에서 PVC를 참조하고, spec.containers.volumeMounts 항목에서 컨테이너 내부의 마운트 경로를 지정한다.

아래는 my-pvc라는 이름의 PVC를 파드의 /data 경로에 마운트하는 예시 매니페스트이다.

```yaml

apiVersion: v1

kind: Pod

metadata:

name: my-pod

spec:

volumes:

• name: data-storage

persistentVolumeClaim:

claimName: my-pvc

containers:

• name: my-container

image: nginx

volumeMounts:

• mountPath: "/data"

name: data-storage

```

파드가 생성되면, 쿠버네티스 스케줄러는 PVC가 바인딩된 퍼시스턴트 볼륨이 위치한 노드를 고려하여 파드를 적절한 노드에 배치한다. 이후 해당 노드의 kubelet이 실제 스토리지 장치를 지정된 컨테이너 경로에 마운트한다. 파드 내 여러 컨테이너가 동일한 PVC를 서로 다른 경로에 마운트하여 데이터를 공유할 수도 있다.

PVC의 액세스 모드는 파드의 사용 방식을 결정한다. 예를 들어, ReadWriteOnce 모드의 PVC는 단일 노드의 여러 파드에서 동시에 마운트할 수 없지만, ReadWriteMany 모드의 PVC는 여러 노드에 걸친 여러 파드에서 동시에 읽기 및 쓰기로 마운트할 수 있다. 파드의 마운트 설정은 PVC에 정의된 액세스 모드와 호환되어야 한다.

이 세 가지 액세스 모드는 퍼시스턴트 볼륨이 하나 이상의 파드에 의해 어떻게 마운트될 수 있는지를 정의합니다. 각 모드는 특정 스토리지 솔루션의 기능과 애플리케이션의 요구 사항에 따라 선택됩니다.

애플리케이션을 설계할 때는 필요한 액세스 패턴을 먼저 평가해야 합니다. 예를 들어, 스테이트풀셋을 사용하는 분산 데이터베이스는 일반적으로 각 파드 복제본마다 전용 스토리지가 필요하므로 ReadWriteOnce 모드를 사용합니다. 반면, 콘텐츠 관리 시스템이나 협업 도구는 여러 워커 파드가 공통 업로드 디렉토리에 접근해야 할 수 있어 ReadWriteMany 모드가 필요합니다. 선택한 액세스 모드는 PVC 매니페스트의 spec.accessModes 필드에 배열로 지정하며, 이는 프로비저닝될 실제 스토리지의 기능과 일치해야 바인딩이 성공합니다[3].

PVC 확장은 생성된 영속적 볼륨 클레임의 스토리지 용량 요구 사항을 증가시키는 작업이다. 쿠버네티스 1.11 버전부터 베타 기능으로 도입되었으며, 1.16 버전부터는 많은 스토리지 플러그인에서 안정적으로 지원한다[5]. 이 기능은 애플리케이션의 데이터 증가에 따라 스토리지 용량을 유연하게 늘릴 수 있게 해주며, 서비스 중단 없이 온라인 상태에서 수행되는 경우가 많다.

확장을 위해서는 몇 가지 전제 조건이 충족되어야 한다. 먼저, 사용 중인 스토리지 클래스가 allowVolumeExpansion: true 필드를 설정하여 확장을 허용해야 한다. 또한, 백엔드 스토리지 프로비저너(예: CSI 드라이버)가 볼륨 확장을 지원해야 하며, 해당 퍼시스턴트 볼륨이 동적 프로비저닝으로 생성된 것이어야 한다. 정적 프로비저닝으로 생성된 PV는 일반적으로 확장이 지원되지 않는다.

확장 작업은 PVC 매니페스트 파일에서 spec.resources.requests.storage 필드의 값을 원하는 더 큰 용량으로 수정하여 시작한다. 이는 kubectl edit pvc <pvc-name> 명령이나 매니페스트 파일을 적용(kubectl apply)하는 방식으로 수행할 수 있다. 변경 사항이 적용되면 쿠버네티스 컨트롤 플레인은 다음 단계를 순차적으로 실행한다.

1. PVC의 상태가 Bound에서 FileSystemResizePending으로 변경된다.

2. 컨트롤 플레인이 백엔드 스토리지 공급자에게 실제 볼륨 확장을 요청한다.

3. 확장이 완료되면, PVC가 마운트된 파드를 재시작하지 않고도 파일 시스템의 온라인 확장을 지원하는 스토리지 시스템의 경우 자동으로 파일 시스템 크기가 조정된다[6].

4. 파일 시스템 확장이 완료되면 PVC 상태는 다시 Bound로 돌아가고, 새로운 용량이 반영된다.

확장 작업은 일반적으로 데이터 손실 없이 이루어지지만, 축소(용량 감소)는 보안상의 이유와 데이터 손실 위험으로 인해 대부분의 스토리지 시스템과 쿠버네티스에서 지원하지 않는다. 또한, 확장 후에도 PVC의 다른 스펙(예: 액세스 모드나 스토리지 클래스)은 변경할 수 없다. 운영 시에는 확장 작업 전에 충분한 용량 계획을 수립하고, 지원되는 스토리지 백엔드를 확인하며, 중요한 데이터에 대해서는 확장 전 스냅샷 백업을 고려하는 것이 모범 사례에 해당한다.

PVC를 삭제할 때, 연결된 퍼시스턴트 볼륨의 데이터가 어떻게 처리될지는 PV의 reclaimPolicy에 따라 결정된다. 기본 정책은 PVC가 삭제되면 연결된 PV의 상태가 Released로 변경되고, 이후 스토리지 공간을 회수(Reclaim)하는 과정이 수행된다.

주요 데이터 보존 정책은 다음과 같다.

Retain 정책이 적용된 PV는 PVC 삭제 후에도 데이터가 물리적 스토리지에 그대로 남아 있다. 관리자는 이 PV를 수동으로 삭제하거나, 데이터를 백업한 후 새로운 PVC에 수동으로 바인딩하여 재사용할 수 있다. 이는 실수로 PVC를 삭제하는 경우 데이터를 보호하는 중요한 안전장치 역할을 한다.

반면, Delete 정책은 주로 동적 프로비저닝 환경에서 사용되며, PVC 삭제 시 외부 스토리지 시스템(예: AWS EBS, 구글 클라우드 Persistent Disk)의 볼륨까지 함께 삭제하여 불필요한 비용 발생을 방지한다. 운영 환경에서는 데이터의 중요성과 스토리지 비용을 고려하여 신중하게 정책을 선택해야 한다.

PVC 스냅샷은 특정 시점의 퍼시스턴트 볼륨 데이터의 상태를 보존하는 기능이다. 이는 주로 데이터 백업, 애플리케이션 롤백, 새로운 환경에 데이터 복제 등의 목적으로 사용된다. 스냅샷 생성은 일반적으로 스토리지 공급자가 제공하는 CSI 드라이버를 통해 이루어지며, 스냅샷 생성 중에도 원본 볼륨은 정상적으로 읽기 및 쓰기 작업이 가능하다[7]. 생성된 스냅샷은 별도의 스토리지 공간에 저장되며, 원본 PVC와 독립적인 생명주기를 가진다.

스냅샷을 기반으로 한 PVC 복원은 크게 두 가지 방식으로 이루어진다. 첫째는 기존 PVC의 데이터를 스냅샷 시점으로 되돌리는 것이다. 둘째는 스냅샷을 원본으로 하는 완전히 새로운 PVC를 프로비저닝하는 것이다. 후자의 방식은 테스트 환경 구성이나 데이터 분석을 위한 샌드박스 생성에 유용하게 활용된다. 복원 작업은 VolumeSnapshot 및 VolumeSnapshotContent라는 쿠버네티스 리소스를 사용하여 선언적으로 관리된다.

모든 스토리지 솔루션이 스냅샷 기능을 지원하는 것은 아니며, 기능의 세부 사항(예: 증분 스냅샷 지원 여부)도 공급자마다 다르다. 따라서 스냅샷 및 복원 전략을 수립할 때는 사용 중인 스토리지 백엔드의 문서를 참고하여 호환성과 제한 사항을 반드시 확인해야 한다. 또한 스냅샷은 데이터 보호 전략의 일부일 뿐, 재해 복구를 위해서는 스냅샷을 외부 시스템으로 이관하는 추가적인 백업 절차가 필요할 수 있다.

데이터베이스, 키-값 저장소, 메시지 큐와 같은 상태 저장 애플리케이션은 PVC의 가장 대표적인 사용 사례이다. 이러한 애플리케이션은 실행 중 생성된 데이터를 영구적으로 보존해야 하며, 파드가 재시작되거나 다른 노드로 이동하더라도 동일한 데이터에 접근할 수 있어야 한다. PVC는 파드의 라이프사이클과 분리된 독립적인 스토리지 리소스를 제공함으로써 이 요구사항을 충족시킨다.

일반적인 데이터베이스 배포 시, 데이터 파일을 저장할 PVC를 생성하고 이를 데이터베이스 파드에 마운트한다. 이때 액세스 모드는 주로 단일 노드에서 읽기-쓰기가 가능한 ReadWriteOnce를 사용한다. 아래는 주요 데이터베이스와 PVC 사용의 연관성을 보여주는 예시이다.

PVC를 사용하면 데이터베이스 파드를 스케일링하거나 업그레이드할 때 데이터의 영속성을 보장할 수 있다. 예를 들어, 데이터베이스 파드를 삭제하고 새 버전의 파드를 생성하더라도 동일한 PVC를 참조하면 모든 데이터가 그대로 유지된다. 또한, 스테이트풀셋과 함께 PVC를 사용하면 각 파드 복제본마다 전용의 영구 스토리지를 안정적으로 프로비저닝할 수 있어, 복제본 간 데이터 일관성을 유지하는 데 필수적이다[8].

PVC는 단일 파드 전용으로 사용되는 ReadWriteOnce 액세스 모드 외에도, 여러 파드가 동시에 데이터를 읽고 쓸 수 있는 공유 스토리지를 구성하는 데 핵심적인 역할을 한다. 이는 ReadWriteMany 또는 ReadOnlyMany 액세스 모드를 지원하는 스토리지 백엔드와 스토리지클래스를 통해 구현된다. 공유 스토리지는 웹 서버의 정적 콘텐츠, 공동 편집 문서, 중앙 집중식 로그 저장소, 또는 MLOps 파이프라인의 모델 아티팩트 저장과 같이 다수의 인스턴스가 동일한 데이터셋에 접근해야 하는 애플리케이션에 필수적이다.

공유 스토리지를 활용하는 일반적인 패턴은 다음과 같다. 먼저, 관리자는 NFS, CephFS, GlusterFS 또는 클라우드 공유 파일 서비스(예: AWS EFS, Azure Files, Google Cloud Filestore)와 같은 공유 스토리지 시스템을 기반으로 하는 스토리지클래스를 생성한다. 이후 애플리케이션 개발자는 이 스토리지 클래스를 참조하고 액세스 모드를 ReadWriteMany로 지정한 PVC 매니페스트를 작성하여 배포한다. 쿠버네티스 컨트롤 플레인은 이 PVC 사양에 맞는 공유 스토리지 볼륨을 동적으로 프로비저닝하거나, 미리 생성된 퍼시스턴트볼륨에 바인딩한다. 최종적으로, 이 PVC는 디플로이먼트나 스테이트풀셋과 같은 워크로드의 여러 파드 템플릿에 동일하게 참조되어 마운트된다.

이러한 구성을 통해 애플리케이션은 확장성과 데이터 일관성을 유지할 수 있다. 예를 들어, 디플로이먼트의 레플리카 수를 늘려도 모든 새로운 파드는 동일한 PVC를 통해 마운트된 공유 스토리지의 데이터를 즉시 인식한다. 그러나 성능과 데이터 무결성에 주의해야 한다. 특히 ReadWriteMany 모드에서 여러 파드가 동일한 파일에 동시에 쓰기를 수행할 경우, 파일 잠금 메커니즘이나 애플리케이션 수준의 동시성 제어가 필요할 수 있다. 또한, 선택한 공유 스토리지 솔루션의 실제 성능(IOPS, 지연 시간, 대역폭)과 가용성은 전체 애플리케이션 성능에 직접적인 영향을 미친다.

애플리케이션의 성능, 비용, 가용성 요구사항에 맞는 스토리지 클래스를 선택하는 것은 PVC 설계의 핵심 단계이다. 각 스토리지 클래스는 백엔드 스토리지 시스템의 유형(예: SSD, 표준 HDD), 프로비저닝 방식, 리플리케이션 정책, 가격 모델 등을 정의한다. 잘못된 선택은 성능 병목 현상을 초래하거나 불필요한 비용을 발생시킬 수 있다.

성능이 중요한 데이터베이스나 트랜잭션 처리 시스템의 경우, 낮은 지연 시간과 높은 IOPS를 제공하는 SSD 기반의 프리미엄 스토리지 클래스를 선택하는 것이 일반적이다. 반면, 로그 저장, 백업 데이터, 개발/테스트 환경과 같이 대용량이지만 빈번한 액세스가 필요하지 않은 워크로드에는 표준 HDD 스토리지 클래스를 사용하여 비용을 절감할 수 있다. 또한, 클라우드 공급자가 제공하는 지역별 또는 존별 스토리지 옵션을 고려하여 데이터 위치와 내구성 요구사항을 충족시켜야 한다.

다음 표는 주요 선택 기준과 고려 사항을 정리한 것이다.

마지막으로, 애플리케이션의 라이프사이클과 운영 요구사항을 고려해야 한다. 예를 들어, 동적으로 생성되고 삭제되는 임시 데이터에는 Delete 리클레임 정책이 설정된 스토리지 클래스를, 장기 보존이 필요한 데이터에는 Retain 정책이 설정된 클래스를 사용한다. 또한, 향후 용량 확장이 예상된다면 allowVolumeExpansion: true 속성을 지원하는 스토리지 클래스를 미리 선택하는 것이 좋다.

애플리케이션의 요구사항과 예상되는 데이터 성장을 기반으로 적절한 용량을 사전에 계획하는 것이 중요합니다. PVC 생성 시 spec.resources.requests.storage 필드에 명시된 용량은 프로비저닝의 기준이 되며, 많은 스토리지 클래스는 이후 PVC 확장을 지원합니다. 그러나 확장 작업이 항상 가능한 것은 아니며, 파일 시스템 유형이나 백엔드 스토리지 시스템에 제약이 있을 수 있습니다. 따라서 초기 용량을 너무 작게 설정하면 애플리케이션 가용성에 영향을 미칠 수 있고, 너무 크게 설정하면 불필요한 비용이 발생할 수 있습니다. 데이터 증가율과 애플리케이션의 중요도를 고려하여 안전 마진을 포함한 용량을 산정하고, 확장 가능성을 사전에 확인하는 것이 좋습니다.

액세스 모드 선택은 애플리케이션의 데이터 접근 패턴을 정확히 이해하는 데서 시작합니다. ReadWriteOnce는 단일 노드에서 읽기-쓰기 마운트를 허용하므로, 대부분의 데이터베이스나 단일 파드 애플리케이션에 적합합니다. ReadOnlyMany는 여러 노드에서 동시에 읽기 전용으로 마운트할 수 있어, 설정 파일이나 정적 콘텐츠를 제공하는 시나리오에 유용합니다. ReadWriteMany는 여러 노드에서 동시에 읽기-쓰기를 지원해야 하는 공유 워크스페이스나 협업 애플리케이션에 필요합니다. 각 액세스 모드는 지원하는 스토리지 클래스와 백엔드 스토리지 시스템이 다르므로, 애플리케이션 설계 단계에서 요구되는 동시 접근 방식을 정의하고, 이를 충족하는 스토리지 솔루션을 선택해야 합니다.

용량과 액세스 모드 계획은 종합적으로 고려되어야 합니다. 예를 들어, ReadWriteMany 모드를 요구하는 애플리케이션은 특정 네트워크 연결 스토리지(NAS, 객체 스토리지 등)에 의존하게 되며, 이는 용량 확장 정책이나 성능 특성에 영향을 줄 수 있습니다. 아래 표는 계획 시 주요 고려 사항을 비교한 것입니다.

잘못된 액세스 모드 선택은 애플리케이션 배포 실패나 데이터 불일치로 이어질 수 있으며, 용량 부족은 운영 중단을 초래할 수 있습니다. 따라서 개발 단계에서부터 스토리지 요구사항을 명확히 정의하고, 테스트 환경에서 검증하는 것이 바람직합니다.

영속적 볼륨 클레임을 사용하는 상태 저장 애플리케이션의 데이터는 비즈니스 연속성을 위해 체계적인 백업 전략이 필수적이다. PVC의 백업은 단순히 파드나 노드를 복제하는 것과 달리, 실제 데이터가 저장된 퍼시스턴트 볼륨의 내용을 안전한 위치로 복사하고 필요시 복원할 수 있는 체계를 구축하는 것을 의미한다.

주요 백업 방법으로는 스토리지 공급자 수준의 스냅샷, 애플리케이션 수준의 내보내기, 그리고 파일 시스템 수준의 복사가 있다. 많은 클라우드 공급자의 스토리지 클래스는 볼륨 스냅샷 기능을 지원하며, 쿠버네티스의 VolumeSnapshot API를 사용해 관리할 수 있다. 이 방법은 빠르지만, 특정 스토리지 인프라에 종속될 수 있다. 애플리케이션 내부 도구(예: mysqldump, pg_dump)를 사용한 논리적 백업은 더 이식성이 높지만, 대용량 데이터베이스의 경우 시간이 오래 걸리고 애플리케이션에 부하를 줄 수 있다. 또 다른 방법은 실행 중인 파드에 백업 도구가 포함된 사이드카 컨테이너를 추가하거나, 백업 전용 잡을 생성하여 PVC를 마운트하고 데이터를 외부 오브젝트 스토리지로 복사하는 것이다.

효과적인 백업 전략을 수립할 때는 다음 사항을 고려해야 한다.

• RPO(복구 시점 목표)와 RTO(복구 시간 목표): 데이터 손실 허용 시간과 복구 소요 시간에 따라 백업 빈도와 방법을 결정한다.

• 백업 검증: 정기적으로 백업 파일의 무결성을 확인하고 복원 절차를 테스트하여 백업이 실제로 작동하는지 검증한다.

• 백업 보관 및 라이프사이클: 최신 백업뿐만 아니라 과거 특정 시점으로의 복원이 필요할 수 있으므로, 백업의 보관 주기와 저장소 계층화 정책을 정의한다.

• 선언적 관리: 백업 작업 자체도 쿠버네티스 매니페스트나 헬름 차트로 정의하여 버전 관리하고 재현 가능하게 만든다.

마지막으로, PVC의 백업은 단일 컴포넌트가 아닌 애플리케이션 전체 컨텍스트에서 고려해야 한다. 중요한 구성 파일이나 시크릿도 함께 백업해야 하며, 복원 시에는 애플리케이션 버전과 데이터 스키마의 호환성 문제가 발생하지 않도록 주의한다.