Kubernetes PersistentVolume — 클러스터 전역의 실제 스토리지 자원

PV가 분리된 객체로 존재하는 이유

Pod는 죽으면 사라지지만, 그 안의 데이터는 살아있어야 할 때가 있다. 그래서 스토리지를 Pod 라이프사이클에서 분리된 객체로 둔다.

• PV (PersistentVolume) — 실제 스토리지 자원. 클러스터 전역 객체.
• PVC (PersistentVolumeClaim) — Pod가 "이런 스토리지를 원해요"라고 요청하는 객체.

비유하자면 PV는 호텔 방이고, PVC는 예약 신청서다.

정적 PV YAML

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-data-01
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: manual
  hostPath:
    path: /mnt/data

hostPath는 단일 노드 테스트용. 실제로는 NFS, EBS, Ceph 같은 백엔드를 쓴다.

AccessMode 4가지

중요: AccessMode는 PV의 속성이 아니라 마운트 방식에 대한 약속이다. EBS는 RWO만 지원, NFS는 RWX 가능. 백엔드 능력을 넘는 모드를 선언해도 실제로는 동작하지 않는다.

ReadWriteMany가 필요한 경우(여러 Pod가 같은 디렉토리 공유): NFS, CephFS, EFS 같은 분산 파일시스템 필요.

volumeMode

spec:
  volumeMode: Filesystem   # 기본

또는:

spec:
  volumeMode: Block        # 블록 디바이스로 그대로 노출, 앱이 직접 포맷

DB가 raw 디바이스를 요구할 때 사용. 일반적으론 Filesystem.

Phase (PV의 상태)

Released 상태의 PV는 다른 PVC에 자동 바인딩되지 않는다. 데이터가 남아있을 수 있어서다. 재사용하려면 수동 작업 필요.

ReclaimPolicy

PVC가 삭제될 때 PV의 운명을 결정.

spec:
  persistentVolumeReclaimPolicy: Retain

동적 vs 정적 프로비저닝

동적 (대부분의 경우)

PVC ──storageClassName 지정──▶ StorageClass ──provisioner──▶ PV 자동 생성

관리자는 StorageClass만 만들어두고, 사용자는 PVC만 만든다.

정적

관리자: PV 미리 생성
사용자: PVC 생성 → 매칭되는 PV가 있으면 바인딩

레거시 NFS 같은 환경에서. 또는 특정 PV에만 바인딩하고 싶을 때.

PVC가 특정 PV에 바인딩되도록 강제

# PV 쪽
metadata:
  name: pv-data-01
spec:
  claimRef:
    namespace: default
    name: my-pvc

# PVC 쪽
metadata:
  name: my-pvc
spec:
  volumeName: pv-data-01

자주 하는 실수

AccessMode 오해

ReadWriteOnce는 "Pod 1개"가 아니라 "노드 1개"다. 같은 노드의 여러 Pod가 같은 RWO PV를 마운트할 수 있다(주의: 동시 쓰기 시 corruption 가능). 진짜 단일 Pod 보장은 ReadWriteOncePod.

Released 상태 방치

Retain 정책으로 PVC를 지웠더니 PV가 Released로 영원히 남음. 정리 스크립트나 수동 검토 필요.

정리

PV는 Pod와 분리된 클러스터 자원이다. AccessMode는 백엔드의 능력에 종속되고, ReclaimPolicy는 데이터 안전과 자원 관리의 트레이드오프다. 다음 글에서는 PV를 요청하는 입장인 PVC를 다룬다.