滴滴弹性云基于 K8S 的调度实践

来源：滴滴技术

上篇文章详细介绍了弹性云混部的落地历程，弹性云是滴滴内部提供给网约车等核心服务的容器平台，其基于 k8s 实现了对海量 node 的管理和 pod 的调度。本文重点介绍弹性云的调度能力，分为以下部分：

• 调度链路图：介绍当前弹性云调度体系链路，对架构体系有一个初步的认知

• k8s 调度能力的运用：整体介绍弹性云现在用到的 k8s 调度能力和对其的增强

• k8s 版本的升级：介绍到从 k8s 1.12 到 1.20 跨版本升级的方案

• 服务画像/真实使用率调度：原生的 request 调度存在着和真实使用率之间的 gap 等缺陷，尝试通过对 node 上业务做数据画像来让调度做出更符合真实情况的调度

• 重调度：由于调度只能依据当前数据，随着业务的增长、集群机器的下线等，调度效果可能不达预期，比如会产生一些宿主机热点等，介绍重调度对这块的处理能力

• 调度规则引擎：通用的调度策略不能满足所有业务场景，直接在调度主流程中做适配比较 hack，介绍 Galahad+Webhook 对调度资源的灵活注入从而影响最终的调度结果的能力

• 调度稳定性建设：介绍整体调度的稳定性保障体系

调度链路图

• kube-rescheduler：重调度模块，自动轮询集群状态，并发起异常 pod 的漂移

• kube-odin：弹性云的上游 pass 层，用户通过 kube-odin 接入弹性云

• galahad：调度规则引擎，按标签选取业务 pod 或 node 的调度策略存储，主要解决物理机集群差异化，快速变化的需求与 k8s 集群管理的灵活度匹配

• kube-hook：k8s 的 mutatingwebhook 和对应服务，用于将 galahad 注入 pod 或 node

• master：原生的 k8s 三大件

• ipam：弹性云的 pod ip 分配模块

• IRMAS：内核组件，包括 Odin-Agent 监控数据上报、pod quota 分配等能力

• kube-agent：node 组件，做真实使用率数据的获取和写入

• zhivago：基于 Prometheus 的服务画像引擎，涉及数据清洗，数据分析，数据存储，大盘展示等多个模块

• 无状态服务（Deployment）：弹性云最开始使用的 workload，但因为历史原因，比如要兼容业务在物理机时代的使用方式等，目前已废弃。

• 有状态服务（StatefulSet）：弹性云目前支持的主 workload，优化了控制器逻辑，实现了自定义部署顺序策略、无序删除策略、打散策略等等。

• 静态容器（Pod）：直接管理 pod，在现有的 Kubernetes 原生调度编排之上，提供和 VM 类似的资源交付手段，是为了兼容类似物理机使用方式的妥协，不 cloudnative，不建议新业务接入

• Endponit：接流组件监听其变化，在pod漂移后自动接上dsi/lvs的流量

• Deamonset：node 上agent 的 workload

kube-scheduler 的根本工作任务是根据各种调度算法将 Pod 绑定（bind）到最合适的工作节点，整个调度流程分为两个阶段：预选策略（Predicates）和优选策略（Priorities），这里不再赘述。

在 k8s 原生的预选卡点上我们做了很多增强：

重点介绍两个优选算法：

很长一段时间我们一直使用如下的优选打分权重，也就是 Balanced 和 Least 并重，但在资源紧张的情况下，重调度效果显示调度在即使有比较低利用率 cpu 的 node，也会选取另一个利用率较高但比较均衡的 node，而这个 node 更可能成为热点，这就是我们说的“调度bad case”。

为此，当前在某些峰值利用率较高、热点较大的大机房，做了如下优选权重的调整，更加关注资源的使用率而不是平铺度。

在将 k8s 版本升级到 1.20 后，我们将上述弹性云的预选卡点和优选算法全部通过 SchedulerFramework 做了重新实现，主要拆解为 PreFilter、Filter 和 Score 三种扩展点。

k8s 版本的升级

不久之前弹性云部分机房 k8s 版本还是 1.12，升级到 1.20 的难点如下：

• 集群体量大，最大集群规模已经远远超出了社区推荐的5千个 node 上限，有问题的爆炸半径大；

• 场景复杂多样，隔离集群、有状态服务容器、不可变更ip漂移容器、静态容器等；

• 周边涉及范围广，kube-odin、各种 operator 和控制器等诸多上游组件。

替换升级方案介绍：

• 两个 k8s 集群，1.12 和 1.20，直接搭建新的一套新的 1.20 master 和周边组件；

• 1.20 集群中创建和 1.12 和等量的业务负载，也就是 sts 和 pod；

• 通过上游的流量管控应用决定流量分布，一开始流量都在 1.12 的 sts 的 pod中，逐步切流到 1.20 的 sts 的 pod；

• 有问题的时候可以快速回切流量。

原地升级方案介绍：

• 只有一个 k8s 集群，将 master 和周边组件直接从 1.12 升级到 1.20；

• 逐步将集群中的 node 也就是 kubelet 从 1.12 版本升级到 1.20；

• 不做任何业务负载相关的操作，也就是 sts 和 pod 无需重建，其实的流量分布也不做操作，随着 node 升级流量天然就逐步从 1.12 切到 1.20了；

• 有问题的时候需要部分回滚 node 的 kubelet，当出现全局性风险的时候需要全量回滚 master 和周边组件。

两个方案对比如下：

从方案可落地以及成本角度最终选取了原地升级。

• 有状态服务，比如 redis 等需要 kubelet 升级容器不重启：修改原生的kubelet 实现，按hash值是否变化来决定是否重建容器的策略。

• 升级中间态风险规避：master 1.20 +部分 Kubelet 1.12 的场景，梳理和关注高版本 apiserver 中资源或协议的变化，推动周边系统使用非 alpha 或 beta版本资源。

目前已无损升级滴滴所有核心机房万级别的 node 和十万级别 pod ，且升级过程中业务完全无感，未发生一次故障。

从全局资源优化角度看，调度是动词，是策略的运用，关键是这个策略从何而来、怎么优化？我们知道 k8s 原生使用 request 做装箱，而一般为了成本考虑都会做 node 上的超卖，这在 node 上所有 pod 利用率都较高的情况下会产生热点和资源争抢。

服务画像的核心目标是探索不影响业务情况下的单机使用率上限，以及寻找真实资源的全局分布最优解。其核心能力包括：元信息完备的多维数据（map能力），灵活的聚合计算语言 promQL（reduce 能力），配置化的数据可视化大盘 （可观测性能力），以及灵活可配置的数据->策略通路（画像能力）。

MapReduce 是一种数据处理思想，Map 代表数据预处理，包括归一化、格式化、补全数据元信息等，Reduce 代表数据聚合，可以进一步分为四种运算操作：过滤（filters）、聚合（aggregations）、集合操作（set operations）和联结（joins）。

举个例子，如何用MapReduce的思想分析数据：

北京机房下，X2234节点、wyc产品线的所有8核规格容器中，所有可漂移的容器过去七天消耗的最大CPU核数按宿主机维度求和。

表达式:

sum(max_over_time(ddcloud_pod_cpu_used{region="beijing",set="X2234",prod_line="wyc",cpu_limit="8",flexible="true"}[7d]))by(m_host)

结论：

依据该分析，可得出 wyc 产品线的容器在北京机房部分物理机上的分布情况，并据此人工或自动消除 wyc 产品线容器热点。

在过去一段时间，整个弹性云公共集群一直处于超卖较大的情况，而真实利用率的限制是真正保证高峰期宿主不会被打爆的主要策略。

如何算出真实使用率？算法是取当前宿主所有 pod，对其进行拟合取七天内最大的点作为调度参考值。当 pod 发生漂移时值也随之改变。zhivago 会将 pod 和 node 的7天最大值提前计算好保存到对应的配置中，此配置会被调度读取并作为调度决策的重要参考，每1分钟为更新周期。

为什么取七天最大值？因为从当前的数据的同比、环比可以看到，滴滴的业务特性7天为循环周期。取7天最大值可以在最坏的情况下尽量不产生热点。调度会保证宿主上所有 pod 7天真实使用率之和不超过真实资源的一定比例，包括cpu、内存、io 和磁盘等。

kubernetes 调度 pod 是一次性决策的，实时状态决策，但业务的压力是变化的，所以长期运行后 node 的状态不一定合理。我们的服务画像/真实使用率调度是一个偏“保守”的调度策略，如果业务流量保持和前7天完全一致，可以确保各个 node 在高峰期的 cpu 利用率都不会超过一定比例。但在很多场景下，业务流量会创新高，比如服务先扩容，后切流：

还有，比如集群新增了亲和/互斥的策略，如何将策略作用于存量 pod ？集群修改超卖规则，超卖系数压缩怎么对存量 pod 生效？怎么处理不满足新调度规则的 pod？对这些场景，我们都希望用重调度来再做一次调度：

• 定时任务1：每10分钟做一次筛选，对不满足调度 Good Case 的 pod 入队列；

• 定时任务2：每分钟做一次筛选，对满足漂移条件的 pod 做漂移；

• 定时任务3：每分钟做一次漂移失败的 pod 的检查，重新入队列；

• 定时任务4：每天捞一轮数据以生成重调度的成功率、失败数以及未恢复 pod 的日报。

由于 CPU 属于抖动性最强的资源，在利用率较高的情况下一般业务都会受到影响，所以提供了紧急情况立即均衡的能力，不区分业务高峰期。紧急均衡触发条件为：物理机实际利用率高于一定的水位，可配置调整。

重调度是统一的再调度中心，具备自动化能力，但调度本身较重，需要规避不可控的爆炸半径。因此有如下重调度的限制：

在流量和核数相同的情况下，重处理前后的集群热点率对比：

一直以来我们努力的方向是完善调度策略精确性或者说是完善基础能力，虽有一定的效果，但已经无法满足日益复杂的调度需求。为了让调度的管理能力可配置化，而不再依赖于代码的上线，需要一个单独的组件对涉及到的如下属性做修改和使用：

• Annotations （各种开关、阈值、附加属性等）

• Labels （阈值、标签）

• Resource （pod所需资源、node总资源）

• Taints/Tolerations （node's taint and pod's tolerations）

• Affinity （node's and pod's soft and hard [anti]affnity）

修改的对象可以是 Pod、Node、Pod Controller（如Statefulset）等。这就是 Galahad，它是核心调度组件，负责集群资源调度与管控，寻找集群调度过程中的圣杯。

Galahad 全景图如下图所示：

通过 Galahad 可以提供对 k8s 各个资源的自定义配置，如容器维度的调度打散，亲和性、物理机维度的资源超卖，资源限制、业务集群维度的物理机亲和性等等。具体是和 webhook 配合使用，基于 k8s 的 mutatingwebhook 实现对新建 pod 或者修改 node 的资源注入。

支持以下场景：

• 为了满足混合调度的需求，尽量减少调度器的修改，通过 Galahad 区分 pod 在不同集群的调度策略；

• 在隔离集群等需要特殊打散配置的场景下，直接通过 Galahad 注入 pod 打散策略；

• 在 map 等公共集群重数据服务上云的场景下，通过 Galahad 注入 pod 的跨 sts 平铺。

稳定性体系

1、调度可观测：

• 调度链路的可观测：apiserver->hook->etcd 的 trace 串联

• 调度现场的可观测：调度失败详情、优选打分日志、调度现场的pod和node快照

• 集群状态的可观测，包括集群 node 和 pod 详情、剩余套餐数、热点和可解释大盘等

2、核心指标保障：周调度成功率、堆积和延迟，重调度成功率和延迟，各组件指标比如apiserver qps等，通过核心指标大盘体现。

3、功能点自动化回归验证：自动化巡检能力。

4、放火能力失败验证：故障注入和系统自我止损能力。

1、apiserver 稳定性

• 请求均衡：基于 go away 的长连接请求打平

• 限流保护：原生的 apf 限流，对内部组件请求豁免的优化

• 来源感知：复杂请求链路梳理、推动调用方增加 client 信息

• 应急预案：master 备机和快速扩容 sop

2、调度器性能优化

• 在离线 pod 调度优先级差异化处理和退避策略，保障在线调度性能

• percentageOfNodesToScore 等调度器参数优化

3、控制器性能优化

• endponit 控制器同步缓存数据优化，时间复杂度从n*n->1，发布封线时间缩短4/5

• 1.12版本 taintController 直接从 etcd list pod 请求的优化

4、galahad+webhook 稳定性

• 1.12 默认的 apiserver 对 webhook 长连接优化为短连接

• webhook 部署优化，容器和物理机冷备

• galahad 操作工单化，防止误操作

• 强弱依赖不可用演练

5、etcd 稳定性

• apiserver 对 etcd 的前置限流保护

• event 和主 etcd 的拆分

• 穿透到 etcd 的 list 请求治理

• 客户端定时压缩优化为服务端自己主动压缩

• 高峰期前的 deflag 磁盘碎片整理

1、事前

• 监控和告警补全

• 周边依赖梳理，强依赖稳定性保障

• 压测环境单集群容量上限摸底

2、事中

• 护堤手册和大盘

• 通用问题排查手册

• 故障场景止损 SOP

3、事后

• 复盘和改进落地流程

滴滴弹性云基于 k8s 实现了容器调度，支持多云调度、在线隔离、在离混部的多种复杂业务场景，目前在线公共集群的平均利用率已经接近50%，未出现明显异常。

在这个过程中，基于对 k8s 的理解完善了画像、重调度、规则引擎能力，提升了调度效果，并通过稳定性治理保证了系统99.99%的可用。后续会进一步在业务精细化调度、隔离能力完善、多调度器支持以及可观测提升等方面做深耕。