StatefulSet、PersistentVolume/Claim 是什么，如何在 Kubernetes 上运行有状态 workload？

Question

IT Interview Practice · Accepted Answer

有状态（stateful）workload（数据库、队列、集群化存储）需要**稳定的身份**和**持久的存储**——这是 Deployment 无法提供的。**StatefulSet** 给 Pod 稳定的名字和有序的生命周期；**PersistentVolume (PV)** 与 **PersistentVolumeClaim (PVC)** 给它们能比 Pod 更长寿的存储。

## 为什么 Deployment 不够用

```text
Deployment 的 Pod 是可互换的：随机名字 (web-7f9-abc)、任意顺序、每个 Pod
之间不共享任何东西。这对无状态应用很完美——但一个数据库副本需要：
  → 一个稳定的网络身份（好让对等者能找到它：db-0, db-1, db-2）
  → 它自己的、能在重启/重新调度后存活的持久磁盘
  → 有序、可控的启动/扩缩（先起 db-0 再起 db-1）
StatefulSet 恰恰提供了这些。
```

## StatefulSet 的保证

```text
稳定的名字     → pod-0, pod-1, pod-2（序号，非随机）
稳定的 DNS     → 通过 headless Service 得到 db-0.db.default.svc...
稳定的存储     → 每个 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 (db-0.db, db-1.db, …) 的 headless Service
apiVersion: v1
kind: Service
metadata: { name: db }
spec:
  clusterIP: None            # headless
  selector: { app: db }
  ports: [{ port: 5432 }]
```

## 访问模式与注意事项

```text
ReadWriteOnce (RWO)  → 被一个 node 以读写方式挂载（多数块存储：EBS/PD）
ReadOnlyMany (ROX)   → 被多个 node 以只读方式挂载
ReadWriteMany (RWX)  → 被多个 node 以读写方式挂载（需要 NFS/CephFS/EFS）
⚠ 删除一个 StatefulSet 默认不会删除它的 PVC（数据被保留）。
⚠ 回收策略 (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（稳定、有序）
```

## 为什么这很重要

正确运行有状态 workload 是 Kubernetes 较难的部分之一，因此理解 StatefulSet 和持久存储是有真实生产后果的高级知识。核心洞见是*为什么* Deployment 不够用：它的 Pod 是可互换的（随机名字、任意顺序、无每 Pod 状态），这对无状态服务很理想，但对需要**稳定身份**（好让对等者通过 DNS 找到 `db-0`、`db-1`、`db-2`）、**自己的、能在重启和重新调度后存活的持久磁盘**，以及**有序、可控**的启动和扩缩的数据库和集群化存储而言则是错的。**StatefulSet** 恰好提供这些保证，并与存储抽象配套：**PersistentVolumeClaim** 是面向应用的存储请求，**PersistentVolume** 是实际供给的卷，而 **StorageClass** 启用动态供给——`volumeClaimTemplates` 让每个 Pod 拥有它自己的 PVC/PV。注意事项正是高级工程师体现价值之处：**访问模式**（RWO vs RWX 以及哪些后端支持它们）、删除 StatefulSet 默认**保留其 PVC** 的事实、决定 PV 命运的**回收策略**，以及——至关重要地——Kubernetes 提供身份和存储，但**应用层的复制和集群化仍是你的责任**，常常委托给一个 Operator。因为数据持久性和正确的有状态行为不容出错（失误意味着数据丢失或脑裂），精通 StatefulSet、PV/PVC 及其注意事项是在 Kubernetes 上可靠运行数据库和其他有状态系统的基础。

为什么 Deployment 不够用

StatefulSet 的保证

持久存储：PV、PVC、StorageClass

一个带每 Pod 存储的 StatefulSet

访问模式与注意事项

为什么这很重要

相关问题