| 为 | 容 | 器 | 技 | 术 | 而 | 生 |
翻译:夏天
校对:任玉泉
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 插件启用自动创建/删除 。
要触发动态配置,请创建一个PersistentVolumeClaim对象。例如,下面的PersistentVolumeClaim可以使用上面的StorageClass触发动态配置。
然后,Kubernetes 会将新的PersistentVolume对象绑定到PersistentVolumeClaim,使其可以使用。如果fast-storageStorageClass被标记为默认值,则不需要在PersistentVolumeClaim中包含StorageClassName,它将被默认使用。
预分配 Volume
您始终可以通过手动创建一个PersistentVolume对象来展示现有 Volumes,从而在 Kubernetes 中暴露预先存在的 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
资料下载
领取专属 10元无门槛券
私享最新 技术干货