[k8] Storage class

정적 프로비저닝

정적 프로비저닝은 말 그대로 수동으로 스토리지를 준비하는 방식입니다. 관리자가 미리 스토리지(디스크)를 만들어 두고, 그에 맞는 PV 정의 파일을 작성해야 합니다. 즉, 애플리케이션이 스토리지를 요청하기 전에 먼저 관리자가 다음과 같은 과정을 거칩니다.

1. 서버나 클라우드에서 실제 디스크를 생성
2. 그 디스크를 기반으로 하는 PV YAML 파일을 직접 작성
3. 쿠버네티스에 kubectl apply -f pv.yaml 로 등록

이렇게 만들어진 PV를 개발자가 PVC에서 요청하면, 쿠버네티스는 해당 PV를 연결해줍니다.

하지만 문제는 매번 수동으로 만들어야 한다는 점입니다. 새로운 애플리케이션이 생길 때마다 디스크를 만들고 PV를 작성해야 하니, 자동화나 확장성 측면에서는 한계가 있습니다.

 

동적 프로비저닝

“매번 디스크를 수동으로 만들지 않아도 된다면 얼마나 편할까?” 이 질문에 대한 답이 바로 동적 프로비저닝입니다. 동적 프로비저닝은 스토리지 클래스(StorageClass) 를 활용합니다. StorageClass는 쿠버네티스에게 “필요할 때 스토리지를 어떻게 만들어야 하는지”를 알려주는 역할을 합니다.

예를 들어, Google Cloud Storage, AWS EBS, NFS, 또는 로컬 디스크용 CSI 드라이버 등을 프로비저너로 지정할 수 있습니다.

그렇게 정의해두면, 애플리케이션이 PVC를 생성할 때 쿠버네티스가 자동으로:

1. 지정된 프로비저너(StorageClass)를 참조해 스토리지를 생성하고
2. 해당 스토리지를 Pod에 자동으로 연결합니다.

이 방식이 바로 동적 프로비저닝(Dynamic Provisioning) 입니다.

 

로컬 스토리지용 StorageClass 예시 

이 설정은 로컬 스토리지(Local Storage) 를 사용하기 위한 설정이며, 동적으로 프로비저닝하지 않고, Pod이 실제로 스케줄링된 노드에서 직접 스토리지를 연결하도록 하는 방식이에요.자동으로 PV를 생성하지 않기 때문에, 관리자가 직접 로컬 디렉터리를 지정하고 PV를 정의해야 합니다. 이 방식은 클라우드 스토리지를 사용하지 않는 환경이나, 각 노드의 물리 디스크를 그대로 활용해야 하는 환경에서 자주 사용됩니다.

 

워크플로우는 다음과 같아요.

1. StorageClass(local-storage)를 생성
2. PV 수동 생성
3. PVC 생성 (storageClassName: local-storage)
4. Pod 생성 시 PVC가 PV에 바인딩됨
5. Pod이 배포된 노드의 실제 디스크 경로가 연결

1. StorageClass(local-storage)를 생성

다음은 쿠버네티스의 StorageClass 리소스를 정의한 YAML입니다. 

# sc.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: local-storage
provisioner: kubernetes.io/no-provisioner
volumeBindingMode: WaitForFirstConsumer

• provisioner: kubernetes.io/no-provisioner

보통 StorageClass는 동적 프로비저너(Dynamic Provisioner) 가 있어 PVC를 만들면 자동으로 PV를 생성합니다. 하지만 kubernetes.io/no-provisioner를 지정하면 자동 생성 안 함, 즉 수동(static) 으로 PV를 만들어야 합니다. 이건 로컬 디스크나 특정 경로를 직접 지정해야 하는 경우 (예: /mnt/data)에 사용합니다.

 

• volumeBindingMode: WaitForFirstConsumer

이 설정은 PV가 언제 노드에 바인딩될지를 결정합니다. 기본값(Immediate)이면 PVC를 생성하자마자 PV가 바인딩됩니다. WaitForFirstConsumer이면 Pod이 실제로 생성되어 스케줄링될 때까지 PV 바인딩을 지연시킵니다.

이게 중요한 이유는 로컬 볼륨(local storage) 의 특성 때문인데요, 로컬 볼륨은 특정 노드에만 존재하므로, Pod이 어느 노드에 배치될지 결정된 다음에야 올바른 PV를 연결할 수 있습니다.

 

2. 관리자가 수동으로 PV를 생성

apiVersion: v1
kind: PersistentVolume
metadata:
  name: kafka-pv-volume
  labels:
    type: local
spec:
  storageClassName: local-storage
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: kafka-pv-volume-2
  labels:
    type: local
spec:
  storageClassName: local-storage
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: kafka-pv-volume-3
  labels:
    type: local
spec:
  storageClassName: local-storage
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteOnce
  hostPath:
    path: "/mnt/data"

 

# List all StorageClasses
kubectl get storageclass
# or shorthand
kubectl get sc

# List all PersistentVolumes
kubectl get pv
# To see more detail:
kubectl describe pv <pv-name>

# List all PersistentVolumeClaims (PVCs)
kubectl get pvc