专栏首页CNCF在 Kubernetes 中,如何动态配置本地存储?

在 Kubernetes 中,如何动态配置本地存储?

日前,全新版本的 Caiclou

发布 | 才云 Caicloud

作者 | iawia002

在企业 IT 架构转型的过程中,存储一直是个不可避免的大问题。

Kubernetes 中使用节点的本地存储资源有 emptyDir、hostPath、Local PV 等几种方式。这之中,emptyDir 无法持久化数据,hostPath 方式需要手动管理卷的生命周期,运维压力大。因此在某些场景下,如果用户出于性能和运维成本考虑需要使用本地存储,Local PV 似乎是唯一选择。

1什么是 Local PV?

所谓 Local PV(本地持久化存储),指的就是利用机器上的磁盘来存放业务需要持久化的数据,和远端存储类似,此时数据依然独立于 Pod 的生命周期,即使业务 Pod 被删除,数据也不会丢失。

同时,和远端存储相比,本地存储可以避免网络 IO 开销,拥有更高的读写性能,所以分布式文件系统和分布式数据库这类对 IO 要求很高的应用非常适合本地存储。

2设计方案

在具体介绍如何动态配置本地存储前,我们先来介绍一下 Kubernetes 上游对于 Local PV 的一些支持情况:

  • Kubernetes v1.7: 正式引入 Local PV;
  • Kubernetes v1.10: Local PV 进入 Beta;
  • Kubernetes v1.14: Local PV 进入 GA。

在今年 3 月发布的 Kubernetes v1.14 中,社区对此的评价是:

出于性能和成本考量,分布式文件系统和数据库一直是 Local PV 的主要用例。相比云服务供应商,本地 SSD 提供的性能远比远程磁盘优秀;而相比裸机,除了性能,本地存储通常更便宜,并且使用它是配置分布式文件系统的必要条件。

目前,Local PV 的本地持久存储允许我们直接使用节点上的一块磁盘、一个分区或者一个目录作为持久卷的存储后端,但暂时还不提供动态配置支持,也就是说:你得先把 PV 准备好。

不同于其他类型的存储,本地存储强依赖于节点。换言之,它在调度 Pod 的时候还要考虑到这些 Local PV 对容量和拓扑域的要求。

这里我先介绍一下延迟绑定机制和 volume topology-aware scheduling。延迟绑定机制可以让 PVC 的绑定推迟到有 Pod 使用它并且完成调度后,而 volume topology-aware scheduling 则可以让 Kubernetes 的调度器知道卷的拓扑约束,也就是这个存储卷只能在特定的区域或节点上使用(访问),让调度器在调度 Pod 的时候必须考虑这一限制条件。

在介绍了这些背景之后,我们来看一个使用本地存储的 PV 示例:

其他内容和一个普通 PV 无异,只是多了一个 nodeAffinity

这个字段的值使得 Kubernetes 调度器能够把使用这个 PV 的 Pod 调度到正确的 Node 上。

对于本地存储的动态配置,除了实现最基础的根据 StorageClass 和 PVC 动态创建 Persistent Volume 外,它还要让 Kubernetes 的调度器能够感知本地存储节点的剩余容量,选择存储量足够大的节点,能够将使用本地存储的 Pod 调度到正确的拓扑域上,例如上面例子中的一个节点或者一个特定的区域。

为了方便对本地存储节点的磁盘进行管理,本地存储功能的底层选择使用 LVM 来实现。LVM 是 Linux 环境下对磁盘分区进行管理的一种机制,是建立在硬盘和分区之上的一个逻辑层,具有很高的灵活性。下面是 LVM 架构的一个示意图:

图片源于网络

而为了让 Kubernetes 的调度器能够感知本地存储节点的剩余容量,我们选择使用 Kubernetes Scheduler Extender,使用一个 webhook 来扩展原生调度器的功能,这种方法实现起来简单、易于维护和使用且无侵入性,不修改源代码。

所以整个组件由两部分组成:一个是 LVM Manager,它以 DaemonSet 的形式运行,负责管理每个节点上的磁盘,汇报节点磁盘的容量和剩余容量,动态创建 PV 等;另一个是个 local storage scheduler 调度模块,负责为使用本地存储的 Pod 选择合适(有足够容量)的节点

StorageClass 需要设置 provisioner 字段的值为我们自定义的 local-volume-provisioner 之类的,表示需要动态创建 Persistent Volume:

创建 StorageClass 时需要选择的节点和磁盘等信息会先记录在 parameters 中,数据结构定义如下(JSON 格式化成普通字符串后存储在 parameters 中):

然后 LVM Manager 会根据这个信息在对应的节点上将选择的磁盘合并成一个 LVM 的卷组(VG),方便后续管理。

考虑到可扩展性,和 StorageClass、Node 关联的磁盘、VG 等信息会记录在一个新增的自定义资源(Custom Resources,以下简称 CR)里面,而不是直接将信息记录在对应的 StorageClass 和 Node 的 annotation 中。原因如下:

  • 其一,我们需要自定义的结构化数据;
  • 其二,我们把本地存储作为一种扩展资源。它区别于 CPU 和内存,包含了类型、节点和磁盘等众多属性,并且一个节点可以关联多个本地存储资源。

一组 StorageClass、Node 和磁盘信息就有一条记录,新的 CR 的定义如下(注意,以下结构只是为了方便说明和阅读,并不是 Kubernetes 推荐的标准结构):

关系示意图如下:

几乎所有和 LVM 相关的操作都只需要监听和更新这一个对象。LVM Manager 监听这个对象,在需要的 Node 上动态创建 VG 并定时更新这个对象中的 VG 的容量和剩余容量等;Scheduler 根据这个对象上的容量信息辅助调度。

然后对于 local storage scheduler 模块,首先我们要配置 Kubernetes Scheduler,为其增加一个 extender,使其在进行 node filter 的时候会访问我们的 local storage scheduler webhook 以达到我们想要的对节点进行二次筛选的效果。下面是一个配置的示例:

下面有一个增加了 scheduler extender 之后的调度流程示例:

最后,我再总结一下整个动态配置的正常流程:

  • 创建 StorageClass 并配置想要选择的节点和对应的磁盘等信息;
  • LVM Manager 为对应的节点创建 VG;
  • LVM Manager 同时需要负责定期上报 VG 的容量信息;
  • 创建 PVC 和使用它的 Pod;
  • Kubernetes 调度器为 Pod 选择合适的节点,然后访问 Extender webhook;
  • local storage scheduler 对选择的节点根据容量条件进行二次过滤;
  • Kubernetes 调度器最后再选中一个节点,并且把该节点名称也存储到 PVC 的 volume.kubernetes.io/selected-node annotation 中;
  • dynamic provisioner 介入,根据 PVC 的 volume.kubernetes.io/selected-node annotation 的值,在这个节点上根据 PVC 的要求创建一个 LVM 的逻辑卷(LV),再创建对应的 PV;
  • volume 绑定完成,Pod 和 Node 绑定,调度完成。

3结语

动态本地存储涉及多个组件的交互,异常处理尤为重要

例如,若 NodeLocalStorage 对象的容量信息没有及时更新,导致选中的节点其实没有剩余容量了,那么相应的 LVM 的逻辑卷(LV)也创建不出来,provisioning 失败。

这时,local-storage-provisioner 就要将 PVC 的 volume.kubernetes.io/selected-node annotation 清空,接下来 Kubernetes Scheduler 会重新调度。

类似异常处理很多,限于篇幅,这里不一一列举。如果你对这方面的创新和进展感兴趣,欢迎关注才云科技公众号ID:Caicloud2015),之后我们还有会奉送更多一线技术内容。

当然,如果你对动态配置本地存储还有疑问或是有新思路,欢迎留言讨论,才云有多个面向开发者的技术社群,期待你的加入。


参考文献

1.[Volumes - Kubernetes]

https://kubernetes.io/docs/concepts/storage/volumes/#local

2.[Volume Topology-aware Scheduling]:https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/volume-topology-scheduling.md

3.[Scheduler extender]:https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md

文章转载自才云Caicloud。

本文分享自微信公众号 - CNCF(lf_cncf)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-05-20

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • 构建Kubernetes集群 - 合理选择工作节点数量和大小

    本文从多个维度分别阐述了使用更少的大节点与使用更多的小节点来组建 Kubernetes 集群各自的优劣,并结合实践经验给出了选择工作节点数量和大小的通用方法。

    CNCF
  • K8s 节点断开连接后,本在运行的 Pod 会如何?

    在工作节点与主节点断开连接后,工作节点上的 Pod 是什么状态,是否在继续运行?Kubernetes 控制器又在做什么?本文对此进行了实例研究,一一解答。

    CNCF
  • Kubernetes调度器101

    如果你阅读过Kubernetes的任何文档、书籍或文章,那么毫无疑问,你会在“Pod被调度到下一个可用节点”之类的短语中看到调度“schedule”这个词。Ku...

    CNCF
  • 在 Kubernetes 中,如何动态配置本地存储?

    Kubernetes 中使用节点的本地存储资源有 emptyDir、hostPath、Local PV 等几种方式。这之中,emptyDir 无法持久化数据,h...

    kubernetes中文社区
  • 红黑树的特性

    (1)每个节点或者是黑色,或者是红色。 (2)根节点是黑色。 (3)每个叶子节点(NIL)是黑色。 [注意:这里叶子节点,是指为空(NIL或NULL)的叶子节点...

    IT技术小咖
  • RocketMQ 多副本前置篇:初探raft协议

    Raft协议是分布式领域解决一致性的又一著名协议,主要包含Leader选举、日志复制两个部分。

    丁威
  • IBM SPSS Modeler Social Network Analysis 的介绍和日常应用

    IBM SPSS Modeler Social Network Analysis,中文叫做社交网络分析,本文将一律简称 SNA。 引言 IBM Business...

    学到老
  • Hyperledger Fabric基础之Peer节点

    https://hyperledger-fabric.readthedocs.io/en/release-1.2/peers/peers.html

    Zeal
  • IBM SPSS Modeler Social Network Analysis 的介绍和日常应用

    IBM SPSS Modeler Social Network Analysis,中文叫做社交网络分析,本文将一律简称 SNA。

    学到老
  • Kubernetes调度器101

    如果你阅读过Kubernetes的任何文档、书籍或文章,那么毫无疑问,你会在“Pod被调度到下一个可用节点”之类的短语中看到调度“schedule”这个词。Ku...

    CNCF

扫码关注云+社区

领取腾讯云代金券