理解 Kubernetes CSI

关于 Kubernetes CSI，现在的资料已经不少，但我仍希望有一篇文档能让人轻松但不失准确地理解 CSI。

本文不涉及代码分析和详细设计。但需要如下基础：

• 会使用至少一种容器，Docker，containerd，Kata 之类的都可以。
• protobuf 和 gRPC：会用并有少量的开发经验，会用某种语言（最好是 Go）开发简单的 client 和 server。
• k8s：懂得基本概念，会简单使用。
• 存储：会使用至少一种。如 Ceph、NFS、公有云的云盘，都可以。

什么是 CSI

CSI 是存储（如 Ceph、NFS）与 CO（如 k8s）之间的对接规范。

这里我们只考虑 k8s 这一种 CO。存储提供方可以通过实现 CSI 的方式接入 k8s 并让 Pod 使用存储。

k8s CSI 在形式上是一个 gRPC proto 定义再加上一些文档形式的约定。

https://github.com/container-storage-interface/spec

该仓库中，有文件 csi.proto。实现了该文件中所定义 API 的程序就具备了成为 CSI 驱动的必要条件。

需要实现的 gRPC Service 有：

service Identity {
    //
}

service Controller {
    //
}

service GroupController {
    //
}

service SnapshotMetadata {
    //
}

service Node {
    //
}

CSI 在 k8s 中的位置

在形式上，CSI driver 常常由如下组成：

• 一两个 Deployment 或 StatefulSet：主要是 provisioner，attacher
• 一两个 DaemonSet：主要是 node-driver-registrar 和 node-plugin

其他组件暂不考虑，遇到了再去了解即可。

通过这里

https://www.cnblogs.com/jthmath/p/19029054

可以看到各个组件的作用。

provisioner 的每个 Pod 通常有 2 个容器，一个是 external-provisioner，一个是存储厂商提供的程序，记为 P。

attacher（有的存储没有此组件）的每个 Pod 通常有 2 个容器，一个是 external-attacher，一个是存储厂商提供的程序，记为 A。

external-provisioner 和 external-attacher 不是 k8s 组成部分，但它是由 k8s-sig 维护的。

它们监听 k8s 中特定的资源（如 PVC、PV），并通过 gRPC 调用 P 和 A。

node-driver-registrar 也是由 k8s-sig 维护，作用是告知它所在节点的 kubelet “这里有个 csi driver，名字是 xxx，其他信息是 xxx”。

kubelet 记住 node-driver-registrar 告知的信息后，适时调用 node-plugin。

这样一来，k8s 和存储就完成了对接。