作者|周培,新东方架构部容器组专家
有状态服务建设一直以来都是 K8s 中非常具有挑战性的工作,新东方在有状态服务云化过程中,采用定制化 Operator 与自研本地存储服务结合的模式,增强了 K8s 原生本地存储方案的能力,在摸索中稳步推进企业的容器化建设。
如上图所示,上层 Pod 由自定义的 Operator 和 StatefulSet 控制器来托管,Pod 关联 PVC,PVC 绑定 PV,最下层是存储服务。
最下层的存储服务包含本地存储和远端存储两类,对于一般的存储需求,首选是远端存储服务;而对于高性能 IO 的存储需求,那就要选择本地存储服务。目前,本地存储服务包含 K8s 原生 local 存储服务和自研的 xlss 存储服务 2 种。
原生 K8s 支撑有状态服务的能力是有状态服务建设的基础,其管理模式是:StatefulSet 控制器 + 存储服务。
StatefulSet 控制器:
用来管理有状态应用的工作负载 API 对象的控制器。管理某 Pod 集合的部署和扩缩,并为这些 Pod 提供持久存储和持久标识符。
StatefulSet 资源的特点:
StatefulSet 资源的局限:
这 5 点局限可进一步概括为:StatefulSet 控制器管理 Pod 和部分存储服务(比如扩容时 pvc 的创建),其它的就无能为力。有序性引起的依赖性也会带来负面影响的,需要人工干预治愈。
Cloud Native Storage
这是 CNCF 官网关于云原生存储的一副截图。截图时间是 2021 年 7 月初,有 50 多种存储产品,接近半数属于商业产品,开源产品多数都是远端存储类型,有支持文件系统的、有支持对象存储的、还有支持块存储的。
K8s PV 类型
数据来源于官网,原生 K8s 支持的 PV 类型,有常用的 rbd、hostpath、local 等类型。
如何选择?
控制器只有 StatefulSet 控制器可使用,存储产品很多,PV 类型也不少,该怎么选择呢?
选择存储产品,需要考虑哪些因素呢?新东方在选择存储产品时考虑了以下一些因素:
做选择是令人头疼的事情,比如选择开源,好处是不用花钱,但稳定性就很难保证,甚至提供的能力也有限;商业产品能力和稳定性有保证,但要付费。在这里先不下结论,最终还是要看需求。
新东方有状态服务建设的关键需求:良好的性能,支持 IO 密集型应用;数据可用性,具有一定的容灾能力;动态供给,实现有状态服务的完全自动化管理。
XLSS(XDF Local Storage Service)中文全称:新东方本地存储服务产品,是一种基于本地存储的高性能、高可用存储方案。可以解决 K8s 中本地存储方案的不足之处:localpv 只能静态供给;使用 localpv 时,pod 与 node 的亲和性绑定造成的可用性降低;本地存储存在数据丢失的风险。
应用场景
如上图所示,XLSS 在 K8s 中的运行状态是 Xlss 的 3 个组件以容器形式运行在 K8s 集群中,使用本地存储为有状态服务提供存储服务,并定期执行数据的备份作业,Xlss 会提供有关存储和相关作业的 metrics 数据。
Xlss 主要组件包含:
如上图,这是 K8s 调度器的调度框架模型,在调度流程中包含了许多扩展点。xlss-scheduler 就是基于该调度框架模型,通过编写自定义的插件实现,主要在 3 个扩展点上做了增强:
图中 3 个部分,左右各一个循环逻辑,中间通过一个缓存队列实现通信。左边的循环实现的功能:收集备份作业策略,并更新到缓存队列中。主要 3 步:
右边的循环实现的功能:执行备份作业。也是 3 步:
![数据恢复作业实现逻辑](https://pek3b.qingstor.com/kubesphere-community/images/ xlss-rescuer-2.webp)
数据恢复作业流程和数据备份作业流程实现思路是类似的,但在具体实现逻辑上有所不同。
左边的循环实现的功能:监视恢复作业请求,并更新到缓存队列中。主要 3 步:
右边的循环实现的功能:执行恢复作业。这里是 4 步:
xlss-localpv-provisioner 组件,其功能比较专一,实现本地存储的动态创建。其工作流程当 provisioner pod 获取到创建存储的请求时,首先会创建一个临时的 helper pod,这个 helper pod 会被调度到指定的 node 上面,创建文件目录作为本地存储使用,这就完成了 pv 实际后端存储的创建,当存储创建完毕,provisioner pod 会将这个 helper pod 删除。至此,一次本地存储的动态创建完成。
完整的自动灾难恢复工作流程要经历 6 个阶段:
至此,一个完整的自动灾难恢复工作流程结束,最后又回到起点。
存储问题基本解决了,那该怎么落地呢?答案就是建设存储型中间件服务。
以 kafka 集群为例,通过定制化的 kafka operator 来部署 kafka 集群,指定存储服务使用 xlss 存储。采取定制化 Operator + xlss 模式去建设存储型中间件服务。
有状态中间件服务在 K8s 中的运行状态如上图所示,这些存储型中间件服务集群托管于对应的 Operator,底层存储根据业务需要适配各类存储。随着中间件服务集群规模的日益扩大,我们建设了 PaaS 控制面,用户可以通过该控制面来管理运行在 K8s 中的各类中间件服务集群。控制面可以直接和 apiserver 交互,用户通过控制面增删改 CRD 资源,Operator 根据 CRD 资源的最新状态,调和中间件服务集群的状态。
这是用户申请中间件服务的示例:用户通过管理台申请服务,填写相关的配置信息后,申请通过后,就可以在 K8s 集群里面创建相应的服务了。
如果希望使用 xlss 存储,那该怎么部署呢?
若是首次部署,首先要做好本地磁盘的规划,创建好提供给 xlss 使用的存储空间。然后,就是将 xlss 的各个组件运行到 K8s 集群中。将 xlss 组件部署到 K8s 集群中,我们借助了 KubeSphere 的 CI/CD 流水线。自定义流水线一共 5 步,实现将 xlss 组件从静态代码到运行在 K8s 中的容器的转换,高度自动化维护。
CI/CD 流水线如下图所示:
目前,新东方的有状态服务容器化建设大致可分成 4 阶段。
有状态服务容器化的起点,确定了容器化的目标。这个阶段有状态服务主要特征是 VM+PaaS 组合的模式管理有状态服务。实现的主要功能:资源管理、白屏运维、简单调度策略、运行时管理。
从这个阶段开始,尝试将有状态服务从 VM 中解脱出来,迁移到 K8s 平台。这个阶段有状态服务主要特征是 K8s+Operator 组合的模式管理有状态服务。
这时,运行时被托管到 K8s,有状态服务由 Opeartor 接管,自动化程度显著提高。此时也暴露出一些不足:比如远端存储的性能不够好,本地存储的可用性不能保证。
主要是新东方自研 xlss 的实践阶段,前面章节已有涉及。此阶段有状态服务建设的典型特征:Scheduler + Logical Backup 组合模式。这基本达到了我们期望的:本地存储 + 动态供给 + 数据可用性保证。但事情永远都不会那么完美,那还有那些瑕疵呢?
瑕不掩瑜,在小规模存储场景:如 redis、kafka 等还是有用武之地的,但是对于大数据量的服务,目前 xlss 的能力还有些勉强。
在这个阶段,有状态服务建设的典型特征:Isolation + Physical Backup 组合模式。重点会解决第三阶段发现的瑕疵。大致的解决思路是:利用 LVM 技术实现存储的隔离;利用 DRBD 技术,增加 DRBD 同步物理备份能力,实现应用数据的同步实时备份,解决由于数据量大导致恢复时间增长的问题。
在使用 DRBD 技术时,有一个需要权衡的地方,那就是副本数量的设置。若副本数量设置多些,则会增大存储资源使用量;若副本数量设置少些,在 K8s 集群 node 异常情况下,有状态服务 Pod 漂移可选择的 node 数量就会减少。最终需要根据业务场景做出合理选择。