2. Volume - Dynamic Provisioning, StorageClass, Status, ReclaimPolicy

이번엔 단순한 볼륨 연결을 넘어, 인프라 관리를 자동화하는 다이나믹 프로비저닝(Dynamic Provisioning)과 볼륨의 생명주기(Lifecycle)를 다루는 아주 중요한 내용이다.

 

 

---

 

 

0. 볼륨의 기초와 다이나믹 프로비저닝 (Dynamic Provisioning)

볼륨은 데이터를 안정적으로 유지하기 위해 클러스터와 분리되어 관리된다. 관리자가 미리 공간을 확보하는 수동 방식의 번거로움을 해결하기 위해 다이나믹 프로비저닝이 등장했다.

 

1) 볼륨의 종류와 접근 모드

• 외부망(Cloud): AWS, GCP, Azure와 같은 클라우드 스토리지를 클러스터와 연결한다.
• 내부망(Internal): 노드의 물리 공간을 쓰는 hostPath, Local 볼륨과 StorageOS, Ceph, NFS 같은 온프레미스 솔루션이 있다.
• Access Modes (액세스 모드)
  • RWO (ReadWriteOnce): 한 노드에서만 읽기/쓰기 가능.
  • ROX (ReadOnlyMany): 여러 노드에서 읽기만 가능.
  • RWX (ReadWriteMany): 여러 노드에서 읽기/쓰기 가능.
  볼륨 종류에 따라 지원되는 모드가 다르기도 하니 확인이 필수다.

 

2) 다이나믹 프로비저닝과 StorageClass

• 개념:사용자가 PVC를 만들면 쿠버네티스가 알아서 적절한 PV를 생성하고 실제 볼륨을 연결해 주는 기능이다.
• StorageClass (스토리지 클래스): 동적 생성을 지원하는 핵심 오브젝트다.
  • PVC 생성 시 storageClassName을 지정하면 해당 정책에 따라 자동으로 PV가 만들어진다.
  • Default 설정: 특정 클래스를 기본값(Default)으로 설정해 두면, PVC에서 이름을 생략해도 자동으로 해당 볼륨이 생성된다.
    1. ""는 기초를 배울 때 했었던거다.
       • 파드가 생성되어 어느 노드에 배치될지 결정되는 순간에 해당 노드에 실제 볼륨 폴더가 만들어진다.
    2.    는 완전 공백(=안적음)이기 때문에 이게 default가 적용되는 것이다.

 

 

 

2. 볼륨의 상태(Status)와 회수 정책(Reclaim Policy)

모든 PV는 파드처럼 현재의 연결 및 작동 상태를 나타내는 상태 값이 있으며, 연결이 끊겼을 때의 처리 방식을 정책으로 결정한다.

 

1) PV의 상태 변화 (Status)

1. Available (사용 가능): PV가 생성되어 PVC의 연결을 기다리는 초기 상태.
2. Bound (연결됨): PVC와 성공적으로 연결된 상태.
   • 실제 볼륨 데이터는 파드가 PVC를 사용해 구동될 때 생성된다.
3. Released (연결 해제): PVC가 삭제되어 연결이 끊긴 상태.
4. Failed (실패): 볼륨과의 연결에 문제가 생긴 상태.

2) 회수 정책 (Reclaim Policy)

PVC가 삭제되었을 때, 남겨진 PV와 데이터를 어떻게 처리할지 결정하는 규칙이다.

• Retain (보존): PVC 삭제 후 PV 상태가 Released로 변하며 실제 데이터는 유지된다.
  • 다만, 다른 PVC가 이 PV를 재사용할 수는 없으므로 수동으로 삭제하거나 정리해야 한다. (수동 PV 생성 시 기본값)
• Delete (삭제): PVC 삭제 시 PV도 같이 삭제된다.
  • 스토리지 종류에 따라 실제 데이터까지 삭제될 수 있다. (다이나믹 프로비저닝 시 기본값)
• Recycle (재사용): 실제 데이터를 삭제하고 PV 상태를 Available로 되돌려 다시 사용할 수 있게 한다.
  • 현재는 중단(Deprecated)된 정책이다.

 

 

💡꼬리 질문

Q: 만약 중요한 DB 데이터를 담은 볼륨의 Reclaim Policy가 Delete로 설정된 상태에서 실수로 PVC를 삭제했다면, 데이터를 복구할 방법이 있을까? 실무에서는 이런 대참사를 막기 위해 어떤 설정을 권장할까?

 

 

 

결론: 정책이 Delete라면 클러스터 수준에서의 복구는 매우 어렵다.

1. 복구 가능성: Delete 정책은 클라우드나 스토리지 솔루션에 삭제 명령을 즉시 날리기 때문에, 스토리지 자체의 '스냅샷' 기능이 없다면 복구가 불가능하다.
2. 권장 설정: 중요한 데이터가 담긴 볼륨이라면 Reclaim Policy를 반드시 Retain으로 설정해야 한다.
3. 관리 포인트: Retain 설정 시 데이터는 안전하지만, PV가 Released 상태로 남아 자원을 점유하므로 관리자가 주기적으로 확인하여 불필요한 PV를 직접 정리해 주는 운영 프로세스가 필요하다.

 

---

 

 

이론을 배웠으니 이제 실제 터미널에서 볼륨이 어떻게 태어나고 죽는지 눈으로 확인할 차례다. 실습은 Longhorn(롱혼)이라는 스토리지 솔루션을 사용해 다이나믹 프로비저닝의 편리함과 리클레임 정책을 알아보자.

 

인프런_대세는 쿠버네티스

 

 

1. 다이나믹 프로비저닝 실습: "PV를 직접 만들 것인가, 맡길 것인가"

사용자가 PVC만 던졌을 때 PV가 자동으로 생겨나는 마법을 확인한다.

 

1) 수동 방식 (storageClassName: "")

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-hostpath1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: ""

• 동작: 관리자가 미리 만든 hostPath PV와 연결된다.
• 특이점: PVC를 만드는 순간에는 실제 디렉토리가 노드에 생기지 않는다. 파드가 생성되어 어느 노드에 배치될지 결정되는 순간에 해당 노드에 실제 볼륨 폴더가 만들어진다.

2) 자동 방식 (storageClassName: "fast")

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-fast1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1G
  storageClassName: "fast"

• 동작: PVC를 생성하자마자 Longhorn이 즉시 적절한 용량의 PV를 찍어내고 실제 볼륨을 할당한다.

3) 기본값 방식 (생략)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-default1
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 2G

• 동작: 스토리지 클래스 이름을 적지 않아도 클러스터에 설정된 default 스토리지 클래스가 자동으로 적용되어 볼륨이 생성된다.

 

 

4. 상태(Status)와 회수 정책(Reclaim Policy) 실습

PVC를 지웠을 때 남겨진 데이터가 어떻게 처리되는지 확인하는 단계다.

• Status 변화: Available(최초) → Bound(연결됨) → Released(PVC 삭제 시) 순으로 변하는 것을 관찰한다.
• Retain (보존) 정책
  • 수동으로 만든 PV의 기본값이다.
  • PVC를 지워도 PV 상태는 Released로 남고 실제 데이터(file.txt)도 노드에 그대로 보존된다. 하지만 이 PV를 다른 PVC가 재사용할 수는 없으므로 엔지니어가 수동으로 청소해줘야 한다.
• Delete (삭제) 정책
  • 스토리지 클래스로 만든 PV의 기본값이다.
  • PVC를 삭제하는 즉시 PV와 Longhorn의 실제 볼륨 데이터가 함께 증발한다.

 

 

 

💡 꼬리 질문

Q: 만약 Retain 정책으로 남겨진 Released 상태의 PV를 다시 사용 가능한 Available 상태로 되돌려 다른 PVC에 연결하려면, YAML 파일의 어떤 부분을 수동으로 수정해야 할까?

 

 

결론: PV 설정 내의 spec.claimRef 항목을 완전히 삭제해야 한다.

1. 원인: Released 상태라는 것은 이 PV가 이전에 어떤 PVC(claimRef)와 연결되었는지를 기억하고 있다는 뜻이다.
2. 해결: kubectl edit pv <이름>으로 들어가서 claimRef 섹션 전체를 지워주면, 쿠버네티스는 이 PV를 '임자 없는' 상태로 인식하여 다시 Available로 변경한다.
3. 주의: 데이터를 그대로 둔 채 재사용하는 것이므로 보안상 주의가 필요하며, 실무에서는 이 과정을 자동화해주는 Recycle 정책이 있었으나 현재는 보안 이슈로 사용을 권장하지 않는다.

 

 

 

위 학습용 정리 내용 및 사진 자료는 "인프런_대세는 쿠버네티스(https://inf.run/Lv5RV)" 강의를 소스로 작성하였습니다