kubernetes容器云技术选型（Kubernetes1.9容器存储接口）

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 核心代码之外开发存储驱动，但为了部署第三方驱动程序文件，仍然需要访问节点和主机的根文件系统。

动态预配

可以通过为 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