关于云原生:Koordinator-v07-为任务调度领域注入新活力

作者：李涛（吕风）

Koordinator [ 1] 继上次 [v0.6 版本 [ 2] ](https://mp.weixin.qq.com/s?__…)公布后，通过 Koordinator 社区的致力，咱们迎来了具备重大意义的 v0.7 版本。在这个版本中着重建设了机器学习、大数据场景须要的任务调度能力，例如 Coscheduling、ElasticQuota 和精细化的 GPU 共享调度能力。并在调度问题诊断剖析方面失去了加强，重调度器也极大的晋升了安全性，升高了重调度的危险。

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) 开始递增，容许从新开始进行调度。这种形式能够无效躲避基于过期工夫的缺点，齐全取决于调度队列的配置重试调度。

基于 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=<podGroupName> 示意这一组 Pod 应用 Coscheduling 调度。如果冀望设置 minMember，能够追加 Annotation gang.scheduling.koordinator.sh/min-available=<availableNum>。举个例子：

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:
  ...

一家中大型公司内有多个产品和研发团队，共用多个比拟大规模的 Kubernetes 集群，这些集群内含有的大量 CPU/Memory/Disk 等资源被资源经营团队对立治理。经营团队往往在洽购资源前，通过额度估算的机制让公司内每个团队依据本身的需要提交额度估算。业务团队此时个别依据业务以后和对将来的预期做好额度估算。最现实的状况是每一份额度都可能被应用，但事实通知咱们这是不事实的。往往呈现的问题是：

团队 A 高估了业务的倒退速度，申请了太多的额度用不完
团队 B 低估了业务的倒退速度，申请的额度不够用
团队 C 安顿了一场流动，手上的额度不够多了，然而流动只继续几周，申请太多额度和资源也会节约掉。
团队 D 上面还有各个子团队和业务，每个子团队内也会呈现相似 A B C 三个团队的状况，而且其中有些团队的业务长期突发须要提交一些计算工作要交个客户，然而没有额度了，走额度估算审批也不够了。
……

以上大家日常常常遇到的场景，在混部场景、大数据场景，临时性突发需要又是时常呈现的，这些资源的需要都给额度管理工作带来了极大的挑战。做好额度管理工作，一方面防止适度洽购资源降低成本，又要在长期须要额度时不洽购资源或者尽量少的洽购资源；另一方面不能因为额度问题限度资源使用率，额度治理不好就会导致即便有比拟好的技术帮忙复用资源，也无奈施展其价值。总之，额度管理工作是宽广公司或组织需长期面对且必须面对的问题。

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 示意须要保障用户实现基本功能 / 性能所须要的最小资源量

通过这两个参数能够帮忙用户实现如下的需要：

用户设置 min < max 时，当有突发资源需要时，即便以后 ElasticQuota 的总用量超过了 min，但只有没有达到 max，那么用户能够持续创立新的 Pod 应答新的工作申请。
当用户须要更多资源时，用户能够从其余 ElasticQuota 中“借用(borrow)”还没有被应用并且须要通保障的 min。
当一个 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 的名字。举个例子：

咱们创立一个 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 时，有一些须要遵循的束缚：

除了根节点，其余所有子节点的 min 之和要小于父节点的 min。
不限度子节点 max，容许子节点的 max 大于父节点的 max。思考以下场景，集群中有 2 个 ElasticQuota 子树：dev-parent 和 production-parent，每个子树都有几个子 ElasticQuota。当 production-parent 忙时，咱们能够通过只升高 dev-parent 的 max 限度 dev-parent 整颗子树的资源使用量，而不是升高 dev-parent 子树的每个子 ElasticQuota 的 max 限度用量。
Pod 不能应用父节点 ElasticQuota。如果放开这个限度，会导致整个弹性 Quota 的机制变的异样简单，临时不思考反对这种场景。
只有父节点能够挂子节点，不容许子节点挂子节点。
临时不容许扭转 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 相等的水位。

机器学习畛域里依附大量弱小算力性能的 GPU 设施实现模型训练，然而 GPU 本身价格非常低廉。如何更好地利用 GPU 设施，施展 GPU 的价值，降低成本，是一个亟待解决的问题。Kubernetes 社区现有的 GPU 分配机制中，GPU 是由 kubelet 调配的，并只反对调配一个或多个残缺的 GPU 实例。这种办法简略牢靠，但相似于 CPU 和 Memory，GPU 并不是始终处于高利用率水位，同样存在资源节约的问题。因而，Koordinator 心愿反对多工作负载共享应用 GPU 设施以节省成本。此外，GPU 有其特殊性。比方上面的 NVIDIA GPU 反对的 NVLink 和超卖场景，都须要通过调度器进行地方决策，以取得全局最优的调配后果。

从图中咱们能够发现，尽管该节点有 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 设施信息。

大家在应用 Kubernetes 时常常会遇到一些调度相干的问题：

我这个 Pod 为什么不能调度？
这个 Pod 为什么会调度到这个节点，不是应该被另一个打分插件影响到么？
我新开发了一个插件，发现调度后果不合乎预期，然而有不晓得哪里出了问题。

要诊断剖析这些问题，除了要把握 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 工具，就能够转为如下表格：

调度插件导出外部状态

像 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/<pluginName>/<pluginEndpoints> 方式构建 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) 或者扫描下方二维码

[1] Koordinator

https://koordinator.sh/

[2] Koordinator 0.6 Release Note

https://mp.weixin.qq.com/s/Yd…

*[3] Github Release*

https://github.com/koordinato…

*[4] Slack Channel*

https://join.slack.com/t/koor…

[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

https://github.com/koordinato…

[7] Design: Fine-grained Device Scheduling

https://github.com/koordinato…

[8] 云原生混部零碎 Koordinator 架构详 解

https://mp.weixin.qq.com/s/y8…

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

关于云原生:Koordinator-v07-为任务调度领域注入新活力

版本性能个性解读

任务调度

Enhanced Coscheduling

1. 反对 Strict 和 NonStrict 两种模式

2. 改良 PodGroup 调度失败的解决机制，实现更高效的重试调度

3. 反对多个 PodGroup 为一组实现 Gang Scheduling

4. 反对轻量化 Gang 协定

ElasticQuota Scheduling

1. Pod 关联 ElasticQuota 形式

2. 树形构造管理机制和应用办法

3. 公平性保障机制

4. 抢占机制

精细化资源调度

Device Share Scheduling

1. GPU 资源协定

2. 设施信息和设施容量上报

3. 核心调度调配设施资源

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

调度器诊断剖析

更平安的重调度

其余改变

社区参加

相干链接