Container Storage Interface (CSI) 用来建立一个标准的、通用的存储接口，使得存储供应商（SP）只需要编写一次插件，就可以在所有支持 CSI 的容器编排系统中使用。

CSI 是目前 Kubernetes 和其他容器编排系统（如 Mesos, Docker Swarm）推荐和事实上的标准接口，用于实现存储的动态供给。

内联 (In-tree) 卷插件

这些插件是 Kubernetes 核心代码的一部分，例如 awsElasticBlockStore、gcePersistentDisk、azureDisk、cephfs、nfs、iscsi 等。

• 动态供给机制: 当用户创建一个 PVC 并引用一个支持动态供给的 StorageClass 时，Kubernetes 的 kube-controller-manager 会调用对应的内联卷插件去创建后端存储资源。
• 缺点:
  • 与 Kubernetes 核心代码紧密耦合，新存储功能的开发和发布需要与 Kubernetes 版本同步。
  • 如果一个存储供应商要支持 Kubernetes，他们必须将自己的代码贡献到 Kubernetes 核心仓库中，这增加了门槛和维护成本。
  • 更新驱动需要升级整个 Kubernetes 集群。

CSI (Container Storage Interface)

k8s 里通过 helm 部署

CSI 就是为了解决内联插件的这些问题而诞生的。它提供了一个标准接口，将存储插件的开发从 Kubernetes 核心中剥离出来。

• 动态供给机制: 当用户创建 PVC 和 StorageClass 时，Kubernetes 会调用 CSI 驱动的 CreateVolume RPC 方法去创建后端存储资源。
• 优点:
  • 解耦: 存储插件可以独立于 Kubernetes 发布和更新。
  • 扩展性: 任何存储供应商都可以基于 CSI 规范开发自己的驱动，无需修改 Kubernetes 核心代码。
  • 灵活性: 新功能（如快照、扩容）可以更快地实现和迭代。

动态供给 (Dynamic Provisioning)

动态供给允许存储卷按需创建。系统根据用户的 PVC 请求，自动在存储端创建物理卷，并自动生成对应的 PV 对象。先有请求，后有卷。

动态供给通常只能生成机器生成的、具有唯一性的名字（通常包含 UUID），用户无法完全自定义后端存储的卷名。

静态供给 (Static Provisioning)

预先在存储端创建好物理卷，并手动在 Kubernetes 中创建对应的 PV 对象。先有卷，后有请求。管理员手动创建 PV
PVC，并手动写配置文件进行挂载。