StatefulSet、PersistentVolume/Claim とは何で、Kubernetes 上で stateful な workload をどう動かしますか？

Question

IT Interview Practice · Accepted Answer

stateful な workload（データベース、キュー、クラスタ化されたストア）は、**安定した同一性**と**永続的なストレージ**を必要とします — Deployment が提供しないものです。**StatefulSet** は Pod に安定した名前と順序づけられたライフサイクルを与え、**PersistentVolume（PV）**と **PersistentVolumeClaim（PVC）**は Pod より長生きするストレージを与えます。

## なぜ Deployment では足りないのか

```text
Deployment Pods are INTERCHANGEABLE: random names (web-7f9-abc), any order, share
nothing per-Pod. That's perfect for stateless apps — but a database replica needs:
  → a STABLE network identity (so peers can find it: db-0, db-1, db-2)
  → its OWN durable disk that survives restarts/rescheduling
  → ORDERED, controlled startup/scaling (bring up db-0 before db-1)
StatefulSet provides exactly these.
```

## StatefulSet の保証

```text
Stable NAMES     → pod-0, pod-1, pod-2 (ordinal, not random)
Stable DNS       → db-0.db.default.svc... via a headless Service
Stable STORAGE   → each Pod gets its OWN PVC (db-0 keeps its disk across restarts)
Ordered ops      → create/scale up in order 0,1,2…; terminate in reverse
```

## 永続ストレージ：PV、PVC、StorageClass

```text
StorageClass → the "how to provision" template (e.g. AWS gp3, fast-ssd)
PVC          → a REQUEST for storage ("I need 20Gi, ReadWriteOnce")   ← app-facing
PV           → the ACTUAL provisioned volume bound to the PVC          ← cluster-facing
Dynamic provisioning: a PVC referencing a StorageClass auto-creates a matching PV.

App → PVC → (StorageClass provisions) → PV → real disk (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 }]
```

## access mode と注意点

```text
ReadWriteOnce (RWO)  → mounted read-write by ONE node (most block storage: EBS/PD)
ReadOnlyMany (ROX)   → read-only by many nodes
ReadWriteMany (RWX)  → read-write by many nodes (needs NFS/CephFS/EFS)
⚠ Deleting a StatefulSet does NOT delete its PVCs by default (data is preserved).
⚠ Reclaim policy (Retain/Delete) decides what happens to the PV when the PVC is removed.
⚠ Kubernetes gives identity+storage, but app-level clustering/replication is YOUR job
  (often via an Operator, e.g. for Postgres/Kafka).
```

```bash
kubectl get statefulset,pvc,pv
kubectl get pods -l app=db      # db-0, db-1, db-2（安定、順序づけ）
```

## なぜ重要なのか

stateful な workload を正しく動かすことは Kubernetes のより難しい部分の 1 つであり、StatefulSet と永続ストレージを理解することは、実際の production への帰結を伴う senior レベルの知識です。中核の洞察は、*なぜ* Deployment では不十分かです。その Pod は交換可能（ランダムな名前、任意の順序、Pod ごとの状態なし）で、これは stateless サービスには理想的ですが、**安定した同一性**（peer が DNS で `db-0`・`db-1`・`db-2` を見つけられる）、restart や再スケジュールを生き延びる**自分専用の永続ディスク**、そして**順序づけられ制御された**起動とスケーリングを必要とするデータベースやクラスタ化ストアには誤りです。**StatefulSet** はまさにこれらの保証を提供し、ストレージの抽象化と組み合わさります。**PersistentVolumeClaim** はアプリケーション側のストレージ要求、**PersistentVolume** は実際にプロビジョニングされた volume、**StorageClass** は動的プロビジョニングを可能にし、`volumeClaimTemplates` が各 Pod に自分専用の PVC/PV を与えます。注意点は senior エンジニアが真価を発揮する所です。**access mode**（RWO 対 RWX と、どのバックエンドが対応するか）、StatefulSet を削除してもデフォルトで **PVC が保持される**こと、PV の運命を左右する **reclaim policy**、そして — 決定的に — Kubernetes は同一性とストレージを提供するが**アプリケーションレベルの replication と clustering はあなたの責任**であり、しばしば Operator に委譲されること。データの永続性と正しい stateful な振る舞いは容赦がない（誤りはデータ損失や split-brain を意味する）ため、StatefulSet・PV/PVC・その注意点の習熟は、Kubernetes 上でデータベースやその他の stateful システムを信頼性高く動かすための基礎です。

なぜ Deployment では足りないのか

StatefulSet の保証

永続ストレージ：PV、PVC、StorageClass

Pod ごとのストレージを持つ StatefulSet

access mode と注意点

なぜ重要なのか

関連する質問