作者：佑祎、吕风

布景

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

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

从 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，感谢以上开发者的奉献和参加。

新特性早知道

节点资源预留

混部场景中包含的运用形态多种多样，除了现已完成云原生化的容器，还包含许多没有完成容器化的运用，这部分运用会以进程的形式在宿主机上与 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)

关于节点资源预留功用的详细阐明，能够参阅规划文档中的介绍，详见：github.com/koordinator…

兼容社区重调度战略

得益于 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] 页面，能够看到更多版别所包含的新增功用。

未来计划

在接下来的版别中，Koordiantor 重点规划了以下功用，详细包含：

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

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

Koordinator 是一个开放的社区，十分欢迎广大云原生爱好者们经过各种方法一起参加共建，无论您在云原生范畴是初学乍练还是驾轻就熟，咱们都十分期待听到您的声音！您也能够运用钉钉搜索群号：33383887 参加 Koordinator 社区钉钉群：

相关链接：

[1]v1.2 release

github.com/koordinator…

点击此处，立即了解 Koordinator 项目！