PV/ PVC/ StorageClass 정리표

1. 기본 개념

1) Volume

컨테이너 종료 시에도 유지할 수 있는 데이터 저장 공간

2) emptyDir

Pod 생성 시 생성, Pod 삭제시 삭제 (임시 저장용)

3) hostPath

노드 로컬 디렉토리 사용 (비권장, 실습용/ 로그용)

4) PersistentVolume (PV)

클러스터에서 미리 만들어진 실제 스토리지 자원

5) PersistentVolumeClaim (PVC)

사용자가 요청하는 스토리지 요구사항 (PV 요청서)

6) StorageClass (SC)

PV 자동 생성 규칙 정의 (Dynamic Provisioning)

2. PV (PersistentVolume)

- 역할: 실제 스토리지 공간을 클러스터에 등록

- 생성 주체: 클러스터 관리자

- 바인딩: PVC와 조건이 맞으면 자동 바인딩

- 상태: Available -> Bound -> Released -> Failed

- 주요 필드: capacity, accessModes, persistentVolumeReclaimPolicy

- persistentVolumeReclaimPolicy란?

  : PV와 PVC와의 연결이 끊겼을 때, 그 스토리지를 어떻게 처리할지 정하는 정책

  : 3가지 Reclaim Policy 종류

   - Retain: PV를 보존. PVC가 삭제되도 PV는 남음 - 데이터 보존, 수동 정리 필요할때

   - Recycle: PVC 삭제 시 PV를 자동 포멧 - 현재는 Deprecated (거의 안씀)

   - Delete: PVC 삭제 시 PV 및 실제 스토리지도 함께 삭제 - 동적 프로비저닝의 기본값

 

  : 설정위치)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain   # 👈 여기!
  hostPath:
    path: "/data"

- 시험에 자주 나오는 포인트:

   - PV는 PersistentVolumeClaim과 바인딩 되어야 Pod 사용 가능

   - ReclaimPolicy Delete -> PV 삭제됨 

   - ReclaimPolicy Retain -> PV 남지만 PVC 해제됨

3. PVC (PersistentVolumeClaim)

- 역할: PV 요청 객체 (유저가 필요한 용량/모드를 명시)

- 생성 주체: 사용자

- 필수 필드: accessModes, resources.requests.storage

- 바인딩 조건: PV 용량, accessMode, StorageClass가 일치해야 함

- 상태: Pending -> Bound

- 시험에 자주 나오는 포인트:

   - PVC는 PV가 자동으로 연결될 때까지 Pending

   - Pod은 PVC 이름으로 Volume을 마운트

   - PVC는 삭제시, PV는 ReclaimPolicy에 따라 동작

4. StorageClass (SC)

- 역할: PV를 자동으로 생성하는 규칙 정의

- 개념: PVC 생성시 storageClassName을 지정하면 PV 자동 생성

- 주요 필드: provisioner, parameters, reclaimPolicy, volumeBindingMode

- volumeBindingMode: Immediate (기본), WaitForFirstConsumer

- 동적 프로비저닝: SC를 통해 PVC(PV 요청서)가 자동으로 PV 생성

- 시험에 자주 나오는 포인트:

   - provisioner 예시:

   - WaitForFirstConsumer: Pod이 스케줄될 때까지 PV 생성 지연 (적정한 zone 선택)

5. Access Modes (접근 모드)

1) RWO (ReadWriteOnce)

- 한 노드에서 읽기/쓰기 가능

- 가장 일반적

2) ROX (ReadOnlyMany)

- 여러 노드에서 읽기 전용 접근 가능

- 공유 읽기용

3) RWX (ReadWriteMany)

- 여러 노드에서 읽기/쓰기 가능

- NFS 등에서 사용 가능

6. 명령어 요약

kubectl get pv

kubectl get pvc

kubectl describe pv <pv-name>

kubectl describe pvc <pvc-name>

kubectl get sc

kubectl explain pv.spec

7. 동작 순서 (시험용 시나리오)

1) 관리자가 StorageClass 생성

2) 사용자가 PVC 생성 (SC 명시)

3) Kubernetes가 SC 규칙에 따라 PV 자동 생성 및 바인딩

4) Pod에서 PVC를 Volume으로 마운트

5) Pod가 삭제되어도 데이터는 PVC/PV에 보존

8. yaml 핵심 (암기필수 -> docs 페이지 구조 암기도 방법임)

1) StorageClass

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
   name: standard
provisioner: kubernetes.io/aws-ebs
reclaimPolicy: Delete
volumeBindingModes: Immediate

 

2) PVC

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
   name: mypvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard

 

3) Pod (PVC 사용)

apiVersion: v1
kind: Pod
metadata:
   name: mypod
spec:
  volumes:
    - name: my-volume
      persistentVolumeClaim:
        claimName: mypvc
  containers:
    - name: nginx
      image: nginx
      volumeMounts:
        - mountPath: /usr/share/nginx/html
          name: my-volume

9. CKA 시험 포인트 정리 (단답형)

1) PVC와 PV의 관계는?

PVC는 PV를 요청하는 객체, PV는 실제 스토리지

2) 여러 노드에서 쓰기 가능한 모드는?

RWX (ReadWriteMany)

3) PV의 reclaimPolicy 종류 3가지는?

Retain(PV는 남지만, PVC 해제됨), Recycle, Delete(PV 삭제됨)

4) 동적 프로비저닝을 가능하게 하는 리소스는?

StorageClass

5) PVC 상태가 Pending일 때 원인은?

조건에 맞는 PV가 없음

6) PV 상태가 Released 일 때 의미는?

PVC 해제됨, 아직 재사용 안됨

7) ReclaimPolicy가 Delete이면?

PVC 삭제 시 PV도 삭제됨