Kubernetes 1.9 容器存储接口（CSI）Alpha 版本全解析

  | 为  |  容  |  器  |  技  |  术  |  而  |  生  |

翻译：夏天

校对：任玉泉

Kubernetes 主要优势之一就是具有强大的 Volume Plugin System（存储卷插件系统)，这个优势可以让许多不同类型的存储系统能够：

• 按需要自动创建存储；

• 无论容器被调度到哪，存储对他们都可用；

• 自动删除无用存储。

然而为 Kubernetes 添加新的存储系统，一直都是一件有挑战性的事情。Kubernetes 1.9 引入了容器存储接口（CSI）Alpha 版本，这使得安装 Volume Plugins 就像部署一个 pod 一样简单。它还允许第三方存储提供商，在不需要修改 Kubernetes 核心代码的情况下，依然可以开发解决方案。

因为 CSI 在 1.9 中还处于 Alpha 阶段，所以必须明确使用场景。这一功能虽然不适用于生产环境，但是该功能很好地表明了项目的未来方向（向更加可扩展和基于标准 Kubernetes 存储的生态系统方向发展）。

K8S  为什么需要 CSI？

Kubernetes 的 Volume Plugins 目前在主干代码中，也就是说它们可以与核心 Kubernetes 二进制文件一起进行链接、编译、构建和发布。在 Kubernetes（a volume plugin ）中添加对新存储系统的支持，需要在核心 Kubernetes 存储库提交代码。但是对于许多 Plugin 开发者来说，与 Kubernetes 发布流程保持一致是很大的难题。

已有的 Flex Volume Plugin 试图通过为外部存储暴露一个基于 exec 的 API 来解决这个问题。尽管它允许第三方存储供应商在 Kubernetes 核心代码之外开发存储驱动，但为了部署第三方驱动程序文件，仍然需要访问节点和主机的根文件系统。

除了上面的问题，Flex 并没能解决插件依赖的问题：Volume Plugins 经常会有很多外部需求（例如挂载和文件系统工具）。我们会假设那个特定的主机系统能满足所有的依赖，但事实上，经常不会是我们假设的这个样子（安装它们同样需要访问节点机器的根文件系统）。

CSI 却解决了所有问题，它通过让存储 Plugins 通过标准的 Kubernetes Primitives 进行部署以及容器化，让用户可以使用熟悉并喜爱的 Kubernetes Storage Primitives 进行使用。

例如：

PersistentVolumeClaims，PersistentVolumes，

StorageClasses

什么是 CSI？

CSI 的目的是为容器编排系统（ COs ）建立一个标准机制，从而能让 COs 为跑在其上的容器化应用负载暴露任意的存储系统。 CSI 规范是由来自多个社区（包括 Kubernetes，Mesos，Docker 和 Cloud Foundry）成员合作起草的。该规范独立于 Kubernetes 开发，并维护在以下文档中。

https://github.com/container-storage-interface/spec/blob/master/spec.md

Kubernetes v1.9 发布了 CSI 规范的 Alpha 版本，允许 CSI 兼容的 Volume 驱动程序部署在 Kubernetes 上，并由 Kubernetes 工作负载使用。CSI 插件作者将提供他们自己在 Kubernetes 上插件部署说明。

如何使用 CSI Volume？

假设集群中已经部署了 CSI 存储插件，就可以通过熟悉的 Kubernetes Storage Primitives 来使用它。例如 PersistentVolumeClaims，PersistentVolumes 和 StorageClasses。

CSI 是 Kubernetes v1.9 的 Alpha feature。要启用它，请设置以下标签

动态预配

可以通过为 CSI 创建插件 StorageClass 来支持动态配置的 CSI Storage 插件启用自动创建/删除 。

例如，以下 StorageClass 允许通过名为 com.example.team/csi-driver 的 CSI Volume Plugin 动态创建 “fast-storage” Volume。

要触发动态配置，请创建一个 PersistentVolumeClaim 对象。例如，下面的 PersistentVolumeClaim 可以使用上面的 StorageClass 触发动态配置。

当动态创建 Volume 时，通过 CreateVolume 调用，将参数 type：pd-ssd 传递给 CSI 插件 com.example.team/csi-driver 。作为响应，外部 Volume 插件会代表一个新 Volume，然后自动创建一个 PersistentVolume 对象来对应前面的 PVC 要求。

然后，Kubernetes 会将新的 PersistentVolume 对象绑定到 PersistentVolumeClaim，使其可以使用。如果fast-storage StorageClass 被标记为默认值，则不需要在 PersistentVolumeClaim 中包含 StorageClassName ，它将被默认使用。

预分配 Volume

您始终可以通过手动创建一个 PersistentVolume 对象来展示现有 Volumes，从而在 Kubernetes 中暴露预先存在的 Volume。

例如，暴露属于 com.example.team/csi-driver 这个 CSI 存储插件的 existingVolumeName Volume

附着和挂载

 现在，已经绑定到 CSI Volume 的 PersistentVolumeClaim，就可以在任何 Pod 或者 Pod 模板中使用了。

当一个引用了 CSI Volume 的 pod 被调度时， Kubernetes 将针对外部 CSI 插件进行相应的操作，以确保特定的 Volume 被 attached、mounted， 并且能被 pod 中的容器使用。

如何创建 CSI 驱动程序

Kubernetes 尽可能少地指定 CSI Volume 驱动程序的打包和部署规范。这里记录了在 Kubernetes 上部署 CSI Volume 驱动程序的最低要求。

https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md#third-party-csi-volume-drivers

最低要求文件还包含概述部分，提供了在 Kubernetes 上部署任意容器化 CSI 驱动程序的建议机制。存储提供商可以运用这个机制来简化 Kubernetes 上容器式 CSI 兼容 Volume 驱动程序的部署。

作为推荐部署的一部分，Kubernetes 团队提供以下 sidecar(helper) containers：

• External-attacher：

  可监听 Kubernetes VolumeAttachment 对象并触发 ControllerPublish 和 ControllerUnPublish 操作的辅助容器，通过 CSI endpoint 触发 ；

• External-provisioner：

  监听 Kubernetes PersistentVolumeClaim 对象的辅助容器，并触发对 CSI 端点的 CreateVolume 和 DeleteVolume 操作；

• Driver-registrar：

  使用 Kubelet（将来）注册 CSI 驱动程序的辅助容器，并将 NodeId （通过 GetNodeID 调用检索到 CSI endpoint）添加到 Kubernetes Node API 对象的 annotation 里面。

存储供应商完全可以使用这些组件来为其 Plugins 构建 Kubernetes Deployment，同时让它们的 CSI 驱动程序完全意识不到 Kubernetes 的存在。

常见问题

1

在哪里能找到 CSI 驱动程序？

CSI 驱动程序由第三方开发和维护。这里可以找到示例 CSI 驱动程序，但这些驱动程序纯粹用于说明，并不适用于生产工作负载。

https://github.com/kubernetes-csi/drivers 

2

Flex 怎么办？

Flex Volume Plugin 通过为外部存储暴露一个基于 exec 的 API 。尽管它确实有如上所述的一些缺点，但 Flex Volume Plugin 会与新的 CSI Volume Plugin 并存。SIG Storage 将继续维护 Flex API，以便现有的第三方 Flex 驱动程序（已经部署在生产群集中）可以继续工作。未来，新的 Volume 功能将只被添加到 CSI。

3

In-tree Volume Plugins 将变成什么样？

一旦 CSI 稳定下来，我们将把大部分 In-tree Volume Plugins 迁移到 CSI。请继续关注 Kubernetes CSI 实施过程中的更多细节。

4

Alpha 阶段的局限是什么？

CSI 在 Alpha 阶段有以下限制：

• 不支持 CreateVolume，NodePublishVolume 和 ControllerPublishVolume 调用中的 credential fields；

• 不支持 Block Volumes，仅支持文件格式；

• 不支持指定文件系统，默认为 ext4；

• 无论是否实现了 ControllerPublishVolume，都必须部署 external-attacher。

• CSI Volume 不支持 Kubernetes 调度程序拓扑感知：简而言之，提供有关 Volume 配置位置（zone，regions 等）的信息，让 Kubernetes 调度程序可以作出更明智的调度决策。

5

CSI 未来发展？

根据反馈意见和采用情况，Kubernetes 团队计划在 1.10 或 1.11 版本，将 CSI 推进到 Beta 阶段。

原文参考：

http://blog.kubernetes.io/2018/01/introducing-container-storage-interface.html

资料下载

推荐阅读：

END