有状态服务建设始终以来都是 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

<center>Kafka Cluster In K8s</center>

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

有状态中间件服务 In K8s

Stateful Apps In K8s

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

用户申请中间件服务示例

用户申请中间件服务示例

这是用户申请中间件服务的示例：用户通过治理台申请服务，填写相干的配置信息后，申请通过后，就能够在 K8s 集群外面创立相应的服务了。

基于 KubeSphere 部署 XLSS

<b/> 如果心愿应用 xlss 存储，那该怎么部署呢？

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

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

<center>CI/CD 流水线 </center>

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 数量就会缩小。最终须要依据业务场景做出正当抉择。