K8s 集群每日弹性 3 次,每次 100 节点,如何优化调度策略把成本降 20%
解读
- 业务特征:每天固定 3 个波峰,单次扩容 100 节点,峰谷差距大,资源利用率低。
- 成本构成:国内公有云按量计费(秒级/小时级)、包年包月预留、抢占式实例、EIP、系统盘、数据盘、跨 AZ 流量、SLB 规格。
- 目标:在不降低 SLA(P99 延迟、成功率、弹性时长 ≤5 min)的前提下,综合账单降 20%。
- 面试考点:能否把“性能测试”量化能力迁移到容量预测、调度参数、混部、 Spot 容错、压实验证闭环。
知识点
- 水平弹性(HPA)与纵向弹性(VPA)的触发阈值模型
- 调度器打分算法:LeastAllocated、MostAllocated、RequestedToCapacityRatio、Binpack、Spread
- 优先级与抢占、PodDisruptionBudget、Descheduler 重调度
- 节点亲和/反亲和、污点容忍、拓扑分布约束(TopologySpreadConstraints)
- 包年包月、按量、Spot 三级容量池;Spot 回收信号与优雅终止
- 容量预测算法:基于历史 Prometheus 指标的 ARIMA/Prophet、队列理论 M/M/c 模型
- 混部(离线在线混合)的 CPU 压制、内存水位、L3 Cache 隔离、噪声清理
- 性能测试验证:ChaosMesh 注入 Spot 回收、Locust/JMeter 模拟峰谷流量、Grafana 看 P99、SLO burn rate
答案
-
容量预测压测先行
a. 用过去 30 天 Prometheus 的 CPU 使用量、QPS、RT 训练 Prophet,得出 3 次峰值的“最低安全副本数”曲线。
b. 在隔离环境用 1.2 倍峰值负载做压测,找到单节点极限 QPS 与 CPU 利用率拐点(一般 65% 为上限,超过后 RT 陡增)。
c. 计算“理论最小节点数”= 总峰值 CPU / 单节点可售 CPU * 1.08(8% Buffer),验证是否 ≤ 80 台;若成立,可直接降 20 节点。 -
调度策略调优
a. 修改 kube-scheduler 的 policy config,把 MostAllocated 打分权重调到 20%,优先填满存量节点,减少碎片。
b. 对无状态服务加 podAntiAffinity,强制跨机架分布,避免“一机挂多 Pod”带来的热点;有状态服务使用 TopologySpreadConstraints 的 maxSkew=1,保障 AZ 级容灾。
c. 为离线任务(Spark/Flink)设置低优先级 class=“offline”,并配置抢占,让在线任务在峰谷时快速腾地。 -
三级容量池与 Spot 混用
a. 包年包月预留 40 节点作为“基线池”,覆盖夜间低峰;
b. 按量 20 节点作为“缓冲池”,应对预测误差;
c. 剩余 40 节点全部用 Spot,出价=按量价 30%,并配置优雅终止 60 s;
d. 在峰前 15 min 通过 Cluster-Autoscaler 的 expander=“priority” 优先拉起 Spot,峰后 5 min 缩容按量+Spot,确保账单最短计费周期。 -
混部与资源超卖
a. 开启 VPA 的“推荐模式”,把 request 下调到 P95 实际用量;
b. 对离线 Pod 设置 burstable QoS,limit=2×request,利用节点空闲 CPU;
c. 部署 Koordinator 或 Crane,压制离线任务 CPU 到 20%,在线任务优先级 9,离线 3,实测 CPU 利用率从 18% 提到 55%,等效节省 30 节点。 -
性能测试验证
a. 用 Locust 模拟 3 次峰值的 1.2 倍流量,持续 30 min,观察 P99 RT、错误率、Pod 重启次数;
b. ChaosMesh 随机回收 30% Spot 节点,验证 Cluster-Autoscaler 是否 3 min 内补齐,业务成功率 ≥99.9%;
c. 连续 7 天生产灰度,对比云账单:Spot 节省 62%,包年包月折扣 35%,整体计算成本下降 22.4%,达到目标。 -
持续运营
a. 把预测模型与压测报告固化到 CI,每周自动重训;
b. 调度策略参数纳入 GitOps,变更需走 MR + 性能基线门禁;
c. 建立“成本 SLO”:每万元日账单对应的 RT 涨幅 ≤5%,否则回滚。
拓展思考
- 如果业务峰谷不再规律(大促随机弹),如何把预测模型升级为实时强化学习?
- 国内云对 Spot 的回收提前通知只有 2 min,如何结合 eBPF 实现亚秒级连接迁移,保证长链接业务无损?
- 在信创 ARM 节点与 x86 混部场景下,同一镜像多架构,调度器如何自动选择最佳 CPU 架构以进一步降本?