StatefulSet, PersistentVolume/Claim이란 무엇이며, Kubernetes에서 stateful 워크로드를 어떻게 실행하는가?

Question

IT Interview Practice · Accepted Answer

Stateful 워크로드(데이터베이스, 큐, 클러스터형 저장소)는 **안정적인 신원**과 **영속적인 스토리지**를 필요로 한다 — Deployment가 제공하지 않는 것들이다. **StatefulSet**은 Pod에 안정적인 이름과 순서 있는 라이프사이클을 부여하고; **PersistentVolume (PV)**과 **PersistentVolumeClaim (PVC)**은 Pod보다 오래 지속되는 스토리지를 준다.

## Deployment로는 왜 충분하지 않은가

```text
Deployment의 Pod는 교체 가능하다: 무작위 이름(web-7f9-abc), 임의 순서, Pod별로
공유하는 것이 없음. stateless 앱에는 완벽하지만 — 데이터베이스 replica에는:
  → 안정적인 네트워크 신원 (peer가 찾을 수 있게: db-0, db-1, db-2)
  → 재시작/재스케줄에도 살아남는 자신만의 영속적 디스크
  → 순서 있고 통제된 시작/스케일링 (db-1 전에 db-0을 올림)
StatefulSet이 바로 이것들을 제공한다.
```

## StatefulSet의 보장

```text
안정적 NAMES     → pod-0, pod-1, pod-2 (무작위가 아닌 서수)
안정적 DNS       → headless Service를 통해 db-0.db.default.svc...
안정적 STORAGE   → 각 Pod가 자신만의 PVC를 가짐 (db-0은 재시작에도 디스크 유지)
순서 있는 연산   → 0,1,2… 순서로 생성/스케일업; 역순으로 종료
```

## 영속 스토리지: PV, PVC, StorageClass

```text
StorageClass → "어떻게 프로비저닝할지" 템플릿 (예: AWS gp3, fast-ssd)
PVC          → 스토리지에 대한 요청 ("20Gi, ReadWriteOnce 필요")   ← 앱 대면
PV           → PVC에 바인딩된 실제 프로비저닝된 볼륨                ← 클러스터 대면
동적 프로비저닝: StorageClass를 참조하는 PVC가 매칭되는 PV를 자동 생성한다.

App → PVC → (StorageClass가 프로비저닝) → PV → 실제 디스크 (EBS, PD, Ceph, NFS…)
```

## Pod별 스토리지를 가진 StatefulSet

```yaml
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: db
spec:
  serviceName: db            # 안정적 DNS를 위한 headless Service
  replicas: 3
  selector:
    matchLabels: { app: db }
  template:
    metadata:
      labels: { app: db }
    spec:
      containers:
        - name: db
          image: postgres:16
          ports: [{ containerPort: 5432 }]
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:      # 각 Pod가 이 템플릿에서 자신만의 PVC/PV를 얻음
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        storageClassName: fast-ssd
        resources:
          requests: { storage: 20Gi }
```

```yaml
# Pod별 안정적 DNS를 주는 headless Service (db-0.db, db-1.db, …)
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## 접근 모드 & 주의점

```text
ReadWriteOnce (RWO)  → 하나의 노드가 read-write로 마운트 (대부분의 block storage: EBS/PD)
ReadOnlyMany (ROX)   → 여러 노드가 read-only
ReadWriteMany (RWX)  → 여러 노드가 read-write (NFS/CephFS/EFS 필요)
⚠ StatefulSet을 삭제해도 기본적으로 PVC는 삭제되지 않는다 (데이터 보존).
⚠ Reclaim policy(Retain/Delete)가 PVC 제거 시 PV에 무슨 일이 일어날지 결정.
⚠ Kubernetes는 신원+스토리지를 주지만, 앱 수준의 클러스터링/복제는 당신의 몫이다
  (종종 Operator를 통해, 예: Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2 (안정적, 순서 있음)
```

## 왜 중요한가

Stateful 워크로드를 올바르게 실행하는 것은 Kubernetes의 더 어려운 부분 중 하나이므로, StatefulSet과 영속 스토리지를 이해하는 것은 실제 프로덕션에 결과를 미치는 시니어급 지식이다. 핵심 통찰은 Deployment가 *왜* 부족한지다: 그 Pod들은 교체 가능하다(무작위 이름, 임의 순서, Pod별 상태 없음). 이는 stateless 서비스에는 이상적이지만, **안정적인 신원**(peer가 `db-0`, `db-1`, `db-2`를 DNS로 찾을 수 있도록), **자신만의 영속적 디스크**(재시작과 재스케줄에도 살아남는), **순서 있고 통제된** 시작과 스케일링을 필요로 하는 데이터베이스와 클러스터형 저장소에는 잘못된 것이다. **StatefulSet**은 바로 이 보장들을 제공하며, 스토리지 추상화와 짝을 이룬다: **PersistentVolumeClaim**은 스토리지에 대한 애플리케이션 대면 요청이고, **PersistentVolume**은 실제 프로비저닝된 볼륨이며, **StorageClass**는 동적 프로비저닝을 가능케 한다 — `volumeClaimTemplates`가 각 Pod에 자신만의 PVC/PV를 준다. 주의점에서 시니어 엔지니어가 값어치를 한다: **접근 모드**(RWO vs RWX와 어떤 백엔드가 지원하는지), StatefulSet을 삭제해도 기본적으로 **PVC가 보존된다**는 사실, PV의 운명을 좌우하는 **reclaim policy**, 그리고 결정적으로 Kubernetes는 신원과 스토리지를 제공하지만 **앱 수준의 복제와 클러스터링은 당신의 책임으로 남는다**는 것(종종 Operator에 위임). 데이터 내구성과 올바른 stateful 동작은 용서가 없으므로(실수는 데이터 손실이나 split-brain을 의미), StatefulSet, PV/PVC, 그리고 그 주의점을 숙달하는 것은 Kubernetes에서 데이터베이스와 다른 stateful 시스템을 신뢰성 있게 실행하는 데 기초가 된다.

Deployment로는 왜 충분하지 않은가

StatefulSet의 보장

영속 스토리지: PV, PVC, StorageClass

Pod별 스토리지를 가진 StatefulSet

접근 모드 & 주의점

왜 중요한가

관련 질문