98. K8s 스토리지 관리 - Volume, PV, PVC

⚠️ 이 문서는 컨테이너(Pod)가 죽고 새로 태어날 때마다 내부의 데이터(DB 회원 정보 등)가 흔적도 없이 리셋되어 날아가 버리는 치명적인 휘발성(Ephemeral)의 저주를 막기 위해, **파드의 목숨(생명주기)과 완전히 분리되어 영원히 죽지 않는 외부 하드디스크(영구 스토리지)를 클러스터에 깎아내고(PV) 파드에 연결(PVC)하는 쿠버네티스의 '스토리지 가상화 분리 아키텍처'**를 다룹니다.

핵심 인사이트 (3줄 요약)

  1. 본질: 쿠버네티스의 파드는 뇌(연산)만 있을 뿐 기억(저장) 능력이 없는 금붕어다. 파드가 죽더라도 데이터가 날아가지 않게 하려면, 파드 바깥쪽에 단단한 철제 금고(스토리지 볼륨)를 따로 세워두고 파드의 배꼽에 호스로 연결(Mount)해 주어야 한다.
  2. 가치: 개발자가 AWS 콘솔에 들어가서 SSD를 10GB짜리 자르고 포맷하는 인프라 뻘짓을 완전히 소멸시켰다. 쿠버네티스에서 관리자가 거대한 디스크 덩어리(PV)를 미리 사두면, 개발자는 그저 "나 10GB짜리 디스크 당장 줘!"라는 요청서(PVC)만 쓱 날려서 즉시 디스크를 자동 발급(할당)받아 쓸 수 있는 완벽한 업무 분업 시스템이다.
  3. 기술 체계: 파드와 함께 죽고 사는 가장 단순한 임시 호주머니 Volume(emptyDir 등), 클러스터 레벨에서 영구적으로 보존되는 쇳덩어리 디스크 PV (Persistent Volume), 그리고 개발자가 그 디스크의 일부를 요구하는 대출 신청서 **PVC (Persistent Volume Claim)**라는 3단계 추상화로 굴러간다.

Ⅰ. 컨테이너의 기억 상실과 기본 Volume의 한계

도커는 기본적으로 재부팅하면 백지상태가 된다.

  1. 상태 없음(Stateless)의 재앙:
    • Nginx 같은 웹 서버 파드는 죽었다가 다시 켜져도 상관없다 (화면만 뿌려주면 되니까).
    • 하지만 MySQL DB 파드가 죽었는데 안에 있던 고객 1만 명의 결제 데이터가 날아가 버리면 회사가 파산한다. 파드 내부에 있는 기본 하드디스크 공간은 파드와 생사고락을 같이하는 '휘발성 램 디스크'에 불과하다.
  2. 기본 Volume (emptyDir / hostPath):
    • emptyDir: 쿠버네티스가 파드를 띄울 때 빈 박스를 하나 같이 띄워 파드에 붙여준다(Mount). 파드 안의 컨테이너 두 개가 서로 파일을 주고받을 때 임시로 쓴다. 치명적인 건, 파드가 삭제되는 순간 이 빈 박스도 폭파되어 데이터가 100% 날아간다.
    • hostPath: 파드가 떠 있는 '물리적 서버(Node 1번)'의 진짜 하드디스크 C드라이브 폴더 하나를 뚫어서 파드에 연결해 준다. 파드가 죽었다가 1번 노드에 다시 켜지면 데이터가 살아있지만, 만약 노드 1번 기계가 고장 나서 파드가 노드 2번으로 이사가서 켜지면? 1번 노드에 놔두고 온 데이터를 읽지 못해 역시 깡통이 된다.

📢 섹션 요약 비유: 파드(Pod)는 모텔 방을 빌린 나그네와 같습니다. 방 안의 냉장고(기본 Volume: emptyDir)에 음식을 가득 채워놨는데, 방을 빼는(파드 삭제) 순간 모텔 주인이 냉장고 안의 음식을 싹 다 쓰레기통에 버려 리셋시켜 버립니다. 나그네가 다시 모텔에 체크인해도 음식은 영영 돌아오지 않는 끔찍한 단기 숙박 시스템의 한계입니다.

Ⅱ. 생명 주기의 분리: PV와 PVC의 완벽한 이분법

파드가 죽든 말든 데이터는 절대 죽지 않는 영생의 땅을 파라.

  1. PV (Persistent Volume, 영구 볼륨 - '공급자'의 몫):
    • 클러스터 관리자(Infra Admin)가 나선다. AWS나 GCP의 비싼 네트워크 하드디스크(EBS, NFS 등) 100GB짜리 10개를 뭉텅이로 100만 원 주고 결제해서 쿠버네티스 클러스터 바닥에 깔아둔다.
    • 이 쇳덩어리들 하나하나가 PV다. 이것들은 파드가 죽든 노드가 박살 나든 허공에 영원히 존재(Persistent)하는 불멸의 존재다.
  2. PVC (Persistent Volume Claim, 볼륨 요청서 - '소비자'의 몫):
    • 앱을 짜던 일반 개발자(Dev)가 DB를 돌리기 위해 "10GB짜리 빠릿빠릿한 SSD 디스크 1개 필요함" 이라는 **요구사항 텍스트 문서(PVC)**를 작성해 K8s에 툭 던진다.
    • 개발자는 AWS 로그인 권한도 없고 진짜 스토리지 이름도 모른다. 그냥 "10GB 줘"라고 서류(Claim)만 제출할 뿐이다.
  3. 바인딩 (Binding / 중매쟁이 결합):
    • 쿠버네티스 컨트롤러가 개발자가 던진 대출 서류(PVC)를 읽고, 관리자가 바닥에 깔아둔 거대 디스크 더미(PV들) 중에서 10GB 조건을 만족하는 남는 쇳덩어리(PV) 하나를 잽싸게 찾아서 둘을 찰칵! 하고 영구적으로 엮어버린다(Bind).
    • 이제 개발자는 파드 yaml 파일에 자기가 던졌던 대출 서류 이름(PVC)만 적어주면, 쿠버네티스가 알아서 그 뒤에 묶여있는 진짜 쇳덩어리(PV)를 파드 배꼽에 호스로 연결(Mount)해 준다. 파드가 죽었다가 노드 2번에서 켜져도, 이 호스는 노드 2번으로 졸졸 따라가서 꽂히므로 데이터는 100% 무결하게 보존된다.

📢 섹션 요약 비유: PV는 건물주(인프라 관리자)가 강남에 지어둔 100평, 50평짜리 텅 빈 튼튼한 '상가용 콘크리트 창고'들입니다. PVC는 세입자(개발자)가 구청에 낸 "나 치킨집 할 건데 10평짜리 빈 창고 하나 빌려주쇼"라는 '임대 신청서'입니다. 구청장(쿠버네티스)이 신청서(PVC)를 보고 비어있는 10평짜리 창고(PV) 열쇠를 세입자에게 찰칵 던져주면(Binding), 세입자는 장사하다가 망해서 가게 간판(Pod)을 뗐다 다시 붙여도 창고 안의 냉장고와 튀김기(데이터)는 안전하게 철문 속에 영원히 보존되는 철통같은 부동산 임대 시스템입니다.

Ⅲ. 클라우드의 마법: 동적 프로비저닝 (Dynamic Provisioning)

관리자가 쇳덩어리를 미리 사서 깔아둘 필요조차 없어졌다.

  1. 정적 프로비저닝(Static)의 귀찮음:
    • 위의 방식은 관리자가 10GB, 20GB짜리 PV 100개를 노가다로 미리 만들어놔야 한다. 만약 개발자가 15GB(PVC)를 달라고 했는데 만들어둔 PV 묶음 중에 딱 맞는 사이즈가 없으면 대출 거절(Pending)이 나버린다.
  2. 동적 프로비저닝 (Dynamic Provisioning)과 StorageClass:
    • 클라우드 시대의 미친 자동화가 도입되었다. 관리자는 PV를 미리 사두지 않는다. 대신 **StorageClass(스토리지 클래스)**라는 자판기 하나만 클러스터에 달아둔다. (예: "버튼을 누르면 AWS SSD가 무한으로 생성되는 자판기")
    • 개발자가 "10GB짜리 디스크 당장 내놔(PVC)!"라고 서류를 던지면, 쿠버네티스가 즉시 자판기(StorageClass) 버튼을 누른다.
    • 자판기는 AWS 클라우드 API를 직접 찔러서, 허공에서 10GB짜리 SSD 디스크(PV)를 0.1초 만에 뚝딱 찍어내고 즉시 개발자 서류(PVC)에 묶어버린다. 인프라 관리자의 개입(노가다)이 0%로 소멸하는 인프라 자동화(IaC)의 극의다.

📢 섹션 요약 비유: 옛날엔 동사무소 창고 관리자(인프라 팀)가 10리터, 20리터짜리 파란색 물통(PV)을 미리 100개 사다 놓고 시민(개발자)이 신청서(PVC)를 내면 맞는 걸 찾아 꺼내 줬습니다(정적 할당). 지금은 창고에 3D 프린터 자판기(StorageClass) 딱 한 대만 놔뒀습니다. 시민이 "저 13리터 물통이요!"라고 동전(PVC)을 넣는 그 찰나의 순간, 자판기(AWS 클라우드)가 위잉 치익 소리를 내며 세상에 없던 13리터짜리 물통을 1초 만에 플라스틱으로 찍어내어(동적 프로비저닝) 시민 손에 쥐여주는 미친 4차 산업혁명의 물류 공장입니다.