小米容器资源画像体系构建与业务实践

1. 演讲人李洋 by 小米

2. 目录

3.

4.

5.

6. 资源浪费导致集群容量不足，发布“pending”，间接导致无法容纳更多的业务，导致集群资源利用率低分配率在很高的情况下，利用率却不足分配率的50%，说明有大量的资源分配出去却没有得到充分的使用 • 近7天的集群cpu均值利用率峰值(usage/capacity)：39% • 近7天的集群cpu申请率均值(cpu-request/allocatabel)： 91%

7. 于此同时 cpu的使用量/cpu的request（mid的资源）：日均峰值仅有30%左右，说明业务申请的request和真实使用的usage偏差也很大。

8. 在原生静态分配资源调度策略的基础上加持了实时负载感知调度策略虽然可以保障调度时刻节点不会造成热点问题，但无法评估未来一段时间的稳定性

9. 当前 HPA 的自动扩缩容虽然能够实现动态调整，但存在以下两大问题： • 扩容滞后，无法提前响应风险 - HPA 仅在应用负载超出设定阈值后才会触发扩容，这意味着容量风险已经出现，扩容只能起到应急作用，而无法提前规避风险（对于启动时间较长的负载影响更大）。 • 负载波动导致无效缩容 - 负载短期波动较大时，可能触发不必要的缩容操作，进一步影响系统稳定性。

10. 以上线上的真实case，围绕云基础资源，带有很强的预测色彩，与传统的资源策略不同，需要加持各种算法的能力才可以实现，我们内部把此类领域统筹到了画像维度。希望借助画像的能力，来突破现有策略的瓶颈。

11.

12. 猎罪图鉴： 1. 画像师沈翊根据受害人描述的嫌疑犯特征画出肖像 -> 肖像成为了一种办案辅助工具 2. 刑警队长杜城基于肖像，快速定位罪犯，绳之以法 -> 画师与警察配合，提高了办案效率画像是一个可以准确衡量事物特征，让上下游提高效率的工具。

13. 有了画像的理解铺垫，我们在k8s场景下，引出了资源画像的概念：资源画像，就是围绕着k8s中最根本的资源方向，对不同类型的负载分层分类的刻画出所需要的特征数据，让上下游策略更加丰富和合理

14.

15. 画像的设计要求： 1. 解耦，让上层策略更关注策略的本身，而不是如何去获取数据，聚合数据，分享数据 2. 画像组件自身也可以独立跟进业界新技术，产出更多的负载特征，让上层策略更加丰富或者更加合理

16. • 静态模块 • 依靠平台,k8s-informer等获取并持续同步集群最新拓扑信息 • 动态模块 • 依靠prometheus定期获取不同负载真实指标，通过算法多维聚合，产出特征，实时，预测数据 • 边缘建设 • 账单输出，预测可视化，准确性巡检等

17.

18. 开源VPA • 核心推荐算法是将负载历史用量数据以半衰指数直方图为输入，计算 cpu/memory 资源推荐值我们借鉴了该原理，并衍生出了时序的概念，希望能将预测的能力扩展到各种维度的策略中

19. 从promethheus取某服务过去7天的真实cpu用量序列当作预测的原始样本，期间涉及如何减少对prometheus查询的压力，例如时段拆分，令牌桶限制等

20. 预处理历史数据： • 填写缺失数据(斜率补齐) • 删除极端异常值（整体采样点分位数去除异常点） • 平滑处理 (滑动窗口进行样本标准差去毛刺)

21. 时域转频域 • FFT:将时序拆分成不同频率、相位、振幅的信号组合(反推可以生成不同形状的序列) • 周期图：按振幅的值进行构图， • 候选周期：周期图中「幅值」明显高于其它点的点，我们认为是候选周期。图片来源 https://mp.weixin.qq.com/s/zs4zUlt2ltRzv_wl8tpOMA

22. 计算序列的自相关函数ACF，ACF是一个用来评估样本集在不同时间区间的相关性。通俗的讲，它就是衡量单位时间下样本集合间的偏差情况。右图反应了平移信号与原始信号的「相似」程度，值越高相似度越高图片来源 https://mp.weixin.qq.com/s/zs4zUlt2ltRzv_wl8tpOMA

23. 依次验证每一个候选周期对应的自相关系数是否位于「山顶」上，并且选择对应「最高峰」的那个候选周期为整个时间序列的主周期（基波周期），并以此为基础进行预测。 • 在两侧个各选取一段曲线，分别做线性回归，当回归后左、右的直线斜率分别大于、小于零时，则认为这个点是在一个「山顶」上图片来源 https://mp.weixin.qq.com/s/zs4zUlt2ltRzv_wl8tpOMA

24. 基于主周期的频率、相位、振幅进行IFFT(逆快速傅里叶变换) -> 得到下一个周期的预测序列结果。黑色是真实，蓝色是带有buffer的预测

25. 整体流程： • • • • • • 原始历史7天序列预处理后的历史7天序列快速傅立叶变换得到频谱图找候选周期列表自相关函数从候选周期列表中找「相似」度最高的周期做为主周期基于主周期的频率、相位、振幅进行IFFT(逆快速傅里叶变换) 得到下一个周期的预测序列结果。图片来源 https://gocrane.io/zh-cn/docs/core-concept/timeseries-forecasting-by-dsp/

26. 存量业务实例迭代发布或者扩容时，借助mutating-webhook，将预测序列的max值作为推荐值来调整用户资源申请，既能保障业务稳定性，又能减少资源浪费（原地更新能力受限集群版本，暂不讨论）

27. 上线半年后收益： • usage峰值/request的比率均值从30%->70%及以上，部分集群可以到90%， • 资源浪费减少了30%，累计减少5W+CPU资源浪费

28. 众所周知，容器方便快捷的弹性能力一直是相较于传统裸金属时代最大的优势，业务上云很大的原因也是来自于k8s提供了负载粒度的弹性扩缩。因此画像在VPA场景有了稳定收益后，我们并没有停止探索，借助workload维度的预测序列，我们又构思了HPA的预测能力来解决业务的困扰： • 扩容滞后，无法提前响应风险 - HPA 仅在应用负载超出设定阈值后才会触发扩容，这意味着容量风险已经出现，扩容只能起到应急作用，而无法提前规避风险（对于启动时间较长的负载影响更大）。 • 负载波动导致无效缩容 - 负载短期波动较大时，可能触发不必要的缩容操作，进一步影响系统稳定性。

29. 1. KEDA Scaler 预测并缓存时序数据 2. KEDA Adapter 转换预测数据为指标，适配 Kubernetes 的 External Metrics API 3. HPA 请求指标

30. 但是大家很容易发现缺陷，那就是画像的预测能力只能做到无限的贴近真实，而无法提前感知。因此我们考虑到了滑动窗口的设计，当 HPA 的查询到达时，取当前时间到未来一段时间为【窗口区间】，返回这个区间中的最大预测值。带来的效果如下：

31. 用实时指标进行兜底，以应对突发情况

32. 收益：我们采样了真实集群里的用量case，进行了预测扩缩器效果预览，发现绝大多数的场景，都可以做到提前扩容，避免无效的缩容，再加上有实时的兜底，业务基于扩缩实现稳定性得到了更多保障

33. 小米内部调度器已经引入了实时负载感知调度，基于不同QOS等级系数的形式进行了简单的用量预估，但是它只能保障调度后短周期节点的资源用量不会超过调度阀值，拥有前瞻性，但缺乏时效性，评估的可靠性很低，有效性很短，因此只能依靠重调度滞后的驱逐来减少热点，但此时对业务造成的影响无法挽回

34. 我们基于framework调度扩展框架，扩展了filter和score的扩展点，同时引入了画像时序序列预测的能力，来提前规避可能发生热点的机器

35. 模拟效果图如下，上线后热点问题从 10次+/月降到了 1～2次/月

36.

37. 画像思维的引入，让我们在生产环境业务问题的解决上，突破了传统策略的设计模式，在成本&稳定性的方向上更进一步(这里以调度器策略演进为例，阐述画像带来的变革) kubernetes很多原生策略都是基于静态资源开展的，例如调度器中 NodeResourceFit策略：只要节点剩余资源够pod申请，那就可以调度只基于静态资源调度，很难解决单机热点问题，因此很多厂商又引入了实时负载感知调度策略：调度时刻资源利用率低于阀值，可以进行调度只基于当前负载进行调度，很难保障长时间集群资源的稳定性，因此画像可以围绕资源进行预测，让调度时稳定性保障的实效性大大增长某些具有相似特征的负载如果调度到同一台机器上会导致资源竞争激烈，严重的时候导致集群动荡，画像可以前置分析，让调度器完成同质化打散

38. • 总结： • 画像解决了很多线上问题 • 思考问题的思路和解决问题的方式更多样化 • 预测效果的可视化还做的不够，收益的采集比较困难 • 预测准确性还有待提升 • 展望 • 更多的预测能力和特征能力产出，例如： • 特征分析 => 潮汐特征 => 用量峰谷时区分析 => 推荐开启定时扩缩策略并推荐给业务扩缩时段建议 • 特征分析 => 资源特征 =>cpu密集/mem密集/io密集/网络密集型等=> 同质打散策略 • 容量预测能力，提前感知pending的发生

39.

40. 让进步持续发生