1、背景

Koordinator 是阿里开源的云原生混部调度系统，在 K8s 之上实现了在线/离线工作负载共存，通过内核机制保障在线服务质量，提升集群整体资源利用率。Koordinator 最初针对 Anolis OS（龙蜥）的内核特性进行了适配，当我们把基础设施切换到 openEuler（欧拉）时，需要解决两者在混部接口上的差异。

本文记录了我们在 openEuler 上运行 Koordinator 的适配实践，重点聚焦于 Group Identity 与 SMT 隔离机制的差异和代码适配方案。

2、混部架构简述

Koordinator 的核心组件包括：

• Koord-Manager：集群级调度器，负责混部调度决策

• Koordlet：节点 Agent，将调度策略转化为内核配置（cgroup 参数写入等）

Koordlet 与操作系统内核接口的适配是本文的核心关注点。当 OS 内核接口不同时，Koordlet 需要感知并选择正确的接口。

┌─────────────────────────────────────────────┐
│ K8s Cluster │
│ ┌─────────────┐ ┌─────────────────┐ │
│ │ Koord- │ │ Koordlet │ │
│ │ Manager │───▶│ │ │
│ └─────────────┘ │ ┌───────────┐ │ │
│ │ │ Kernel │ │ │
│ │ │ Hooks │ │ │
│ │ │ (cgroup, │ │ │
│ │ │ BVT/QoS) │ │ │
│ │ └─────┬─────┘ │ │
│ └────────┼────────┘ │
│ │ │
│ ┌─────────▼─────────┐ │
│ │ OS Kernel │ │
│ │ (Anolis/openEuler)│ │
│ └───────────────────┘ │
└─────────────────────────────────────────────┘

3 混部功能支持对比

经过验证，Anolis OS 与 openEuler 在混部核心功能上均具备完整能力，差异主要体现在配置接口和参数语义上。

Group Identity 是差异最大的部分：Anolis 使用 cpu.bvt_warp_ns（4 级优先级），openEuler 使用 cpu.qos_level（2 级优先级），接口路径和语义不同，需要代码适配。

4.Group Identity 与 SMT 机制对比

openEuler：cpu.qos_level

openEuler 通过 cpu.qos_level 接口统一管理任务优先级与 SMT 驱逐行为，设计简洁：

cpu.qos_level	角色	调度行为	SMT 驱逐
0	在线任务（LC）	高调度优先级	✅ 自动启用
-1	离线任务（BE）	最低调度优先级，可被抢占	❌ 被 LC 驱逐

当 LC 任务独占物理核时，对应的超线程逻辑核上不会运行 BE 任务，从硬件层面消除干扰。前提是系统已开启 SMT：

cat /sys/devices/system/cpu/smt/active
# 输出 1 表示已启用

Anolis OS：cpu.bvt_warp_ns

Anolis 通过 Cgroup v1 的 cpu.bvt_warp_ns 接口配置，提供 4 级优先级：

设置值	角色	调度行为	SMT 驱逐
2	关键在线任务	最高优先级	✅ 启用
1	重要服务	高优先级	❌ 不启用
0	普通任务	默认值	❌ 不启用
-1	离线任务	最低优先级	❌ 被 LC 驱逐

核心差异

对比维度	Anolis (cpu.bvt_warp_ns)	openEuler (cpu.qos_level)
优先级粒度	4 级（2/1/0/-1）	2 级（0/-1）
SMT 驱逐触发	BVT=2 隐式触发	QoS=0 自动触发
Cgroup 版本	v1	v1（兼容 v2）
设计理念	细粒度区分服务等级	二元化：在线 vs 离线

Anolis 的中间优先级（BVT=1，高优先级但无 SMT 驱逐）在 openEuler 上没有直接对应。迁移时需要决策：映射为 0（获得 SMT 驱逐）还是保持默认。

5.openEuler SMT 功能验证

我们在 openEuler 测试环境上验证了 cpu.qos_level 的 SMT 驱逐效果。

测试环境

• CPU：24 核，SMT 已启用

• 操作系统：openEuler

测试步骤

1. 准备 Cgroup

mkdir -p /sys/fs/cgroup/cpu/online.slice
mkdir -p /sys/fs/cgroup/cpu/offline.slice
echo -1 > /sys/fs/cgroup/cpu/offline.slice/cpu.qos_level

2. 启动离线任务（无在线干扰）

docker run -it --cgroup-parent=/offline.slice \
stress-ng -c 24

整机 CPU 被占满（24 核全部 100%）。

3. 启动在线任务（验证 SMT 驱逐）

docker run --cpus 4 --cpuset-cpus 0-3 \
–cgroup-parent=/online.slice \
stress -c 4

在线服务使用 CPU 0-3，对应的超线程逻辑核上的离线进程被自动压制，CPU 资源让给在线服务。

测试结果

场景	在线任务	离线任务	结果
仅离线运行	—	占满 24 核	✅ 整机 CPU 占满
在线+离线共存	CPU 0-3	已占满 0-23	✅ 对应超线程核上离线进程被压制

openEuler 的 SMT 驱逐机制基于 cpu.qos_level 生效且可靠。

6.Koordinator 代码适配方案

优先级映射

Koordinator 语义	Anolis BVT	openEuler QoS	说明
LC（在线，启用 SMT 驱逐）	2	0	映射为在线，自动获得 SMT 驱逐
LC（在线，无 SMT 驱逐）	1	0	openEuler 无中间态，默认映射为 0
普通任务	0	0	保持默认
BE（离线）	-1	-1	一一对应

Anolis BVT=1 在 openEuler 上无直接对应，当前映射为 0（获得 SMT 驱逐能力）。如有业务依赖此中间态需单独评估。

核心修改文件

pkg/koordlet/runtimehooks/hooks/groupidentity/bvt.go

主要改动：

1. 新增接口路径抽象

const (
anolisBVTPath = “cpu.bvt_warp_ns”
openEulerQoSLevelPath = “cpu.qos_level”
)

func getPriorityPath(osType string) string {
switch osType {
case “openEuler”:
return openEulerQoSLevelPath
default:
return anolisBVTPath
}
}

2. 优先级值映射

func mapPriorityLevel(bvtValue int, osType string) int {
if osType == “openEuler” {
if bvtValue >= 0 {
return 0 // 所有非负值映射为在线
}
return -1 // 负值映射为离线
}
return bvtValue // Anolis 直接使用原值
}

3. OS 类型检测

推荐通过接口探测而非 OS 标识，更加健壮：

// 探测接口是否存在
func detectOSType() string {
if _, err := os.Stat(“/sys/fs/cgroup/cpu/cpu.qos_level”); err == nil {
return “openEuler”
}
return “Anolis”
}

改动范围

代码库中所有直接读写 cpu.bvt_warp_ns 的位置均需改为通过抽象层操作：

1. - bvt.go — Group Identity 核心逻辑，优先级写入

2. - cgroup 操作辅助函数 — 文件路径拼接、读写封装

3. - 初始化逻辑 — 节点启动时检测 OS 类型，选择接口

7.迁移注意事项

混合集群

龙蜥与欧拉节点共存时，Koordlet 需根据节点 OS 动态选择接口，不能硬编码单一路径。上述接口探测方案可以解决这个问题。

回归测试

适配修改后需在 openEuler 环境上完整测试所有混部功能，不能只测 SMT 驱逐：

• 离线任务 CPU 压制

• 离线任务驱逐

• SMT 物理核隔离

• 绑核与 cgroup 资源限制

监控指标

迁移后重点关注在线服务延迟指标（P99/P999），确认混部效果无退化。

灰度策略

建议先在测试集群验证，再逐步灰度到生产节点。

8.风险评估

风险项	等级	缓解措施
优先级粒度丢失（BVT=1 无对应）	中	梳理业务是否使用 BVT=1
混合集群接口管理	中	节点级 OS 检测，动态选择接口
内核版本兼容性	低	部署前验证 cpu.qos_level 可用
Koordinator 升级兼容	低	适配代码提交上游或维护 fork

9.总结

1. - 功能对等：openEuler 在混部所需的全部内核功能上与 Anolis OS 能力对等

2. - 差异明确：核心差异在 Group Identity 接口——Anolis 用 cpu.bvt_warp_ns（4 级），openEuler 用 cpu.qos_level（2 级）

3. - 适配成本可控：主要修改 bvt.go 一个文件，新增接口抽象和优先级映射

4. - 已验证可行：openEuler SMT 驱逐功能实测通过，cpu.qos_level 机制有效

从 Anolis 迁移到 openEuler 在技术层面无阻塞性问题，适配工作量可控，后续重点在于完整回归测试和混合集群的灰度验证。

360智汇云是企业智数云底座，以"智-数-云"三大核心底座为支柱，以贯穿全程的 “观测与管控” 为神经中枢，全链路赋能企业数智基建在 “用、运、管、看、维” 五维生命周期中实现价值闭环。提供数据库、中间件、存储、大数据、人工智能、计算等多种产品服务以及一站式解决方案，让每一份IT投入都转化为智能生产力。

官网：https://zyun.360.cn