作者：李涛（吕风）

Koordinator [ 1] 继前次v0.6版别​ [ 2] 发布后，经过 Koordinator 社区的努力，咱们迎来了具有重大意义的 v0.7 版别。在这个版别中着重建设了机器学习、大数据场景需求的使命调度才干，例如 Coscheduling、ElasticQuota 和精密化的 GPU 同享调度才干。并在调度问题确诊剖析方面得到了增强，重调度器也极大的提高了安全性，下降了重调度的危险。

版别功能特性解读

使命调度

Enhanced Coscheduling

Gang scheduling 是在并发体系中将多个相相关的进程调度到不同处理器上一起运转的战略，其最主要的原则是保证一切相相关的进程能够一起发动，防止部分进程的反常，导致整个相关进程组的阻塞。例如当提交一个 Job 时会产生多个使命，这些使命期望要么悉数调度成功，要么悉数失利。这种需求称为 All-or-Nothing，对应的完结被称作 Gang Scheduling(or Coscheduling) 。

Koordinator 在发动之初，期望支撑 Kubernetes 多种作业负载的混部调度，提高作业负载的运转时功率和可靠性，其中就包含了机器学习和大数据范畴中广泛存在的具有 All-or-Nothing 需求的作业负载。为了处理 All-or-Nothing 调度需求，Koordinator v0.7.0 根据社区已有的 Coscheduling 完结了 Enhanced Coscheduling。

Enhanced Coscheduling 秉承着 Koordiantor 兼容社区的原则，彻底兼容社区 scheduler-plugins/Coscheduling 和依赖的 PodGroup CRD。现已运用 PodGroup 的用户能够无缝升级到 Koordinator。

除此之外，Enhanced Coscheduling 还完结了如下增强才干：

1. 支撑 Strict 和 NonStrict 两种方法

scheduler-plugins/Coscheduling 在调度失利时会 Reject 一切分配到资源但处于 Wait 状况的 Pod。这种方法咱们界说为 Strict 方法，也是默许方法。但这种方法关于体量较大的 Job 并不是很友爱，有可能会导致这种大体量的 Job 拿不到资源。为了处理这个问题，咱们答应调度失利时不当即 Reject，并经过重试调度测验拿到资源满意 MinMember。这种方法咱们称为 NonStrict。尽管这种方法关于体量大的 Job 友爱，能够让这种 Job 更快的调度完结，但一起也添加了资源死锁的危险。后续 Koordinator 会供给 NonStrict 方法下处理死锁的计划完结。

要运用这种方法也比较简略，在 PodGroup 或许 Pod 中追加 annotation gang.scheduling.koordinator.sh/mode=NonStrict 敞开 NonStrict 方法。

2. 改进 PodGroup 调度失利的处理机制，完结更高效的重试调度

社区 scheduler-plugins/Coscheduling 在调度失利后会在一段时刻不在测验处理该 PodGroup。这个时刻一般是 20 秒。而且只支撑依照插件维度装备，不支撑用户按事务装备不同的时刻。别的这种时刻参数一般也难装备合适的值。

而在 Enhanced Coscheduling 中，完结了一种根据 ScheduleCycle 的重试机制。能够简略的理解为一种熔断机制。每个 PodGroup 会有一个单调递加的变量，咱们界说为 ScheduleCycle(PodGroup)，初始值为 1。该 PodGroup 相关的一切 Pod 也有一个 ScheduleCycle 变量，咱们界说为 ScheduleCycle(Pod)，初始值为 ScheduleCycle(PodGroup) – 1。每次 Pod 调度时，ScheduleCycle(Pod) 等于当时 ScheduleCycle(PodGroup)。

当一个 PodGroup 中的一个 Pod 调度失利时，会符号当时的 ScheduleCycle(PodGroup) 无效，后续其他 Pod 都会调度失利。当该 PodGroup 中一切 Pod ScheduleCycle(Pod) 都与当时 ScheduleCycle(PodGroup) 持平时，ScheduleCycle(PodGroup) 开端递加，答应重新开端进行调度。这种方法能够有效躲避根据过期时刻的缺点，彻底取决于调度行列的装备重试调度。

Koordinator v0.7: 为任务调度领域注入新活力

根据 ScheduleCycle 的重试机制

3. 支撑多个 PodGroup 为一组完结 Gang Scheduling

一些杂乱的 Job 有多种人物，每个人物办理一批使命，每个人物的使命要求支撑 All-or-Nothing ，每个人物的 MinMember 要求也不一样，而且每个人物之间也要求 All-or-Nothing。这就导致每个人物都有一个对应的 PodGroup ，而且还要求 PodGroup 即便满意了也需求等候其他人物的 PodGroup 有必要满意。社区 Coscheduling 无法满意这种场景需求。而 Koordinator 完结的 Enhanced Coscheduling 支撑用户在多个 PodGroup 中添加 anntation 相关相关完结，并支撑跨Namespace。例如用户有 2 个 PodGroup ，名字分别是PodGroupA 和 PodGroupB，能够依照如下例子相关两个 PodGroup：

apiVersion: v1alpha1
kind: PodGroup
metadata:
  name: podGroupA
  namespace: default
  annotations:
    gang.scheduling.koordinator.sh/groups: ["namespaceA/podGroupA", "namespaceB/podGroupB"]
spec:
  ...
4. 支撑轻量化 Gang 协议

假如用户不期望创立 PodGroup，以为创立 PodGroup 太繁琐，那么能够考虑在一组 Pod 中填充相同的 annotation gang.scheduling.koordinator.sh/name= 表明这一组 Pod 运用 Coscheduling 调度。假如期望设置 minMember ，能够追加 Annotation gang.scheduling.koordinator.sh/min-available=。举个例子：

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gang.scheduling.koordinator.sh/name: "pod-group-a"
    gang.scheduling.koordinator.sh/min-available: "5"
  name: demo-pod
  namespace: default
spec:
  ...

ElasticQuota Scheduling

一家中大型公司内有多个产品和研制团队，共用多个比较大规模的 Kubernetes 集群，这些集群内含有的很多 CPU/Memory/Disk 等资源被资源运营团队统一办理。运营团队往往在收购资源前，经过额度预算的机制让公司内每个团队根据自身的需求提交额度预算。事务团队此刻一般根据事务当时和对未来的预期做好额度预算。最理想的状况是每一份额度都能够被运用，但现实告知咱们这是不现实的。往往呈现的问题是：

  1. 团队 A 高估了事务的发展速度，恳求了太多的额度用不完
  2. 团队 B 低估了事务的发展速度，恳求的额度不行用
  3. 团队 C 安排了一场活动，手上的额度不行多了，可是活动只持续几周，恳求太多额度和资源也会糟蹋掉。
  4. 团队 D 下面还有各个子团队和事务，每个子团队内也会呈现相似 A B C 三个团队的状况，而且其中有些团队的事务暂时突发需求提交一些核算使命要交个客户，可是没有额度了，走额度预算审批也不行了。
  5. ……

以上咱们日常常常遇到的场景，在混部场景、大数据场景，暂时性突发需求又是经常呈现的，这些资源的需求都给额度办理作业带来了极大的挑战。做好额度办理作业，一方面防止过度收购资源下降本钱，又要在暂时需求额度时不收购资源或许尽量少的收购资源；另一方面不能由于额度问题束缚资源运用率，额度办理欠好就会导致即便有比较好的技能协助复用资源，也无法发挥其价值。总归，额度办理作业是广阔公司或组织需长期面临且有必要面临的问题。

Kubernetes ResourceQuota 能够处理额度办理的部分问题。原生 Kubernetes ResourceQuota API 用于指定每个 Namespace 的最大资源额度量，并经过 admission 机制完结准入检查。假如 Namespace 当时资源分配总量超越 ResourceQuota 指定的配额，则回绝创立 Pod。Kubernetes ResourceQuota 规划有一个局限性：Quota 用量是依照 Pod Requests 聚合的。尽管这种机制能够保证实践的资源消耗永远不会超越 ResourceQuota 的束缚，但它可能会导致资源利用率低，由于一些 Pod 可能现已恳求了资源但未能调度。

Kuberenetes Scheduler-Sig 后来给出了一个学习 Yarn Capacity Scheduling，称作 ElasticQuota 的规划计划并给出了详细的完结。答应用户设置 max 和 min：

  • max 表明用户能够消费的资源上限
  • min 表明需求保证用户完结根本功能/功能所需求的最小资源量

经过这两个参数能够协助用户完结如下的需求：

  1. 用户设置 min < max 时，当有突发资源需求时，即便当时 ElasticQuota 的总用量超越了 min， 但只要没有达到 max，那么用户能够持续创立新的 Pod 应对新的使命恳求。
  2. 当用户需求更多资源时，用户能够从其他 ElasticQuota 中“借用(borrow)” 还没有被运用而且需求通保证的 min。
  3. 当一个 ElasticQuota 需求运用 min 资源时，会经过抢占机制从其他借用方抢回来，即驱赶一些其他 ElasticQuota 超越 min 用量的 Pod。

ElasticQuota 还有一些局限性：没有很好的保证公平性。假如同一个 ElasticQuota 有很多新建的 Pod，有可能会消耗一切其他能够被借用的 Quota，从而导致后来的 Pod 可能拿不到 Quota。此刻只能经过抢占机制抢回来一些 Quota。

别的 ElasticQuota 和 Kubernetes ResourceQuota 都是面向 Namespace 的，不支撑多级树形结构，关于一些自身具有杂乱组织关系的企业/组织不能很好的运用 ElasticQuota/Kubenretes ResourceQuota 完结额度办理作业。

Koordinator 针对这些额度办理问题，给出了一种根据社区 ElasticQuota 完结的支撑多级办理方法的弹性 Quota 办理机制(multi hierarchy quota management)。具有如下特性：

  • 兼容社区的 ElasticQuota API。用户能够无缝升级到 Koordinator
  • 支撑树形结构办理 Quota。
  • 支撑依照同享权重(shared weight)保证公平性。
  • 答应用户设置是否答应借用 Quota 给其他消费目标。
1. Pod 相关 ElasticQuota 方法

用户能够十分运用的运用该才干，能够彻底依照 ElasticQuota 的用法，即每个 Namespace 设置一个 ElasticQuota 目标。也能够在 Pod 中追加 Label 相关 ElasticQuota：

apiVersion: v1
kind: Pod
metadata:
  labels:
    quota.scheduling.koordinator.sh/name: "elastic-quota-a"
  name: demo-pod
  namespace: default
spec:
  ...
2. 树形结构办理机制和运用办法

需求运用树形结构办理 Quota 时，需求在 ElasticQuota 中追加 Label quota.scheduling.koordinator.sh/is-parent表明当时 ElasticQuota 是否是父节点，quota.scheduling.koordinator.sh/parent表明当时 ElasticQuota 的父节点 ElasticQuota 的名字。举个例子：

Koordinator v0.7: 为任务调度领域注入新活力

咱们创立一个 ElasticQuota parentA 作为父节点，资源总量为CPU 100C，内存 200Gi，以及子节点 childA1

apiVersion: scheduling.sigs.k8s.io/v1alpha1
kind: ElasticQuota
metadata:
  name: parentA
  namespace: default
  labels:
    quota.scheduling.koordinator.sh/is-parent: "true"
    quota.scheduling.koordinator.sh/allow-lent-resource: "true"
spec:
  max:
    cpu: 100
    memory: 200Gi
  min:
    cpu: 100
    memory: 200Gi
---
apiVersion: scheduling.sigs.k8s.io/v1alpha1
kind: ElasticQuota
metadata:
  name: childA1
  namespace: default
  labels:
    quota.scheduling.koordinator.sh/is-parent: "false"
    quota.scheduling.koordinator.sh/parent: "parentA"
    quota.scheduling.koordinator.sh/allow-lent-resource: "true"
spec:
  max:
    cpu: 40
    memory: 100Gi
  min:
    cpu: 20
    memory: 40Gi

在运用树形结构办理 ElasticQuota 时，有一些需求遵从的束缚：

  1. 除了根节点，其他一切子节点的 min 之和要小于父节点的 min。

  2. 不束缚子节点 max，答应子节点的 max 大于父节点的 max。考虑以下场景，集群中有 2 个 ElasticQuota 子树：dev-parent 和 production-parent，每个子树都有几个子 ElasticQuota。当 production-parent 忙时，咱们能够经过只下降 dev-parent 的 max 束缚 dev-parent 整颗子树的资源运用量，而不是下降 dev-parent 子树的每个子 ElasticQuota 的 max 束缚用量。

  3. Pod 不能运用父节点 ElasticQuota。假如放开这个束缚，会导致整个弹性 Quota 的机制变的反常杂乱，暂时不考虑支撑这种场景。

  4. 只有父节点能够挂子节点，不答应子节点挂子节点。

  5. 暂时不答应改动 ElasticQuota 的 quota.scheduling.koordinator.sh/is-parent 属性

咱们将在下个版别中经过 webhook 机制完结这些束缚。

3. 公平性保证机制

Koordinator ElasticQuota 支撑依照同享权重(shared weight)保证公平性。shared-weight 表明一个 ElasticQuota 目标 的竞争力，默许等于 ElasticQuota Max。经过公平性保证机制，会给一切 min < max 的 ElasticQuota 分配实践可用的资源量，该资源量用 runtime表明，并保证 runtime 在min 与 max 之间，即 max >= runtime >= min。

当一个 ElasticQuota 目标相关的一切 Pod 的资源恳求量（咱们界说为 request）大于 min 时，会借用其他 ElasticQuota 目标中 min 未分配的部分。被借出去的 Quota 需求运用时，会再次经过该公平性保证机制拿回来。

别的还有一种日常生产时会遇到的状况：即集群内资源总量会随着节点毛病、资源运营等原因下降，导致一切 ElasticQuota 的 min 之和大于资源总量。当呈现这种状况时，咱们无法保证 min 的资源需求。此刻咱们会依照必定的比例调整各个 ElasticQuota 的 min，保证一切 min 之和小于或许等于当时实践的资源总量。

4. 抢占机制

Koordinator ElasticQuota 机制在调度阶段假如发现 Quota 不足，会进入抢占阶段，依照优先级排序，抢占属于同一个ElasticQuota 内的 低优先级 Pod。一起，咱们不支撑跨 ElasticQuota 抢占其他 Pod。可是咱们也供给了别的的机制支撑从借用 Quota 的 ElasticQuota 抢回。

举个例子，在集群中，有两个 ElasticQuota，ElasticQuota A {min = 50, max = 100}， ElasticQuota B {min = 50, max = 100}。用户在上午 10 点运用 ElasticQuota A 提交了一个 Job， Request = 100 ，此刻由于 ElasticQuota B 无人运用，ElasticQuota A 能从 B 手里借用 50 个 Quota，满意了 Request = 100， 而且此刻 Used = 100。在 11 点钟时，另一个用户开端运用 ElasticQuota B 提交 Job，Request = 100，由于 ElasticQuota B 的 min = 50，是有必要保证的，经过公平性保证机制，此刻 A 和 B 的 runtime 均为 50。那么此刻关于 ElasticQuota A ，Used = 100 是大于当时 runtime = 50 的，因而咱们会供给一个 Controller，驱赶掉一部分 Pod ，使得当时 ElasticQuota A 的 Used 下降到 runtime 持平的水位。

精密化资源调度

Device Share Scheduling

机器学习范畴里依靠很多强壮算力功能的 GPU 设备完结模型训练，可是 GPU 自身价格十分贵重。怎么更好地利用 GPU 设备，发挥 GPU 的价值，下降本钱，是一个亟待处理的问题。Kubernetes 社区现有的 GPU 分配机制中，GPU 是由 kubelet 分配的，并只支撑分配一个或多个完好的 GPU 实例。这种办法简略可靠，但相似于 CPU 和 Memory，GPU 并不是一向处于高利用率水位，相同存在资源糟蹋的问题。因而，Koordinator 期望支撑多作业负载同享运用 GPU 设备以节约本钱。此外，GPU 有其特殊性。比如下面的 NVIDIA GPU 支撑的 NVLink 和超卖场景，都需求经过调度器进行中心决策，以取得大局最优的分配成果。

Koordinator v0.7: 为任务调度领域注入新活力

从图中咱们能够发现，尽管该节点有 8 个 GPU 实例，型号为 A100/V100，但 GPU 实例之间的数据传输速度是不同的。当一个 Pod 需求多个 GPU 实例时，咱们能够为 Pod 分配具有最大数据传输速度组合关系的 GPU 实例。此外，当咱们期望一组 Pod 中的 GPU 实例具有最大数据传输速度组合关系时，调度器应该将最佳 GPU 实例批量分配给这些 Pod，并将它们分配到同一个节点。

1. GPU 资源协议

Koordinator 兼容社区已有的 nvidia.com/gpu 资源协议，而且还自界说了扩展资源协议，支撑用户更细粒度的分配 GPU 资源。

  • kubernetes.io/gpu-core 代表 GPU 的核算才干。与 Kuberetes MilliCPU 相似，咱们将 GPU 的总算力抽象为 100，用户能够根据需求恳求相应数量的 GPU 算力。
  • kubernetes.io/gpu-memory 表明 GPU 的内存容量，以字节为单位。
  • kubernetes.io/gpu-memory-ratio 代表 GPU 内存的百分比。

假定一个节点有 4 个 GPU 设备实例，每个 GPU 设备实例有 8Gi 显存。用户假如期望恳求一个完好的 GPU 实例，除了运用 nvidia.com/gpu 之外，还能够依照如下方法恳求：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  namespace: default
spec:
  containers:
  - name: main
    resources:
      limits: 
        kubernetes.io/gpu-core: 100
        kubernetes.io/gpu-memory: "8Gi"
      requests:
        kubernetes.io/gpu-core: 100
        kubernetes.io/gpu-memory: "8Gi"

假如期望只运用一个 GPU 实例一半的资源，能够依照如下方法恳求：

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
  namespace: default
spec:
  containers:
  - name: main
    resources:
      limits: 
        kubernetes.io/gpu-core: 50
        kubernetes.io/gpu-memory: "4Gi"
      requests:
        kubernetes.io/gpu-core: 50
        kubernetes.io/gpu-memory: "4Gi"
2. 设备信息和设备容量上报

在 Koordinator v0.7.0 版别中，单机侧 koordlet 装置后会自动识别节点上是否含有 GPU 设备，假如存在的话，会上报这些 GPU 设备的 Minor ID、 UUID、算力和显存巨细到一个类型为 Device CRD 中。每个节点对应一个 Device CRD 实例。Device CRD 不仅支撑描绘 GPU，还支撑相似于 FPGA/RDMA 等设备类型，现在 v0.7.0 版别只支撑 GPU， 暂未支撑这些设备类型。

Device CRD 会被 koord-manager 内的 NodeResource controller 和 koord-scheduler 消费。NodeResource controller 会根据 Device CRD 中描绘的信息，换算成 Koordinator 支撑的资源协议 kubernetes.io/gpu-core,kubernetes.io/gpu-memory 更新到 Node.Status.Allocatable 和 Node.Status.Capacity 字段，协助调度器和 kubelet 完结资源调度。gpu-core 表明 GPU 设备实例的算力，一个实例的完好算力为100。假定一个节点有 8 个 GPU 设备实例，那么节点的 gpu-core 容量为 8 * 100 = 800；gpu-memory 表明 GPU 设备实例的显存巨细，单位为字节，相同的节点能够分配的显存总量为 设备数量 * 每个实例的单位容量，例如一个 GPU 设备的显存是 8G，节点上有 8 个 GPU 实例，总量为 8 * 8G = 64G。

apiVersion: v1
kind: Node
metadata:
  name: node-a
status:
  capacity:
    koordinator.sh/gpu-core: 800
    koordinator.sh/gpu-memory: "64Gi"
    koordinator.sh/gpu-memory-ratio: 800
  allocatable:
    koordinator.sh/gpu-core: 800
    koordinator.sh/gpu-memory: "64Gi"
    koordinator.sh/gpu-memory-ratio: 800
3. 中心调度分配设备资源

Kuberetes 社区原生供给的设备调度机制中，调度器只担任校验设备容量是否满意 Pod，关于一些简略的设备类型是足够的，可是当需求更细粒度分配 GPU 时，需求中心调度器给予支撑才干完结大局最优。

Koordinator 调度器 koord-scheduler 新增了调度插件 DeviceShare，担任精密度设备资源调度。DeviceShare 插件消费 Device CRD，记载每个节点能够分配的设备信息。DeviceShare 在调度时，会把 Pod 的GPU资源恳求转换为 Koordinator 的资源协议，并过滤每个节点的未分配的 GPU 设备实例。保证有资源可用后，在 Reserve 阶段更新内部状况，并在 PreBind 阶段更新 Pod Annotation，记载当时 Pod 应该运用哪些 GPU 设备。

DeviceShare 将在后续版别支撑 Binpacking 和 Spread 战略，完结更好的设备资源调度才干。

4. 单机侧精准绑定设备信息

Kubernetes 社区在 kubelet 中供给了 DevicePlugin 机制，支撑设备厂商在 kubelet 分配好设备后有时机取得设备信息，并填充到环境变量或许更新挂载路径。可是不能支撑 中心化的 GPU 精密化调度场景。

针对这个问题， Koordinator 扩展了 koord-runtime-proxy ，支撑在 kubelet 创立容器时更新环境变量，注入调度器分配的 GPU 设备信息。

Koordinator v0.7: 为任务调度领域注入新活力

调度器确诊剖析

咱们在运用 Kubernetes 经常常会遇到一些调度相关的问题：

  1. 我这个 Pod 为什么不能调度？
  2. 这个 Pod 为什么会调度到这个节点，不是应该被另一个打分插件影响到么？
  3. 我新开发了一个插件，发现调度成果不符合预期，可是有不知道哪里出了问题。

要确诊剖析这些问题，除了要掌握 Kubernetes 根本的调度机制和资源分配机制外，还需求调度器自身给予支撑。可是 Kubernetes kube-scheduler 供给的确诊才干比较有限，有时候乃至没有什么日志能够检查。kube-scheduler 原生是支撑经过 HTTP 更改日志等级，能够取得更多日志信息，例如履行如下命令能够更改日志等级到 5：

$ curl -X PUT schedulerLeaderIP:10251/debug/flags/v --data '5'
successfully set klog.logging.verbosity to 5

Koordinator 针对这些问题，完结了一套 Restful API ，协助用户提高问题确诊剖析的功率

  • 剖析 Score 成果

PUT /debug/flags/s 答应用户打开 Debug Score 开关，在打分完毕后，以Markdown 格式打印 TopN 节点各个插件的分值。例如：

$ curl -X PUT schedulerLeaderIP:10251/debug/flags/s --data '100'
successfully set debugTopNScores to 100

当有新 Pod 调度时，观察 scheduler log 能够看到如下信息

| # | Pod | Node | Score | ImageLocality | InterPodAffinity | LoadAwareScheduling | NodeAffinity | NodeNUMAResource | NodeResourcesBalancedAllocation | NodeResourcesFit | PodTopologySpread | Reservation | TaintToleration || --- | --- | --- | ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:| ---:|
| 0 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.51 | 577 | 0 | 0 | 87 | 0 | 0 | 96 | 94 | 200 | 0 | 100 || 1 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.50 | 574 | 0 | 0 | 85 | 0 | 0 | 96 | 93 | 200 | 0 | 100 |
| 2 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.19 | 541 | 0 | 0 | 55 | 0 | 0 | 95 | 91 | 200 | 0 | 100 || 3 | default/curlimage-545745d8f8-rngp7 | cn-hangzhou.10.0.4.18 | 487 | 0 | 0 | 15 | 0 | 0 | 90 | 82 | 200 | 0 | 100 |

找个 Markdown 东西，就能够转为如下表格：

Koordinator v0.7: 为任务调度领域注入新活力

  • 调度插件导出内部状况

像 koord-scheduler 内部的 NodeNUMAResource 、 DeviceShare 和 ElasticQuota 等插件内部都有保护一些状况协助调度。koord-scheduler 自界说了一个新的插件扩展接口（界说见下文），并会在初始化插件后，识别该插件是否完结了该接口并调用该接口，让插件注入需求暴露的 RestfulAPI。以 NodeNUMAResource 插件为例，会供给/cpuTopologyOptions/:nodeName 和/availableCPUs/:nodeName 两个 Endpoints，能够检查插件内部记载的 CPU 拓扑信息和分配成果。

type APIServiceProvider interface {
  RegisterEndpoints(group *gin.RouterGroup)
}

用户在运用时，依照 /apis/v1/plugins//方 式构建 URL 检查数据，例如要检查 /cpuTopologyOptions/:nodeName：

$ curl schedulerLeaderIP:10252/apis/v1/plugins/NodeNUMAResources/cpuTopologyOptions/node-1
{"cpuTopology":{"numCPUs":32,"numCores":16,"numNodes":1,"numSockets":1,"cpuDetails":....
  • 检查当时支撑的插件 API

为了便利咱们运用，koord-scheduler 供给了 /apis/v1/services 检查支撑的 API Endpoints

$ curl schedulerLeaderIP:10251/apis/v1/__services__
{
    "GET": [
        "/apis/v1/__services__",
        "/apis/v1/nodes/:nodeName",
        "/apis/v1/plugins/Coscheduling/gang/:namespace/:name",
        "/apis/v1/plugins/DeviceShare/nodeDeviceSummaries",
        "/apis/v1/plugins/DeviceShare/nodeDeviceSummaries/:name",
        "/apis/v1/plugins/ElasticQuota/quota/:name",
        "/apis/v1/plugins/NodeNUMAResource/availableCPUs/:nodeName",
        "/apis/v1/plugins/NodeNUMAResource/cpuTopologyOptions/:nodeName"
    ]
}

更安全的重调度

在 Koordinator v0.6 版别中咱们发布了全新的 koord-descheduler，支撑插件化完结需求的重调度战略和自界说驱赶机制，并内置了面向 PodMigrationJob 的迁移控制器，经过 Koordinator Reservation 机制预留资源，保证有资源的状况下建议驱赶。处理了 Pod 被驱赶后无资源可用影响应用的可用性问题。

Koordinator v0.7 版别中，koord-descheduler 完结了更安全的重调度

  • 支撑 Evict 限流，用户能够根据需求装备限流战略，例如答应每分钟驱赶多少个 Pod
  • 支撑装备 Namespace 灰度重调度才干，让用户能够更定心的灰度
  • 支撑依照 Node/Namespace 装备驱赶数量，例如装备节点维度最多只驱赶两个，那么即便有插件要求驱赶该节点上的更多 Pod，会被回绝。
  • 感知 Workload ，假如一个 Workload 正在发布、缩容、现已有必定量的 Pod 正在被驱赶或许一些 Pod NotReady，重调度器会回绝新的重调度恳求。现在支撑原生的 Deployment，StatefulSet 以及 Kruise CloneSet，Kruise AdvancedStatefulSet。

后续重调度器还会提高公平性，防止一向重复的重调度同一个 workload ，尽量下降重调度对应用的可用性的影响。

其他改动

  • Koordinator 进一步增强了 CPU 精密化调度才干，彻底兼容 kubelet ( <= v1.22) CPU Manager static 战略。调度器分配 CPU 时会防止分配被 kubelet 预留的 CPU，单机侧 koordlet 完好适配了 kubelet 从 1.18 到 1.22 版别的分配战略，有效防止了 CPU 抵触。
  • 资源预留机制支撑 AllocateOnce 语义，满意单次预留场景。并改进了 Reservation 状况语义，愈加精确描绘 Reservation 目标当时的状况。
  • 改进了离线资源(Batch CPU/Memory) 的声明方法，支撑 limit 大于 request 的资源描绘方法，能够便利原 burstable 类型的使命直接转换为混部方法运转。

你能够经过Github release [ 3] 页面，来检查更多的改动以及它们的作者与提交记载。

社区参加

十分欢迎你经过 Github/Slack/钉钉/微信 等方法参加咱们来参加 Koordinator 开源社区。你是否现已有一些期望与咱们社区沟通的内容呢？能够经过以下途径参加评论：

  • 参加社区Slack channel [ 4] (English)
  • 参加社区钉钉群：搜索群号 33383887 (Chinese) 或许扫描下方二维码

Koordinator v0.7: 为任务调度领域注入新活力

相关链接

[1] Koordinator

koordinator.sh/

[2] Koordinator 0.6 Release Note

mp.weixin.qq.com/s/YdoxVxz_9…

[3] Github Release

github.com/koordinator…

[4] Slack Channel

join.slack.com/t/koordinat…

[5] Design: Gang Scheduling

https://github.com/koordinator-sh/koordinator/blob/main/docs/proposals/scheduling/20220901-gang-scheduling.md

[6] Design: Multi Hierarchy ElasticQuota Management

github.com/koordinator…

[7] Design: Fine-grained Device Scheduling

github.com/koordinator…

[8] 云原生混部体系 Koordinator 架构详 解

mp.weixin.qq.com/s/y8k_q6rhT…

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