Storage - Volume

퍼시스턴트 볼륨(PV/PVC)을 보기 전에, 먼저 Kubernetes에서 말하는 볼륨(Volume) 이 무엇인지부터 정리하는 게 좋습니다.
결론부터 말하면:

• 파드(Pod)는 본질적으로 휘발성(ephemeral)이라서, 파드가 삭제되면 파드 내부 파일 시스템에 있던 데이터도 같이 사라집니다.
• 따라서 파드에서 생성/처리한 데이터를 남기려면 파드에 볼륨을 “붙이고(mount)”, 데이터를 그쪽에 쓰게 만들어야 합니다.
• 다만 “볼륨”은 개념이고, 실제로 데이터가 어디에 저장되는지는 볼륨 타입(hostPath, NFS, cloud disk, CSI 등) 에 따라 달라집니다.

---

1) Docker에서의 볼륨 복습: 컨테이너는 휘발성, 볼륨은 영속성

Docker 컨테이너는 보통 작업 단위로 실행되었다가 종료/삭제됩니다.
컨테이너의 writable layer에 생성된 데이터는 컨테이너와 운명을 같이 하죠.

• 컨테이너 삭제 → writable layer 삭제 → 데이터 소멸

그래서 DB처럼 데이터를 남겨야 하는 경우:

• Docker volume(또는 bind mount)을 컨테이너에 붙여서
• 데이터가 컨테이너 내부가 아니라 호스트(또는 외부 스토리지)에 저장되도록 만듭니다.

---

2) Kubernetes에서도 동일: 파드는 휘발성, 그래서 볼륨이 필요

Kubernetes에서 파드는 컨테이너의 실행 단위입니다. 파드도 마찬가지로 휘발성입니다.

• 파드 삭제/재생성 → 파드 내부 파일 시스템의 데이터는 보장되지 않음

따라서 파드가 생성한 파일을 유지하려면:

• 파드 spec에 volumes 를 정의하고
• 컨테이너 spec에 volumeMounts 로 원하는 경로에 마운트합니다.

---

3) “가장 단순한 볼륨” 예시: hostPath로 노드 디렉터리에 저장하기

강의에서 다룬 예시는 단일 노드 클러스터에서 이해하기 좋습니다.

• 파드가 1~100 사이 임의 숫자를 만들어 /opt/number.txt에 기록
• /opt 경로를 볼륨으로 마운트
• 볼륨의 실제 저장소는 노드의 /data 디렉터리(hostPath)

예시 YAML (hostPath + random write)

apiVersion: v1
kind: Pod
metadata:
  name: random-writer
spec:
  restartPolicy: Never
  containers:
    - name: writer
      image: busybox:1.36
      command:
        - sh
        - -c
        - |
          n=$(( (RANDOM % 100) + 1 ))
          echo $n > /opt/number.txt
          echo "wrote: $n"
          # 파드가 바로 종료되면 로그 확인이 불편하니 잠깐 대기(필요 없으면 제거)
          sleep 5
      volumeMounts:
        - name: data-vol
          mountPath: /opt
  volumes:
    - name: data-vol
      hostPath:
        path: /data
        type: DirectoryOrCreate

실행:

kubectl apply -f random-writer.yaml
kubectl logs -f pod/random-writer
kubectl delete pod random-writer

그 다음 노드에 들어가서 /data/number.txt가 남아 있는지 확인하면, 파드를 삭제해도 파일이 그대로 남아있음을 볼 수 있습니다.

단일 노드 환경(예: minikube)이면 minikube ssh로 확인할 수 있고, kind면 노드가 컨테이너라 docker exec로 확인하는 방식이 됩니다.

---

4) 중요한 경고: hostPath는 “단일 노드에서는” 잘 되지만, “멀티 노드에서는” 위험

강의에서 강조한 포인트가 이겁니다.

멀티 노드에서 hostPath가 위험한 이유

• 파드는 스케줄러에 의해 어느 노드로든 이동(reschedule) 될 수 있습니다.
• hostPath는 노드 로컬 디렉터리를 가리킵니다.
• 즉,
  • 노드 A의 /data와
  • 노드 B의 /data는
  • 물리적으로 다른 디스크/다른 서버입니다.

그래서 파드가 노드 A에서 노드 B로 이동하면:

• 노드 A에 쓰던 데이터는 노드 B에서 보이지 않거나
• “같은 경로인데 내용이 다름” 같은 문제가 생깁니다.

또한 hostPath는 보안 관점에서도 주의가 필요합니다.

• 잘못 마운트하면 컨테이너가 호스트의 민감한 경로에 접근할 수 있음
• 운영 클러스터에서 hostPath는 특별한 이유 없으면 지양하는 편이 일반적

정리:

• 단일 노드 학습용/테스트용: hostPath OK
• 멀티 노드 운영용: hostPath 지양, 외부 스토리지 + PV/PVC/CSI 사용

---

5) Kubernetes 볼륨 “백엔드”는 다양하다: NFS부터 클라우드 디스크까지

Kubernetes는 볼륨을 구성하는 방법(볼륨 타입)을 여러 개 제공합니다.

• NFS, CephFS, iSCSI/FC 계열
• 클라우드 디스크: (예) AWS EBS, Azure Disk/File, GCP Persistent Disk
• 그리고 요즘 표준은 CSI(Container Storage Interface) 드라이버 기반

강의에서는 “hostPath 대신 awsElasticBlockStore 같은 필드를 쓰면 EBS에 저장된다”는 식으로 설명했는데,
실무/현대 Kubernetes에서는 보통 다음 방식으로 가는 게 정석입니다.

• 파드 spec에 스토리지를 직접 박기보다는
• StorageClass + PVC 로 요청하고
• CSI 드라이버가 실제 볼륨을 프로비저닝/연결/마운트하도록 구성

이게 다음 챕터의 PersistentVolume(PV) / PersistentVolumeClaim(PVC) 로 이어지는 이유입니다.

---

6) 여기까지의 핵심만 요약

• 파드의 파일 시스템은 기본적으로 휘발성이다.
• 데이터를 남기려면 볼륨을 파드에 마운트해야 한다.
• hostPath는 “노드 로컬”이라 단일 노드에서는 이해가 쉽지만, 멀티 노드에서는 데이터 일관성이 깨져서 위험하다.
• 운영에서는 보통 외부 스토리지 + CSI + PV/PVC 로 간다.