K8s 持久化存储怎么选？别只盯着性能，能不能活下来更重要

说句实在的，K8s 里最容易让人“心态崩”的，不是 Pod 起不来，而是存储出问题。

Pod 挂了能重启，
服务崩了能扩容，
但数据要是没了、乱了、慢到拖垮业务，那是真的要写事故复盘的。

而 CSI（Container Storage Interface），恰好就是那个：

平时存在感不高，出事时全场最忙的组件。

今天这篇，我不打算做 CSI 教科书扫盲，
而是站在运维视角，聊一个现实问题：

K8s 持久化存储选型，到底该怎么在性能、可用性、备份之间做取舍？

一、先泼一盆冷水：不存在“完美 CSI”

很多同学在选型时，潜意识里想要的是：

• 高性能（IOPS 拉满）
• 强一致
• 高可用
• 支持快照
• 支持备份
• 运维成本低
• 还最好不要钱（🙂）

我一般会直接说一句大实话：

CSI 选型，本质是“你更怕什么”。

• 怕慢？
• 怕丢？
• 怕挂？
• 还是怕半夜被叫起来？

想清楚这个，比看一堆 Benchmark 更重要。

二、先把 CSI 的“底层逻辑”想明白

不管你用的是哪家 CSI，底层无非几种形态：

1. 本地盘（Local PV）
2. 网络块存储（Ceph RBD、云盘）
3. 网络文件系统（NFS、CephFS）

这三种，对应的取舍非常清晰。

三、性能视角：IO 快不快，真不是第一优先级

1️⃣ Local PV：性能王者，但心脏脆

Local PV 的特点一句话总结：

IO 快到飞起，节点挂了你就想哭。

典型配置：

apiVersion: v1
kind: PersistentVolume
spec:
  storageClassName: local-storage
  local:
    path: /data/local-pv
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: kubernetes.io/hostname
          operator: In
          values:
          - node-1

优点：

• 没网络 IO，延迟极低

• 非常适合：

  • 日志缓冲
  • 临时计算缓存
  • 高性能但可丢数据场景

缺点（致命）：

• 跟节点强绑定
• 节点挂 = 数据基本凉
• Pod 漂移成本极高

👉 结论：
Local PV 不是不能用，但千万别用在“你解释不起数据丢失”的系统里。

2️⃣ 网络块存储：性能和安全的平衡点

以 Ceph RBD / 云厂商云盘 CSI 为代表。

kind: StorageClass
provisioner: rbd.csi.ceph.com
parameters:
  pool: kube-pool
  imageFeatures: layering

优点：

• 性能可预期
• 支持快照
• Pod 可迁移
• 节点挂了还能救

缺点：

• 网络 IO 有开销
• Ceph 本身需要精心运维

👉 结论：
这是我见过线上用得最多、翻车率最低的一类 CSI。

3️⃣ 网络文件系统：省心，但别指望极限性能

典型代表：NFS、CephFS。

provisioner: nfs.csi.k8s.io
parameters:
  server: nfs-server
  share: /exports

优点：

• 多 Pod 共享（RWX）
• 使用成本低
• 对应用透明

缺点：

• 性能受限明显
• 单点风险（NFS Server）

👉 结论：
配置中心、模型文件、静态资源，没问题；
数据库、日志写入密集型服务，慎用。

四、可用性视角：别等到节点挂了才想起来

我一直强调一句话：

K8s 的高可用，存储必须先高可用。

常见翻车现场

• Deployment 有 3 副本
• 但 PVC 都绑在同一个节点
• 节点一挂，服务全体跪

CSI 选型时你必须问自己：

• 存储是否支持多副本？
• 是否支持自动重建？
• Pod 漂移时数据还能不能跟着走？

Ceph 这类分布式存储的价值就在这里：

不是因为它快，而是因为它“活得久”。

五、备份视角：快照 ≠ 备份，这坑我踩过

这是我最想强调的一点。

1️⃣ CSI Snapshot 只是“时间点冻结”

apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
spec:
  volumeSnapshotClassName: csi-snapclass
  source:
    persistentVolumeClaimName: data-pvc

Snapshot 的问题在于：

• 和主存储在一个集群
• 集群炸了，快照一起陪葬
• 不是异地，不是长期备份

👉 快照是回滚工具，不是救灾工具。

2️⃣ 真正的备份，必须满足三点

我自己的最低要求：

1. 跨集群 / 跨存储
2. 可恢复验证
3. 和业务解耦

像 Velero + CSI Snapshot + 对象存储，才算完整链路。

velero backup create mysql-backup \
  --include-namespaces prod \
  --snapshot-volumes

六、我的运维选型心法（非常主观）

如果你让我一句话给建议：

生产环境，优先选“你出事后能解释得清楚的方案”。

我的常见搭配是：

• 数据库 / 状态服务
  👉 Ceph RBD / 云盘 CSI + 快照 + 异地备份
• 共享配置 / 模型文件
  👉 CephFS / NFS
• 缓存 / 日志中转
  👉 Local PV

你会发现：
不是一个 CSI 打天下，而是“分场景用存储”。

七、写在最后

K8s 这套体系，本质是“算力弹性 + 存储现实”。

CPU、内存可以随便调度，
但数据永远是有重量的。

很多事故，表面看是存储炸了，
本质其实是：

选型时只看了性能，却低估了可用性和备份。