Koordinator v1.4 正式发布！为用户带来更多的计算负载类型和更灵活的资源管理机制
内容提要
Koordinator v1.4.0版本发布，新增Kubernetes与YARN负载混部、NUMA拓扑对齐策略、CPU归一化和冷内存上报等特性。增强了弹性配额管理、宿主机非容器化应用的QoS管理和重调度防护策略。旨在支持企业级Kubernetes集群环境，提供更多计算负载类型支持和灵活的资源管理机制。
延伸解读
NUMA 拓扑对齐：从节点到集群的调度优化
Koordinator v1.4.0 将 NUMA 拓扑对齐的决策从 Kubelet 上移到中心调度器，解决了节点组件缺乏全局视角导致 Pod 因拓扑不满足而启动失败的问题。新版本支持 None、BestEffort、Restricted 和 SingleNUMANode 四种策略，并允许通过节点 Label 配置。同时，调度器支持对 NUMA 节点分配结果进行打分，可选择 LeastAllocated 或 MostAllocated 策略，并支持资源权重配置。这为机器学习等高性能计算场景提供了更灵活的拓扑管理能力
ElasticQuota 增强：多 QuotaTree 与不可抢占 Pod
v1.4.0 对 ElasticQuota 进行了多项增强：引入 Multi QuotaTree 支持按节点属性（如架构、可用区）划分资源池，并通过 ElasticQuotaProfile 简化节点关联；新增 non-preemptible 特性，允许 Pod 声明不可被抢占，避免在线服务因资源回收而受影响，但需合理设置 min 并确保资源保障；此外，还支持通过 annotation 限制 ElasticQuota 的共享命名空间，并优化了配额树重建性能。这些改进提升了多租户场景下的资源管理灵活性和公平性。
CPU 归一化：异构节点算力一致性
针对不同架构和代数的 CPU 性能差异，Koordinator v1.4.0 引入了 CPU 归一化机制。该机制通过调整节点可分配 CPU 数量，使每个 CPU 单元提供的计算能力在异构节点间保持一致。用户需先评估 CPU 性能基准（如参考 SPEC CPU），然后将归一化系数配置到 slo-controller-config 中。Koordinator 通过 Webhook 拦截 Kubelet 对 Node.Status.Allocatable 的更新，实现资源缩放。这有助于避免因 CPU 性能不一致导致的资源
重调度防护与冷内存上报：稳定性与资源效率
v1.4.0 将重调度防护策略增强为仲裁机制，通过排序和筛选决定哪些 PodMigrationJob 可执行，避免大量 Pod 同时迁移引发稳定性问题。排序考虑迁移开始时间、Pod 优先级和工作负载分散；筛选则检查工作负载、节点和命名空间的迁移数量阈值。同时，新版本引入冷内存上报功能，通过 koordlet 收集冷页面信息并上报到 NodeMetric CRD，为未来冷内存回收打下基础，旨在提升节点内存利用率和混部资源效率。
Q&A
Koordinator v1.4.0 版本有哪些主要新特性？
Koordinator v1.4.0 引入了 Kubernetes 与 YARN 负载混部、NUMA 拓扑对齐策略、CPU 归一化和冷内存上报等新特性，同时重点增强了弹性配额管理、宿主机非容器化应用的 QoS 管理、重调度防护策略等领域的功能。
Koordinator 如何实现 K8s 与 YARN 混部？
Koordinator 通过 Koordinator YARN Copilot 支持将 Hadoop NodeManager 运行在 Kubernetes 集群中。它基于 Hadoop YARN 开源版本，不涉及侵入式改造；YARN NM 使用 Koordinator 的 Batch 优先级资源，遵循 Koordinator QoS 管理策略；节点级别的混部资源既可被 K8s Pod 使用，也可被 YARN task 使用，不同类型的离线应用可运行在同一节点。
Koordinator 的 NUMA 拓扑对齐策略有哪些？
Koordinator 支持通过节点 Label 配置 NUMA 拓扑对齐策略，包括：None（默认，不执行任何拓扑对齐）、BestEffort（不严格按照 NUMA 拓扑对齐分配资源）、Restricted（严格按照 NUMA 拓扑对齐，可使用多个 NUMA 节点）、SingleNUMANode（严格按照 NUMA 拓扑对齐，只允许使用一个 NUMA 节点）。
ElasticQuota 的 non-preemptible 特性是什么？
non-preemptible 特性允许用户通过在 Pod 上声明 quota.scheduling.koordinator.sh/preemptible: false 来标记 Pod 不可被抢占。调度器调度时发现 Pod 声明了不可抢占，则此类 Pod 的可用配额上限不能超过 min。启用该能力时，需要合理设置 ElasticQuota 的 min，并确保集群内有相应的资源保障。
CPU 归一化机制是如何工作的？
CPU 归一化通过标准化节点上可分配 CPU 的性能，保证每个 CPU 单元在异构节点间提供的计算能力一致。它分为两个步骤：1. CPU 性能评估，计算不同 CPU 的性能基准（Koordinator 未提供）；2. 配置 CPU 归一化系数到 Koordinator，调度系统基于归一化系数调度资源。Koordinator 通过 Webhook 拦截 Kubelet 对 Node.Status.Allocatable 的更新以实现 CPU 资源的缩放。
Koordinator 的重调度防护策略如何通过仲裁机制优化 Pod 迁移？
Koordinator v1.4.0 将重调度防护策略增强为仲裁机制。当有大量 PodMigrationJob 可执行时，仲裁器通过排序和筛选决定哪些可以执行。排序依据：迁移开始时间与当前时间的间隔（越小排名越高）、Pod 优先级（越低排名越高）、按工作负载分散 Jobs、若作业中已有 Pods 正在迁移则排名更高。筛选过程：按工作负载、节点、命名空间分组筛选；检查每个工作负载中运行状态的 PodMigrationJob 数量是否超阈值；检查不可用副本数是否超出最大不可用副本数；检查目标节点上正在迁移的 Pod 数量是否超过单节点最大迁移量。
冷内存上报功能的作用是什么？
冷内存上报功能为未来冷内存回收打下基础。冷内存回收主要用于两个场景：1. 对于标准 Kubernetes 集群，当节点内存水位过高时，突发的内存请求容器导致系统直接内存回收，影响已运行容器性能，保持节点内存相对空闲对提升稳定性至关重要；2. 在混部场景中，高优先级应用程序请求但未使用的资源可被低优先级应用程序回收利用，回收容器未使用的内存页面可提高整机资源利用效率。
Koordinator 如何管理非容器化应用的 QoS？
Koordinator 开发了节点资源预留机制，可以在尚未容器化的应用预留资源并赋予特定的 QoS 特性。目前支持：LS (Latency Sensitive) CPU QoS (Group Identity)：应用将进程运行在 cgroup 的 cpu 子系统中，koordlet 根据配置设置 Group Identity 参数；CPUSet Allocation：koordlet 为其设置 cpu share pool 中的所有 CPU 核心；BE (Best-effort) CPU QoS (Group Identity)：koordlet 根据配置设置 Group Identity 参数。
