1. CSI 概述：起源、设计目标与 Kubernetes 生态核心地位
1.1 起源：从 in-tree 到 out-of-tree 的必然演进
在 CSI（Container Storage Interface）出现之前，Kubernetes 对存储系统的支持采用 in-tree（树内） 模式：每个存储厂商的驱动代码直接合入 Kubernetes 主干仓库。这种模式在早期快速扩展了生态，但很快暴露出严重问题：
- 发布耦合： 存储驱动的 Bug 修复或新功能必须跟随 Kubernetes 大版本发布，无法独立迭代。
- 代码膨胀： 每个厂商的驱动代码都进入 Kubernetes 核心仓库，导致二进制体积和编译时间持续增长。
- 认证困难： 存储厂商需要深入理解 Kubernetes 内部调度、卷生命周期管理等复杂逻辑，开发门槛极高。
- 安全风险： 驱动代码运行在 kubelet 或 kube-controller-manager 进程中，权限过大，隔离性差。
关键转折点： Kubernetes v1.13（2018 年 12 月）将 CSI 标记为 GA（General Availability），正式宣告存储插件进入 out-of-tree（树外） 时代。所有存储厂商不再需要向 Kubernetes 主干提交代码，而是通过标准 gRPC 接口实现独立插件。
1.2 设计目标：标准化、可移植、解耦
CSI 由 Kubernetes SIG-Storage、Mesos、Docker 等社区联合定义，其核心设计目标可归纳为以下四点：
| 设计目标 | 说明 | 解决的核心问题 |
|---|---|---|
| 标准化接口 | 定义统一的 gRPC 协议，涵盖卷的创建、挂载、快照、扩容等全生命周期操作 | 消除各厂商私有 API 差异，实现“一次适配，到处运行” |
| 容器编排解耦 | CSI 驱动作为独立进程运行，不侵入 Kubernetes 核心组件 | 驱动崩溃不影响 kubelet 主进程，支持独立升级和回滚 |
| 存储后端透明 | Kubernetes 无需感知底层存储是 NFS、Ceph、iSCSI 还是云厂商块存储 | 运维人员可自由切换存储后端，无需修改应用 YAML |
| 生态中立 | 任何存储厂商、开源社区均可按同一规范实现驱动 | 避免厂商锁定，促进存储生态良性竞争 |
1.3 在 Kubernetes 生态中的核心地位
CSI 已成为 Kubernetes 存储架构的 唯一标准插件机制。从 Kubernetes v1.23 开始，所有 in-tree 存储驱动被正式移除，CSI 成为接入存储的唯一途径。其核心地位体现在以下三个层面：
- 卷生命周期管理： CSI 驱动负责处理
CreateVolume、DeleteVolume、ControllerPublishVolume、NodePublishVolume等关键操作，覆盖从存储资源分配到 Pod 内挂载的完整链路。 - 快照与克隆： CSI 规范定义了
CreateSnapshot、DeleteSnapshot接口，使得 Kubernetes 可以原生支持存储快照和基于快照的卷恢复。 - 可扩容性： 通过
ControllerExpandVolume和NodeExpandVolume接口，CSI 支持在线扩容，无需重启 Pod。
生态现状： 截至 2025 年，CNCF 生态中已有超过 80 个 CSI 驱动，覆盖 AWS EBS、GCE PD、Azure Disk、Ceph RBD、NFS、Local PV 等主流存储方案。几乎所有云原生存储项目（如 Rook、Longhorn、OpenEBS）都基于 CSI 构建。
1.4 CSI 规范的核心接口与版本演进
CSI 规范定义了三个核心 gRPC 服务，每个服务包含若干 RPC 方法：
| 服务名称 | 关键 RPC 方法 | 职责 |
|---|---|---|
| Identity | GetPluginInfo、GetPluginCapabilities、Probe |
驱动自描述与健康检查 |
| Controller | CreateVolume、DeleteVolume、ControllerPublishVolume、CreateSnapshot、ControllerExpandVolume |
存储资源的管理（控制面操作） |
| Node | NodePublishVolume、NodeUnpublishVolume、NodeGetCapabilities、NodeExpandVolume |
卷在节点上的挂载/卸载（数据面操作） |
CSI 规范版本从 v0.1（2017）演进到 v1.9（2024），每次迭代都增加了关键能力：
- v1.0（2018）： 基础卷创建、挂载、删除能力。
- v1.1（2019）： 引入拓扑感知（Topology），支持跨 AZ 调度。
- v1.2（2020）： 增加卷快照（Snapshot）支持。
- v1.5（2021）： 增加卷克隆（Clone）和可扩容（Expand）支持。
- v1.9（2024）： 增加卷组（Volume Group）和卷健康（Volume Health）支持。
适配注意事项： 在移植 CSI 驱动时，必须明确声明支持的 CSI 规范版本。Kubernetes 1.28+ 要求 CSI 驱动至少支持 v1.5 以上版本，否则部分高级功能（如在线扩容）将不可用。
1.5 总结：CSI 带来的核心价值
CSI 的引入彻底改变了 Kubernetes 存储生态：
- 对存储厂商： 只需实现一个 gRPC 服务，即可接入所有支持 CSI 的容器编排平台（Kubernetes、Mesos、Nomad 等），大幅降低适配成本。
- 对集群管理员： 存储插件的安装、升级、回滚完全独立于 Kubernetes 版本，运维灵活性极大提升。
- 对应用开发者： 通过标准化的
PersistentVolumeClaim和StorageClass声明式 API，存储资源的使用变得简单且可移植。