PV·PVC

• PV — 실제 저장 공간. 클러스터 수준 자원
• PVC — "이만큼, 이런 조건으로 달라" 는 요청. 네임스페이스 자원
• SC — PVC 가 오면 PV 를 자동으로 만들어 주는 규칙

애플리케이션은 PVC 만 안다 — 뒤에 어떤 스토리지가 있는지 몰라도 된다 이 분리가 이식성을 만든다

접근 모드 — 가장 많이 오해하는 부분

• ReadWriteOnce (RWO) — '하나의 노드' 에서 읽기·쓰기
  • 같은 노드의 여러 파드는 함께 쓸 수 있다
• ReadOnlyMany (ROX) — 여러 노드에서 읽기만
• ReadWriteMany (RWX) — 여러 노드에서 읽기·쓰기
• ReadWriteOncePod (RWOP) '하나의 파드' 만 (더 엄격하다)

오해 ① "RWO 는 파드 하나만"

• 아니다. '노드' 단위다. 진짜 파드 하나로 제한하려면 RWOP 를 쓴다

오해 ② "RWX 를 쓰면 되지"

• 블록 스토리지(EBS · GCE PD)는 RWX 를 지원하지 않는다
• 파일 스토리지(NFS · EFS · CephFS)가 필요하다

Multi-Attach 오류

• 증상 — "replicas 를 2로 올렸더니 하나가 Pending"

  • Events: Multi-Attach error for volume ...

• 원인 — RWO 볼륨을 다른 노드의 파드가 붙이려 한다

• 대응 — StatefulSet + volumeClaimTemplates (파드마다 전용 볼륨)

  • 또는 RWX 지원 스토리지

• Deployment + RWO PVC + replicas > 1 은 구조적으로 안 되는 조합이다

반환 정책

• Retain — PVC 를 지워도 PV 와 데이터가 남는다 (수동 정리)
• Delete — PVC 를 지우면 PV 와 실제 저장소까지 지운다 ← 동적 기본값

운영 데이터에 Delete 를 쓰면 PVC 실수 삭제가 곧 데이터 손실이다 중요한 것은 Retain 으로 두고 정리 절차를 별도로 만든다

바인딩 모드

• Immediate — PVC 생성 즉시 PV 를 만든다
  • 볼륨이 A영역에 생겼는데 파드가 B영역으로 스케줄되면
    • 영원히 못 붙는다
• WaitForFirstConsumer — 파드가 스케줄될 때까지 기다렸다가 만든다
  • 파드가 갈 영역에 맞춰 볼륨이 생긴다
  • 다중 영역 클러스터에서는 사실상 필수다

스냅숏과 확장

• 용량 확장 — allowVolumeExpansion: true 인 StorageClass 에서

  • PVC 의 requests.storage 를 늘리면 확장된다
  • 줄이는 것은 불가능하다
  • 파일시스템 확장은 파드 재시작이 필요할 수 있다

• 스냅숏 — VolumeSnapshot / VolumeSnapshotClass (CSI)

  • 스냅숏에서 새 PVC 를 만들 수 있다
  • 운영 데이터를 개발 환경으로 복제할 때 쓴다

• 둘 다 CSI 드라이버가 지원해야 한다

안 지워지는 PVC

PVC 를 지웠는데 Terminating 에서 멈춘다면

• 그 PVC 를 쓰는 파드가 아직 있다

kubernetes.io/pvc-protection finalizer 가 막고 있는 것이다 파드를 먼저 지우면 PVC 가 사라진다

이것은 버그가 아니라 데이터 보호 장치다

면접 함정

• ❌ "RWO면 파드 하나만 쓸 수 있다" → 노드 단위다.
• ❌ "PVC를 지우면 항상 데이터가 지워진다" → 반환 정책에 따라 다르다. Retain이면 남는다.