Volume과 영구 스토리지 완벽 가이드

Kubernetes에서 데이터를 영구적으로 저장하는 방법을 알아봅니다. 컨테이너가 사라져도 데이터는 안전하게 보관하는 Volume의 세계로 안내합니다.

---

목차

1. Volume_종류_이해
2. emptyDir과_hostPath
3. PersistentVolume_개념
4. PersistentVolumeClaim_사용
5. 액세스_모드와_리클레임_정책
6. 볼륨_스냅샷

---

1. Volume 종류 이해

어느 날 김개발 씨는 운영 중인 서비스에서 이상한 현상을 발견했습니다. 분명히 사용자가 업로드한 파일이 있었는데, Pod가 재시작되자 모든 파일이 사라져버린 것입니다.

"컨테이너는 휘발성이라서 그래요"라는 선배의 말에 김개발 씨는 Volume이라는 개념을 처음 알게 되었습니다.

Volume은 컨테이너의 수명과 독립적으로 데이터를 저장하는 공간입니다. 마치 컴퓨터 본체가 꺼져도 외장 하드에 저장된 데이터는 사라지지 않는 것과 같습니다.

Kubernetes는 다양한 상황에 맞는 여러 종류의 Volume을 제공하며, 각각의 특성을 이해하면 적재적소에 활용할 수 있습니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: volume-demo
spec:
  containers:
  - name: app
    image: nginx
    # Volume을 컨테이너 내부 경로에 마운트합니다
    volumeMounts:
    - name: data-volume
      mountPath: /usr/share/nginx/html
  # Pod 레벨에서 Volume을 정의합니다
  volumes:
  - name: data-volume
    emptyDir: {}

김개발 씨는 입사 6개월 차 DevOps 엔지니어입니다. 최근 회사에서 Kubernetes로 서비스를 이전하는 프로젝트를 맡게 되었습니다.

모든 것이 순조로워 보였지만, 어느 날 큰 문제가 발생했습니다. "개발팀에서 업로드한 이미지가 전부 사라졌어요!" 운영팀의 긴급 연락이었습니다.

확인해보니 Pod가 재시작되면서 컨테이너 내부에 저장된 모든 파일이 증발해버린 것입니다. 선배 개발자 박시니어 씨가 상황을 파악하고 말했습니다.

"컨테이너는 기본적으로 휘발성이에요. 종료되면 내부 데이터도 함께 사라지죠.

이럴 때 Volume을 사용해야 해요." 그렇다면 Volume이란 정확히 무엇일까요? 쉽게 비유하자면, Volume은 마치 이사할 때 가져가는 이삿짐 박스와 같습니다.

집(컨테이너)을 옮기더라도 박스(Volume) 안에 담긴 물건(데이터)은 그대로 유지됩니다. 새 집에 도착하면 박스를 풀어서 물건을 꺼내면 되는 것처럼, 새 컨테이너에 Volume을 마운트하면 기존 데이터를 그대로 사용할 수 있습니다.

Kubernetes에서 제공하는 Volume 종류는 크게 세 가지로 나눌 수 있습니다. 첫 번째는 임시 Volume입니다.

emptyDir이 대표적인 예로, Pod가 살아있는 동안만 데이터를 유지합니다. 같은 Pod 내 여러 컨테이너가 데이터를 공유할 때 유용합니다.

두 번째는 노드 기반 Volume입니다. hostPath는 노드의 파일시스템을 직접 마운트합니다.

특정 노드에 종속되므로 Pod가 다른 노드로 이동하면 데이터에 접근할 수 없다는 단점이 있습니다. 세 번째는 영구 Volume입니다.

PersistentVolume은 클러스터 레벨에서 관리되며, 클라우드 스토리지나 네트워크 스토리지와 연결됩니다. Pod가 어느 노드에서 실행되든 동일한 데이터에 접근할 수 있습니다.

위의 코드를 살펴보면, volumes 섹션에서 Volume을 정의하고, volumeMounts 섹션에서 컨테이너의 어느 경로에 마운트할지 지정합니다. 이렇게 두 단계로 나뉘는 이유는 하나의 Volume을 여러 컨테이너에서 공유할 수 있도록 하기 위함입니다.

실제 현업에서는 어떤 Volume을 선택할지가 중요합니다. 임시 캐시 데이터는 emptyDir로 충분하고, 로그 수집처럼 노드에 종속되어도 괜찮은 경우는 hostPath를 사용합니다.

하지만 사용자 데이터나 데이터베이스처럼 절대 손실되면 안 되는 데이터는 반드시 PersistentVolume을 사용해야 합니다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"그래서 사용자 업로드 파일이 사라졌던 거군요. PersistentVolume을 적용해야겠어요!"

실전 팁

💡 - Volume 선택 시 데이터의 중요도와 지속성 요구사항을 먼저 파악하세요

• 같은 Pod 내 컨테이너 간 데이터 공유는 emptyDir로 충분합니다
• 운영 환경에서는 대부분 PersistentVolume을 사용하는 것이 안전합니다

---

2. emptyDir과 hostPath

김개발 씨는 Volume의 기본 개념을 이해한 후, 가장 먼저 접하게 되는 두 가지 Volume 타입에 대해 공부하기 시작했습니다. 팀에서 진행 중인 로그 수집 시스템 구축 프로젝트에서 emptyDir과 hostPath를 어떻게 활용할지 고민이 필요했기 때문입니다.

emptyDir은 Pod가 생성될 때 빈 디렉토리로 시작하여 Pod가 삭제될 때 함께 사라지는 임시 저장 공간입니다. hostPath는 노드의 파일시스템을 직접 Pod에 마운트하는 방식입니다.

두 가지 모두 간단하게 사용할 수 있지만, 각각의 한계를 명확히 이해해야 합니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: Pod
metadata:
  name: sidecar-logging
spec:
  containers:
  # 메인 애플리케이션 컨테이너
  - name: app
    image: myapp:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /var/log/app
  # 로그 수집 사이드카 컨테이너
  - name: log-collector
    image: fluentd:latest
    volumeMounts:
    - name: shared-logs
      mountPath: /logs
      readOnly: true
  volumes:
  # emptyDir: Pod 내 컨테이너 간 공유
  - name: shared-logs
    emptyDir:
      sizeLimit: 500Mi

김개발 씨의 팀에서는 마이크로서비스 아키텍처를 도입하면서 각 서비스의 로그를 중앙에서 수집하는 시스템을 구축하고 있었습니다. 박시니어 씨가 제안한 방식은 사이드카 패턴이었습니다.

"메인 애플리케이션은 로그를 파일로 남기고, 옆에 붙은 로그 수집 컨테이너가 그 파일을 읽어서 중앙 서버로 보내는 거예요." 박시니어 씨의 설명이었습니다. "이때 두 컨테이너가 같은 디렉토리를 봐야 하는데, 그게 바로 emptyDir이에요." emptyDir은 말 그대로 빈 디렉토리에서 시작합니다.

Pod가 노드에 스케줄링되는 순간 생성되고, Pod가 삭제되면 함께 사라집니다. 마치 회의실에 비치된 화이트보드와 같습니다.

회의 참석자들은 화이트보드를 함께 사용할 수 있지만, 회의가 끝나면 내용은 지워집니다. emptyDir의 핵심 사용 사례는 컨테이너 간 데이터 공유입니다.

위 코드에서 app 컨테이너는 /var/log/app 경로에 로그를 쓰고, log-collector 컨테이너는 같은 Volume을 /logs 경로로 읽기 전용 마운트하여 로그를 수집합니다. sizeLimit 옵션을 사용하면 Volume이 사용할 수 있는 최대 용량을 제한할 수 있습니다.

로그가 무한정 쌓여서 노드의 디스크를 가득 채우는 사고를 예방할 수 있습니다. 반면 hostPath는 조금 다른 상황에서 사용됩니다.

"노드 레벨의 모니터링 에이전트를 배포할 때 hostPath가 필요해요." 박시니어 씨가 설명을 이어갔습니다. hostPath는 노드의 실제 파일시스템을 Pod에 노출시킵니다.

예를 들어 노드의 Docker 소켓(/var/run/docker.sock)에 접근하거나, 노드의 시스템 로그(/var/log)를 읽어야 할 때 사용합니다. 하지만 박시니어 씨는 경고를 덧붙였습니다.

"hostPath는 정말 필요한 경우가 아니면 쓰지 마세요. 보안 위험이 큽니다." hostPath를 사용하면 컨테이너가 노드의 파일시스템에 직접 접근할 수 있기 때문에, 악의적인 컨테이너가 시스템 파일을 조작할 수 있습니다.

또한 Pod가 다른 노드로 이동하면 이전 노드의 데이터에는 접근할 수 없다는 문제도 있습니다. 김개발 씨는 정리해보았습니다.

emptyDir은 Pod 수명 동안 컨테이너 간 데이터를 공유할 때, hostPath는 노드 시스템에 접근해야 하는 특수한 경우에만 사용하는 것이 좋겠습니다.

실전 팁

💡 - emptyDir에 medium: Memory 옵션을 주면 tmpfs(메모리 기반)로 사용할 수 있어 더 빠릅니다

• hostPath 사용 시 type 필드로 디렉토리인지 파일인지 명시하면 안전합니다
• 프로덕션 환경에서는 hostPath 대신 PersistentVolume을 권장합니다

---

3. PersistentVolume 개념

로그 수집 시스템 구축을 마친 김개발 씨에게 새로운 과제가 주어졌습니다. "이번엔 PostgreSQL 데이터베이스를 Kubernetes로 이전해야 해요." 팀장의 요청이었습니다.

데이터베이스는 절대 데이터 손실이 있어서는 안 됩니다. 이제 영구 스토리지의 세계로 들어갈 시간입니다.

**PersistentVolume(PV)**은 클러스터 관리자가 프로비저닝한 스토리지 리소스입니다. Pod의 수명과 완전히 독립적이며, 클러스터 레벨에서 관리됩니다.

마치 데이터센터에 있는 스토리지 장비처럼, Pod가 사라지고 새로 생겨도 데이터는 그대로 유지됩니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: postgres-pv
spec:
  # 스토리지 용량 정의
  capacity:
    storage: 10Gi
  # 접근 모드: 단일 노드에서 읽기/쓰기
  accessModes:
    - ReadWriteOnce
  # 볼륨 해제 시 정책: 데이터 유지
  persistentVolumeReclaimPolicy: Retain
  # 스토리지 클래스 지정
  storageClassName: standard
  # AWS EBS 볼륨 연결
  awsElasticBlockStore:
    volumeID: vol-0a1b2c3d4e5f6g7h8
    fsType: ext4

데이터베이스 이전 프로젝트를 시작하기 전, 박시니어 씨가 김개발 씨를 불러 중요한 개념을 설명해주었습니다. "emptyDir이나 hostPath로는 데이터베이스를 운영할 수 없어요.

Pod가 죽으면 모든 데이터가 사라지거나, 특정 노드에 묶여버리니까요." 박시니어 씨의 말이었습니다. "이럴 때 필요한 게 PersistentVolume이에요." PersistentVolume은 마치 회사의 공용 파일 서버와 같습니다.

직원 개인 컴퓨터가 고장나거나 교체되어도 파일 서버의 데이터는 영향받지 않습니다. 새 컴퓨터를 받으면 파일 서버에 다시 연결하기만 하면 됩니다.

Kubernetes에서 PV는 클러스터 관리자가 미리 생성해두는 리소스입니다. 실제 스토리지는 다양한 형태로 존재할 수 있습니다.

AWS의 EBS, Google Cloud의 Persistent Disk, NFS 서버, 또는 Ceph 같은 분산 스토리지 시스템 등이 있습니다. 위 코드를 하나씩 살펴보겠습니다.

capacity는 스토리지의 총 용량을 정의합니다. 10Gi는 10 기비바이트를 의미합니다.

accessModes는 이 볼륨에 어떻게 접근할 수 있는지를 정의합니다. ReadWriteOnce는 하나의 노드에서만 읽기/쓰기가 가능하다는 의미입니다.

데이터베이스처럼 단일 인스턴스가 접근하는 경우에 적합합니다. persistentVolumeReclaimPolicy는 PV가 더 이상 사용되지 않을 때 어떻게 처리할지 결정합니다.

Retain은 데이터를 그대로 보존합니다. 실수로 삭제해도 데이터를 복구할 수 있는 안전장치입니다.

storageClassName은 PV를 분류하는 라벨과 같습니다. 나중에 PVC에서 이 클래스를 지정하여 원하는 스토리지를 선택할 수 있습니다.

마지막으로 awsElasticBlockStore 섹션은 실제 AWS EBS 볼륨과의 연결을 정의합니다. volumeID는 AWS 콘솔에서 생성한 EBS 볼륨의 ID입니다.

"이렇게 PV를 만들어두면, 개발자들은 필요할 때 PersistentVolumeClaim으로 요청해서 사용하면 돼요." 박시니어 씨가 다음 단계를 예고했습니다. 김개발 씨는 PV가 인프라 관리자의 영역이라는 것을 이해했습니다.

관리자가 스토리지를 준비해두면, 개발자는 그것을 요청해서 사용하는 구조입니다. 마치 회사에서 IT팀이 서버를 준비해두면 개발팀이 필요할 때 요청하는 것과 같습니다.

실전 팁

💡 - PV는 네임스페이스에 속하지 않는 클러스터 레벨 리소스입니다

• 클라우드 환경에서는 동적 프로비저닝을 사용하면 PV를 직접 만들 필요가 없습니다
• Retain 정책을 사용하면 실수로 인한 데이터 손실을 방지할 수 있습니다

---

4. PersistentVolumeClaim 사용

PersistentVolume의 개념을 이해한 김개발 씨는 이제 실제로 애플리케이션에서 이 스토리지를 어떻게 사용하는지 배울 차례입니다. 박시니어 씨는 "PV는 창고고, PVC는 그 창고를 빌리겠다는 신청서야"라고 비유했습니다.

**PersistentVolumeClaim(PVC)**은 사용자가 스토리지를 요청하는 방법입니다. 개발자는 필요한 용량과 접근 모드를 명시한 PVC를 생성하고, Kubernetes가 조건에 맞는 PV를 찾아 연결해줍니다.

이렇게 분리된 구조 덕분에 개발자는 실제 스토리지 인프라를 몰라도 됩니다.

다음 코드를 살펴봅시다.

# PersistentVolumeClaim 정의
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
  storageClassName: standard
---
# Pod에서 PVC 사용
apiVersion: v1
kind: Pod
metadata:
  name: postgres
spec:
  containers:
  - name: postgres
    image: postgres:15
    volumeMounts:
    - name: postgres-storage
      mountPath: /var/lib/postgresql/data
  volumes:
  - name: postgres-storage
    persistentVolumeClaim:
      claimName: postgres-pvc

김개발 씨가 PostgreSQL 배포 작업을 시작하려던 참이었습니다. "잠깐, PV는 인프라팀이 만들어놓은 거잖아요.

그걸 어떻게 제 Pod에서 쓰죠?" 김개발 씨가 질문했습니다. 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다.

"PVC를 만들어서 요청하면 돼요. '나는 5기가 용량의 스토리지가 필요해'라고 말하는 거예요." PersistentVolumeClaim은 마치 도서관에서 책을 대출하는 과정과 같습니다.

도서관(클러스터)에는 여러 책(PV)이 있고, 이용자(개발자)는 대출 신청서(PVC)를 작성합니다. 사서(Kubernetes)가 조건에 맞는 책을 찾아서 빌려줍니다.

위 코드의 첫 번째 부분이 PVC 정의입니다. accessModes와 storageClassName은 PV에서 본 것과 같습니다.

차이점은 resources.requests.storage인데, 이것은 "최소한 이 정도 용량이 필요하다"는 요청입니다. Kubernetes는 이 조건을 보고 매칭되는 PV를 찾습니다.

5Gi를 요청했는데 10Gi PV밖에 없다면, 그 10Gi PV가 연결됩니다. 조건에 맞는 PV가 없으면 PVC는 Pending 상태로 대기합니다.

두 번째 부분은 Pod에서 PVC를 사용하는 방법입니다. volumes 섹션에서 persistentVolumeClaim을 지정하고 claimName으로 PVC 이름을 참조합니다.

그리고 volumeMounts에서 컨테이너 내부 경로에 마운트합니다. "여기서 핵심은 추상화예요." 박시니어 씨가 강조했습니다.

"개발자는 AWS EBS인지 NFS인지 몰라도 돼요. 그냥 '5기가 스토리지 주세요'라고 요청하면 끝이에요." 이 구조의 장점은 명확합니다.

개발 환경에서는 hostPath 기반의 PV를 사용하고, 운영 환경에서는 클라우드 스토리지 기반의 PV를 사용해도, PVC와 Pod 정의는 동일하게 유지됩니다. 환경에 따라 PV만 다르게 준비하면 됩니다.

김개발 씨는 PVC를 적용한 후 PostgreSQL Pod를 배포했습니다. Pod를 삭제하고 다시 생성해도 데이터가 그대로 유지되는 것을 확인하고 안도의 한숨을 쉬었습니다.

"이제 데이터베이스를 안심하고 운영할 수 있겠어요!" 김개발 씨의 목소리에 자신감이 실렸습니다.

실전 팁

💡 - PVC를 먼저 생성한 후 Pod를 생성해야 정상적으로 마운트됩니다

• PVC의 storageClassName을 빈 문자열("")로 설정하면 동적 프로비저닝을 비활성화합니다
• PVC 삭제 전에 사용 중인 Pod를 먼저 삭제해야 합니다

---

5. 액세스 모드와 리클레임 정책

PostgreSQL 배포에 성공한 김개발 씨에게 새로운 요구사항이 들어왔습니다. "이번엔 여러 Pod에서 동시에 읽어야 하는 설정 파일 스토리지가 필요해요." 팀장의 요청이었습니다.

박시니어 씨는 액세스 모드에 대해 설명하기 시작했습니다.

**액세스 모드(Access Modes)**는 PV에 동시 접근할 수 있는 노드의 수와 접근 방식을 정의합니다. **리클레임 정책(Reclaim Policy)**은 PVC가 삭제될 때 PV와 데이터를 어떻게 처리할지 결정합니다.

이 두 가지 설정은 운영 환경에서 데이터 안정성과 가용성을 결정하는 핵심 요소입니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: shared-config-pv
spec:
  capacity:
    storage: 1Gi
  # 여러 노드에서 동시 읽기 가능
  accessModes:
    - ReadOnlyMany
  # PVC 삭제 시 PV 자동 삭제
  persistentVolumeReclaimPolicy: Delete
  storageClassName: nfs-storage
  nfs:
    server: 192.168.1.100
    path: /exports/config
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: database-pv
spec:
  capacity:
    storage: 50Gi
  # 단일 노드에서만 읽기/쓰기
  accessModes:
    - ReadWriteOnce
  # PVC 삭제 후에도 데이터 보존
  persistentVolumeReclaimPolicy: Retain
  storageClassName: premium-storage

박시니어 씨가 화이트보드에 세 가지 액세스 모드를 적었습니다. "**ReadWriteOnce(RWO)**는 하나의 노드에서만 읽기/쓰기가 가능해요.

대부분의 블록 스토리지가 이 모드만 지원해요." 박시니어 씨의 설명이 시작되었습니다. AWS EBS나 Google Persistent Disk 같은 클라우드 블록 스토리지는 물리적으로 하나의 인스턴스에만 연결할 수 있습니다.

따라서 RWO가 자연스러운 선택입니다. 데이터베이스처럼 단일 Pod가 접근하는 경우에 적합합니다.

"**ReadOnlyMany(ROX)**는 여러 노드에서 동시에 읽기만 가능해요." 박시니어 씨가 이어갔습니다. ROX는 설정 파일이나 정적 콘텐츠를 여러 Pod에서 공유할 때 유용합니다.

NFS 같은 네트워크 파일시스템에서 주로 사용됩니다. 쓰기는 안 되지만, 여러 노드의 Pod들이 동시에 같은 데이터를 읽을 수 있습니다.

"**ReadWriteMany(RWX)**는 여러 노드에서 동시에 읽기/쓰기가 가능해요. 하지만 지원하는 스토리지가 제한적이에요." 박시니어 씨가 주의를 당부했습니다.

RWX는 NFS, CephFS, Azure Files 등 일부 스토리지만 지원합니다. 여러 Pod가 동시에 파일을 쓸 수 있어 편리하지만, 동시성 문제가 발생할 수 있으므로 애플리케이션 레벨에서의 락 처리가 필요합니다.

이제 리클레임 정책 차례입니다. Retain 정책은 PVC가 삭제되어도 PV와 데이터를 보존합니다.

관리자가 수동으로 정리해야 합니다. 중요한 데이터의 실수로 인한 삭제를 방지할 수 있습니다.

Delete 정책은 PVC 삭제 시 PV도 함께 삭제됩니다. 클라우드 환경에서는 실제 스토리지 리소스(예: EBS 볼륨)도 삭제되어 비용이 절감됩니다.

Recycle 정책은 더 이상 권장되지 않습니다. 동적 프로비저닝을 대신 사용하세요.

김개발 씨는 정리해보았습니다. 데이터베이스처럼 중요한 데이터는 RWO + Retain, 공유 설정은 ROX + Delete, 임시 공유 데이터는 RWX + Delete가 적절할 것 같습니다.

"정확해요. 데이터의 중요도와 접근 패턴을 먼저 분석하고 결정해야 해요." 박시니어 씨가 마무리했습니다.

실전 팁

💡 - 클라우드 블록 스토리지는 대부분 RWO만 지원하므로 다중 접근이 필요하면 NFS 등을 고려하세요

• 운영 데이터베이스는 반드시 Retain 정책을 사용하세요
• 동적 프로비저닝의 기본 정책은 Delete이므로 중요 데이터는 정책을 확인하세요

---

6. 볼륨 스냅샷

어느 날 김개발 씨의 팀에서 대규모 마이그레이션을 앞두고 있었습니다. "만약의 사태에 대비해서 데이터베이스 스냅샷을 떠놓아야 해요." 팀장의 지시였습니다.

Kubernetes에서도 볼륨 스냅샷을 관리할 수 있다는 것을 김개발 씨는 처음 알게 되었습니다.

VolumeSnapshot은 PersistentVolume의 특정 시점 복사본입니다. 마치 게임의 세이브 포인트처럼, 문제가 발생했을 때 이전 상태로 복원할 수 있습니다.

Kubernetes 1.20부터 정식 기능으로 포함되었으며, 데이터 백업과 복구에 필수적인 기능입니다.

다음 코드를 살펴봅시다.

# VolumeSnapshotClass 정의
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: csi-snapclass
driver: ebs.csi.aws.com
deletionPolicy: Retain
---
# VolumeSnapshot 생성
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgres-snapshot-20240115
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: postgres-pvc
---
# 스냅샷에서 새 PVC 생성
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: postgres-pvc-restored
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  dataSource:
    name: postgres-snapshot-20240115
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

마이그레이션 D-1, 김개발 씨는 박시니어 씨와 함께 백업 전략을 논의하고 있었습니다. "예전에는 데이터베이스 덤프를 뜨는 게 전부였는데, Kubernetes에서는 VolumeSnapshot 기능이 있어요." 박시니어 씨가 설명을 시작했습니다.

VolumeSnapshot은 마치 사진을 찍는 것과 같습니다. 특정 순간의 데이터 상태를 그대로 캡처해둡니다.

나중에 문제가 생기면 그 사진(스냅샷)을 기반으로 새로운 볼륨을 만들 수 있습니다. 이 기능을 사용하려면 세 가지 리소스를 이해해야 합니다.

첫 번째는 VolumeSnapshotClass입니다. StorageClass가 PV 프로비저닝 방법을 정의하듯, VolumeSnapshotClass는 스냅샷 생성 방법을 정의합니다.

driver 필드에 CSI 드라이버를 지정하고, deletionPolicy로 스냅샷 삭제 정책을 설정합니다. 두 번째는 VolumeSnapshot 자체입니다.

source.persistentVolumeClaimName으로 어떤 PVC의 스냅샷을 찍을지 지정합니다. 스냅샷 이름에 날짜를 포함하면 나중에 관리하기 편합니다.

세 번째는 스냅샷에서 복원하는 방법입니다. 새 PVC를 생성할 때 dataSource 필드에 스냅샷을 지정하면, 해당 스냅샷의 데이터로 초기화된 새 볼륨이 생성됩니다.

"스냅샷의 장점은 속도예요." 박시니어 씨가 강조했습니다. "데이터베이스 덤프는 테이블 잠금이 필요하고 시간이 오래 걸리지만, 스냅샷은 거의 즉각적으로 생성됩니다." 단, 모든 스토리지가 스냅샷을 지원하는 것은 아닙니다.

CSI(Container Storage Interface) 드라이버가 스냅샷 기능을 구현해야 합니다. AWS EBS, Google Persistent Disk, Azure Disk 등 주요 클라우드 스토리지는 모두 지원합니다.

김개발 씨는 마이그레이션 직전에 스냅샷을 생성하고, 만약의 사태에 대비했습니다. 다행히 마이그레이션은 성공적으로 완료되었지만, 스냅샷이 있다는 사실만으로도 팀 전체가 안심할 수 있었습니다.

"스냅샷은 보험과 같아요. 사용하지 않으면 다행이지만, 필요할 때 없으면 큰일이죠." 박시니어 씨의 말에 김개발 씨는 깊이 공감했습니다.

실전 팁

💡 - 중요한 작업 전에는 항상 스냅샷을 먼저 생성하세요

• 스냅샷도 스토리지 비용이 발생하므로 오래된 것은 정기적으로 정리하세요
• CSI 드라이버가 설치되어 있는지 먼저 확인하세요 (kubectl get csidrivers)

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!