Koordinator 一周年，新版本 v1.2.0 支持节点资源预留，兼容社区重调度策略

阿里云云原生 2023-04-20

303

背景

Cloud Native

Koordinator 是一个开源项目，基于阿里巴巴在容器调度领域多年累积的经验孵化诞生，可以提升容器性能，降低集群资源成本。通过混部、资源画像、调度优化等技术能力，能够提高延迟敏感的工作负载和批处理作业的运行效率和可靠性，优化集群资源使用效率。

从 2022 年 4 月发布以来，Koordinator 迄今一共迭代发布了 10 个版本，吸引了了包括阿里巴巴、小米、小红书、爱奇艺、360、有赞等在内的大量优秀工程师参与贡献。随着 2023 年春天的来临，Koordinator 也迎来了它的一周年，在此我们很高兴的向大家宣布，Koordinator v1.2 版本正式发布。新版本中 Koordinator 支持了节点资源预留功能，并兼容了 K8s 社区的重调度策略，同时在单机侧增加了对 AMD 环境 L3 Cache 和内存带宽隔离的支持。

在新版本中，共有 12 位新加入的开发者参与到了 Koordiantor 社区的建设，他们是@Re-Grh，@chengweiv5，@kingeasternsun，@shelwinnn，@yuexian1234，@Syulin7，@tzzcfrank，@Dengerwei，@complone，@AlbeeSo，@xigang，@leason00，感谢以上开发者的贡献和参与。

新特性早知道

Cloud Native

节点资源预留

混部场景中包含的应用形态多种多样，除了已经完成云原生化的容器，还包含很多尚未完成容器化的应用，这部分应用会以进程的形式在宿主机上与 K8s 容器共同运行。为了减少 K8s 应用和其他类型应用在节点侧的资源竞争，Koordinator 支持将一部分资源预留，使其既不参与调度器的资源调度，也不参与节点侧的资源分配，达到资源分隔使用的效果。在 v1.2 版本中，Koordiantor 已经支持 CPU 和内存资源维度的预留，并允许直接指定预留的 CPU 编号，具体如下。

节点资源预留声明

在 Node 上可以配置需要预留的资源量或具体的 CPU 编号，举例如下：

apiVersion: v1
kind: Node
metadata:
  name: fake-node
  annotations: # specific 5 cores will be calculated, e.g. 0, 1, 2, 3, 4, and then those core will be reserved.
    node.koordinator.sh/reservation: '{"resources":{"cpu":"5"}}'
---
apiVersion: v1
kind: Node
metadata:
  name: fake-node
  annotations: # the cores 0, 1, 2, 3 will be reserved.
    node.koordinator.sh/reservation: '{"reservedCPUs":"0-3"}'

单机组件 Koordlet 在上报节点资源拓扑信息时，会将具体预留的 CPU 编号更新到 NodeResourceTopology 对象的 Annotation 中。

调度及重调度场景适配

调度器在分配资源的过程中，涉及了多种情况的资源校验，包括 Quota 管理，节点容量校验，CPU 拓扑校验等等，这些场景都需要增加对节点预留资源的考虑，例如，调度器在计算节点 CPU 容量时，需要将节点预留的资源进行扣除。

cpus(alloc) = cpus(total) - cpus(allocated) - cpus(kubeletReserved) - cpus(nodeAnnoReserved)

此外，对于 Batch 混部超卖资源的计算同样需要将这部分资源扣除，而考虑到节点中还包括一部分系统进程的资源消耗，Koord-Manager 在计算时会取节点预留和系统用量的最大值，具体为：

reserveRatio = (100-thresholdPercent)  100.0
node.reserved = node.alloc * reserveRatio
system.used = max(node.used - pod.used, node.anno.reserved)
Node(BE).Alloc = Node.Alloc - Node.Reserved - System.Used - Pod(LS).Used

对于重调度，各插件策略需要在节点容量、利用率计算等场景感知节点预留资源量，此外，若已经有容器占用了节点的预留资源，重调度需要考虑将其进行驱逐，确保节点容量得到正确管理，避免资源竞争。这部分重调度相关的功能，我们将在后续版本进行支持，也欢迎广大爱好者们一起参与共建。

单机资源管理

对于 LS 类型的 Pod，单机 Koordlet 组件会根据 CPU 分配情况动态计算共享 CPU 池，对于节点预留的 CPU 核心会将其排除在外，确保 LS 类型 pod 和其他非容器化的进程资源隔离。同时，对于单机相关的 QoS 策略，例如 CPUSuppress 压制策略在计算节点利用率时，会将预留资源量考虑在内。

suppress(BE) := node.Total * SLOPercent - pod(LS).Used - max(system.Used, node.anno.reserved)

关于节点资源预留功能的详细说明，可以参考设计文档中的介绍，详见：

https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20221227-node-resource-reservation.md

兼容社区重调度策略

得益于 Koordinator Descheduler 的框架日益成熟，在 Koordinator v1.2 版本中，通过引入一种接口适配机制，可以无缝的对 Kubernetes Desceheduler 已有插件进行兼容，在使用时您只需部署 Koordinator Descheduler 即可使用到上游的全部功能。

在实现上，Koordinator Descheduler 通过 import 上游代码不做任何侵入式的改动，保证完全兼容上游所有的插件、参数配置以及其运行策略。同时，Koordinator 允许用户为上游插件指定增强的 evictor，从而复用 Koordinator 提供的资源预留、工作负载可用性保障以及全局流控等安全性策略。

兼容的插件列表：

HighNodeUtilization
LowNodeUtilization
PodLifeTime
RemoveFailedPods
RemoveDuplicates
RemovePodsHavingTooManyRestarts
RemovePodsViolatingInterPodAntiAffinity
RemovePodsViolatingNodeAffinity
RemovePodsViolatingNodeTaints
RemovePodsViolatingTopologySpreadConstraint
DefaultEvictor

在使用时，可以参考如下的方式配置，以 RemovePodsHavingTooManyRestarts 为例：

apiVersion: descheduler/v1alpha2
kind: DeschedulerConfiguration
clientConnection:
  kubeconfig: "/Users/joseph/asi/koord-2/admin.kubeconfig"
leaderElection:
  leaderElect: false
  resourceName: test-descheduler
  resourceNamespace: kube-system
deschedulingInterval: 10s
dryRun: true
profiles:
- name: koord-descheduler
  plugins:
    evict:
      enabled:
        - name: MigrationController
   deschedule:
     enabled:
       - name: RemovePodsHavingTooManyRestarts
  pluginConfig:
    - name: RemovePodsHavingTooManyRestarts
      args:
        apiVersion: descheduler/v1alpha2
        kind: RemovePodsHavingTooManyRestartsArgs
        podRestartThreshold: 10

资源预留调度能力增强

Koordinator 在比较早期的版本中引入了 Reservation 机制，通过预留资源并复用给指定特征的 Pod 使用，用于帮助解决资源交付确定性问题。例如重调度场景中期望被驱逐的 Pod 一定有资源可以使用，而不是被驱逐后无资源可用导致引起稳定性问题；又或者需要扩容时，一些 PaaS 平台希望能够先确定是否满足应用调度编排的资源，再决定是否扩容，或者提前做一些预备工作等。

Koordinator Reservation 通过 CRD 定义，每个 Reservation 对象会在 koord-scheduler 内伪造成一个 Pod 进行调度，这样的 Pod 我们称为 Reserve Pod，Reserve Pod 就可以复用已有的调度插件和打分插件找到合适的节点，并最终在调度器内部状态中占据对应的资源。Reservation 在创建时都会指定预留的资源将来要给哪些 Pod 使用，可以指定具体某个 Pod，也可以指定某些 workload 对象，或者具备某些标签的 Pod 使用。当这些 Pod 通过 koord-scheduler 调度时，调度器会找到可以被该 Pod 使用的 Reservation 对象，并且优先使用 Reservation 的资源。并且 Reservation Status 中会记录被哪个 Pod 使用，以及 Pod Annotations 中也会记录使用了哪个 Reservation。Reservation 被使用后，会自动的清理内部状态，确保其他 Pod 不会因为 Reservation 导致无法调度。

在 Koordinator v1.2 中，我们做了大幅度的优化。首先我们放开了只能使用 Reservation 持有的资源的限制，允许跨出 Reservation 的资源边界，既可以使用 Reservation 预留的资源，也可以使用节点上剩余的资源。而且我们通过非侵入式的方式扩展了 Kubernetes Scheduler Framework，支持预留精细化资源，即可以预留 CPU 核和 GPU 设备等。我们也修改了 Reservation 可以被重复使用的默认行为，改为 AllocateOnce，即 Reservation 一旦被某个 Pod 使用，该 Reservation 会被废弃。这样的改动是考虑到，AllocateOnce 更能覆盖大部分场景，这样作为默认行为，大家在使用时会更简单。

支持 AMD 环境下的 L3 Cache 和内存带宽隔离

在 v0.3.0 版本中，Koordiantor 已经支持了 Intel 环境的 L3 Cache 和内存带宽隔离，在最新的 1.2.0 版本中我们新增了对 AMD 环境的支持。

Linux 内核 L3 Cache 和内存带宽隔离能力提供了统一的 resctrl 接口，同时支持 Intel 和 AMD 环境，主要区别在于，Intel 提供的内存带宽隔离接口为百分比格式，而 AMD 提供的内存带宽隔离接口为绝对值格式，具体如下。

# Intel Format
# resctrl schema
L3:0=3ff;1=3ff
MB:0=100;1=100


# AMD Format
# resctrl schema
L3:0=ffff;1=ffff;2=ffff;3=ffff;4=ffff;5=ffff;6=ffff;7=ffff;8=ffff;9=ffff;10=ffff;11=ffff;12=ffff;13=ffff;14=ffff;15=ffff
MB:0=2048;1=2048;2=2048;3=2048;4=2048;5=2048;6=2048;7=2048;8=2048;9=2048;10=2048;11=2048;12=2048;13=2048;14=2048;15=2048

接口格式包含两部分，L3 表示对应的 socket 或 CCD 可用的“路数”（way），以 16 进制的数据格式表示，每个比特位表示一路；MB 表示对应的 socket 或 CCD 可以使用的内存带宽范围，Intel 可选范围为 0~100 的百分比格式，AMD 对应的为绝对值格式，单位为 Gb/s，2048 表示不限制。Koordiantor 统一提供了百分比格式的接口，并自动感知节点环境是否为 AMD，决定 resctrl 接口中填写的格式。

apiVersion: v1
kind: ConfigMap
metadata:
  name: slo-controller-config
  namespace: koordinator-system
data:
  resource-qos-config: |-
    {
      "clusterStrategy": {
        "lsClass": {
           "resctrlQOS": {
             "enable": true,
             "catRangeStartPercent": 0,
             "catRangeEndPercent": 100,
             "MBAPercent": 100
           }
         },
        "beClass": {
           "resctrlQOS": {
             "enable": true,
             "catRangeStartPercent": 0,
             "catRangeEndPercent": 30,
             "MBAPercent": 100
           }
         }
      }
    }

其他功能

通过 v1.2 release^[^1] 页面，可以看到更多版本所包含的新增功能。

未来计划

Cloud Native

在接下来的版本中，Koordiantor 重点规划了以下功能，具体包括：

硬件拓扑感知调度，综合考虑节点 CPU、内存、GPU 等多个资源维度的拓扑关系，在集群范围内进行调度优化。
对重调度器的可观测性和可追溯性进行增强。
GPU 资源调度能力的增强。

Koordinator 是一个开放的社区，非常欢迎广大云原生爱好者们通过各种方式一起参与共建，无论您在云原生领域是初学乍练还是驾轻就熟，我们都非常期待听到您的声音！

您也可以使用钉钉扫描下方二维码或搜索群号：33383887 加入 Koordinator 社区钉钉群：

相关链接：

[1] v1.2 release

https://github.com/koordinator-sh/koordinator/releases/tag/v1.2.0

点击阅读原文，立即了解 Koordinator 项目！

pod cpu参数社区功能

文章转载自阿里云云原生，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。

Koordinator 一周年，新版本 v1.2.0 支持节点资源预留，兼容社区重调度策略

节点资源预留声明

调度及重调度场景适配

单机资源管理

评论