영구 볼륨 및 볼륨 클레임

Pod는 생성되고 사라지지만 애플리케이션의 데이터는 계속 유지되어야 하는 경우가 많습니다. 데이터베이스나 사용자가 업로드한 파일을 생각해 보세요.

• Pod가 다시 시작되거나 다른 곳에 재배치되면 컨테이너 파일 시스템에 직접 저장된 데이터는 모두 사라집니다.
• 이러한 임시 특성은 상태 비저장 애플리케이션에는 적합하지만, 중요한 데이터에는 내구성 있는 해결책이 필요합니다.
• Kubernetes는 Pod의 수명 주기를 넘어 유지되는 영구 저장소를 관리할 수 있는 강력한 시스템을 제공합니다.

PersistentVolume (PV)는 Kubernetes 클러스터에 있는 저장소의 일부입니다.

• 클러스터 범위 리소스이므로 특정 네임스페이스에 속하지 않습니다.
• 관리자가 프로비저닝하거나 StorageClass를 통해 동적으로 프로비저닝할 수 있습니다.
• 기반 저장소 기술(예: Google Persistent Disk, AWS EBS, NFS 공유)의 세부 사항을 추상화합니다.

PV는 용량, 접근 모드, 저장소 유형과 같은 세부 정보로 정의합니다. 다음 YAML은 5기가바이트 저장소를 사용하는 hostPath(로컬 테스트용) PV를 설명합니다.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

참고: hostPath는 일반적으로 단일 노드 개발 환경에서 사용하며, 운영 환경에는 권장되지 않습니다.

PersistentVolumeClaim (PVC)는 특정 네임스페이스 내의 사용자 또는 애플리케이션이 저장소를 요청하는 것입니다.

• Pod는 PV를 직접 사용하지 않고 PVC를 통해 저장소를 요청합니다.
• PVC는 네임스페이스 범위이므로 특정 프로젝트나 팀의 영역 안에 존재합니다.
• 원하는 크기와 접근 모드, 선택적으로 저장소 클래스를 지정합니다.

Kubernetes는 바인딩이라는 과정을 통해 PVC를 사용 가능한 PV와 자동으로 연결합니다.

• PVC가 생성되면 Kubernetes는 PVC의 요구 사항(크기, 접근 모드, 저장소 클래스)을 충족하는 PV를 검색합니다.
• 적합한 PV를 찾으면 둘은 일대일 관계로 함께 "바인딩"됩니다.
• 이 바인딩을 통해 PVC는 요청한 특정 저장소를 사용할 수 있습니다.

접근 모드는 저장소를 Pod에서 어떻게 마운트하고 사용할 수 있는지 정의합니다. 다음 모드는 PVC가 요청하고 PV가 지원합니다.

• ReadWriteOnce (RWO): 하나의 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있습니다.
• ReadOnlyMany (ROX): 여러 노드에서 볼륨을 읽기 전용으로 마운트할 수 있습니다.
• ReadWriteMany (RWX): 여러 노드에서 볼륨을 읽기-쓰기로 마운트할 수 있습니다.

사용할 수 있는 모드는 특정 저장소 제공업체에 따라 다릅니다.

Storage Classes는 관리자가 저장소의 "클래스"(예: "fast-ssd", "slow-hdd")를 설명할 수 있는 방법을 제공합니다.

• PV를 수동으로 생성하는 대신, PVC가 요청하면 StorageClass가 PV를 동적으로 프로비저닝할 수 있습니다.
• 미리 정의된 템플릿을 바탕으로 PV 생성을 자동화합니다.
• 저장소 프로비저닝과 사용을 분리하여 사용자가 더 쉽게 이용할 수 있도록 합니다.

1기가바이트 저장소와 ReadWriteOnce 접근을 요청하는 PVC를 만들어 보겠습니다. 이 PVC는 기존 PV를 찾거나 StorageClass를 통해 동적 프로비저닝을 시작합니다.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

이 내용을 pvc.yaml로 저장하고 kubectl apply -f pvc.yaml을 실행하세요.

PVC가 바인딩되면 Pod는 볼륨 구성에서 PVC 이름을 참조하여 이를 사용할 수 있습니다. Pod는 기반 PV를 알 필요 없이 PVC만 알면 됩니다.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

이 Pod는 마운트된 영구 볼륨에 파일을 작성합니다.

kubectl을 사용해 영구 저장소 리소스의 상태를 모니터링할 수 있습니다.

• 모든 PV 보기: kubectl get pv
• 네임스페이스의 모든 PVC 보기: kubectl get pvc
• 상태와 이벤트를 포함한 자세한 정보 보기:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

PV가 Bound 상태이고 PVC가 올바른 PV에 Bound되어 있는지 확인하세요.

지금까지 Kubernetes가 애플리케이션의 내구성 있는 저장소를 관리하는 방법을 살펴보았습니다.

• PersistentVolumes (PVs)는 실제 저장소를 나타내는 클러스터 리소스입니다.
• PersistentVolumeClaims (PVCs)는 사용자의 저장소 요청입니다.
• Kubernetes는 요구 사항에 따라 PVC를 적합한 PV에 바인딩합니다.
• 접근 모드는 저장소를 사용하는 방법을 정의합니다(RWO, ROX, RWX).
• Storage Classes는 PV의 동적 프로비저닝을 가능하게 하여 설정을 자동화합니다.

이 시스템을 사용하면 Pod가 생성되고 사라져도 애플리케이션 데이터가 유지되므로 상태 저장 애플리케이션의 안정성이 향상됩니다.