1. 为什么容器存储这件事值得单独拎出来讲很多人刚接触容器编排的时候注意力几乎全被调度、网络、服务发现这些话题吸走了存储往往被放到最后才想起来。结果就是应用跑起来了日志一重启就丢数据库一漂移就崩文件上传到某个节点上换个副本就找不到了。我见过太多团队在测试环境里用默认配置跑得好好的一上生产就各种数据不一致回头排查半天发现根子上就是存储这一层没设计好。Kubernetes 的存储体系之所以让人头疼是因为它不像无状态服务那样可以随便重建。有状态负载对数据的持久性、一致性、访问模式都有硬性要求而这些要求又跟底层基础设施强绑定。你用的是本地盘、网络块存储、文件存储还是对象存储直接决定了能支持什么样的工作负载。更麻烦的是Kubernetes 本身并不直接管理存储它通过一层抽象把存储能力接进来这层抽象就是 CSI也就是容器存储接口。这篇内容想做的事情很明确把 CSI 这套机制从原理到落地讲透把市面上主流的存储方案拉出来做横向对比再把我自己在生产环境里踩过的坑和总结出来的实施要点摊开说。不管你是刚接手一个有状态服务的运维还是正在为团队选型的架构师或者只是想把数据库稳稳当当跑在集群里的开发者都能从这里找到能直接用的东西。我不会只讲概念每个环节都会落到具体配置和参数上让你看完能动手。2. CSI 到底解决了什么问题它的工作原理是什么2.1 从 in-tree 到 out-of-tree 的演进逻辑要理解 CSI 的价值得先知道它出现之前是什么样子。早期 Kubernetes 把各种存储驱动的代码直接塞在主仓库里这叫 in-tree 模式。AWS、GCE、Ceph、GlusterFS 这些存储的适配代码全都跟 Kubernetes 核心代码耦合在一起。这种做法的毛病非常明显存储厂商想发一个新版本得等 Kubernetes 发版Kubernetes 想升级得保证不破坏所有内置驱动的兼容性。两边节奏完全对不上社区维护成本高得离谱而且主仓库越来越臃肿。CSI 的思路是把存储驱动从核心代码里彻底剥离出来定义一套标准的 gRPC 接口任何存储厂商只要实现这套接口就能以独立进程的方式跟 Kubernetes 对接。这个进程通常以 DaemonSet 或者 Deployment 的形式跑在集群里通过 Unix Domain Socket 跟 kubelet 通信。这样一来存储厂商可以独立迭代自己的驱动Kubernetes 也不用再背着一堆存储代码的包袱。这个转变的本质是把存储集成从编译期绑定变成了运行期插件灵活性和可维护性完全不是一个量级。2.2 CSI 的三个核心组件与调用链路CSI 驱动在集群里通常由三个部分组成理解这三者的分工是排查问题的前提。第一个是CSI Controller一般以 Deployment 形式部署副本数不用多它负责的是集群级别的操作比如创建和删除卷、挂载和卸载卷到某个节点、创建快照、扩容等。这些操作往往需要调用底层存储的 API属于控制面行为。第二个是CSI Node必须以 DaemonSet 形式跑在每个节点上因为卷最终要挂到具体节点上。它负责节点级别的操作比如把卷格式化并挂载到宿主机的某个目录然后把挂载点告诉 kubelet。这个组件跟节点强绑定节点上没跑起来Pod 就挂不上卷。第三个是external-provisioner、external-attacher、external-resizer、external-snapshotter这一组 sidecar 容器。它们其实是 Kubernetes 社区提供的通用组件负责监听 API Server 里的 PV、PVC、VolumeAttachment 等资源变化然后调用 CSI 驱动暴露的 gRPC 接口。为什么要拆成 sidecar 而不是让驱动自己监听因为这样驱动只需要专注实现存储逻辑跟 Kubernetes API 打交道的脏活累活由社区统一维护的组件来干降低了驱动开发的门槛。整个调用链路大致是这样的用户创建一个 PVCexternal-provisioner 监听到之后调用 CSI Controller 的 CreateVolume 接口底层存储创建出卷然后返回卷信息provisioner 据此创建 PV 对象。Pod 调度到某个节点后external-attacher 调用 ControllerPublishVolume 把卷 attach 到节点kubelet 再通过 CSI Node 的 NodeStageVolume 和 NodePublishVolume 把卷挂载到容器里。删除的时候反向走一遍。这条链路里任何一环出问题Pod 都会卡在 ContainerCreating 状态所以排查的时候要顺着链路一段段看。2.3 卷的生命周期与关键接口CSI 定义了一组 gRPC 接口每个接口对应卷生命周期的一个阶段。我把最核心的几个列出来配合说明它们什么时候被调用。接口名称调用方触发时机作用CreateVolumeexternal-provisionerPVC 创建且需要动态供给在底层存储创建卷DeleteVolumeexternal-provisionerPV 被删除删除底层存储的卷ControllerPublishVolumeexternal-attacherPod 调度到节点把卷 attach 到节点ControllerUnpublishVolumeexternal-attacherPod 从节点移除把卷从节点 detachNodeStageVolumekubelet卷首次挂到节点格式化并挂载到全局目录NodePublishVolumekubelet容器启动把全局挂载点 bind mount 到容器NodeUnstageVolumekubelet卷从节点卸载卸载全局挂载CreateSnapshotexternal-snapshotterVolumeSnapshot 创建创建卷快照这里有个容易混淆的点NodeStageVolume 和 NodePublishVolume 的区别。Stage 是把卷挂到节点上的一个全局目录比如/var/lib/kubelet/plugins/kubernetes.io/csi/...这个操作对同一个卷在同一个节点上只做一次。Publish 是把 Stage 好的目录 bind mount 到具体 Pod 的挂载点每个 Pod 都要做一次。为什么要分两步因为一个卷可能被同一个节点上的多个 Pod 共享比如 ReadWriteMany 模式Stage 一次就够了Publish 按 Pod 来。理解这个分层排查挂载问题时就能快速定位是卡在 Stage 还是 Publish。3. 主流存储方案横向对比与选型思路3.1 块存储、文件存储、对象存储的适用边界选存储方案之前先要搞清楚你的负载需要哪种访问模式。Kubernetes 里 PVC 的 accessModes 有三种ReadWriteOnceRWO、ReadOnlyManyROX、ReadWriteManyRWX。这三种模式直接对应了底层存储的类型。块存储通常只支持 RWO也就是同一时刻只能被一个节点挂载读写。它性能好、延迟低适合数据库、消息队列这类对 IO 要求高的单实例有状态服务。文件存储支持 RWX多个节点可以同时挂载读写适合共享配置文件、多副本同时写日志、CI 构建缓存这类场景。对象存储不走 PVC 这套通常通过 SDK 或者 CSI 的特定实现接入适合存图片、视频、备份归档这类非结构化数据。我见过有人把数据库放到 NFS 上跑结果性能惨不忍睹还时不时出现锁竞争问题。也见过把纯静态文件塞进块存储白白浪费了高性能。选型的第一步不是看哪个方案火而是看你的负载到底需要什么访问模式这个搞错了后面怎么调都是白搭。3.2 常见 CSI 驱动方案对比下面这张表是我根据实际使用和社区反馈整理的覆盖了几种常见的存储类型。注意这里说的是存储类型不是具体产品具体产品只要实现了对应 CSI 驱动特性大同小异。存储类型典型访问模式性能表现部署复杂度适用场景主要坑点本地盘 CSIRWO极高低缓存、临时数据、高性能单实例节点故障数据丢失无法漂移网络块存储RWO高中数据库、有状态中间件依赖网络attach/detach 有延迟网络文件存储RWX中中共享配置、多副本日志、CI 缓存并发写一致性锁机制分布式存储RWO/RWX中高高大规模集群、自建存储运维成本高脑裂风险对象存储 CSIRWX挂载低低大数据、备份、归档不适合高频随机写本地盘 CSI 的性能是最好的因为它直接用的是节点上的 NVMe 或者 SSD没有网络开销。但它的致命问题是数据跟节点绑定节点挂了数据就没了Pod 也没法漂移到其他节点。所以它只适合那些数据可以重建的场景比如缓存层、临时计算中间结果。如果你非要用它跑数据库那必须自己做数据复制和故障转移复杂度一下子就上去了。网络块存储是生产环境里跑数据库最常见的选择。它通过 iSCSI 或者 NVMe-oF 把远端的块设备挂到节点上性能比本地盘差一些但胜在数据跟节点解耦Pod 可以漂移。它的坑主要在两个地方一是 attach/detach 有延迟节点故障后卷重新挂到新节点可能需要几十秒甚至几分钟这期间 Pod 一直起不来二是有些存储对单节点挂载数量有限制节点上 Pod 多了会挂不上。网络文件存储的 RWX 能力是它的核心价值。多副本服务同时读写同一个目录这在块存储上做不到。但文件存储的并发写一致性是个大问题不同实现的行为差异很大。有的用锁有的用版本号有的干脆不管。如果你的应用对并发写有强一致性要求用文件存储之前一定要确认底层实现能不能满足。3.3 选型时容易被忽略的三个维度除了访问模式和性能还有三个维度经常被忽略但生产环境里往往就是它们出问题。第一个是快照与备份能力。不是所有 CSI 驱动都实现了快照接口。如果你的业务需要定期备份数据选型时必须确认驱动支持 VolumeSnapshot并且底层存储的快照是崩溃一致的还是应用一致的。崩溃一致只能保证数据不损坏但可能包含未完成的事务应用一致需要配合应用层的冻结和解冻操作复杂度更高。第二个是扩容能力。业务增长后卷不够用是常态能不能在线扩容直接决定了你要不要停机迁移数据。CSI 的扩容需要驱动实现 ControllerExpandVolume 接口并且 StorageClass 里要设置allowVolumeExpansion: true。有些存储只支持扩容不支持缩容有些扩容后需要重启 Pod 才能生效这些细节都要提前确认。第三个是拓扑感知。在跨可用区部署的集群里卷和节点必须在同一个可用区才能挂载。CSI 驱动通过 topology keys 告诉调度器这个约束调度器据此把 Pod 调度到正确的可用区。如果驱动没实现拓扑感知或者 StorageClass 里没配置Pod 可能被调度到挂不上卷的节点一直卡在 ContainerCreating。这个坑在多可用区集群里非常常见。4. 生产级实施的关键步骤与配置要点4.1 部署 CSI 驱动前的环境检查清单在动手部署任何 CSI 驱动之前有几项环境检查必须做否则后面出问题排查起来会很痛苦。首先是内核版本和依赖。不同的 CSI 驱动对内核有不同要求比如 iSCSI 需要iscsi_tcp模块NVMe-oF 需要nvme-tcp模块NFS 需要nfs模块。这些模块如果没加载节点上的 CSI Node 组件会报错但错误信息往往很隐晦。建议在部署前用lsmod确认相关模块已经加载并且配置了开机自动加载。其次是容器运行时配置。CSI 驱动需要跟 kubelet 的插件目录通信默认路径是/var/lib/kubelet/plugins和/var/lib/kubelet/plugins_registry。这些目录必须正确挂载到 CSI 驱动的 Pod 里否则驱动注册不上。另外如果用的是 containerd 或者 CRI-O要确认它们的配置里没有限制挂载传播mount propagationCSI 需要rshared传播模式。第三是RBAC 和 ServiceAccount。CSI 驱动的各个组件需要不同的权限Controller 需要创建删除 PV、PVC、VolumeAttachment 等资源的权限Node 需要读取节点信息和更新 CSINode 的权限。社区提供的部署清单里通常已经包含了这些 RBAC 配置但如果你用的是厂商定制的清单一定要检查权限是否完整。权限不足的表现是驱动日志里出现大量 forbidden 错误但 Pod 本身是 Running 状态很容易被忽略。第四是存储后端的连通性。在部署驱动之前先在节点上手动测试能不能访问存储后端。比如 iSCSI 用iscsiadm -m discovery测试发现 portalNFS 用showmount -e测试导出列表对象存储用 curl 测试 endpoint 可达性。这一步能提前排除网络策略、防火墙、认证配置的问题避免部署完驱动才发现连不上。4.2 StorageClass 的参数设计与默认类配置StorageClass 是连接 PVC 和底层存储的桥梁它的参数设计直接决定了卷的行为。下面是一个典型的 StorageClass 示例我逐字段说明。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd annotations: storageclass.kubernetes.io/is-default-class: true provisioner: csi.example.com parameters: type: ssd iops: 3000 throughput: 250 fsType: ext4 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer mountOptions: - noatime - nodiratimeprovisioner字段必须跟 CSI 驱动注册的名字完全一致写错了 PVC 会一直 Pending。parameters里的内容由驱动定义不同驱动支持的参数完全不同必须查对应驱动的文档。reclaimPolicy建议生产环境用Retain而不是Delete这样即使 PVC 被误删底层卷还在数据不会丢可以手动恢复。volumeBindingMode强烈建议用WaitForFirstConsumer它会让卷的创建延迟到 Pod 调度之后这样调度器能根据 Pod 的节点选择器和卷的拓扑约束做出正确决策。如果用Immediate卷可能在 Pod 调度前就创建在某个可用区结果 Pod 被调度到另一个可用区挂不上。mountOptions里的noatime和nodiratime是文件系统挂载选项能减少不必要的元数据写入对性能有提升。但要注意不是所有文件系统都支持这些选项写错了会导致挂载失败。fsType也要跟底层存储和操作系统兼容比如 ext4 通用性好xfs 在大文件场景下表现更好但有些存储只支持特定文件系统。默认 StorageClass 的配置要谨慎。一个集群里最好只有一个默认类多个默认类会导致 PVC 不指定 storageClassName 时行为不确定。设置默认类的 annotation 是storageclass.kubernetes.io/is-default-class: true注意不同 Kubernetes 版本这个 annotation 可能有变化部署前确认一下版本文档。4.3 PVC 与 PV 的绑定机制与常见卡点PVC 和 PV 的绑定看似简单实际生产里卡住的情况非常多。绑定过程大致是PVC 创建后如果指定了 storageClassNameprovisioner 会尝试动态创建 PV如果没有指定且集群有默认类用默认类如果指定了但不存在的类PVC 永远 Pending。PVC Pending 是最常见的故障排查思路是先用kubectl describe pvc看 Events里面通常会有明确的原因。常见原因有这么几类provisioner 没部署或者没正常运行Events 里会显示等待外部 provisioner存储后端容量不足或者配额超限Events 里会有创建卷失败的信息拓扑约束不满足比如 PVC 要求的可用区没有可用节点StorageClass 参数错误驱动返回参数校验失败。还有一种情况是 PVC 和 PV 都正常但 Pod 挂载失败。这时候要看 Pod 的 Events 和 kubelet 日志。如果卡在MountVolume.WaitForAttach说明卷 attach 到节点这一步没完成可能是存储后端 attach 慢或者失败。如果卡在MountVolume.SetUp说明 attach 完成了但挂载失败可能是文件系统格式化问题或者挂载点冲突。如果卡在FailedMount并且提示timeout expired waiting for volumes to attach or mount那基本就是 attach 或者 mount 超时了需要去查 CSI Node 的日志。提示PVC 的 accessModes 必须跟底层存储实际支持的模式匹配。有些存储虽然声明支持 RWX但实际是通过 NFS 网关实现的性能和一致性跟原生文件存储有差距。选型时不要只看声明要看实际实现。4.4 有状态负载的存储配置实战拿一个典型的有状态服务来说比如一个需要持久化数据的消息中间件。它的存储需求通常是单实例 RWO、高 IOPS、数据不能丢、支持快照备份。对应的配置思路是这样的。StatefulSet 的 volumeClaimTemplates 里定义 PVC 模板每个 Pod 会生成一个独立的 PVC命名规则是模板名-StatefulSet名-序号。这样每个副本有独立的卷数据不会互相干扰。storageClassName 指向高性能块存储的类accessModes 用 ReadWriteOnceresources.requests.storage 根据数据量预估建议留 30% 以上的余量。volumeClaimTemplates: - metadata: name: data spec: accessModes: [ReadWriteOnce] storageClassName: fast-ssd resources: requests: storage: 100Gi这里有个细节StatefulSet 缩容的时候对应的 PVC 不会自动删除这是有意设计的防止误删数据。如果你确认数据不需要了要手动删 PVC。扩容的时候新的 Pod 会创建新的 PVC但已有的 PVC 不会自动扩容需要手动 patch PVC 的 storage 字段前提是 StorageClass 开启了 allowVolumeExpansion。对于需要共享存储的多副本服务比如多个 Pod 同时读同一份配置或者写同一个日志目录就要用 RWX 的 PVC。这时候要注意并发写的语义如果多个 Pod 同时写同一个文件没有锁机制的话数据会错乱。建议应用层自己做文件锁或者分片写不要依赖存储层保证并发写一致性。5. 生产环境常见故障与排查实录5.1 卷挂载失败的排查路径卷挂载失败是 CSI 相关故障里最高频的表现是 Pod 一直 ContainerCreatingEvents 里有 FailedMount 或者 FailedAttachVolume。排查的时候我习惯按下面的顺序走基本能覆盖九成以上的情况。第一步看 Pod 的 Events确认卡在哪一步。是 attach 没完成还是 mount 没完成还是格式化失败。Events 里的信息虽然简略但方向是明确的。第二步看 CSI Controller 的日志。attach 相关的问题在这里能找到原因比如存储后端 API 调用失败、认证过期、配额不足。日志里通常有具体的错误码和错误信息比 Events 详细得多。第三步看对应节点上 CSI Node 的日志。mount 和格式化的问题在这里。常见的有设备路径不对、文件系统损坏、挂载点被占用、权限不足。如果是 iSCSI还要看 iscsid 服务的日志确认 session 是否建立成功。第四步上节点手动排查。用lsblk看块设备有没有出现用mount看挂载点状态用dmesg看内核有没有报错。有时候 CSI 日志里看不出来的问题内核日志里一目了然比如设备超时、IO 错误、文件系统校验失败。我遇到过一个案例Pod 一直卡在 mount 阶段CSI Node 日志显示格式化成功但挂载失败最后上节点发现是之前异常终止的挂载点残留目录被占用导致新挂载失败。清理残留目录后恢复正常。这种问题在节点异常重启后比较常见建议在 CSI Node 的启动逻辑里加上清理残留挂载点的步骤或者用mountPropagation: Bidirectional让 kubelet 能感知到挂载变化。5.2 卷扩容不生效的原因分析PVC 扩容后容量没变化也是高频问题。扩容的完整链路是用户修改 PVC 的 storage 字段external-resizer 监听到变化调用 CSI Controller 的 ControllerExpandVolume 接口底层存储扩容然后 resizer 更新 PV 的容量最后 kubelet 在节点上扩容文件系统。卡点通常在这几个地方。一是 StorageClass 没开 allowVolumeExpansionPVC 修改会被拒绝Events 里会有明确提示。二是驱动没实现 ControllerExpandVolumeresizer 日志里会报 unsupported。三是底层存储扩容成功但文件系统没扩容这时候 PVC 和 PV 的容量显示是新的但容器里df -h看到的还是旧容量。这种情况需要重启 Pod 触发文件系统扩容或者手动在节点上执行 resize2fs 或 xfs_growfs。注意文件系统扩容只能在卷挂载状态下进行如果 Pod 没运行扩容会卡住。所以在线扩容的前提是 Pod 处于 Running 状态并且文件系统支持在线扩容。ext4 和 xfs 都支持在线扩容但 xfs 只能扩不能缩。还有一个容易忽略的点有些存储的扩容是异步的API 返回成功不代表底层已经完成。这时候 resizer 会不断重试直到确认扩容完成。如果底层扩容特别慢PVC 会长时间处于 Resizing 状态这是正常的不要急着去干预。5.3 节点故障后的卷恢复流程节点故障是有状态服务最怕的场景。节点挂了之后上面的 Pod 需要漂移到其他节点卷也要重新 attach 到新节点。这个过程能不能顺利完成取决于几个因素。首先是卷的 attach 语义。如果底层存储是 RWO 且不支持多节点挂载那么卷必须先从前一个节点 detach 才能 attach 到新节点。如果前一个节点已经彻底失联detach 操作可能会超时Kubernetes 默认等待 6 分钟由node-monitor-grace-period和pod-eviction-timeout控制后才强制 detach。这期间 Pod 一直起不来。可以通过调整这些参数缩短等待时间但调太短会导致网络抖动时误判节点故障引发不必要的漂移。其次是多挂载保护。Kubernetes 有 VolumeAttachment 对象来记录卷和节点的绑定关系正常情况下一个 RWO 卷只能有一个 VolumeAttachment。如果节点故障后 VolumeAttachment 没被清理新节点上的 attach 会被拒绝。这时候需要手动删除残留的 VolumeAttachment 对象但删之前一定要确认旧节点确实不会再访问这个卷否则会出现两个节点同时写同一个卷数据直接损坏。第三是数据一致性。节点故障时如果卷上还有未刷盘的数据强制 detach 后这些数据可能丢失或者损坏。对于数据库这类对一致性要求高的服务建议在应用层做数据复制比如主从架构节点故障时从库接管而不是依赖单卷漂移。单卷漂移只能保证数据不丢但保证不了数据一致。5.4 常见问题速查表现象可能原因排查方向解决思路PVC 一直 Pendingprovisioner 未运行/参数错误/容量不足describe pvc 看 Events查 provisioner 日志修复驱动或调整参数Pod 卡 ContainerCreatingattach 失败/mount 失败describe pod 看 Events查 CSI 日志按 attach/mount 分别排查扩容后容量不变文件系统未扩容容器内 df -h 确认重启 Pod 或手动 resize节点故障后 Pod 起不来VolumeAttachment 残留查 VolumeAttachment 对象确认安全后手动删除多副本写数据错乱并发写无锁检查应用写逻辑应用层加锁或分片快照创建失败驱动不支持/后端配额查 snapshotter 日志确认驱动能力或清理配额6. 几个我踩过的坑和总结的经验6.1 别在 StorageClass 里写死太多参数我早期做选型的时候喜欢把一堆参数塞进 StorageClass 的 parameters 里觉得这样统一管理方便。后来发现这是个坑。不同业务对存储的需求差异很大有的要高性能有的要低成本有的要特定文件系统。如果都用一个 StorageClass要么参数取折中谁都不满意要么就得频繁改 StorageClass影响面太大。正确的做法是按业务维度拆分多个 StorageClass比如高性能类、标准类、低成本类、共享文件类。每个类只放该类业务共性的参数个性化的参数通过 PVC 的 annotation 或者驱动支持的其他方式传入。这样既保持了统一管理又保留了灵活性。StorageClass 的数量不用怕多它本身是轻量对象多几个不影响性能。6.2 监控和告警要覆盖存储层存储故障往往不是突然发生的而是有前兆的。容量快满了、IO 延迟升高了、attach 耗时变长了这些都是信号。如果只监控 Pod 和节点不监控存储层等故障爆发的时候就被动了。我建议至少监控这几个指标PVC 的使用率和剩余容量、卷的 IOPS 和吞吐、attach 和 mount 的耗时、CSI 各组件的错误率和重启次数、存储后端的健康状态。容量告警阈值建议设在 80%因为从 80% 到 100% 可能只需要几个小时留出处理时间。attach 耗时如果持续超过 30 秒就要查原因了正常应该在几秒内完成。6.3 定期做故障演练存储的故障恢复流程不演练是不知道能不能走通的。我见过团队写了厚厚的应急预案真出事的时候发现步骤对不上或者权限不够或者工具版本不兼容。建议定期做演练比如模拟节点故障看 Pod 能不能自动漂移卷能不能重新挂载数据是否完整。模拟存储后端故障看应用的表现和恢复时间。模拟误删 PVC看备份能不能恢复。演练的时候要记录每一步的耗时和遇到的问题这些数据是优化应急预案的依据。演练完要复盘把发现的问题落实到具体的改进项上。存储这层的东西平时不出事一出事就是大事提前演练的成本远低于事故的损失。6.4 版本兼容性要提前确认CSI 驱动、Kubernetes 版本、容器运行时版本、操作系统内核版本这四者之间的兼容性矩阵一定要提前确认。我遇到过一次升级 Kubernetes 之后 CSI 驱动不工作的情况原因是驱动依赖的某个 API 版本在新版本里被废弃了。也遇到过操作系统内核升级后 iSCSI 模块行为变化导致挂载失败的情况。建议在升级任何一环之前先查驱动的 release notes 和兼容性说明在测试环境验证通过后再上生产。升级顺序也有讲究一般是先升级 CSI 驱动到兼容新 Kubernetes 的版本再升级 Kubernetes最后升级操作系统。每一步之间留出观察期确认稳定后再进行下一步。6.5 数据备份不能只依赖快照快照很方便但它不是备份。快照通常跟源卷在同一个存储系统里如果存储系统故障或者被误操作快照和源数据一起丢。而且快照的保留策略往往有限时间长了会被自动清理。真正的备份应该是异地的、独立的、可验证的。我的做法是快照加定期全量备份双管齐下。快照用于快速恢复近期误操作全量备份用于灾难恢复。全量备份要存到独立的存储系统定期做恢复验证确保备份数据是可用的。备份的保留周期根据业务要求定关键业务至少保留 30 天并且要有多份副本。存储这层的东西说到底就是要在性能、成本、可靠性之间找平衡。没有银弹只有适合当前业务阶段的方案。我自己的体会是早期业务快速迭代的时候用托管存储服务省心把精力放在业务上业务稳定后如果成本压力大或者有特殊需求再考虑自建或者混合方案。不管选哪种CSI 这套机制都是绕不开的把它的原理和排查方法吃透遇到问题就不会慌。 
长河君 · 2026/10/23 5:38:08 · 阅读 1.2k Kubernetes CSI 存储实战：原理、选型与生产环境避坑指南
1. 为什么容器存储这件事值得单独拎出来讲很多人刚接触容器编排的时候注意力几乎全被调度、网络、服务发现这些话题吸走了存储往往被放到最后才想起来。结果就是应用跑起来了日志一重启就丢数据库一漂移就崩文件上传到某个节点上换个副本就找不到了。我见过太多团队在测试环境里用默认配置跑得好好的一上生产就各种数据不一致回头排查半天发现根子上就是存储这一层没设计好。Kubernetes 的存储体系之所以让人头疼是因为它不像无状态服务那样可以随便重建。有状态负载对数据的持久性、一致性、访问模式都有硬性要求而这些要求又跟底层基础设施强绑定。你用的是本地盘、网络块存储、文件存储还是对象存储直接决定了能支持什么样的工作负载。更麻烦的是Kubernetes 本身并不直接管理存储它通过一层抽象把存储能力接进来这层抽象就是 CSI也就是容器存储接口。这篇内容想做的事情很明确把 CSI 这套机制从原理到落地讲透把市面上主流的存储方案拉出来做横向对比再把我自己在生产环境里踩过的坑和总结出来的实施要点摊开说。不管你是刚接手一个有状态服务的运维还是正在为团队选型的架构师或者只是想把数据库稳稳当当跑在集群里的开发者都能从这里找到能直接用的东西。我不会只讲概念每个环节都会落到具体配置和参数上让你看完能动手。2. CSI 到底解决了什么问题它的工作原理是什么2.1 从 in-tree 到 out-of-tree 的演进逻辑要理解 CSI 的价值得先知道它出现之前是什么样子。早期 Kubernetes 把各种存储驱动的代码直接塞在主仓库里这叫 in-tree 模式。AWS、GCE、Ceph、GlusterFS 这些存储的适配代码全都跟 Kubernetes 核心代码耦合在一起。这种做法的毛病非常明显存储厂商想发一个新版本得等 Kubernetes 发版Kubernetes 想升级得保证不破坏所有内置驱动的兼容性。两边节奏完全对不上社区维护成本高得离谱而且主仓库越来越臃肿。CSI 的思路是把存储驱动从核心代码里彻底剥离出来定义一套标准的 gRPC 接口任何存储厂商只要实现这套接口就能以独立进程的方式跟 Kubernetes 对接。这个进程通常以 DaemonSet 或者 Deployment 的形式跑在集群里通过 Unix Domain Socket 跟 kubelet 通信。这样一来存储厂商可以独立迭代自己的驱动Kubernetes 也不用再背着一堆存储代码的包袱。这个转变的本质是把存储集成从编译期绑定变成了运行期插件灵活性和可维护性完全不是一个量级。2.2 CSI 的三个核心组件与调用链路CSI 驱动在集群里通常由三个部分组成理解这三者的分工是排查问题的前提。第一个是CSI Controller一般以 Deployment 形式部署副本数不用多它负责的是集群级别的操作比如创建和删除卷、挂载和卸载卷到某个节点、创建快照、扩容等。这些操作往往需要调用底层存储的 API属于控制面行为。第二个是CSI Node必须以 DaemonSet 形式跑在每个节点上因为卷最终要挂到具体节点上。它负责节点级别的操作比如把卷格式化并挂载到宿主机的某个目录然后把挂载点告诉 kubelet。这个组件跟节点强绑定节点上没跑起来Pod 就挂不上卷。第三个是external-provisioner、external-attacher、external-resizer、external-snapshotter这一组 sidecar 容器。它们其实是 Kubernetes 社区提供的通用组件负责监听 API Server 里的 PV、PVC、VolumeAttachment 等资源变化然后调用 CSI 驱动暴露的 gRPC 接口。为什么要拆成 sidecar 而不是让驱动自己监听因为这样驱动只需要专注实现存储逻辑跟 Kubernetes API 打交道的脏活累活由社区统一维护的组件来干降低了驱动开发的门槛。整个调用链路大致是这样的用户创建一个 PVCexternal-provisioner 监听到之后调用 CSI Controller 的 CreateVolume 接口底层存储创建出卷然后返回卷信息provisioner 据此创建 PV 对象。Pod 调度到某个节点后external-attacher 调用 ControllerPublishVolume 把卷 attach 到节点kubelet 再通过 CSI Node 的 NodeStageVolume 和 NodePublishVolume 把卷挂载到容器里。删除的时候反向走一遍。这条链路里任何一环出问题Pod 都会卡在 ContainerCreating 状态所以排查的时候要顺着链路一段段看。2.3 卷的生命周期与关键接口CSI 定义了一组 gRPC 接口每个接口对应卷生命周期的一个阶段。我把最核心的几个列出来配合说明它们什么时候被调用。接口名称调用方触发时机作用CreateVolumeexternal-provisionerPVC 创建且需要动态供给在底层存储创建卷DeleteVolumeexternal-provisionerPV 被删除删除底层存储的卷ControllerPublishVolumeexternal-attacherPod 调度到节点把卷 attach 到节点ControllerUnpublishVolumeexternal-attacherPod 从节点移除把卷从节点 detachNodeStageVolumekubelet卷首次挂到节点格式化并挂载到全局目录NodePublishVolumekubelet容器启动把全局挂载点 bind mount 到容器NodeUnstageVolumekubelet卷从节点卸载卸载全局挂载CreateSnapshotexternal-snapshotterVolumeSnapshot 创建创建卷快照这里有个容易混淆的点NodeStageVolume 和 NodePublishVolume 的区别。Stage 是把卷挂到节点上的一个全局目录比如/var/lib/kubelet/plugins/kubernetes.io/csi/...这个操作对同一个卷在同一个节点上只做一次。Publish 是把 Stage 好的目录 bind mount 到具体 Pod 的挂载点每个 Pod 都要做一次。为什么要分两步因为一个卷可能被同一个节点上的多个 Pod 共享比如 ReadWriteMany 模式Stage 一次就够了Publish 按 Pod 来。理解这个分层排查挂载问题时就能快速定位是卡在 Stage 还是 Publish。3. 主流存储方案横向对比与选型思路3.1 块存储、文件存储、对象存储的适用边界选存储方案之前先要搞清楚你的负载需要哪种访问模式。Kubernetes 里 PVC 的 accessModes 有三种ReadWriteOnceRWO、ReadOnlyManyROX、ReadWriteManyRWX。这三种模式直接对应了底层存储的类型。块存储通常只支持 RWO也就是同一时刻只能被一个节点挂载读写。它性能好、延迟低适合数据库、消息队列这类对 IO 要求高的单实例有状态服务。文件存储支持 RWX多个节点可以同时挂载读写适合共享配置文件、多副本同时写日志、CI 构建缓存这类场景。对象存储不走 PVC 这套通常通过 SDK 或者 CSI 的特定实现接入适合存图片、视频、备份归档这类非结构化数据。我见过有人把数据库放到 NFS 上跑结果性能惨不忍睹还时不时出现锁竞争问题。也见过把纯静态文件塞进块存储白白浪费了高性能。选型的第一步不是看哪个方案火而是看你的负载到底需要什么访问模式这个搞错了后面怎么调都是白搭。3.2 常见 CSI 驱动方案对比下面这张表是我根据实际使用和社区反馈整理的覆盖了几种常见的存储类型。注意这里说的是存储类型不是具体产品具体产品只要实现了对应 CSI 驱动特性大同小异。存储类型典型访问模式性能表现部署复杂度适用场景主要坑点本地盘 CSIRWO极高低缓存、临时数据、高性能单实例节点故障数据丢失无法漂移网络块存储RWO高中数据库、有状态中间件依赖网络attach/detach 有延迟网络文件存储RWX中中共享配置、多副本日志、CI 缓存并发写一致性锁机制分布式存储RWO/RWX中高高大规模集群、自建存储运维成本高脑裂风险对象存储 CSIRWX挂载低低大数据、备份、归档不适合高频随机写本地盘 CSI 的性能是最好的因为它直接用的是节点上的 NVMe 或者 SSD没有网络开销。但它的致命问题是数据跟节点绑定节点挂了数据就没了Pod 也没法漂移到其他节点。所以它只适合那些数据可以重建的场景比如缓存层、临时计算中间结果。如果你非要用它跑数据库那必须自己做数据复制和故障转移复杂度一下子就上去了。网络块存储是生产环境里跑数据库最常见的选择。它通过 iSCSI 或者 NVMe-oF 把远端的块设备挂到节点上性能比本地盘差一些但胜在数据跟节点解耦Pod 可以漂移。它的坑主要在两个地方一是 attach/detach 有延迟节点故障后卷重新挂到新节点可能需要几十秒甚至几分钟这期间 Pod 一直起不来二是有些存储对单节点挂载数量有限制节点上 Pod 多了会挂不上。网络文件存储的 RWX 能力是它的核心价值。多副本服务同时读写同一个目录这在块存储上做不到。但文件存储的并发写一致性是个大问题不同实现的行为差异很大。有的用锁有的用版本号有的干脆不管。如果你的应用对并发写有强一致性要求用文件存储之前一定要确认底层实现能不能满足。3.3 选型时容易被忽略的三个维度除了访问模式和性能还有三个维度经常被忽略但生产环境里往往就是它们出问题。第一个是快照与备份能力。不是所有 CSI 驱动都实现了快照接口。如果你的业务需要定期备份数据选型时必须确认驱动支持 VolumeSnapshot并且底层存储的快照是崩溃一致的还是应用一致的。崩溃一致只能保证数据不损坏但可能包含未完成的事务应用一致需要配合应用层的冻结和解冻操作复杂度更高。第二个是扩容能力。业务增长后卷不够用是常态能不能在线扩容直接决定了你要不要停机迁移数据。CSI 的扩容需要驱动实现 ControllerExpandVolume 接口并且 StorageClass 里要设置allowVolumeExpansion: true。有些存储只支持扩容不支持缩容有些扩容后需要重启 Pod 才能生效这些细节都要提前确认。第三个是拓扑感知。在跨可用区部署的集群里卷和节点必须在同一个可用区才能挂载。CSI 驱动通过 topology keys 告诉调度器这个约束调度器据此把 Pod 调度到正确的可用区。如果驱动没实现拓扑感知或者 StorageClass 里没配置Pod 可能被调度到挂不上卷的节点一直卡在 ContainerCreating。这个坑在多可用区集群里非常常见。4. 生产级实施的关键步骤与配置要点4.1 部署 CSI 驱动前的环境检查清单在动手部署任何 CSI 驱动之前有几项环境检查必须做否则后面出问题排查起来会很痛苦。首先是内核版本和依赖。不同的 CSI 驱动对内核有不同要求比如 iSCSI 需要iscsi_tcp模块NVMe-oF 需要nvme-tcp模块NFS 需要nfs模块。这些模块如果没加载节点上的 CSI Node 组件会报错但错误信息往往很隐晦。建议在部署前用lsmod确认相关模块已经加载并且配置了开机自动加载。其次是容器运行时配置。CSI 驱动需要跟 kubelet 的插件目录通信默认路径是/var/lib/kubelet/plugins和/var/lib/kubelet/plugins_registry。这些目录必须正确挂载到 CSI 驱动的 Pod 里否则驱动注册不上。另外如果用的是 containerd 或者 CRI-O要确认它们的配置里没有限制挂载传播mount propagationCSI 需要rshared传播模式。第三是RBAC 和 ServiceAccount。CSI 驱动的各个组件需要不同的权限Controller 需要创建删除 PV、PVC、VolumeAttachment 等资源的权限Node 需要读取节点信息和更新 CSINode 的权限。社区提供的部署清单里通常已经包含了这些 RBAC 配置但如果你用的是厂商定制的清单一定要检查权限是否完整。权限不足的表现是驱动日志里出现大量 forbidden 错误但 Pod 本身是 Running 状态很容易被忽略。第四是存储后端的连通性。在部署驱动之前先在节点上手动测试能不能访问存储后端。比如 iSCSI 用iscsiadm -m discovery测试发现 portalNFS 用showmount -e测试导出列表对象存储用 curl 测试 endpoint 可达性。这一步能提前排除网络策略、防火墙、认证配置的问题避免部署完驱动才发现连不上。4.2 StorageClass 的参数设计与默认类配置StorageClass 是连接 PVC 和底层存储的桥梁它的参数设计直接决定了卷的行为。下面是一个典型的 StorageClass 示例我逐字段说明。apiVersion: storage.k8s.io/v1 kind: StorageClass metadata: name: fast-ssd annotations: storageclass.kubernetes.io/is-default-class: true provisioner: csi.example.com parameters: type: ssd iops: 3000 throughput: 250 fsType: ext4 reclaimPolicy: Delete allowVolumeExpansion: true volumeBindingMode: WaitForFirstConsumer mountOptions: - noatime - nodiratimeprovisioner字段必须跟 CSI 驱动注册的名字完全一致写错了 PVC 会一直 Pending。parameters里的内容由驱动定义不同驱动支持的参数完全不同必须查对应驱动的文档。reclaimPolicy建议生产环境用Retain而不是Delete这样即使 PVC 被误删底层卷还在数据不会丢可以手动恢复。volumeBindingMode强烈建议用WaitForFirstConsumer它会让卷的创建延迟到 Pod 调度之后这样调度器能根据 Pod 的节点选择器和卷的拓扑约束做出正确决策。如果用Immediate卷可能在 Pod 调度前就创建在某个可用区结果 Pod 被调度到另一个可用区挂不上。mountOptions里的noatime和nodiratime是文件系统挂载选项能减少不必要的元数据写入对性能有提升。但要注意不是所有文件系统都支持这些选项写错了会导致挂载失败。fsType也要跟底层存储和操作系统兼容比如 ext4 通用性好xfs 在大文件场景下表现更好但有些存储只支持特定文件系统。默认 StorageClass 的配置要谨慎。一个集群里最好只有一个默认类多个默认类会导致 PVC 不指定 storageClassName 时行为不确定。设置默认类的 annotation 是storageclass.kubernetes.io/is-default-class: true注意不同 Kubernetes 版本这个 annotation 可能有变化部署前确认一下版本文档。4.3 PVC 与 PV 的绑定机制与常见卡点PVC 和 PV 的绑定看似简单实际生产里卡住的情况非常多。绑定过程大致是PVC 创建后如果指定了 storageClassNameprovisioner 会尝试动态创建 PV如果没有指定且集群有默认类用默认类如果指定了但不存在的类PVC 永远 Pending。PVC Pending 是最常见的故障排查思路是先用kubectl describe pvc看 Events里面通常会有明确的原因。常见原因有这么几类provisioner 没部署或者没正常运行Events 里会显示等待外部 provisioner存储后端容量不足或者配额超限Events 里会有创建卷失败的信息拓扑约束不满足比如 PVC 要求的可用区没有可用节点StorageClass 参数错误驱动返回参数校验失败。还有一种情况是 PVC 和 PV 都正常但 Pod 挂载失败。这时候要看 Pod 的 Events 和 kubelet 日志。如果卡在MountVolume.WaitForAttach说明卷 attach 到节点这一步没完成可能是存储后端 attach 慢或者失败。如果卡在MountVolume.SetUp说明 attach 完成了但挂载失败可能是文件系统格式化问题或者挂载点冲突。如果卡在FailedMount并且提示timeout expired waiting for volumes to attach or mount那基本就是 attach 或者 mount 超时了需要去查 CSI Node 的日志。提示PVC 的 accessModes 必须跟底层存储实际支持的模式匹配。有些存储虽然声明支持 RWX但实际是通过 NFS 网关实现的性能和一致性跟原生文件存储有差距。选型时不要只看声明要看实际实现。4.4 有状态负载的存储配置实战拿一个典型的有状态服务来说比如一个需要持久化数据的消息中间件。它的存储需求通常是单实例 RWO、高 IOPS、数据不能丢、支持快照备份。对应的配置思路是这样的。StatefulSet 的 volumeClaimTemplates 里定义 PVC 模板每个 Pod 会生成一个独立的 PVC命名规则是模板名-StatefulSet名-序号。这样每个副本有独立的卷数据不会互相干扰。storageClassName 指向高性能块存储的类accessModes 用 ReadWriteOnceresources.requests.storage 根据数据量预估建议留 30% 以上的余量。volumeClaimTemplates: - metadata: name: data spec: accessModes: [ReadWriteOnce] storageClassName: fast-ssd resources: requests: storage: 100Gi这里有个细节StatefulSet 缩容的时候对应的 PVC 不会自动删除这是有意设计的防止误删数据。如果你确认数据不需要了要手动删 PVC。扩容的时候新的 Pod 会创建新的 PVC但已有的 PVC 不会自动扩容需要手动 patch PVC 的 storage 字段前提是 StorageClass 开启了 allowVolumeExpansion。对于需要共享存储的多副本服务比如多个 Pod 同时读同一份配置或者写同一个日志目录就要用 RWX 的 PVC。这时候要注意并发写的语义如果多个 Pod 同时写同一个文件没有锁机制的话数据会错乱。建议应用层自己做文件锁或者分片写不要依赖存储层保证并发写一致性。5. 生产环境常见故障与排查实录5.1 卷挂载失败的排查路径卷挂载失败是 CSI 相关故障里最高频的表现是 Pod 一直 ContainerCreatingEvents 里有 FailedMount 或者 FailedAttachVolume。排查的时候我习惯按下面的顺序走基本能覆盖九成以上的情况。第一步看 Pod 的 Events确认卡在哪一步。是 attach 没完成还是 mount 没完成还是格式化失败。Events 里的信息虽然简略但方向是明确的。第二步看 CSI Controller 的日志。attach 相关的问题在这里能找到原因比如存储后端 API 调用失败、认证过期、配额不足。日志里通常有具体的错误码和错误信息比 Events 详细得多。第三步看对应节点上 CSI Node 的日志。mount 和格式化的问题在这里。常见的有设备路径不对、文件系统损坏、挂载点被占用、权限不足。如果是 iSCSI还要看 iscsid 服务的日志确认 session 是否建立成功。第四步上节点手动排查。用lsblk看块设备有没有出现用mount看挂载点状态用dmesg看内核有没有报错。有时候 CSI 日志里看不出来的问题内核日志里一目了然比如设备超时、IO 错误、文件系统校验失败。我遇到过一个案例Pod 一直卡在 mount 阶段CSI Node 日志显示格式化成功但挂载失败最后上节点发现是之前异常终止的挂载点残留目录被占用导致新挂载失败。清理残留目录后恢复正常。这种问题在节点异常重启后比较常见建议在 CSI Node 的启动逻辑里加上清理残留挂载点的步骤或者用mountPropagation: Bidirectional让 kubelet 能感知到挂载变化。5.2 卷扩容不生效的原因分析PVC 扩容后容量没变化也是高频问题。扩容的完整链路是用户修改 PVC 的 storage 字段external-resizer 监听到变化调用 CSI Controller 的 ControllerExpandVolume 接口底层存储扩容然后 resizer 更新 PV 的容量最后 kubelet 在节点上扩容文件系统。卡点通常在这几个地方。一是 StorageClass 没开 allowVolumeExpansionPVC 修改会被拒绝Events 里会有明确提示。二是驱动没实现 ControllerExpandVolumeresizer 日志里会报 unsupported。三是底层存储扩容成功但文件系统没扩容这时候 PVC 和 PV 的容量显示是新的但容器里df -h看到的还是旧容量。这种情况需要重启 Pod 触发文件系统扩容或者手动在节点上执行 resize2fs 或 xfs_growfs。注意文件系统扩容只能在卷挂载状态下进行如果 Pod 没运行扩容会卡住。所以在线扩容的前提是 Pod 处于 Running 状态并且文件系统支持在线扩容。ext4 和 xfs 都支持在线扩容但 xfs 只能扩不能缩。还有一个容易忽略的点有些存储的扩容是异步的API 返回成功不代表底层已经完成。这时候 resizer 会不断重试直到确认扩容完成。如果底层扩容特别慢PVC 会长时间处于 Resizing 状态这是正常的不要急着去干预。5.3 节点故障后的卷恢复流程节点故障是有状态服务最怕的场景。节点挂了之后上面的 Pod 需要漂移到其他节点卷也要重新 attach 到新节点。这个过程能不能顺利完成取决于几个因素。首先是卷的 attach 语义。如果底层存储是 RWO 且不支持多节点挂载那么卷必须先从前一个节点 detach 才能 attach 到新节点。如果前一个节点已经彻底失联detach 操作可能会超时Kubernetes 默认等待 6 分钟由node-monitor-grace-period和pod-eviction-timeout控制后才强制 detach。这期间 Pod 一直起不来。可以通过调整这些参数缩短等待时间但调太短会导致网络抖动时误判节点故障引发不必要的漂移。其次是多挂载保护。Kubernetes 有 VolumeAttachment 对象来记录卷和节点的绑定关系正常情况下一个 RWO 卷只能有一个 VolumeAttachment。如果节点故障后 VolumeAttachment 没被清理新节点上的 attach 会被拒绝。这时候需要手动删除残留的 VolumeAttachment 对象但删之前一定要确认旧节点确实不会再访问这个卷否则会出现两个节点同时写同一个卷数据直接损坏。第三是数据一致性。节点故障时如果卷上还有未刷盘的数据强制 detach 后这些数据可能丢失或者损坏。对于数据库这类对一致性要求高的服务建议在应用层做数据复制比如主从架构节点故障时从库接管而不是依赖单卷漂移。单卷漂移只能保证数据不丢但保证不了数据一致。5.4 常见问题速查表现象可能原因排查方向解决思路PVC 一直 Pendingprovisioner 未运行/参数错误/容量不足describe pvc 看 Events查 provisioner 日志修复驱动或调整参数Pod 卡 ContainerCreatingattach 失败/mount 失败describe pod 看 Events查 CSI 日志按 attach/mount 分别排查扩容后容量不变文件系统未扩容容器内 df -h 确认重启 Pod 或手动 resize节点故障后 Pod 起不来VolumeAttachment 残留查 VolumeAttachment 对象确认安全后手动删除多副本写数据错乱并发写无锁检查应用写逻辑应用层加锁或分片快照创建失败驱动不支持/后端配额查 snapshotter 日志确认驱动能力或清理配额6. 几个我踩过的坑和总结的经验6.1 别在 StorageClass 里写死太多参数我早期做选型的时候喜欢把一堆参数塞进 StorageClass 的 parameters 里觉得这样统一管理方便。后来发现这是个坑。不同业务对存储的需求差异很大有的要高性能有的要低成本有的要特定文件系统。如果都用一个 StorageClass要么参数取折中谁都不满意要么就得频繁改 StorageClass影响面太大。正确的做法是按业务维度拆分多个 StorageClass比如高性能类、标准类、低成本类、共享文件类。每个类只放该类业务共性的参数个性化的参数通过 PVC 的 annotation 或者驱动支持的其他方式传入。这样既保持了统一管理又保留了灵活性。StorageClass 的数量不用怕多它本身是轻量对象多几个不影响性能。6.2 监控和告警要覆盖存储层存储故障往往不是突然发生的而是有前兆的。容量快满了、IO 延迟升高了、attach 耗时变长了这些都是信号。如果只监控 Pod 和节点不监控存储层等故障爆发的时候就被动了。我建议至少监控这几个指标PVC 的使用率和剩余容量、卷的 IOPS 和吞吐、attach 和 mount 的耗时、CSI 各组件的错误率和重启次数、存储后端的健康状态。容量告警阈值建议设在 80%因为从 80% 到 100% 可能只需要几个小时留出处理时间。attach 耗时如果持续超过 30 秒就要查原因了正常应该在几秒内完成。6.3 定期做故障演练存储的故障恢复流程不演练是不知道能不能走通的。我见过团队写了厚厚的应急预案真出事的时候发现步骤对不上或者权限不够或者工具版本不兼容。建议定期做演练比如模拟节点故障看 Pod 能不能自动漂移卷能不能重新挂载数据是否完整。模拟存储后端故障看应用的表现和恢复时间。模拟误删 PVC看备份能不能恢复。演练的时候要记录每一步的耗时和遇到的问题这些数据是优化应急预案的依据。演练完要复盘把发现的问题落实到具体的改进项上。存储这层的东西平时不出事一出事就是大事提前演练的成本远低于事故的损失。6.4 版本兼容性要提前确认CSI 驱动、Kubernetes 版本、容器运行时版本、操作系统内核版本这四者之间的兼容性矩阵一定要提前确认。我遇到过一次升级 Kubernetes 之后 CSI 驱动不工作的情况原因是驱动依赖的某个 API 版本在新版本里被废弃了。也遇到过操作系统内核升级后 iSCSI 模块行为变化导致挂载失败的情况。建议在升级任何一环之前先查驱动的 release notes 和兼容性说明在测试环境验证通过后再上生产。升级顺序也有讲究一般是先升级 CSI 驱动到兼容新 Kubernetes 的版本再升级 Kubernetes最后升级操作系统。每一步之间留出观察期确认稳定后再进行下一步。6.5 数据备份不能只依赖快照快照很方便但它不是备份。快照通常跟源卷在同一个存储系统里如果存储系统故障或者被误操作快照和源数据一起丢。而且快照的保留策略往往有限时间长了会被自动清理。真正的备份应该是异地的、独立的、可验证的。我的做法是快照加定期全量备份双管齐下。快照用于快速恢复近期误操作全量备份用于灾难恢复。全量备份要存到独立的存储系统定期做恢复验证确保备份数据是可用的。备份的保留周期根据业务要求定关键业务至少保留 30 天并且要有多份副本。存储这层的东西说到底就是要在性能、成本、可靠性之间找平衡。没有银弹只有适合当前业务阶段的方案。我自己的体会是早期业务快速迭代的时候用托管存储服务省心把精力放在业务上业务稳定后如果成本压力大或者有特殊需求再考虑自建或者混合方案。不管选哪种CSI 这套机制都是绕不开的把它的原理和排查方法吃透遇到问题就不会慌。