Kubernetes CSI

Kubernetes 权威指南 4 源码：

链接

• Kubernetes CSI
  • CSI 存储插件的挂件组件和部署架构
    • CSI Controller
    • CSI Node
  • CSI 存储插件的使用实例

Kubernetes CSI

Kubernetes 从 1.9 版本开始引入容器存储接口 Container Storage Interface（CSI）机制，用于在 Kubernetes 和外部存储系统之间建立一套标准的存储管理接口，通过该接口为容器提供存储服务。CSI 到 Kubernetes 1.10 版本升级为 Beta 版，到 Kubernetes 1.13 版本升级为 GA 版，已逐渐成熟。

Kubernetes 通过 PV、PVC、Storageclass 已经提供了一种强大的基于插件的存储管理机制，但是各种存储插件提供的存储服务都是基于一种被称为 "in-tree"（树内）的方式提供的，这要求存储插件的代码必须被放进 Kubernetes 的主干代码库中才能被 Kubernetes 调用，属于紧耦合的开发模式。这种 "in-tree" 方式会带来一些问题：

• 存储插件的代码需要与 Kubernetes 的代码放在同一代码库中，并与 Kubernetes 的二进制文件共同发布。
• 存储插件代码的开发者必须遵循 Kubernetes 的代码开发规范。
• 存储插件代码的开发者必须遵循 Kubernetes 的发布流程，包括添加对 Kubernetes 存储系统的支持和错误修复。
• Kubernetes 社区需要对存储插件的代码进行维护，包括审核、测试等工作。
• 存储插件代码中的问题可能会影响 Kubernetes 组件的运行并且很难排查问题。
• 存储插件代码与 Kubernetes 的核心组件（kubelet 和 kube-controller-manager）享有相同的系统特权权限，可能存在可靠性和安全性问题。

Kubernetes 已有的 Flex Volume 插件机制视图通过外部存储暴露一个基于可执行程序（exec）的 API 来解决这些问题。尽管它允许第三方存储提供商在 Kubernetes 核心代码之外开发存储驱动，但仍然有两个问题没有得到很好的解决：

• 部署第三方驱动的可执行文件仍然需要宿主机的 root 权限，存在安全隐患。
• 存储插件在执行 mount、attach 这些操作时，通常需要在宿主机上安装一些第三方工具包和依赖库，使得部署过程更加复杂，例如部署 Ceph 时需要安装 rbd 库，部署 GlusterFS 时需要安装 mount.glusterfs 库，等等。

基于以上这些问题和考虑，Kubernetes 逐步推出与容器对接的存储接口标准，存储提供方只需要基于标准接口进行存储插件的实现，就能使用 Kubernetes 的原生存储机制为容器提供存储服务。这套标准被称为 CSI（容器存储接口）。在 CSI 成为 Kubernetes 的存储提供标准之后，存储提供方的代码就能和 Kubernetes 代码彻底解耦，部署也与 Kubernetes 核心组件分离，显然，存储插件的开发由提供方自行维护，就能为 Kubernetes 用户提供更多的存储功能，也更加安全可靠。基于 CSI 的存储插件机制也被称为 "out-of-tree"（树外）的服务提供方式，是未来 Kubernetes 第三方存储插件的标准方案。

CSI 存储插件的挂件组件和部署架构

其中主要包括两个组件：CSI Controller 和 CSI Node。

CSI Controller

CSI Controller 的主要功能是提供存储服务视角对存储资源和存储卷进行管理和操作。在 Kubernetes 中建议将其部署为单实例 Pod，可以实验 StatefulSet 或 Deployment 控制器进行部署，设置副本数量为 1，保证为一种存储插件只运行一个控制器实例。

在这个 Pod 内部署两个容器，如下所述。

（1）与 Master（kube-controller-manager）通信的辅助 sidecar 容器。

在 sidecar 容器内由可以包含 external-attacher 和 external-provisioner 两个容器，它们的功能分别如下：

• external-attacher：监控 VolumeAttachment 资源对象的变更，触发针对 CSI 端点的 ControllerPublish 和 ControllerUnpublish 操作。
• external-provisioner：监控 PersistentVolumeClaim 资源对象的变更，触发针对 CSI 端点 CreateVolume 和 DeleteVolume 操作。

（2）CSI Driver 存储驱动容器，由第三方存储提供商提供，需要实现上述接口。

这两个容器通过本地 Socket（Unix Domain Socket，UDS），并使用 gRPC 协议进行通信。sidecar 容器通过 Socket 调用 CSO Driver 容器的 CSI 接口，CSI Driver 容器负责具体的存储操作。

CSI Node

CSI Node 的主要功能是对主机（Node）上的 Volume 进行管理和操作。在 Kubernetes 中建议将其部署为 DaemonSet，在每个 Node 上都运行一个 Pod。

在这个 Pod 中部署以下两个容器：

（1）与 Kubelet 通信的辅助 sidecar 容器 node-driver-registrar，主要功能是将存储驱动注册到 Kubelet 中；

（2）CSI Driver 存储驱动容器，由第三方存储提供商提供，主要功能是接收 kubelet 的调用，需要实现一系列与 Node 相关的 CSI 接口，例如 NodePublishV