쿠버네티스에서 퍼시스턴트 스토리지 구현을 위한 간단 가이드

쿠버네티스 퍼시스턴트 스토리지는 간단한 문제를 해결합니다: 컨테이너는 사라질 수 있지만, 데이터베이스 파일, 업로드, 큐 데이터는 사라지면 안 됩니다. 무상태(stateless) Pod는 언제든지 교체될 수 있습니다. 상태 저장(stateful) 애플리케이션은 Pod 재시작, 재스케줄링, 노드 유지보수에도 데이터가 유지되는 스토리지가 필요합니다.

이 가이드는 PersistentVolume(PV), PersistentVolumeClaim(PVC), 접근 모드, StorageClass를 실제 워크로드에 적용할 수 있는 실용적인 YAML 예제와 함께 설명합니다.

PersistentVolume(PV)과 PersistentVolumeClaim(PVC) 이해하기

Pod에 스토리지를 마운트하기 전에 각 객체가 어떤 역할을 하는지 알아야 합니다:

• PersistentVolume (PV): PV는 관리자가 프로비저닝했거나 StorageClass를 사용하여 동적으로 프로비저닝된 클러스터의 스토리지 조각입니다. PV는 노드와 유사한 클러스터 리소스입니다. PV를 사용하는 개별 Pod와 독립적인 라이프사이클을 가집니다. PV는 기본 스토리지 구현 세부 사항(예: NFS, iSCSI, 클라우드 제공업체 블록 스토리지)을 추상화합니다.
• PersistentVolumeClaim (PVC): PVC는 사용자의 스토리지 요청입니다. PVC는 클러스터에서 PV로 사용 가능한 스토리지 리소스를 소비합니다. PVC는 Pod가 컴퓨팅 리소스를 소비하는 것과 유사하며, 네임스페이스로 범위가 지정됩니다. PVC는 원하는 스토리지 용량, 접근 모드, 선택적으로 StorageClass를 지정합니다.

이러한 분리를 통해 플랫폼 팀은 스토리지 세부 사항을 관리하고, 애플리케이션 팀은 필요한 용량과 접근 패턴을 요청할 수 있습니다.

핵심 개념: 접근 모드와 StorageClass

두 가지 설정이 대부분의 PVC 동작을 제어합니다: 볼륨이 마운트되는 방식과 어떤 스토리지 백엔드가 이를 생성할지입니다.

접근 모드

접근 모드는 볼륨이 Pod에 마운트될 수 있는 방식을 정의합니다. 사용 가능한 접근 모드는 다음과 같습니다:

• ReadWriteOnce (RWO): 볼륨이 단일 노드에 읽기-쓰기로 마운트될 수 있습니다.
• ReadOnlyMany (ROX): 볼륨이 여러 노드에 읽기 전용으로 마운트될 수 있습니다.
• ReadWriteMany (RWX): 볼륨이 여러 노드에 읽기-쓰기로 마운트될 수 있습니다.
• ReadWriteOncePod (RWOP): 볼륨이 단일 Pod에 읽기-쓰기로 마운트될 수 있습니다. 더 엄격한 단일 작성자 동작이 필요하고 CSI 드라이버가 이를 지원할 때 유용합니다.

이러한 모드에 대한 실제 지원은 기본 스토리지 제공업체에 따라 달라질 수 있습니다.

StorageClass

StorageClass는 관리자가 제공하는 스토리지의 "클래스"를 설명할 수 있는 방법을 제공합니다. 다른 클래스는 서비스 품질 수준, 백업 정책 또는 클러스터 관리자가 결정한 임의의 정책에 매핑될 수 있습니다. StorageClass에는 스토리지를 프로비저닝하는 프로비저너와 프로비저너에 대한 매개변수 집합이 있습니다. 특정 PV 없이 PVC가 생성되고 StorageClass를 요청하면, 쿠버네티스는 지정된 StorageClass를 사용하여 PV를 동적으로 프로비저닝합니다.

퍼시스턴트 스토리지 단계별 구현

일반적인 시나리오를 살펴보겠습니다: Pod에 대한 퍼시스턴트 스토리지 요청 및 사용.

1단계: PersistentVolumeClaim(PVC) 정의

먼저 스토리지 요구 사항을 지정하는 PVC를 생성해야 합니다. 이 PVC는 애플리케이션의 스토리지 요청 역할을 합니다.

예시 pvc.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

이 예시에서:

• name: my-pvc: PVC의 이름입니다.
• accessModes: - ReadWriteOnce: 단일 노드에 읽기-쓰기로 마운트될 수 있는 스토리지를 요청합니다.
• resources.requests.storage: 1Gi: 1GB의 스토리지를 요청합니다.

PVC 적용:

위 내용을 pvc.yaml 파일로 저장하고 클러스터에 적용합니다:

kubectl apply -f pvc.yaml

적용 후 PVC 상태를 확인할 수 있습니다:

kubectl get pvc my-pvc

적합한 PV가 있거나 동적으로 프로비저닝된 경우 PVC가 Bound 상태임을 나타내는 출력이 표시됩니다.

2단계: PVC를 사용하는 Pod 생성

이제 PVC가 요청한 스토리지를 사용할 Pod를 생성해 보겠습니다. PVC가 제공하는 볼륨을 컨테이너 내 특정 디렉토리에 마운트합니다.

예시 pod-with-pv.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

이 예시에서:

• volumes: my-persistent-storage라는 이름의 볼륨을 정의합니다.
• persistentVolumeClaim.claimName: my-pvc: 이 볼륨을 이전에 생성한 PVC에 연결합니다.
• volumeMounts: 컨테이너 정의 내에서 이 볼륨이 마운트될 위치를 지정합니다 (mountPath: /usr/share/nginx/html).

Pod 적용:

위 내용을 pod-with-pv.yaml 파일로 저장하고 적용합니다:

kubectl apply -f pod-with-pv.yaml

이제 nginx 컨테이너는 /usr/share/nginx/html 경로에서 my-pvc가 정의한 퍼시스턴트 스토리지에 접근할 수 있습니다. PVC와 기본 PV가 유지되는 한, 컨테이너 내 이 경로에 기록된 모든 데이터는 Pod가 삭제되고 재생성되어도 유지됩니다.

StorageClass를 사용한 동적 프로비저닝

PV를 수동으로 생성하는 것은 번거로울 수 있습니다. 쿠버네티스는 동적 프로비저닝을 제공하여, 기존 PV로 충족할 수 없는 스토리지를 PVC가 요청할 때 PV가 자동으로 생성됩니다. 이는 StorageClass를 통해 이루어집니다.

대부분의 클라우드 제공업체(AWS, GCP, Azure)는 사전 구성된 StorageClass를 제공합니다. 다음 명령어로 확인할 수 있습니다:

kubectl get storageclass

동적 프로비저닝을 사용하려면 PVC 정의에 storageClassName 필드를 추가하기만 하면 됩니다:

예시 pvc-dynamic.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # 'standard'를 실제 StorageClass 이름으로 바꾸세요
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

이 PVC를 적용하면 쿠버네티스는 standard(또는 지정한 이름)라는 StorageClass를 찾고, 해당 프로비저너에게 5Gi 크기의 새 PV를 생성하여 이 PVC에 바인딩하도록 지시합니다.

팁과 모범 사례

• 올바른 접근 모드 선택: 애플리케이션에 필요한 접근 모드를 신중히 고려하세요. ReadWriteOnce는 단일 복제본 데이터베이스에 일반적이며, ReadWriteMany는 여러 Pod에서 사용하는 공유 파일 시스템에 필요합니다.
• 스토리지 성능 이해: 다양한 스토리지 제공업체와 StorageClass는 다양한 성능 특성(IOPS, 처리량)을 제공합니다. 애플리케이션의 성능 요구 사항을 충족하는 StorageClass를 선택하세요.
• 백업 전략: 퍼시스턴트 스토리지가 자동으로 백업을 의미하지는 않습니다. 특히 중요한 데이터의 경우 퍼시스턴트 볼륨에 대한 강력한 백업 전략을 구현하세요.
• PV 회수 정책: PV에는 persistentVolumeReclaimPolicy가 있으며, 일반적으로 Delete 또는 Retain입니다. 동적으로 프로비저닝된 볼륨은 종종 StorageClass에 정의된 회수 정책을 사용합니다. 이전 Recycle 정책은 더 이상 사용되지 않으며 새 설정에 사용해서는 안 됩니다.
• 네임스페이스 고려 사항: PVC는 네임스페이스로 범위가 지정됩니다. 바인딩이 발생하려면 Pod와 PVC가 동일한 네임스페이스에 있는지 확인하세요.

결론

쿠버네티스의 퍼시스턴트 스토리지는 PVC, Pod 마운트, 워크로드에 맞는 StorageClass로 시작됩니다. 단일 복제본 데이터베이스의 경우 ReadWriteOnce 클레임으로 시작하고, Bound 상태가 되는지 확인한 후 컨테이너에 마운트하고, 첫날부터 백업을 설계의 일부로 포함시키세요.