Kubernetes StatefulSet과 Persistent Volume 완벽 가이드: CSI Driver, StorageClass, 동적 프로비저닝 실전 운영

• 들어가며
• StatefulSet 핵심 개념
  • Deployment와 StatefulSet의 차이
  • StatefulSet 스펙 정의
  • PVC 보존 정책
• PV/PVC/StorageClass 아키텍처
  • 3계층 스토리지 모델
  • 접근 모드 비교
  • Reclaim Policy
• CSI Driver 심층 분석
  • CSI 아키텍처 개요
  • CSI Driver 비교
  • AWS EBS CSI Driver 설치
• 동적 프로비저닝 실전 구현
  • StorageClass 설계
  • 동적 프로비저닝 흐름
• 볼륨 확장과 스냅샷
  • 온라인 볼륨 확장
  • 볼륨 스냅샷
• 트러블슈팅 사례
  • 사례 1: PVC가 Pending 상태에서 멈춤
  • 사례 2: PV/PVC가 Terminating 상태에서 고착
  • 사례 3: CSI Driver 크래시와 데이터 복구
  • 사례 4: StatefulSet 스케일 다운 후 데이터 손실 우려
• 운영 체크리스트
• 마치며
• 참고자료

들어가며

Kubernetes에서 Stateless 워크로드는 Deployment와 ReplicaSet으로 비교적 간단하게 관리할 수 있지만, 데이터베이스, 메시지 큐, 분산 캐시처럼 상태를 유지해야 하는 워크로드는 완전히 다른 차원의 복잡성을 요구한다. Pod가 재시작되거나 다른 노드로 이동할 때 데이터가 유실되지 않아야 하고, 각 Pod가 고유한 네트워크 Identity와 안정적인 스토리지를 가져야 하며, 스케일링 시에도 순서가 보장되어야 한다.

Kubernetes는 이러한 요구사항을 위해 StatefulSet, PersistentVolume(PV), PersistentVolumeClaim(PVC), StorageClass, 그리고 Container Storage Interface(CSI) Driver라는 스토리지 생태계를 제공한다. 하지만 이들의 관계와 동작 방식을 제대로 이해하지 못하면 프로덕션에서 데이터 유실, 볼륨 고착(stuck), 프로비저닝 실패 같은 심각한 장애를 겪게 된다.

이 글에서는 StatefulSet의 핵심 동작 원리부터 시작하여, PV/PVC/StorageClass의 아키텍처를 깊이 있게 분석하고, CSI Driver의 내부 구조와 주요 구현체(EBS CSI, EFS CSI, Ceph CSI, Longhorn)를 비교한다. 이어서 동적 프로비저닝 실전 구현, 볼륨 확장과 스냅샷, 실제 운영에서 자주 발생하는 트러블슈팅 사례, 그리고 프로덕션 운영 체크리스트까지 종합적으로 다룬다.

StatefulSet 핵심 개념

Deployment와 StatefulSet의 차이

Deployment는 Pod를 교체 가능한 동일한 단위로 취급한다. Pod 이름은 무작위 해시를 포함하고, 스케줄링 순서도 보장하지 않으며, 어떤 Pod가 삭제되더라도 동일한 역할을 하는 새 Pod가 즉시 생성된다. 반면 StatefulSet은 각 Pod에 **순서형 인덱스(Ordinal Index)**를 부여하고, 네트워크 Identity와 스토리지를 Pod의 Identity에 바인딩한다.

StatefulSet이 제공하는 핵심 보장 사항은 다음과 같다.

1. 안정적인 네트워크 Identity: Pod 이름이 statefulset-name-0, statefulset-name-1 형태로 고정되며, Headless Service를 통해 각 Pod에 대한 고유 DNS 레코드가 생성된다.
2. 안정적인 스토리지: volumeClaimTemplates를 통해 각 Pod에 전용 PVC가 자동 생성되며, Pod가 재스케줄링되어도 동일한 PVC에 바인딩된다.
3. 순서 보장: Pod 생성은 0번부터 순서대로 진행되고, 삭제는 역순으로 진행된다.
4. 롤링 업데이트 순서 보장: 업데이트 시에도 가장 높은 인덱스부터 역순으로 진행된다.

StatefulSet 스펙 정의

다음은 3개의 복제본을 가진 PostgreSQL StatefulSet의 실전 예시이다.

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgresql
  namespace: database
spec:
  serviceName: postgresql-headless
  replicas: 3
  podManagementPolicy: OrderedReady
  updateStrategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
  selector:
    matchLabels:
      app: postgresql
  template:
    metadata:
      labels:
        app: postgresql
    spec:
      terminationGracePeriodSeconds: 120
      securityContext:
        fsGroup: 999
        runAsUser: 999
      containers:
        - name: postgresql
          image: postgres:16.2-alpine
          ports:
            - containerPort: 5432
              name: postgresql
          env:
            - name: PGDATA
              value: /var/lib/postgresql/data/pgdata
            - name: POSTGRES_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: postgresql-secret
                  key: password
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              cpu: 2000m
              memory: 4Gi
          livenessProbe:
            exec:
              command:
                - pg_isready
                - -U
                - postgres
            initialDelaySeconds: 30
            periodSeconds: 10
          readinessProbe:
            exec:
              command:
                - pg_isready
                - -U
                - postgres
            initialDelaySeconds: 5
            periodSeconds: 5
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes:
          - ReadWriteOnce
        storageClassName: gp3-encrypted
        resources:
          requests:
            storage: 100Gi
---
apiVersion: v1
kind: Service
metadata:
  name: postgresql-headless
  namespace: database
spec:
  type: ClusterIP
  clusterIP: None
  selector:
    app: postgresql
  ports:
    - port: 5432
      targetPort: postgresql

이 매니페스트에서 주목할 점은 다음과 같다.

• volumeClaimTemplates: StatefulSet이 각 Pod마다 data-postgresql-0, data-postgresql-1, data-postgresql-2 형태의 PVC를 자동 생성한다.
• podManagementPolicy: OrderedReady: 기본값으로, Pod 0이 Ready 상태가 되어야 Pod 1이 생성된다. 병렬 시작이 필요하면 Parallel로 변경할 수 있다.
• terminationGracePeriodSeconds: 120: 데이터베이스는 종료 시 정리 작업이 필요하므로 충분한 유예 시간을 설정한다.
• fsGroup: 999: PV 마운트 시 파일 시스템 그룹 권한을 PostgreSQL 사용자에 맞춘다.

PVC 보존 정책

Kubernetes 1.27부터 StatefulSet의 PVC 보존 정책을 세밀하게 제어할 수 있다. 기본적으로 StatefulSet을 삭제하거나 스케일 다운해도 PVC는 삭제되지 않는다(데이터 안전을 위해). 이 동작을 변경하려면 persistentVolumeClaimRetentionPolicy를 사용한다.

spec:
  persistentVolumeClaimRetentionPolicy:
    whenDeleted: Delete
    whenScaled: Retain

• whenDeleted: Delete: StatefulSet 자체가 삭제될 때 PVC도 함께 삭제한다.
• whenScaled: Retain: 스케일 다운 시에는 PVC를 보존한다. 다시 스케일 업하면 기존 PVC가 재사용된다.

PV/PVC/StorageClass 아키텍처

3계층 스토리지 모델

Kubernetes 스토리지는 3개의 추상화 계층으로 구성된다.

1. PersistentVolume(PV): 클러스터 수준의 스토리지 리소스이다. 실제 물리 또는 클라우드 스토리지 볼륨을 나타내며, 관리자가 직접 생성하거나 StorageClass를 통해 동적으로 프로비저닝된다.
2. PersistentVolumeClaim(PVC): 사용자(개발자)가 스토리지를 요청하는 명세이다. 용량, 접근 모드, StorageClass를 지정하면 조건에 맞는 PV에 바인딩된다.
3. StorageClass: 동적 프로비저닝의 청사진이다. 어떤 프로비저너(CSI Driver)를 사용할지, 어떤 파라미터(디스크 타입, IOPS, 암호화 등)로 볼륨을 생성할지 정의한다.

접근 모드 비교

Reclaim Policy

PVC가 삭제된 후 PV의 운명을 결정하는 정책이다.

• Retain: PV와 데이터를 그대로 보존한다. 수동으로 정리하거나 다른 PVC에 다시 바인딩할 수 있다. 프로덕션 데이터베이스에 권장된다.
• Delete: PV와 함께 백엔드 스토리지(EBS 볼륨 등)도 자동 삭제된다. 임시 데이터나 개발 환경에 적합하다.
• Recycle(Deprecated): 사용 금지. CSI Driver 기반 동적 프로비저닝으로 대체되었다.

CSI Driver 심층 분석

CSI 아키텍처 개요

Container Storage Interface(CSI)는 Kubernetes와 스토리지 시스템 사이의 표준 인터페이스이다. CSI 이전에는 스토리지 플러그인이 Kubernetes 코어 코드에 포함되어 있어(in-tree plugin), 새로운 스토리지를 추가하려면 Kubernetes 자체를 수정해야 했다. CSI는 이 결합을 끊고, 스토리지 벤더가 독립적으로 드라이버를 개발하고 배포할 수 있게 했다.

CSI Driver는 두 가지 핵심 컴포넌트로 구성된다.

1. Controller Plugin (Deployment): 볼륨 생성/삭제/확장/스냅샷 등 클러스터 수준 작업을 처리한다. External Provisioner, External Attacher, External Snapshotter 같은 사이드카 컨테이너와 함께 실행된다.
2. Node Plugin (DaemonSet): 각 워커 노드에서 실행되며, 볼륨의 마운트/언마운트, 포맷팅, 디바이스 경로 관리를 담당한다. kubelet과 직접 통신한다.

CSI Driver 비교

AWS EBS CSI Driver 설치

EKS 환경에서 EBS CSI Driver를 설치하는 실전 절차이다.

# 1. IAM OIDC Provider 확인
eksctl utils associate-iam-oidc-provider \
  --cluster my-cluster \
  --approve

# 2. EBS CSI Driver용 IAM ServiceAccount 생성
eksctl create iamserviceaccount \
  --name ebs-csi-controller-sa \
  --namespace kube-system \
  --cluster my-cluster \
  --role-name AmazonEKS_EBS_CSI_DriverRole \
  --role-only \
  --attach-policy-arn arn:aws:iam::aws:policy/service-role/AmazonEBSCSIDriverPolicy \
  --approve

# 3. EKS Addon으로 EBS CSI Driver 설치
aws eks create-addon \
  --cluster-name my-cluster \
  --addon-name aws-ebs-csi-driver \
  --service-account-role-arn arn:aws:iam::ACCOUNT_ID:role/AmazonEKS_EBS_CSI_DriverRole

# 4. 설치 확인
kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver
kubectl get csidriver

동적 프로비저닝 실전 구현

StorageClass 설계

프로덕션 환경에서는 워크로드 특성에 맞는 여러 StorageClass를 정의해야 한다.

# 범용 SSD - 일반 워크로드용
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gp3-standard
  annotations:
    storageclass.kubernetes.io/is-default-class: 'true'
provisioner: ebs.csi.aws.com
parameters:
  type: gp3
  fsType: ext4
  encrypted: 'true'
  kmsKeyId: 'arn:aws:kms:ap-northeast-2:ACCOUNT_ID:key/KEY_ID'
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# 고성능 SSD - 데이터베이스용
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: io2-database
provisioner: ebs.csi.aws.com
parameters:
  type: io2
  iopsPerGB: '50'
  fsType: ext4
  encrypted: 'true'
reclaimPolicy: Retain
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
---
# 공유 파일 시스템 - RWX 접근용
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: efs-shared
provisioner: efs.csi.aws.com
parameters:
  provisioningMode: efs-ap
  fileSystemId: fs-0123456789abcdef0
  directoryPerms: '700'
  basePath: '/dynamic_provisioning'
reclaimPolicy: Delete

StorageClass 설계 시 핵심 포인트는 다음과 같다.

• volumeBindingMode: WaitForFirstConsumer: 멀티 AZ 환경에서 필수이다. Pod가 스케줄링될 노드의 AZ를 확인한 후 해당 AZ에 볼륨을 생성하므로, 볼륨과 Pod의 AZ 불일치 문제를 방지한다.
• allowVolumeExpansion: true: 나중에 디스크 용량을 늘릴 수 있도록 반드시 활성화해야 한다. 이 옵션이 false인 StorageClass로 생성된 PVC는 확장이 불가능하다.
• reclaimPolicy: 데이터베이스처럼 중요한 데이터를 저장하는 볼륨에는 Retain을, 임시 데이터에는 Delete를 사용한다.
• encrypted: "true": 보안 컴플라이언스를 위해 모든 볼륨에 암호화를 적용한다.

동적 프로비저닝 흐름

동적 프로비저닝의 전체 흐름은 다음과 같다.

1. 사용자가 PVC를 생성하면 StorageClass의 provisioner 필드에 지정된 CSI Driver가 호출된다.
2. CSI Controller Plugin의 CreateVolume RPC가 실행되어 클라우드 API를 통해 실제 볼륨이 생성된다.
3. PV 오브젝트가 자동 생성되고 PVC에 바인딩된다.
4. Pod가 해당 PVC를 참조하여 스케줄링되면, CSI Controller Plugin의 ControllerPublishVolume RPC가 호출되어 볼륨이 노드에 Attach된다.
5. CSI Node Plugin의 NodeStageVolume과 NodePublishVolume RPC가 호출되어 볼륨이 포맷되고 Pod 내부 경로에 마운트된다.

볼륨 확장과 스냅샷

온라인 볼륨 확장

EBS CSI Driver는 온라인 볼륨 확장을 지원한다. Pod를 재시작하지 않고도 디스크 용량을 늘릴 수 있다.

# PVC의 요청 용량 변경
kubectl patch pvc data-postgresql-0 -n database \
  -p '{"spec":{"resources":{"requests":{"storage":"200Gi"}}}}'

# 확장 상태 확인
kubectl get pvc data-postgresql-0 -n database -o jsonpath='{.status.conditions}'

# 실제 파일 시스템 크기 확인 (Pod 내부에서)
kubectl exec -it postgresql-0 -n database -- df -h /var/lib/postgresql/data

확장 작업은 두 단계로 진행된다. 먼저 백엔드 볼륨(EBS)의 크기가 증가하고, 그 다음 파일 시스템이 확장된다. 파일 시스템 확장이 완료될 때까지 PVC의 condition에 FileSystemResizePending 상태가 표시된다.

볼륨 스냅샷

CSI 스냅샷을 활용한 데이터 백업과 복원 절차이다.

# VolumeSnapshotClass 정의
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshotClass
metadata:
  name: ebs-snapshot-class
driver: ebs.csi.aws.com
deletionPolicy: Retain
parameters:
  tagSpecification_1: 'Environment=production'
  tagSpecification_2: 'BackupType=scheduled'
---
# 스냅샷 생성
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
  name: postgresql-snapshot-20260313
  namespace: database
spec:
  volumeSnapshotClassName: ebs-snapshot-class
  source:
    persistentVolumeClaimName: data-postgresql-0
---
# 스냅샷에서 새 PVC 복원
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: data-postgresql-restored
  namespace: database
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: gp3-standard
  resources:
    requests:
      storage: 100Gi
  dataSource:
    name: postgresql-snapshot-20260313
    kind: VolumeSnapshot
    apiGroup: snapshot.storage.k8s.io

스냅샷 운영 시 주의사항은 다음과 같다.

• 스냅샷은 **크래시 일관성(crash-consistent)**만 보장한다. 애플리케이션 일관성이 필요하면 스냅샷 전에 CHECKPOINT 명령 등을 실행해야 한다.
• VolumeSnapshotClass의 deletionPolicy를 Retain으로 설정하면 VolumeSnapshot 오브젝트를 삭제해도 실제 스냅샷 데이터는 보존된다.
• 스냅샷 CRD(VolumeSnapshot, VolumeSnapshotContent, VolumeSnapshotClass)가 클러스터에 설치되어 있어야 한다. snapshot-controller도 별도 배포가 필요하다.

트러블슈팅 사례

사례 1: PVC가 Pending 상태에서 멈춤

증상: PVC를 생성했지만 계속 Pending 상태로 남아있다.

# PVC 상태 확인
kubectl describe pvc data-postgresql-0 -n database

# 일반적인 이벤트 메시지 예시:
# waiting for first consumer to be created before binding
# no persistent volumes available for this claim
# storageclass "gp3-standard" not found

원인과 해결:

1. StorageClass가 존재하지 않는 경우: PVC에 지정한 storageClassName이 클러스터에 없다. kubectl get storageclass로 확인한다.
2. WaitForFirstConsumer 모드: volumeBindingMode가 WaitForFirstConsumer이면 PVC를 사용하는 Pod가 생성될 때까지 Pending 상태가 정상이다.
3. CSI Driver 미설치: 프로비저너로 지정한 CSI Driver가 설치되어 있지 않다. kubectl get csidriver로 확인한다.
4. 리소스 쿼터 초과: 네임스페이스에 ResourceQuota가 설정되어 있고 스토리지 한도를 초과한 경우이다.
5. AZ 제약: Pod가 특정 AZ에 스케줄링되었지만, 해당 AZ에서 볼륨을 생성할 수 없는 경우이다.

사례 2: PV/PVC가 Terminating 상태에서 고착

증상: PVC를 삭제했지만 Terminating 상태에서 무한히 대기한다.

# Finalizer 확인
kubectl get pvc data-postgresql-0 -n database -o jsonpath='{.metadata.finalizers}'
# 출력 예시: ["kubernetes.io/pvc-protection"]

# 해당 PVC를 사용 중인 Pod 확인
kubectl get pods -n database -o json | \
  jq '.items[] | select(.spec.volumes[]?.persistentVolumeClaim.claimName == "data-postgresql-0") | .metadata.name'

원인과 해결:

kubernetes.io/pvc-protection finalizer는 PVC를 사용하는 Pod가 있으면 삭제를 차단한다. 먼저 해당 PVC를 참조하는 모든 Pod를 삭제한 후 PVC 삭제를 재시도한다. Pod를 이미 삭제했음에도 여전히 고착된 경우에만 finalizer를 수동 제거한다.

# 주의: 데이터 유실 가능성이 있으므로 반드시 백업 후 실행
kubectl patch pvc data-postgresql-0 -n database \
  -p '{"metadata":{"finalizers":null}}'

PV가 Terminating 상태에 고착되는 경우도 유사하다. VolumeAttachment이 남아있거나, CSI Driver가 정상적으로 볼륨을 삭제하지 못하는 경우에 발생한다.

# VolumeAttachment 확인
kubectl get volumeattachment | grep "pv-name"

# CSI Driver Pod 로그 확인
kubectl logs -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver \
  -c ebs-plugin --tail=100

사례 3: CSI Driver 크래시와 데이터 복구

증상: CSI Driver Pod가 CrashLoopBackOff 상태이고, 새로 생성되는 Pod들이 볼륨을 마운트하지 못한다.

진단 절차:

# CSI Driver Pod 상태 확인
kubectl get pods -n kube-system -l app.kubernetes.io/name=aws-ebs-csi-driver

# CSI Driver 이벤트 확인
kubectl describe pod -n kube-system ebs-csi-controller-0

# CSI Node Plugin 로그 확인 (각 노드)
kubectl logs -n kube-system -l app=ebs-csi-node -c ebs-plugin --tail=50

# VolumeAttachment 상태 확인
kubectl get volumeattachment -o wide

복구 절차:

1. CSI Driver를 재배포한다. Helm이나 EKS Addon을 통해 재설치한다.
2. 고착된 VolumeAttachment이 있다면 수동으로 정리한다.
3. Pod를 삭제하여 kubelet이 볼륨 마운트를 재시도하도록 한다.
4. 최악의 경우 노드 자체를 drain하고 교체한다.

사례 4: StatefulSet 스케일 다운 후 데이터 손실 우려

StatefulSet을 3에서 2로 스케일 다운하면 postgresql-2 Pod는 삭제되지만, data-postgresql-2 PVC는 기본적으로 보존된다. 다시 3으로 스케일 업하면 기존 PVC가 재사용된다.

하지만 persistentVolumeClaimRetentionPolicy.whenScaled: Delete로 설정했거나, 수동으로 PVC를 삭제한 경우에는 데이터가 유실된다. 따라서 스케일 다운 전에 반드시 데이터 마이그레이션 또는 백업을 수행해야 한다.

운영 체크리스트

프로덕션 환경에서 StatefulSet과 Persistent Volume을 운영할 때 반드시 확인해야 할 항목이다.

배포 전 체크리스트:

• StorageClass에 volumeBindingMode: WaitForFirstConsumer가 설정되어 있는가
• StorageClass에 allowVolumeExpansion: true가 활성화되어 있는가
• 데이터베이스 볼륨의 reclaimPolicy가 Retain으로 설정되어 있는가
• CSI Driver가 정상적으로 설치되어 있고 csidriver 오브젝트가 등록되어 있는가
• VolumeSnapshot CRD와 snapshot-controller가 배포되어 있는가
• PodDisruptionBudget이 설정되어 있는가
• 충분한 terminationGracePeriodSeconds가 설정되어 있는가

일상 운영 체크리스트:

• PVC 용량 사용률을 모니터링하고 있는가 (kubelet_volume_stats_used_bytes 메트릭)
• 볼륨 스냅샷이 정기적으로 생성되고 있는가
• 스냅샷 복원 테스트를 주기적으로 수행하고 있는가
• CSI Driver 버전이 Kubernetes 버전과 호환되는가
• StorageClass의 파라미터가 보안 요구사항(암호화 등)을 충족하는가
• Pending 또는 Terminating 상태의 PVC/PV가 없는가

장애 대응 체크리스트:

• PVC Pending 시: StorageClass 존재 여부, CSI Driver 상태, ResourceQuota, AZ 제약 확인
• PVC Terminating 시: 참조하는 Pod 존재 여부, Finalizer 확인
• 볼륨 마운트 실패 시: VolumeAttachment 상태, CSI Node Plugin 로그 확인
• 데이터 복구 시: 최신 스냅샷 확인, 스냅샷에서 PVC 복원 절차 실행
• CSI Driver 장애 시: Driver Pod 재배포, 고착된 VolumeAttachment 정리

마치며

Kubernetes에서 상태 유지 워크로드를 안정적으로 운영하려면 StatefulSet, PV, PVC, StorageClass, CSI Driver가 어떻게 상호작용하는지 깊이 이해해야 한다. 단순히 매니페스트를 복사해서 적용하는 것이 아니라, 각 컴포넌트의 동작 원리를 파악하고 장애 시나리오를 미리 준비하는 것이 핵심이다.

특히 프로덕션 환경에서는 다음 원칙을 지켜야 한다.

1. WaitForFirstConsumer를 기본으로 사용하여 AZ 불일치 문제를 원천 차단한다.
2. 볼륨 암호화를 모든 StorageClass에 적용한다.
3. 스냅샷 기반 백업을 정기적으로 수행하고, 복원 테스트도 반드시 포함한다.
4. 모니터링을 통해 디스크 사용률, IOPS, 지연시간을 실시간으로 추적한다.
5. reclaimPolicy를 데이터 중요도에 맞게 설정하여 의도치 않은 데이터 삭제를 방지한다.

CSI Driver 생태계는 계속 발전하고 있다. Kubernetes 1.29에서 GA된 ReadWriteOncePod 접근 모드, 볼륨 그룹 스냅샷(Volume Group Snapshot) 기능, SELinux 마운트 옵션 지원 등 새로운 기능이 지속적으로 추가되고 있으므로, 릴리스 노트를 꾸준히 확인하며 스토리지 운영 전략을 업데이트해야 한다.

참고자료

• Kubernetes 공식 문서 - StatefulSets
• Kubernetes 공식 문서 - Persistent Volumes
• Kubernetes 공식 문서 - Storage Classes
• Kubernetes 공식 문서 - Volume Snapshots
• Kubernetes 공식 문서 - Dynamic Volume Provisioning
• AWS EBS CSI Driver GitHub
• AWS EFS CSI Driver GitHub
• Kubernetes CSI Developer Documentation - Drivers
• Longhorn CSI Snapshot Documentation
• Kubernetes Storage Layers: Ceph vs. Longhorn