Storage - Storage Class

StorageClass: “PV를 미리 만들어두는 방식(정적)”에서 “PVC 요청 시 자동 생성(동적)”으로 넘어가기

이 강의의 요지는 한 줄입니다.

• 정적 프로비저닝(Static provisioning): 사람이(관리자) 클라우드/스토리지에 디스크를 먼저 만들고 → PV도 직접 만들어둔 뒤 → 사용자는 PVC로 그 PV를 골라 씀
• 동적 프로비저닝(Dynamic provisioning): 관리자가 StorageClass(프로비저너 + 정책 + 옵션)를 정의해두면 → 사용자가 PVC를 만들 때 자동으로 디스크/PV가 생성되고 바인딩됨

강의 중에 “이제 PVC도 더 이상 만들 필요 없다 / StorageClass가 PVC를 만든다”처럼 들리는 부분이 있는데, 정확히는 반대입니다.
PVC는 여전히 사용자가 만듭니다. StorageClass는 PVC를 트리거로 PV와 실제 스토리지를 자동으로 만들어주는 역할입니다.

---

1) 정적 프로비저닝이 왜 불편한가?

정적 방식에서는 앱에 스토리지가 필요할 때마다 반복 작업이 생깁니다.

1. (예: GCP) 콘솔/CLI로 디스크를 수동 생성
2. 그 디스크 이름/ID를 참조하는 PV YAML을 수동 작성
3. 사용자는 PVC를 만들어 PV에 바인딩
4. Pod에서 PVC를 마운트

팀/파드 수가 많아질수록:

• “어떤 앱은 SSD, 어떤 앱은 Standard” 같은 정책을 매번 PV YAML에 박아야 하고
• 스토리지 정책 변경 시 PV를 일괄 수정해야 하는 운영 부담이 커집니다.

---

2) StorageClass가 해결하는 것: “중앙 정책 + 자동 생성”

StorageClass는 “클러스터가 제공하는 스토리지 클래스(등급/정책)”를 정의합니다. 여기에 보통 아래가 들어갑니다.

• provisioner: 어떤 스토리지 드라이버(프로비저너)가 실제 볼륨을 만들지
• parameters: 디스크 타입(SSD/Standard), 복제 옵션 등 “스토리지 벤더별 설정”
• reclaimPolicy: PVC 삭제 시 실제 볼륨을 지울지/남길지
• volumeBindingMode: PVC가 생성될 때 언제 PV 바인딩/프로비저닝을 할지(매우 중요)

이렇게 StorageClass를 만들어두면, 사용자는 PVC에서 storageClassName만 고르면 되고, 나머지는 자동으로 처리됩니다.

---

3) 동적 프로비저닝 동작 흐름(중요)

동적 프로비저닝의 실제 흐름은 다음 순서입니다.

1. 관리자가 StorageClass를 만들어 둠
2. 사용자가 PVC 생성 (storageClassName: gold 같은 식)
3. Kubernetes가 StorageClass에 지정된 provisioner를 호출해 실제 스토리지(디스크/NFS 볼륨 등) 생성
4. Kubernetes가 그 스토리지를 대표하는 PV를 자동 생성
5. PVC ↔ PV가 자동으로 Bound
6. Pod가 PVC를 마운트하면 노드에 Attach/Mount가 이뤄짐(CSI 등)

즉:

• PVC는 사용자가 만든다
• PV와 실제 디스크는 자동으로 만들어진다

---

4) 예시: StorageClass / PVC / Pod

4.1 StorageClass 예시(개념 템플릿)

아래는 구조를 이해하기 위한 템플릿입니다.
※ provisioner와 parameters는 클러스터/스토리지에 따라 달라서, 실제 값은 클러스터의 CSI 드라이버 문서를 따라야 합니다.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: silver
provisioner: <YOUR_PROVISIONER>
parameters:
  <VENDOR_SPECIFIC_KEY>: <VALUE>
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

• reclaimPolicy: Delete: PVC 삭제 시 실제 볼륨도 삭제(동적 환경에서 흔함)
• volumeBindingMode: 아래 섹션에서 자세히 설명(멀티 노드/멀티 AZ에서 특히 중요)

4.2 PVC: 어떤 클래스(silver/gold/platinum)를 쓸지 선택

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: silver
  resources:
    requests:
      storage: 10Gi

PVC를 만들면, Kubernetes가 silver StorageClass를 보고 PV/디스크를 자동 생성합니다.

4.3 Pod: PVC를 마운트해서 사용

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: myfrontend
    image: nginx
    volumeMounts:
    - name: mypd
      mountPath: /var/www/html
  volumes:
  - name: mypd
    persistentVolumeClaim:
      claimName: myclaim

---

5) volumeBindingMode를 “왜” 알아야 하나?

volumeBindingMode는 PVC가 PV에 바인딩되고(동적이면 디스크가 생성되는) 타이밍을 결정합니다. 값은 2가지가 핵심입니다.

5.1 Immediate (즉시 바인딩/프로비저닝)

• PVC가 생성되면 즉시 PV 바인딩(및 디스크 프로비저닝)이 일어납니다.
• 단순한 환경에서는 편하지만,
• 존(Zone) 제약이 있는 스토리지(EBS/GCE PD 등) 에서는 “스토리지가 먼저 특정 존에 만들어져버려” Pod 스케줄링 선택지가 줄거나, 스케줄링이 꼬일 수 있습니다.

5.2 WaitForFirstConsumer (첫 소비자 Pod가 생길 때까지 대기)

• PVC만 만들면 바로 바인딩하지 않고 기다립니다.
• 그 PVC를 사용하는 Pod가 실제로 어느 노드/존에 스케줄될지 결정된 다음에,
  • 그 위치에 맞춰 디스크를 만들고(PV 생성)
  • 바인딩합니다.
• 멀티 노드/멀티 AZ에서 스케줄링 제약(nodeSelector/affinity/anti-affinity) 을 존중하기 때문에 운영에서 더 안전한 경우가 많습니다.

“PVC가 Pending인데 정상인가요?”

WaitForFirstConsumer에서는 consumer Pod가 없으면 PVC가 Pending인 상태가 정상일 수 있습니다.
Pod를 만들면 그때 바인딩/프로비저닝이 진행됩니다.

확인:

kubectl describe pvc myclaim
kubectl describe pod mypod
kubectl get events --sort-by=.metadata.creationTimestamp

---

6) “실버/골드/플래티넘 클래스” 예시가 왜 가능한가?

StorageClass를 여러 개 만들어두면,

• silver: 표준 디스크(저렴, 느림)
• gold: SSD(비쌈, 빠름)
• platinum: SSD + 복제/고가용 옵션

처럼 정책별 클래스를 제공할 수 있습니다. 그래서 이름이 “StorageClass(스토리지 등급)”입니다.

PVC에서 필요한 클래스만 지정하면 됩니다.

---

7) 운영 팁: “내 클러스터에서 실제로 어떤 provisioner를 써야 하나?”

환경별로 프로비저너 이름/파라미터 키가 다르기 때문에, 아래부터 확인하면 정확합니다.

# 어떤 StorageClass가 이미 있는지 / 기본(default)인지 확인
kubectl get storageclass -o wide

# CSI 드라이버가 무엇이 설치되어 있는지 확인
kubectl get csidrivers

# PVC 만들었는데 자동 PV가 생기는지 확인
kubectl get pvc
kubectl get pv
kubectl describe pvc myclaim

---

요약

• StorageClass는 동적 프로비저닝의 핵심: PVC 생성 시 PV/실제 스토리지가 자동 생성되게 한다.
• “PVC를 안 만든다”가 아니라, “PV(및 클라우드 디스크)를 수동으로 안 만든다”가 정확하다.
• volumeBindingMode는 바인딩/프로비저닝 타이밍을 제어하며, 멀티 노드/멀티 AZ에서는 WaitForFirstConsumer가 스케줄링 안정성에 도움이 되는 경우가 많다.
• 클래스(silver/gold/platinum)는 성능/정책/복제/삭제정책 같은 운영 기준을 중앙에서 제공하기 위한 패턴이다.

 

Practice Test - https://uklabs.kodekloud.com/topic/practice-test-storage-class-3/