透析 Kubernetes 1.9,8 大要点详解存储升级
随着 Kubernetes 1.9 的发布,许多新的 features 被加入到 Kubernetes 之中,也有一些以前引入的 features 被进一步优化、升级,变得越来越稳定。在最新发布的 1.9 版本中,Caicloud(才云科技) 帮助实现了 Cinder 和 RBD 的 resize 支持; 修改本地临时存储部分内容,为其添加 E2E 测试,增强稳定性;目前正在往上游推 PV 监控的相关功能。
Kubernetes 的存储子系统也有许多新的变化,下面我们来具体看一下。
Volume Plugins Resize Support
Kubernetes 1.8 中加入了 PVC resize 这个新的 feature,允许对存储卷进行扩容操作。由于 1.8 发布的时间问题,我们(RedHat 和 Caicloud)只实现了 resize controller,StorageClass API 变动以及 admission 相关的功能,volume plugin 也只有 glusterfs 支持 resize (因为是文件系统存储,不用实现 fs resize)。1.9 中,我们主要实现了文件系统 resize 功能,并对几个比较常用的存储驱动进行 resize 支持,包括 AWS, GCE, Cinder 和 RBD。Caicloud 深度参与这个 feature, 负责其中的 StorageClass API, Admission ,以及 Cinder 和 RBD 等部分。
具体的 proposal 见: https://github.com/Kubernetes/community/pull/657
Local Ephemeral Storage Enhancement
本地临时存储的功能实现是在 1.8 中加入的,由 Google 和 Caicloud 的工程师讨论完成。1.9 中, 本地临时存储没有非常大的功能变动,主要是为其添加了 E2E tests,保证其稳定性。才云科技也深度参与了此 features 的讨论和实现。这个 feature 在 1.9 中还是保持 Alpha,可能会在 1.10 版本升级为 Beta.
具体的 proposal 见: https://github.com/Kubernetes/community/pull/306
CSI Volume Plugin
Kubernetes 1.9 release 中, 存储系统一个比较大的突破是实现了 CSI(Container Storage Interface)。经过上游长时间的讨论,最终在 Kubernetes 1.9 版本中实现了 CSI,目标是为了给各个存储组件提供和 Kubernetes 交互的统一接口。如果用户想扩展 Kubernetes 的存储驱动,可以通过 CSI 来实现相关的存储接口(CSI 各个组件通过 gRPC 通信)和功能,不必像以前一样,必须修改 Kubernetes 的核心代码。用户在 Kubernetes 核心代码之外实现存储服务,解除了存储驱动和 Kubernetes 之间的绑定,大大增加了各自的升级灵活性,同时也降低了存储插件对 Kubernetes 系统稳定性的影响。这个 feature 在 1.9 中是 Alpha 版本,后面需要继续优化升级。
具体的 proposal 见: https://github.com/Kubernetes/community/pull/1258
Topology Aware Volume Scheduling
Kubernetes 1.9 中, 存储方面的另一个比较重大的改变是调度器和 PV 控制器的逻辑变动。1.9 之前,调度器和 PV controller 各自独立工作,互相不交流影响,这样会导致本地持久化存储的调动问题。
想象一下: Pod p 引用了 PVC c,而 c 绑定到了本地节点 A 上的 PV v,但是如果节点 A 的 CPU 或者 Memory 等不满足 Pod p 的需求,这样调度就无法进行。这个 feature 就是为了解决这样的问题, 在调度 Pod 的时候,除了考虑以前已经存在的限制,比如 CPU, Memory 等,还需要考虑 Pod 中 Volume 的拓扑约束,比如考虑节点的本地存储大小,处于哪个 region 等。
如果我们让这个 feature 工作了的话,PVC 和 PV 的绑定逻辑也要跟着做相应的变化,不会像以前一样,盲目的找到合适的 PV 就和 PVC 绑定,如果这个 PVC 所在的 StorageClass 的 VolumeBindingMode 是 VolumeBindingWaitForFirstConsumer 的话,如果 PVC 没有预绑定到 PV, 那么此时 PV controller 那边会先不做绑定,而是在 Pod 调度的时候,考虑各种因素之后,比如 NodeAffinity, labels/selector 等, 如果找到合适的 PV, 再进行绑定。这样就解决了上面提到的问题。同样的,这个新的 feature 在 1.9 中也是 Alpha 版本。
具体的 proposal 见:
https://github.com/Kubernetes/community/pull/1054
https://github.com/Kubernetes/community/pull/1168
Block Volumes Support
1.9 中,本地存储另一个变化就是支持了本地块存储设备。把本地块设备作为一种新的 PV source 支持,用户可以通过 PV 来消费本地块存储设备了,具体的 API 支持代码已经实现,相关的文档也正在更新。
具体的 proposal 见: https://github.com/Kubernetes/community/pull/1265
Enable Containerization of Mount Dependencies
1.9 之前,volume 的 mount 操作都需要在 host 上完成,这个新 feature 允许 Kubernetes 在 pods 里面运行 mount 相关操作,避免因为主机本身导致的问题。这个 feature 的代码实现已经完成, Alpha 版本, 还需要加一下测试用例等。
具体的 proposal 见:
https://github.com/Kubernetes/community/pull/589
Prevent PVC Deletion When Pod is Using It
对 PVC 的删除操作加了一些限制, 如果这个 PVC 正在被 pod 引用,则不能对其进行删除操作,避免因误操作导致的数据丢失以及服务不可用等问题。
具体的 proposal 见: https://github.com/Kubernetes/community/pull/1174
Flex Volumes Marked as GA
flex volume feature 在 1.9 中变为稳定版本。
总 结
由上可知,Kubernetes 1.9 版本中,存储系统的变化还是挺大的,有新功能的添加,也有以前功能的加强改进,使得 Kubernetes 变得越来越完善。
才云科技也参与了许多 feature 的讨论和实现,后面我们也会持续对开源社区进行贡献,实时输出相关文章,欢迎关注。
更多阅读:
Kubernetes 1.9 亮点爆料 | WorkloadsAPI v1 正式版发布
本文作者:任玉泉
Kubernetes 社区 member, approver, feature owner,commits 全球总排名 Top70,毕业于东南大学,先后就职于中兴软创,EasyStack, 于 17 年 7 月加入才云,任职云开源工程师。
END