Koordinator v1.5：持续优化，进入CNCF Sandbox-阿里云开发者社区

【阅读原文】戳：Koordinator v1.5：持续优化，进入CNCF Sandbox

背景

Koordinator[1]是一个开源项目，基于阿里巴巴在容器调度领域的多年经验积累而生，自发布以来经历了个版本的迭代，持续不断地为Kubernetes生态系统带来创新和增强。旨在提供混部工作负载编排、混部资源调度、混部资源隔离和混部性能调优的综合解决方案，帮助用户优化容器性能，并提升集群资源使用效率，管理和优化延迟敏感型工作负载和批处理作业的运行效率和可靠性。

在此，我们向大家宣布Koordinator v1.5.0版本的发布，这是自2022年4月正式开源以来，Koordinator迭代发布的第13个大版本。在2年多的时间里，Koordinator很荣幸吸引了包括阿里巴巴、蚂蚁科技、Intel、小红书、小米、爱奇艺、360、有赞等众多企业的优秀工程师参与，贡献了众多的想法、代码和场景。在v1.5.0版本中，Koordinator带来了众多的功能优化，新增了Pod级别NUMA对齐策略、网络QoS、Core Scheduling等功能支持。

此外，Koordinator项目近期通过了CNCF TOC投票，顺利被CNCF基金会接受为Sandbox项目，CNCF全称Cloud Native Computing Foundation（云原生计算基金会），旨在为云原生软件构建可持续发展的生态系统，服务于厂商中立的快速增长的开源项目，如Kubernetes、Prometheus等。

投票地址：

https://github.com/cncf/sandbox/issues/51

版本功能特性解读

Pod 级别 NUMA 对齐策略

在v1.4.0版本中，Koordinator支持了用户在节点上加标签为不同节点配置不同的NUMA对齐策略。然而这意味着用户需要提前将集群中的节点拆分为不同 NUMA对齐策略的节点池，引入了额外管理节点的负担。Koordinator在v1.5.0中引入了Pod级别的NUMA对齐策略来解决该问题。举例，我们可以为pod-1设置SingleNUMANode：

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  annotations: 
    scheduling.koordinator.sh/numa-topology-spec: |-
      {
        "numaTopologyPolicy": "SingleNUMANode"
      }
spec:
  containers:
    resource:
      requests:
        cpu: 1
      limits:
        cpu: 1

引入Pod级别的NUMA策略后，必然会出现不同NUMA策略的节点部署在同一个NUMA Node的情况。举例，node-1有两个NUMA Node，pod-1采用SingleNUMANode策略使用了numa-0，pod-2采用Restricted策略使用了numa-0和numa-1。由于Pod设置Limit只能限制Pod在整机维度最多能使用多少资源，无法限制在某个NUMA节点下最多能使用多少NUMA资源，所以pod-2在numa-0使用的资源可能超过调度器分配给它的资源量。这时候pod-2和pod-1在numa-0上存在资源竞争。为了解决上述问题，Koordinator支持用户为SingleNUMANode的Pod配置独占策略。举例，我们可以配置Pod为SingleNUMANode且不与跨NUMA共存在一个机器上：

apiVersion: v1
kind: Pod
metadata:
  name: pod-1
  annotations: 
    scheduling.koordinator.sh/numa-topology-spec: |-
      {
        "numaTopologyPolicy": "SingleNUMANode",
        "singleNUMANodeExclusive": "Required" # Required or Preferred
      }
spec:
  containers:
    resource:
      requests:
        cpu: 1
      limits:
        cpu: 1

另外，Pod级别的NUMA策略的引入并不意味着废弃Node级别的NUMA策略，而是相互兼容的。因此，如果Pod和节点上的策略不同，Pod将不会被调度到该节点上；如果节点上的策略为“”，则表示该节点能够放置任何Pod；如果Pod上的策略为“”，则表示 Pod可以调度到任何节点上。

关于Pod级别NUMA对齐策略的更多信息，请见Proposal: Pod-level NUMA Policy[2]。

Terway网络QoS

在v1.5.0版本中，Koordinator联动Terway[3]社区提供了网络QoS能力。

Terway QoS[4]的诞生是为了解决混部场景下的网络带宽争抢问题，它支持按单个Pod或QoS类型进行带宽限制，与其他方案相比具备以下优势：

1. 支持按业务类型限制带宽，适用于多种业务混部的场景。

2. 支持动态调整Pod带宽限制。

3. 提供整机带宽限制，支持多网卡，支持容器网络和HostNetWork Pod的带宽限制。

Terway QoS包括3种网络带宽的优先级，对应的Koordinator默认QoS映射如下：

在混部场景中，我们希望在线业务具有最大的带宽保障，以避免争抢；在空闲时，离线业务也可以充分利用所有带宽资源。

因此，用户可以为业务流量定义为3个优先级，从高到低依次为：L0、L1、L2。我们定义争用场景为：当 L0+L1+L2的总流量超过整机带宽时。

L0的最大带宽根据L1和L2的实时流量动态调整。它可以高至整机带宽，低至“整机带宽-L1最小带宽-L2最小带宽”。在任何情况下，L1和L2的带宽都不会超过各自的上限。在争用场景中，L1和L2的带宽不会低于各自的下限。在争用场景中，带宽将按L2、L1和L0的顺序进行限制。由于Terway QoS只有三个优先级，因此只能设置LS和BE的全机带宽限制，其余L0部分根据整机的带宽上限计算。

下面是一个配置示例：

# unit: bps
resource-qos-config: |
    {
      "clusterStrategy": {
        "policies": {"netQOSPolicy":"terway-qos"},
        "lsClass": {
          "networkQOS": {
            "enable": true,
            "ingressRequest": "50M",
            "ingressLimit": "100M",
            "egressRequest": "50M",
            "egressLimit": "100M"
          }
        },
        "beClass": {
          "networkQOS": {
            "enable": true,
            "ingressRequest": "10M",
            "ingressLimit": "200M",
            "egressRequest": "10M",
            "egressLimit": "200M"
          }
        }
      }
    }
system-config: |-
    {
      "clusterStrategy": {
        "totalNetworkBandwidth": "600M"
      }
    }

此外，网络QoS能力也支持Pod维度的带宽限制，采用以下annotations协议：

关于网络QoS能力的更多信息，请见Network Bandwidth Limitation Using Terway QoS[5]和Terway[3]社区。

Core Scheduling

在v1.5.0版本中，Koordinator提供了容器维度的Core Scheduling能力，用于多租户场景下降低侧信道（Side Channel Attack）攻击风险，也可以作为CPU QoS能力增强混部隔离。

Linux Core Scheduling[6]支持在用户态定义可以共享物理核的任务分组。属于同一分组的任务将赋予相同的cookie作为标识，同一物理核（SMT维度）在同一时刻只会运行一种cookie的任务。通过将这种机制应用到安全方面或性能方面，我们可以做到以下事情：

1. 对不同租户的任务进行物理核维度的隔离。

2. 避免离线任务争抢在线服务的物理资源。

Koordinator使能内核的Core Scheduling机制，实现容器维度的分组隔离策略，最终形成了以下两种能力：

1. Pod运行时物理核隔离：对Pods进行分组，不同分组的Pods不能同时共享物理核，保障多租户隔离。

2. 下一代CPU QoS策略：作为Group Identity机制以外，兼顾安全的CPU QoS能力。

Pod运行时物理核隔离

Koordinator提供Pod Label协议，标识Pod的Core Scheduling分组。

不同分组的Pods运行时在物理核层面互斥，可以规避了一些物理核、L1 cache、L2 cache维度的侧信道攻击，适用于多租户场景。

区别于绑核调度，Pod运行的物理核范围并不固定，同一物理核在不同时刻可能运行着不同分组的Pods，物理核资源可以被分时复用。

下一代CPU QoS策略

Koordinator基于Anolis OS[7]内核提供的Core Scheduling和CGroup Idle机制，构建了新的CPU QoS策略。

• BE容器启用CGroup Idle特性，最小化调度权重和优先级。

• LSR/LS容器启用Core Scheduling特性，支持驱逐物理核上同分组的BE任务。

用户可以通过在ConfigMap中指定cpuPolicy="coreSched"来启用该策略。

# Example of the slo-controller-config ConfigMap.
apiVersion: v1
kind: ConfigMap
metadata:
  name: slo-controller-config
  namespace: koordinator-system
data:
  resource-qos-config: |
    {
      "clusterStrategy": {
        "policies": {
          "cpuPolicy": "coreSched"
        },
        "lsClass": {
          "cpuQOS": {
            "enable": true,
            "coreExpeller": true,
            "schedIdle": 0
          }
        },
        "beClass": {
          "cpuQOS": {
            "enable": true,
            "coreExpeller": false,
            "schedIdle": 1
          }
        }
      }
    }

关于Core Scheduling能力的更多信息，请见CPU QoS[8]。

其他功能

除了上述新功能特性以外，Koordinator v1.5.0版本还包含了以下一系列的功能增强和稳定性优化：

1. 功能增强：Reservation Restricted模式下支持通过Annotation控制哪些资源严格遵循Restricted语义；将NUMA对齐策略Restricted的语义跟上游对齐；Coscheduling实现完全公平的调度队列排队规则，确保同一个GangGroup的Pod一起出队，不同Gang以及裸Pod之间按照上次调度时间排队；NRI模式支持重连机制；koordlet优化监控指标分类，增加性能指标；BlkioReconcile配置能力增强。

2. BugFixes：修复koordlet CPU压制功能的内存泄露问题；修复runtimeproxy的panic问题；修正CPICollector、BECPUEvict、CPUBurst模块计算逻辑。

3. 环境适配：所有组件升级到K8S 1.28；koordlet支持非CUDA镜像的部署；koordlet适配kubelet 1.28配置，优化cpu manager兼容逻辑；适配cri-o运行时。

4. 重构优化：koordlet优化Resctrl更新逻辑；优化单机驱逐接口逻辑；优化节点GPU资源和卡型号同步逻辑；优化Batch账本计算逻辑。

5. CI/CD：修复多个flaky tests。

通过v1.5.0 Release[9]页面，可以看到更多包含在v1.5.0版本的功能改动。

欢迎社区新成员

Koordinator是一个开放的社区，在v1.5.0版本中，共有10位新的开发者参与到了Koordinator的建设，他们是@georgexiang、@googs1025、@l1b0k、@ls-2018、@PeterChg、@sjtufl、@testwill、@yangfeiyu20102011、@zhifanggao、@zwForrest。

Koordinator社区目前有许多来自不同行业的企业级贡献者，其中不少同学成为了项目的Maintainer和Member，近期新加入的Maintainer成员有 @songzh215、@j4ckstraw、@lucming、@kangclzjc。在此感谢各位新同学的积极参与和老同学的持续投入，也欢迎更多优秀的同学参与到Koordinator[1]社区～

未来计划

在接下来的版本中，Koordinator目前规划了以下工作：

• 调度性能优化：调度性能是调度器能否应对大规模集群的关键指标。接下来的版本中，Koordinator将给出基本的压测环境搭建手册以及常见压测场景，并着手提升Koord-Scheduler的调度性能。

• 设备联合分配：在AI大模型分布式训练场景中，不同机器GPU之间通常需要通过高性能网卡相互通信，且GPU和高性能网卡就近分配的时候性能更好。Koordinator正在推进支持多种异构资源的联合分配，目前已经在协议上和调度器分配逻辑上支持联合分配；单机侧关于网卡资源的上报逻辑正在探索中。

• Job粒度的抢占实现：在大规模共享集群中，有些配额可能非常繁忙，有些配额可能处于空闲状态。在ElasticQuota插件中，我们已经支持从空闲的 ElasticQuota借用资源。但是，当被借用的ElasticQuota关联的Pod需要取回资源时，并没有考虑到Job粒度。对于属于同一个Job的Pod，我们需要以Job粒度进行抢占，以确保获得足够的资源来满足Job的需求，提高资源交付效率。之前社区已经通过了Proposal[10]，接下来Koordinator将推进该提案的实现。

• 负载感知调度针对inflight pods的优化：负载感知调度当前基于节点真实利用率进行多个维度的调度过滤和打分，可以用于优化节点利用率的分布，降低Pod调度到高负载节点的风险；不过，由于节点利用率视图存在同步延迟，各个阶段的inflight pods可能影响利用率信息的准确性，接下来，负载感知调度将完善这部分优化，更充分地规避调度到过载节点，优化节点间的负载均衡度。

• 细粒度的末级缓存及内存带宽隔离策略：容器间争抢共享的末级缓存和内存带宽资源，可能导致应用访存性能的抖动；当前Koordinator提供了ResctrlQoS能力，在满足隔离分组的数量限制的前提下，用来对QoS维度隔离末级缓存和内存带宽资源，降低离线负载对在线应用的干扰。下一步，Koordinator将基于v1.3版本支持的NRI（Node Resource Interface）框架[11]，增强末级缓存及内存带宽的隔离策略，提供Pod维度的隔离能力，增强功能的灵活性和时效性。

致谢

自开源以来，Koordinator已经共计发布了19个小版本，吸引了80多名贡献者的参与，社区的不断发展壮大，离不开广大工程师的积极参与，在此真诚感谢各位社区同学们的贡献和持续投入。同时，也特别感谢CNCF社区同仁对项目发展的提供的大力支持。

欢迎更多开发者和用户参与Koordinator社区建设，是您们的积极参与和宝贵意见让Koordinator不断进步。我们期待您继续提供反馈，并欢迎新的贡献者加入我们的行列。您可以使用钉钉搜索群号33383887或使用钉钉扫描下发二维码加入Koordinator社区钉钉群，无论您在云原生领域是初学乍练还是驾轻就熟，我们都非常期待听到您的声音！