云原生｜新东方在有状态服务 In K8s 的实践

有状态服务建设一直以来都是 K8s 中非常具有挑战性的工作，新东方在有状态服务云化过程中，采用定制化 Operator 与自研本地存储服务结合的模式，增强了 K8s 原生本地存储方案的能力，在摸索中稳步推进企业的容器化建设。

新东方有状态服务 In K8s 的现状

新东方有状态服务现状示意图

如上图所示，上层 Pod 由自定义的 Operator 和 StatefulSet 控制器来托管，Pod 关联 PVC，PVC 绑定 PV，最下层是存储服务。

最下层的存储服务包含本地存储和远端存储两类，对于一般的存储需求，首选是远端存储服务；而对于高性能 IO 的存储需求，那就要选择本地存储服务。目前，本地存储服务包含 K8s 原生 local 存储服务和自研的 xlss 存储服务 2 种。

原生 K8s 支撑有状态服务的能力

原生 K8s 支撑有状态服务的能力是有状态服务建设的基础，其管理模式是：StatefulSet 控制器 + 存储服务。

StatefulSet 控制器

StatefulSet 控制器：

用来管理有状态应用的工作负载 API 对象的控制器。管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。

StatefulSet 资源的特点：

• 稳定的、唯一的网络标识

• 稳定的、持久的存储

• 有序的、优雅的部署和缩放

• 有序的、自动的滚动更新

StatefulSet 资源的局限：

• 关于存储，StatefulSet 控制器是不提供存储供给的。

• 删除或者缩容时，StatefulSet 控制器只负责 Pod。

• 人工要建一个无头服务，提供每个 Pod 创建唯一的名称。

• 优雅删除 StatefulSet，建议先缩放至 0 再删除。

• 有序性也导致依赖性，比如编号大的 pod 依赖前面 pod 的运行情况，前面 pod 无法启动，后面 pod 就不会启动。

这 5 点局限可进一步概括为：StatefulSet 控制器管理 Pod 和部分存储服务（比如扩容时 pvc 的创建），其它的就无能为力。有序性引起的依赖性也会带来负面影响的，需要人工干预治愈。

存储服务

Cloud Native Storage

CNS Of CNCF

这是 CNCF 官网关于云原生存储的一副截图。截图时间是 2021 年 7 月初，有 50 多种存储产品，接近半数属于商业产品，开源产品多数都是远端存储类型，有支持文件系统的、有支持对象存储的、还有支持块存储的。

K8s PV 类型

PV Type Defined by K8s

数据来源于官网，原生 K8s 支持的 PV 类型，有常用的 rbd、hostpath、local 等类型。

如何选择？

控制器只有 StatefulSet 控制器可使用，存储产品很多，PV 类型也不少，该怎么选择呢？

存储服务考虑因素示意图

选择存储产品，需要考虑哪些因素呢？新东方在选择存储产品时考虑了以下一些因素：

• 开源 VS 商业

• 本地 VS 远端

• 动态供给 VS 静态供给

• 数据高可用方案

做选择是令人头疼的事情，比如选择开源，好处是不用花钱，但稳定性就很难保证，甚至提供的能力也有限；商业产品能力和稳定性有保证，但要付费。在这里先不下结论，最终还是要看需求。

自研存储产品 XLSS

关键需求

新东方有状态服务建设的关键需求:良好的性能，支持 IO 密集型应用；数据可用性，具有一定的容灾能力；动态供给，实现有状态服务的完全自动化管理。

XLSS 介绍

XLSS

XLSS（XDF Local Storage Service）中文全称：新东方本地存储服务产品，是一种基于本地存储的高性能、高可用存储方案。可以解决 K8s 中本地存储方案的不足之处：localpv 只能静态供给；使用 localpv 时，pod 与 node 的亲和性绑定造成的可用性降低；本地存储存在数据丢失的风险。

应用场景

• 高性能应用，IO 密集型的应用软件，比如 Kafka

• 本地存储的动态化管理

• 数据安全，应用数据定期备份，备份数据加密保护

• 存储资源监控告警，比如 K8s Pv 资源的使用量监控告警

XLSS In K8s

XLSS In K8s

如上图所示，XLSS 在 K8s 中的运行状态是 Xlss 的 3 个组件以容器形式运行在 K8s 集群中，使用本地存储为有状态服务提供存储服务，并定期执行数据的备份作业，Xlss 会提供有关存储和相关作业的 metrics 数据。

XLSS 核心组件介绍

Xlss 主要组件包含：

xlss-scheduler

• 基于 kube-scheduler 的自定义调度器

• 对于有状态服务的 pod 的调度，自动识别 xlss localpv 的使用身份，智能干预 pod 调度，消除 pod 与 node 的亲和性绑定造成的可用性降低

xlss-rescuer

• 以 DaemonSet 资源类型运行在 k8s 集群中

• 按照数据备份策略，执行数据备份作业

• 监视数据恢复请求，执行数据恢复作业

• 提供 metrics 数据

xlss-localpv-provisioner

• 动态供给本地存储

xlss-scheduler 关键逻辑实现思路

K8s 调度框架模型

如上图，这是 K8s 调度器的调度框架模型，在调度流程中包含了许多扩展点。xlss-scheduler 就是基于该调度框架模型，通过编写自定义的插件实现，主要在 3 个扩展点上做了增强：

• Prefilter：依据 Pod 的节点亲和性，分析亲和性节点的健康状态，若节点异常，对 Pod 设置特殊标记。

• Filter：针对设置特殊标记的 Pod，解除节点亲和性。

• Prebind：对设置特殊标记的 Pod，删除特殊标记，根据调度结果，发送数据恢复请求。

xlss-rescuer 数据备份作业实现逻辑

数据备份作业实现逻辑

图中 3 个部分，左右各一个循环逻辑，中间通过一个缓存队列实现通信。左边的循环实现的功能：收集备份作业策略，并更新到缓存队列中。主要 3 步：

• watch pod 事件

• 从 pod 注解当中获取备份策略，备份作业的配置信息是通过 pod 注解实现的

• 同步备份策略到缓存队列

右边的循环实现的功能：执行备份作业。也是 3 步：

• 对缓存队列元素排序，排序按照下次备份作业的执行时间点进行升序排列

• 休眠等待，若当前时间还没有到最近的一个备份作业执行时间，就会进行休眠等待

• 执行备份作业

xlss-rescuer 数据恢复作业实现逻辑

数据恢复作业实现逻辑

数据恢复作业流程和数据备份作业流程实现思路是类似的，但在具体实现逻辑上有所不同。

左边的循环实现的功能：监视恢复作业请求，并更新到缓存队列中。主要 3 步：

• watch CRD，监视数据恢复请求，接收 xlss-scheduler 发出的数据恢复请求（数据恢复请求以 CRD 方式实现）

• 分析 CRD 状态，避免重复处理

• 同步恢复请求到缓存队列

右边的循环实现的功能：执行恢复作业。这里是 4 步：

• 更新 CRD 实例状态

• 恢复快照数据到指定目录

• 更新 PV 与 PVC

• 删除 CRD 实例

xlss-localpv-provisioner 存储创建实现思路

本地存储动态创建示意图

xlss-localpv-provisioner 组件，其功能比较专一，实现本地存储的动态创建。其工作流程当 provisioner pod 获取到创建存储的请求时，首先会创建一个临时的 helper pod，这个 helper pod 会被调度到指定的 node 上面，创建文件目录作为本地存储使用，这就完成了 pv 实际后端存储的创建，当存储创建完毕，provisioner pod 会将这个 helper pod 删除。至此，一次本地存储的动态创建完成。

xlss 自动灾难恢复工作流程

xlss 自动灾难恢复工作流程

完整的自动灾难恢复工作流程要经历 6 个阶段:

• 数据备份：以 pod 为粒度，对 pv 数据进行备份。

• 节点异常：此时集群出现异常情况，某一节点发生异常，比如服务器损坏，引起在其上面的 pod 工作异常，最后有状态服务的 pod 就会一直处于 Terminating 状态。

• 异常 pod 处理：当有状态服务的 pod 处于 Terminating 状态时，要清理掉这些 pod，可以手动删除，也可借助工具，让这些有状态的 pod 有重新创建的机会。

• 智能调度 ：解除亲和性，将新 pod 调度到健康的节点上。

• 数据恢复：拉取该 pod 对应的最新的快照数据进行数据恢复。

• 服务恢复：启动应用，对外提供服务。

至此，一个完整的自动灾难恢复工作流程结束，最后又回到起点。

大规模存储型中间件服务

存储问题基本解决了，那该怎么落地呢？答案就是建设存储型中间件服务。

Kafka Cluster In K8s

Kafka Cluster In K8s

以 kafka 集群为例，通过定制化的 kafka operator 来部署 kafka 集群，指定存储服务使用 xlss 存储。采取定制化 Operator + xlss 模式去建设存储型中间件服务。

有状态中间件服务 In K8s

Stateful Apps In K8s

有状态中间件服务在 K8s 中的运行状态如上图所示，这些存储型中间件服务集群托管于对应的 Operator，底层存储根据业务需要适配各类存储。随着中间件服务集群规模的日益扩大，我们建设了 PaaS 控制面，用户可以通过该控制面来管理运行在 K8s 中的各类中间件服务集群。控制面可以直接和 apiserver 交互，用户通过控制面增删改 CRD 资源，Operator 根据 CRD 资源的最新状态，调和中间件服务集群的状态。

用户申请中间件服务示例

用户申请中间件服务示例

这是用户申请中间件服务的示例：用户通过管理台申请服务，填写相关的配置信息后，申请通过后，就可以在 K8s 集群里面创建相应的服务了。

基于 KubeSphere 部署 XLSS

如果希望使用 xlss 存储，那该怎么部署呢？

若是首次部署，首先要做好本地磁盘的规划，创建好提供给 xlss 使用的存储空间。然后，就是将 xlss 的各个组件运行到 K8s 集群中。将 xlss 组件部署到 K8s 集群中，我们借助了 KubeSphere 的 CI/CD 流水线。自定义流水线一共 5 步，实现将 xlss 组件从静态代码到运行在 K8s 中的容器的转换，高度自动化维护。

CI/CD 流水线如下图所示：

CI/CD 流水线

Road Map

Road Map

目前，新东方的有状态服务容器化建设大致可分成 4 阶段。

第一阶段：“云前时代”。

有状态服务容器化的起点，确定了容器化的目标。这个阶段有状态服务主要特征是 VM+PaaS 组合的模式管理有状态服务。实现的主要功能：资源管理、白屏运维、简单调度策略、运行时管理。

第二阶段：“初上云端”。

从这个阶段开始，尝试将有状态服务从 VM 中解脱出来，迁移到 K8s 平台。这个阶段有状态服务主要特征是 K8s+Operator 组合的模式管理有状态服务。

这时，运行时被托管到 K8s，有状态服务由 Opeartor 接管，自动化程度显著提高。此时也暴露出一些不足：比如远端存储的性能不够好，本地存储的可用性不能保证。

第三阶段：“自研之路”。

主要是新东方自研 xlss 的实践阶段，前面章节已有涉及。此阶段有状态服务建设的典型特征：Scheduler + Logical Backup 组合模式。这基本达到了我们期望的：本地存储 + 动态供给 + 数据可用性保证。但事情永远都不会那么完美，那还有那些瑕疵呢？

• 数据恢复时长取决于数据量大小，如果数据量很大，恢复时间也会增大，在 node 异常发生的情况下，这就增大了有状态服务的不可用时间。

• 现在 PV 数据还没能做到存储隔离，无法约束应用对存储的使用量，会存在一定的风险。

瑕不掩瑜，在小规模存储场景：如 redis、kafka 等还是有用武之地的，但是对于大数据量的服务，目前 xlss 的能力还有些勉强。

第四阶段：“追求卓越”。

在这个阶段，有状态服务建设的典型特征：Isolation + Physical Backup 组合模式。重点会解决第三阶段发现的瑕疵。大致的解决思路是：利用 LVM 技术实现存储的隔离；利用 DRBD 技术，增加 DRBD 同步物理备份能力，实现应用数据的同步实时备份，解决由于数据量大导致恢复时间增长的问题。

在使用 DRBD 技术时，有一个需要权衡的地方，那就是副本数量的设置。若副本数量设置多些，则会增大存储资源使用量；若副本数量设置少些，在 K8s 集群 node 异常情况下，有状态服务 Pod 漂移可选择的 node 数量就会减少。最终需要根据业务场景做出合理选择。