滴滴弹性云基于 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 的服务画像引擎，涉及数据清洗，数据分析，数据存储，大盘展示等多个模块

k8s 调度能力的运用

涉及资源

无状态服务（Deployment）：弹性云最开始使用的 workload，但因为历史原因，比如要兼容业务在物理机时代的使用方式等，目前已废弃。
有状态服务（StatefulSet）：弹性云目前支持的主 workload，优化了控制器逻辑，实现了自定义部署顺序策略、无序删除策略、打散策略等等。
静态容器（Pod）：直接管理 pod，在现有的 Kubernetes 原生调度编排之上，提供和 VM 类似的资源交付手段，是为了兼容类似物理机使用方式的妥协，不 cloudnative，不建议新业务接入
Endponit：接流组件监听其变化，在pod漂移后自动接上dsi/lvs的流量
Deamonset：node 上 agent 的 workload

k8s 调度器的实现

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

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 利用率都不会超过一定比例。但在很多场景下，业务流量会创新高，比如服务先扩容，后切流：