FlexVolume与CSI两代存储扩展机制的能力差距

在[[存储接入的三阶段模型及PV控制器AD控制器Volume管理器的职责分工]]的 Provision/Attach/Mount操作之外，Kubernetes同时支持两套独立的存储扩展 机制。FlexVolume（1.2版本起，Kubernetes私有的存储扩展，已冻结不再 发展新功能）：驱动就是一个实现了Attach/Detach/Mount/Unmount的可执行 文件（甚至可以只是Shell脚本），放在每个节点的固定目录下，被AD控制器 和Volume管理器需要时调用——实现起来非常简单，但短板也很明显：不包含 Provision/Delete操作，无法直接支持动态存储分配（除非再单独写一个 External Provisioner）；作为独立可执行文件部署维护很烦琐（新节点加入 要人工部署，通常得专门写DaemonSet代劳）；多次操作之间无法通信，只能 靠约定临时文件传递状态（比如Mount阶段生成的信息要给Unmount阶段用）， 这对一个面向生产的编排系统来说过于简陋。CSI（Container Storage Interface，1.9版本起，与CRI、CNI同类的公开技术规范，目前的重点发展 方向）远比FlexVolume完善——按GitHub代码行数对比，FlexVolume规范文档 只有155行，CSI长达2704行。CSI把职责拆成容器系统侧要实现的部分（Driver Register、External Provisioner/Attacher/Resizer/Snapshotter/Health Monitor等标准组件，Kubernetes提供的插件已完整实现）和存储提供商侧要 实现的部分（CSI Identity/Controller/Node三个gRPC接口）。更关键的是部署 形态的差异：CSI插件本身就是标准Kubernetes资源（Controller接口以 StatefulSet部署，Node接口以DaemonSet部署），像装CNI插件一样直接load Manifest即可，不需要FlexVolume那样人工运维或自己写DaemonSet，用gRPC 传参也比命令行参数+临时文件严谨可靠得多。