乐趣区

关于阿里云:Koordinator-一周年新版本-v120-支持节点资源预留兼容社区重调度策略

jiezi

作者：佑祎、吕风

背景

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

新个性早晓得

节点资源预留

混部场景中蕴含的利用状态多种多样，除了曾经实现云原生化的容器，还蕴含很多尚未实现容器化的利用，这部分利用会以过程的模式在宿主机上与 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] 页面，能够看到更多版本所蕴含的新增性能。

将来打算

在接下来的版本中，Koordiantor 重点布局了以下性能，具体包含：

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

Koordinator 是一个凋谢的社区，十分欢送宽广云原生爱好者们通过各种形式一起参加共建，无论您在云原生畛域是初学乍练还是轻车熟路，咱们都十分期待听到您的声音！您也能够应用钉钉搜寻群号：33383887 退出 Koordinator 社区钉钉群：

相干链接：

[1] v1.2 release

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

点击此处，立刻理解 Koordinator 我的项目！

退出移动版