有状态应用与存储选型

有状态应用为什么是 K8s 的"硬骨头"

K8s 天生为无状态应用设计: Deployment 管理一堆完全对等, 可随意替换的 Pod--挂一个补一个, 谁是谁无所谓. 但有状态应用(数据库, 消息队列, 分布式存储)有三个 Deployment 满足不了的诉求:

无状态(Deployment 擅长)          有状态(需要 StatefulSet)
─────────────────────           ─────────────────────────
Pod 完全对等, 可互换      vs     每个实例有身份(主库 / 从库 不一样)
随便扩缩, 随便重建        vs     启动/缩容要有序(先起主, 再起从)
不需要稳定的网络标识      vs     需要稳定的网络名(从库要一直找得到主库)
共享或无持久存储          vs     每个实例要独占自己的那块数据盘

这三个诉求--稳定身份, 有序操作, 独立存储--正是 StatefulSet 这个工作负载(Kubernetes 笔记里见过)存在的理由. 本篇聚焦它和存储结合的那一面.

StatefulSet + volumeClaimTemplates: 每个副本一块独立盘

关键机制是 volumeClaimTemplates(卷申领模板). 普通 Deployment 如果引用一个 PVC, 所有副本会共用同一个 PVC(对数据库是灾难--多个实例写同一份数据文件会损坏). StatefulSet 则用模板为每个副本自动创建一个独立的 PVC:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: postgres
spec:
  serviceName: postgres
  replicas: 3
  template:
    spec:
      containers:
        - name: postgres
          image: postgres:16
          volumeMounts:
            - name: data
              mountPath: /var/lib/postgresql/data
  volumeClaimTemplates:           # ← 不是固定的 PVC, 而是"模板"
    - metadata:
        name: data
      spec:
        accessModes: ["ReadWriteOnce"]   # 每块盘单节点独占(第 06 篇)
        storageClassName: fast-ssd
        resources:
          requests:
            storage: 20Gi

这个模板的效果是: K8s 给每个副本生成一块专属, 稳定绑定的盘:

postgres-0  →  PVC: data-postgres-0  →  独立的 20Gi 盘
postgres-1  →  PVC: data-postgres-1  →  另一块独立 20Gi 盘
postgres-2  →  PVC: data-postgres-2  →  又一块独立 20Gi 盘

关键: postgres-0 这个 Pod 重建后, 仍然绑回 data-postgres-0 这块盘
     → 实例身份(序号)和它的数据盘是终身绑定的, 数据不会错乱

存储选型: 本地 vs 网络 vs 分布式

给有状态应用选什么底层存储(即第 06 篇 StorageClass 背后是什么), 是核心决策. 三类选择, 又是一组经典权衡:

灵魂拷问: 数据库到底该不该上 Kubernetes

这是有状态领域最有争议的问题. 先给结论: 没有标准答案, 取决于运维能力和数据库类型, 但要先想清两道坎.

两种立场, 各有道理:

支持上 K8s:                      谨慎/反对:
  · 统一用一套编排管理所有负载       · 数据库是"皇冠上的明珠", 出事代价极高
  · Operator 能自动化主从/备份/故障转移  · 有状态运维(备份/恢复/迁移)远比无状态难
  · 开发自助, 环境一致               · 性能敏感场景, 存储抽象层有损耗
  · 云原生生态(监控/GitOps)天然集成   · 团队若缺 K8s + DB 双重运维能力, 风险高

绕不开的最后一道坎: 备份

无论数据库在不在 K8s 上, 有状态应用都有一条铁律: 持久化(Persistence)不等于备份(Backup). 这是最致命的误区之一:

K8s 环境下的备份手段, 正好用上前面的知识:

• 卷快照(第 07 篇 CSI Snapshot): 给数据盘拍时间点快照, 可快速恢复或克隆. 注意快照通常和原卷在同一存储后端, 不能替代异地备份.
• 应用层逻辑备份: 如 pg_dump 导出数据库, 存到对象存储(第 06 篇, S3 这类异地, 便宜, 耐久).
• 专用工具: 如 Velero(备份整个 K8s 资源 + PV 数据), 各数据库 Operator 自带的备份能力.

全系列收束: 两套对称的可插拔体系

回望这八篇, 云原生的网络与存储其实讲的是同一个故事的两半:

网络这一半:                          存储这一半:
  01 内核原语(namespace/veth/网桥)      06 存储抽象(块/文件/对象, PV/PVC)
  02 跨节点(Overlay vs 路由)             ──对称──
  03 CNI 接口外包给插件          ◀═══════▶  07 CSI 接口外包给插件
  04 eBPF/Cilium 数据平面                    (三段式 provision/attach/mount)
  05 NetworkPolicy 零信任隔离
                    ╲                      ╱
                     ╲                    ╱
                  08 在有状态应用上, 网络与存储一起落地
                  (StatefulSet 要稳定网络名 + 独立存储盘)

贯穿始终的是那条主线: Kubernetes 自己不实现网络和存储, 而是定义 CNI / CSI 标准接口, 把实现外包给可插拔的插件. 正是这套"机制与策略分离"的设计, 让 K8s 核心保持精简, 而网络与存储生态各自繁荣, 自由竞争与替换. 所有眼花缭乱的选择(Flannel/Calico/Cilium, EBS/Ceph/NFS), 本质都是同一个接口下的不同实现--抓住接口, 就抓住了不变的骨架.