openFuyao技术讲堂 | 众核编排(Many-Core Orchestrator)
前引---众核编排:干扰感知调度与虚拟机级隔离,降低在线业务长尾延迟“抖动”。
特性介绍
在众核混部集群中,离线业务对共享硬件资源的“无声侵占”,如LLC缓存冲刷、块设备I/O队列挤占、内存回收压力飙升-----往往成为在线业务长尾延迟抖动的根源,而这些干扰Cgroup无法完全隔离。
openFuyao社区针对这一痛点,推出了Many-Core Orchestrator(MCO,众核调度编排系统)。MCO面向众核混部集群,提供宿主机干扰指标采集、节点干扰分析、Volcano干扰感知调度,以及可选的Kata Containers虚拟机级隔离能力。不修改应用代码的前提下,降低在线业务在I/O、LLC(Last Level Cache,末级缓存)缓存和内存压力混部场景下的长尾延迟抖动,并提高节点安全混部密度。
MCO的核心价值在于调度与隔离的双层防护:干扰感知调度从选节点阶段规避高干扰节点;Kata虚拟机级隔离从物理层面切断离线业务对在线业务的串扰。两者可独立使用,也可组合使用,灵活适配不同混部策略。
应用场景
MCO适合在线延迟敏感业务和离线吞吐型业务共用同一批众核节点的场景,例如Redis、实时推理、搜索服务与批处理、全量查询、I/O压测任务混部。系统重点感知以下干扰信号:
- LLC cache miss rate与LLC occupancy,用于识别缓存污染。
- block I/O latency P95/P99,用于识别块设备队列拥塞。
- PSI(Pressure Stall Information,压力停滞信息) I/O与PSI memory,用于识别资源等待压力。
- PSI不可用时,使用MemAvailable ratio与page scan rate做降级评估。
需要强调的是,MCO不会自动判断业务类型,也不会强制把某类Pod切换到Kata。是否使用Kata由用户在Pod中设置runtimeClassName决定,系统尊重用户的运维策略。
能力范围
MCO由四类核心组件组成:
表1 核心组件
| 组件 | 部署形态 | 作用 |
|---|---|---|
| Collector | DaemonSet | 在每个节点采集LLC、I/O、PSI、内存回收等宿主机指标,并通过gRPC(Google Remote Procedure Call,谷歌远程过程调用)上报Analyzer。 |
| Analyzer | Deployment | 对Collector样本做窗口平滑、规则检测和干扰等级计算,并写入NodeInterferenceReport。 |
| MCO Volcano Plugin | Volcano scheduler插件 | 在Filter阶段排除高压力或不满足Kata条件的节点,在Score阶段优先选择低干扰节点。 |
| Kata Deploy | Deployment/DaemonSet | 检查节点虚拟化能力,安装/注册Kata runtime handler,并创建RuntimeClass。 |
MCO使用两个CRD(Custom Resource Definition,自定义资源定义):
表2 CRD说明
| CRD | Scope | 简写 | 说明 |
|---|---|---|---|
NodeInterferenceReport | Cluster | nir | 保存所有节点的最新干扰等级、指标快照、检测原因和采样状态。默认对象名为cluster。 |
DetectionRuleConfig | Namespaced | drc | 保存干扰检测阈值、权重、惩罚系数和PSI降级规则。默认在mco-system命名空间,名称为cluster。 |
实现原理
MCO的数据链路清晰简洁:
Collector ->Analyzer -> NodeInterferenceReport CR -> Volcano mco-plugin -> Pod调度落点- 指标采集:Collector每秒采集一次宿主机指标(LLC miss/occupancy、bio latency P95/P99、PSI I/O/memory),通过gRPC流推送至Analyzer。
- 干扰分析:Analyzer对窗口内(默认10s)的样本取均值平滑,基于
DetectionRuleConfigCR中的阈值判定是否触发缓存污染、I/O 队列拥塞、内存压力三类检测,计算归一化干扰指数并加权求和得出干扰等级。 - 报告写入:Analyzer定期(默认1s)将各节点的干扰等级、原始指标快照、检测明细写入
NodeInterferenceReport/clusterCR的status.nodes中。 - 调度决策:MCO Plugin通过Kubernetes informer侦听
NodeInterferenceReport/cluster,在Filter阶段排除PSI memory full > 0 或 PSI I/O some 超过硬约束阈值的节点;在Score阶段按score = 100 × (1 - interferenceLevel)评分。 - Kata隔离:用户在Pod中设置
runtimeClassName: kata-*后,调度插件确保Pod只落到Kata就绪节点,容器运行时以独立Guest OS运行,从物理层面切断LLC缓存污染和I/O队列串扰。
安装与使用
- MCO通过Helm Chart部署,支持四种场景(全功能部署、只部署Kata隔离、只部署采集和分析以及接入已有Volcano集群)灵活组合,详情可参考安装。
- 使用干扰感知调度与Kata隔离的操作指导,包括启用调度、使用Kata隔离、查看干扰报告、调整检测规则和调度插件参数等,详情请参见使用干扰感知调度与Kata隔离。
未来展望
未来openFuyao社区将在以下方向持续演进众核调度隔离能力:
- 补充 CPU 中断抢占干扰维度:当前方案聚焦缓存污染与 I/O/内存带宽竞争两类干扰,CPU 调度队列积压与软中断抢占暂通过 I/O 压力指标间接反映。后续将引入 CPU steal time、运行队列延迟、中断率等独立采集与检测能力,形成更完整的微架构干扰感知体系。
- 策略增强与调优闭环:完善调度决策解释输出与指标看板,支持阈值热更新与配置回滚流程。
- 细粒度调度策略与自动化建议:基于预留的业务类型标签,结合实际混部场景迭代更细粒度的调度策略模板,并探索自动化阈值推荐能力,降低人工调优成本。
- 规模化长稳验证:在更多机型与负载组合下开展长周期稳定性与性能回归测试,持续验证并优化干扰感知与隔离能力在规模化集群中的表现。
资源参考
openFuyao v26.06版本软件包下载地址:https://www.openFuyao.cn/zh/download/
本文由openFuyao社区首发,欢迎遵照CC-BY-SA 4.0协议规定转载。
