🏗️ [쿠버네티스] 파드에 디스크를 직접 연결하면 안 되는 이유 (PV, PVC, SC의 필요성)

안녕하세요! 오늘은 쿠버네티스 스토리지의 "꽃"이라고 할 수 있는 PV(PersistentVolume), PVC(PersistentVolumeClaim), SC(StorageClass)가 도대체 왜 필요한지에 대해 깊이 파보려고 합니다.

처음 쿠버네티스를 공부하다 보면 이런 의문이 듭니다.

"그냥 파드 설정 파일(YAML)에 AWS EBS ID나 NFS 경로를 바로 적으면 편하지 않나?
왜 굳이 복잡하게 PV, PVC를 따로 만들어서 연결해야 하지?"

 

 

결론부터 말씀드리면, "직접 연결은 편해 보이지만, 지옥으로 가는 지름길"이기 때문입니다. 왜 그런지, 그리고 PV/PVC 시스템이 어떻게 우리를 구원해 주는지 4가지 핵심 이유로 정리해 드립니다. 🚀

 

---

1. ☁️ 이식성(Portability)의 파괴: "내 파드는 AWS에서만 살 수 있어!"

만약 파드(Pod) YAML 파일에 특정 클라우드의 볼륨 ID를 직접 적었다고 가정해 봅시다.

YAML

# ❌ 나쁜 예시 (직접 연결)
volumes:
  - name: my-data
    awsElasticBlockStore: # AWS에 종속됨!
      volumeID: <vol-0a1b2c...>
      fsType: ext4

이 방식의 가장 큰 문제는 종속성(Lock-in)입니다.

• 문제점: 이 파드는 AWS 환경에서만 동작합니다. 만약 회사가 Google Cloud(GCP)로 이사를 가거나, 온프레미스(IDC) 환경으로 옮겨야 한다면? 이 YAML 파일은 쓰레기가 됩니다. 일일이 다 수정해야 하죠.
• 해결책 (PVC): PVC를 사용하면 개발자는 *"나는 10GB 용량이 필요해"*라고 추상적인 요청만 합니다. 그 뒤에 실제 스토리지가 AWS인지, Azure인지, 로컬 디스크인지는 신경 쓰지 않아도 됩니다.

2. 👨‍💻 역할의 분리 (DevOps 철학): "개발자는 인프라를 몰라도 된다"

쿠버네티스는 개발자(Developer)와 운영자(Admin/Ops)의 역할을 명확히 나누는 것을 지향합니다.

• 직접 연결 시: 개발자가 파드를 띄우려면 스토리지 서버의 IP 주소, 디스크 ID, 파일 시스템 타입 등을 상세히 알아야 합니다. 개발자가 인프라의 복잡한 세부 사항까지 공부해야 하는 부담이 생깁니다.
• PV/PVC 사용 시:
  • 운영자(Admin): 스토리지 인프라를 구축하고 PV(자원) 또는 SC(스토리지 클래스)를 세팅해 둡니다.
  • 개발자(User): 인프라 내용을 몰라도 PVC(요청서)만 작성하면 됩니다. "운영자님, 저 빠른 디스크 50기가만 주세요!" 라고 티켓을 끊는 것과 같습니다.

3. ⚡ 동적 프로비저닝 (Dynamic Provisioning)의 마법

가장 강력한 이유 중 하나는 바로 StorageClass(SC) 덕분에 가능한 '자동화'입니다.

• 직접 연결/수동 관리: 파드가 100개 필요하다면, 운영자가 클라우드 콘솔에 들어가서 디스크 100개를 일일이 클릭해서 만들고 ID를 따와야 합니다. 끔찍하죠? 😱
• SC 사용 시: StorageClass를 정의해 두면, 개발자가 PVC를 만드는 순간 쿠버네티스가 알아서 클라우드에 명령을 내려 디스크를 생성하고 파드에 연결해 줍니다.

이 과정이 단 몇 초 만에 자동으로 이루어집니다.

4. 🛡️ 리소스 관리와 보안

스토리지는 비싼 자원입니다. 아무나 막 쓰게 두면 안 되겠죠?

• 직접 연결 시: 개발자가 임의로 매우 비싼 고성능 디스크를 연결해 버리거나, 회사 정책에 맞지 않는 설정을 할 위험이 있습니다.
• PV/PVC 패턴: 운영자는 StorageClass를 통해 생성 가능한 디스크의 종류를 제한하거나, ResourceQuota를 통해 특정 팀이 사용할 수 있는 스토리지 총량을 제어할 수 있습니다. 체계적인 자원 관리가 가능해집니다.

---

📝 요약: PV, PVC, SC 관계도

이해를 돕기 위해 식당에 비유해 보겠습니다. 🍽️

쿠버네티스 개념	비유 (식당)	설명
Pod	손님	밥(데이터 공간)을 먹고 싶은 주체
PVC (Claim)	주문서	"여기 공깃밥(10GB) 하나 주세요!" (요청)
StorageClass	주방장/메뉴얼	주문이 들어오면 밥을 짓는 방법과 정책
PV (Volume)	실제 밥공기	실제 준비된 밥 (준비된 스토리지 자원)
실제 디스크	쌀	밥을 만드는 원재료 (AWS EBS, NFS 등)

1. 손님(Pod)이 주문서(PVC)를 냅니다.
2. 주방장(StorageClass)이 주문을 보고 쌀(실제 디스크)로 밥(PV)을 짓습니다. (동적 프로비저닝)
3. 준비된 밥(PV)이 주문서(PVC)와 매칭(Binding)되어 손님에게 나갑니다.

---

💡 결론

파드에 디스크를 직접 연결하는 것은 혼자서 텐트를 칠 때 못을 하나하나 다 박는 것과 같습니다. 반면 PV, PVC, SC를 사용하는 것은 "호텔 체크인"과 같습니다.

우리는 그저 *"방 하나 주세요(PVC)"*라고 말하면, 호텔 시스템(K8s)이 알아서 *"여기 키 있습니다(PV 바인딩)"*라고 처리해 주는 것이죠.

쿠버네티스를 운영 환경에서 제대로 쓰려면, 이 추상화 계층(Abstraction Layer)을 반드시 이해하고 사용해야 합니다! 😊

---