共计 15907 个字符，预计需要花费 40 分钟才能阅读完成。
简介：通过社区多位成员的奉献，Koordinator 0.6 版本正式公布。相较于上一个版本 0.5，新版本进一步欠缺了 CPU 精细化编排能力，更好的兼容原生用法；反对了资源预留的能力（Reservation），补齐了调度原子语意缺失；公布了全新的重调度框架，反对用户灵便的扩大自定义插件。这些个性源自于阿里巴巴外部的生产实践，并联合上游社区规划思考，为用户带来规范、弱小、灵便的调度解决方案。作者：李涛、曾凡松 阿里云原生开源的混部零碎 Koordinator 基于阿里超大规模混部生产实践经验而来，旨在为用户打造云原生场景下接入老本最低、混部效率最佳的解决方案，助力用户企业实现云原生后晋升计算资源利用率、升高 IT 老本。通过社区多位成员的奉献，Koordinator 0.6 版本正式公布。相较于上一个版本 0.5[1]，新版本进一步欠缺了 CPU 精细化编排能力，更好的兼容原生用法；反对了资源预留的能力（Reservation），补齐了调度原子语意缺失；公布了全新的重调度框架，反对用户灵便的扩大自定义插件。这些个性源自于阿里巴巴外部的生产实践，并联合上游社区规划思考，为用户带来规范、弱小、灵便的调度解决方案。现代化调度零碎的挑战 多云、混合云成为业务常态，调度零碎必须适应多样化基础设施 随着国内外云厂商的一直倒退，到 2022 年，大多数企业基础设施将围绕云计算环境构建，企业基础设施以云计算为主，以自建为辅。云计算按需的算力调配个性帮忙企业实现通用、灵便、弹性的计算需要，自建局部满足企业传统利用架构适度、定制化或者平安合规诉求。在企业应用云时，最大的顾虑是应用了厂商锁定的技术，因而多云架构是近年企业重点关注的畛域，在多云环境中，不同云厂商的硬件可能存在不同水平的定制差别。调度零碎如何适配多云场景下异构的算力设施，解决好异构资源调度、拓扑感知、运行时 QoS 保障，让用户在不同环境取得统一的体验，是一个很大的挑战。为了帮忙企业便当地治理云上、线下的算力，也会倒退出混合云这样的产品架构，这其中可能呈现一个集群中即蕴含云上又蕴含线下的计算节点，根底环境比较复杂。调度零碎如何适配云上、线下环境，解决好不同环境对资源容量治理、工作编排、存储网络调度的诉求，同时反对用户在线下场景能够低成本的扩大自定义个性，让用户在一套调度零碎上编排云上、线下的容器资源，是第二大挑战。多种工作负载的混部成为常态，对调度零碎能力的要求更加全面平面 Kubernetes 容器调度编排零碎，帮忙用户在一个节点上运行多个容器，也就提供了将不同业务的容器同时运行到一个节点的可能。也就是说，Kubernetes 人造地就反对了“混部”。随着企业容器化上云的过程减速，越来越多的利用类型通过 Kubernetes 部署到云基础设施之上。当企业的利用越来越多，为每一种类型的利用独自布局集群，在运维老本和资源老本上将不再可行。企业治理不同业务类型的形式逐渐从切分集群到共享集群，从切分节点池到共享节点池这样的形式演进。不同业务类型的工作负载，对调度零碎都有不同的个性需要，调度零碎如何在同一个集群、同一个节点上编排不同类型的工作负载，解决好它们各自的运行效率稳定性、对 Kubernetes 管控面性能和节点运行时稳定性的诉求，是现代化调度零碎的一个重要课题。
老本效率成为企业关注的重点方向，调度零碎是其中的要害一环 2020 年开始，受寰球疫情的影响，企业的生产经营流动或多、或少的受到打击。有 65% 的企业开始思考通过上云的形式升高企业 IT 信息化老本，曾经上云的企业开始通过更深度的优化来升高 IT 资源老本。在老本治理畛域，FinOps 的理念逐步被企业所承受，在 2021 年 CNCF《FinOps Kubernetes Report》的调研报告显示，迁徙至 Kubernetes 平台后，68% 的受访者示意所在企业计算资源老本有所增加，36% 的受访者示意老本飙升超过 20%。这一调研后果与大型企业的利用实际截然不同，Google、微软、Alibaba 等国内外企业曾经通过实践证明了企业容器化在老本上的微小经济价值。这其中最要害的差异在于大型企业外部通常建设有齐备的老本洞察能力，晓得老本开销在哪里，同时建设了齐备而弱小的调度零碎，让企业的资源充沛的被利用起来。在这其中，调度零碎如何解决好企业内部门间的 Quota 治理、资源借用，解决好下层弹性伸缩场景与底层节点池弹性伸缩之间的配合，正当的布局底层机型升高资源闲置率，是现代化云原生调度零碎必须要解决的问题。Koordinator 的解法和门路 打造下一代容器调度零碎，咱们这么做：
拥抱上游规范，打造基于 QoS 的闭环调度零碎 在学术界，集群资源调度零碎的架构设计是一个老话题了，从集中式到分布式，从两层调度到共享状态架构，从乐观锁到乐观锁。在工业界历史上，每一种架构都或多或少的有过胜利的案例，也正印证了那句话“架构设计没有对错，只有适合不适合”。在 Kubernetes 成为容易编排的事实标准之后，在 Kubernetes 之上仍然衍生出了多种的调度器设计，他们或是善于解决某一垂直畛域的问题，或是采纳了不同的设计实现，在各自的场景中实现了价值。打造现代化的云原生调度零碎，Koordinator 保持了如下的设计思路：1. 拥抱 Kubernetes 上游规范，基于 Scheduler-Framework 来构建调度能力，而不是实现一个全新的调度器。构建规范造成共识是艰难的，但毁坏是容易的，Koordinator 社区与 Kubernetes sig-scheduling 社区相向而行。2. QoS 是零碎的一等公民，与业界大多数调度器更多的关注编排后果（动态）不同，Koordinator 十分关注 Pod 运行时品质（QoS），因为对于调度零碎的用户而言，运行时稳定性是其业务胜利的要害。3. 状态自闭环，Koordinator 认为调度必须是一个残缺的闭环零碎，能力满足企业级利用要求。因而，咱们在第一个版本就引入了状态反馈回路，节点会依据运行时状态调优容器资源，核心会依据节点运行时状态反馈做调度决策。4. 智能化、简单化，Koordinator 并不是就所有的抉择裸露把问题留给客户，而是依据利用特色智能的为用户提供优化配置倡议，简化用户应用 Kubernetes 的老本。建设能力弱小、灵便且可插拔的精细化资源编排优化计划 明天，服务器的 CPU 有 Intel、AMD、多家供应商的 ARM 芯片，AI 场景广泛应用的 GPU、FPGA 等，Kubernetes 作为容器编排基础设施，承载着异构硬件的管理工作，如何在规范 Kubernetes 之上提供异构硬件的调度编排，同时反对用户多样、灵便的策略管制，Koordinator 遵循了如下的设计思路：1. 兼容 Kubernetes，Kubernetes 为用户提供了 static policy cpu manager，Koordinator 的 CPU 拓扑感知能够在用户启用 static policy 时兼容运行，也反对接管用户存量的运行时 Pod，不便用户做技术升级。2. 核心调度 + 单机调度联结决策，核心调度看到全局视角，其决策能够找到集群中最适宜利用需要的节点，而单机调度能够在节点侧做肯定的灵便度，以应答利用突发的流量平稳。3. 调度 + 重调度密切配合，调度解决 Pod 一次性搁置的问题，而重调度才是驱动集群资源编排长期保持最优化的要害。Koordinator 将建设面向 SLO 的重调度能力，继续的驱动利用的编排合乎预约义的 SLO。打造开箱即用的混部和工作负载弹性解决方案 混部是解决 Kubernetes 集群资源利用率的终极武器，这一点在国内外大型企业中都失去了实际论证，但也只是限于这个小圈子之中。近年随着国内外厂商的宣传以及要害信息在学术界论文透出，数字化路上的企业特地是云原生化的企业，对混部都有或多或少的理解。但面对混部，用户的心声是有没有一套开箱即用的解决方案，帮忙用户优化 Kubernetes 集群的资源老本效率。企业接入混部最大的挑战是如何让利用跑在混部平台之上，这第一步的门槛往往是最大的拦路虎。Koordinator 针对这一问题，联合外部生产实践经验，设计了“双零侵入”的混部调度零碎：1. 对 Kubernetes 平台的零侵入。行业内的人大多晓得，将 Kubernetes 利用于企业外部的简单场景混部时，因为这样或者那样的起因总是须要对 Kubernetes 做一定量的批改，这些批改将导致用户应用混部时呈现厂商锁定的危险。而 Koordinator 混部零碎，设计之处即保障了不须要对社区原生 Kubernetes 做任何批改，只须要一键装置 Koordinator 组件到集群中，既能够为 Kubernetes 集群带来混部的能力。2. 对工作负载编排零碎的零侵入。想像一下，在企业外部的 Kubernetes 集群之上提供混部能力之后，将面临的问题是如何将企业的工作负载接入进来，以混部的形式运行。对工作负载治理逻辑的侵入，乐观是须要付出额定的适配老本，乐观时是这些改变是在云厂商提供的组件内（比方 kcm），将面临厂商锁定或者供应商不反对的危险。Koordinator 针对利用接入层的革新老本，设计了独自的工作负载接入层，帮忙用户解决工作负载接入混部的难题，用户只须要治理混部的配置即可灵便的调度编排哪些工作以混部的形式运行在集群中，十分的简略且灵便。构建工作负载数据分析体系，提供智能的优化倡议 调度零碎不止于解决调度、重调度、弹性伸缩等畛域问题，一个残缺的调度零碎，须要具备基于历史数据驱动的自我迭代演进的能力。为工作负载的运行历史状态建设数据仓库，基于这些运行历史的大数据分析，继续的改良利用间在各个维度的的亲和、互斥关系，能力在用户运行时体验、集群资源利用效率同时达到最佳状态。Koordinator 针对智能化调度的设计思路如下：1. 智能资源超卖，Koordinator 首先解决的是节点资源充分利用的问题，通过剖析节点容器的运行状态计算可超卖的资源量，并联合 QoS 的差异化诉求将超卖的资源分配给不同类型的工作，大幅提高集群的资源利用率。
2. QoS 感知的重调度，当节点中 Pod 的运行时 QoS 不合乎预期时，Koordinator 将智能决策克制更低优先级的工作亦或是迁徙以后收到烦扰的容器，从而解决利用 QoS 不满足导致的问题。3. 更多的能力敬请期待，将来这里将是 Koordinator 重点迭代的畛域。围绕着这条路，在 0.6 版本中，社区带来了下述更新。版本性能个性解读 Koordinator 近期公布了 v0.6 版本，蕴含了以下加强、新增个性：1. 新版本进一步欠缺了 CPU 精细化编排能力，更好的兼容原生用法。2. 在 Kubernetes 之上引入资源预留的原子能力（Reservation），资源预留在容量治理、碎片优化、调度成功率优化等方面有重要作用。3. 提供了 Pod 腾挪的能力（PodMigrationJob），能够帮忙用户牢靠地迁徙有问题实例、整顿集群资源碎片等。4. 公布了全新的 Descheduler Framework，反对用户灵便的扩大自定义插件，联合 PodMigrationJob 实现平安、牢靠、灵便的重调度。5. 此外，该版本蕴含了 GPU、Gang、Elastic Quota 相干的设计。更加欠缺的 CPU 精细化编排 – Fine-grained CPU Orchestration 随着资源利用率的晋升进入到混部的深水区，须要对资源运行时的性能做更深刻的调优，更精密的资源编排能够更好的保障运行时品质，从而通过混部将利用率推向更高的程度。咱们把 Koordinator QoS 在线利用 LS 类型做了更粗疏的划分，分为 LSE、LSR 和 LS 三种类型。拆分后的 QoS 类型具备更高的隔离性和运行时品质，通过这样的拆分，整个 Koordinator QoS 语义更加准确和残缺，并且兼容 K8s 已有的 QoS 语义。并且咱们针对 Koordinator QoS，设计了一套丰盛灵便的 CPU 编排策略，如下表所示：
大家能够联合下图，能够更容易了解这一套 QoS 和编排策略：
在之前的《云原生混部零碎 Koordinator 架构详解》中，咱们向大家介绍过过后正在实现 CPU 精细化编排计划 [2] 设计，并在 Koordinator v0.5 版本中，实现了根本的 CPU 精细化编排能力，用户能够在 Pod 中新增 Koordinator CPU 精细化编排协定，指定冀望的 CPU 编排策略领导 koord-scheduler 在调度时抉择最适宜的节点。koord-scheduler 在调配时优先思考 NUMA 架构，使得调配的 CPU 尽可能不跨 NUMA Node/Socket，并且为了尽可能防止 NUMA Node/Socket 维度产生碎片，默认应用 MostAllocated 策略抉择残余 CPU 少的 NUMA Node。在 Koordinator v0.6 中，进一步欠缺了 CPU 精细化编排能力，更好的反对了提早敏感型利用对于烦扰隔离的需要以及更好的兼容原生用法：1. 当 Koordinator QoS 为 LSE/LSR 类型的 Pod 没有设置 CPU 精细化编排协定时，koord-scheduler 应用配置的默认 CPU 编排策略调配 CPU。2. 新增反对 PCPULevel 或者 NUMANodeLevel 两种 CPU 互斥策略 (CPU Exclusive Policy)。koord-scheduler 会依据用户的配置，尽量的保障具备雷同互斥策略的 Pod 在物理核维度(PCPULevel) 或者 NUMA Node 维度 (NUMANodeLevel) 互斥。该机制能够无效的防止 CPU 密集型利用的互相烦扰。3. 反对 Node CPU Orchestration API，集群管理员或者集群资源经营能够通过该 API 束缚节点的 CPU 编排策略。反对通过标签 node.koordinator.sh/cpu-bind-policy 束缚调度时的 CPU 绑定逻辑。以后反对的策略 FullPCPUsOnly 示意要求 koord-scheduler 在调配 CPU 时，调配的 CPU 数量必须调配在雷同的一批物理核上，并且在 SMT 架构下(例如常见的 x86 架构) 要求 Pod 的 CPU 申请数量必须是单个物理核内虚构逻辑核的倍数。FullPCPUsOnly 与 Kubernetes 反对的 kubelet CPU Manager Policy Option full-pcpus-only=true 等价。反对通过标签 node.koordinator.sh/numa-allocate-strategy 指定 NUMA Node 维度的调配抉择策略，如果设置 MostAllocated，冀望 koord-scheduler 优先从残余 CPU 起码的 NUMA Node 上调配；如果设置 LeastAllocated，冀望 koord-scheduler 优先从残余 CPU 最多的 NUMA Node 上调配。默认应用 MostAllocated 策略。该配置还会作用在后续将要反对的 NUMA Topology 调度能力。4. 单机侧 koordlet 加强了对 LSE QoS 的反对，例如 koordlet 启用 CPU Suppress 机制时，在为 BE Pod 调配 CPU 时会排除掉 LSE Pod 绑定的 CPU，实现 LSE QoS 的强保障。资源预留 – Reservation 在 Koordinator v0.6 中，咱们基于原有 v0.5 版本实现的资源预留 API 设计方案[3]，在不侵入 Kubernetes 已有的机制和代码前提下，实现了资源预留的原子能力(Reservation)。资源预留在容量治理、碎片优化、调度成功率和重调度等场景有重要作用：1. 当有重要的工作负载在将来某段时间须要资源时，能够提前预留资源满足需要。2. 用户在 PaaS 上发动扩容时，能够通过资源预留能力尝试预留，预留胜利后发动扩容，保障 PaaS 的 SLA。3. 用户在 PaaS 上公布时，如果利用采纳了滚动公布的能力，能够通过资源预留保留行将销毁的 Pod 持有的资源，在滚动公布时，新建的 Pod 能够复用预留下来的原有资源，可能无效进步滚动公布的成功率。4. 碎片优化场景中，能够通过资源预留占住闲暇的碎片资源，并把可被整顿的 Pod 迁徙到这些节点。5. 重调度时在发动驱赶前，先尝试预留资源，预留胜利后发动驱赶，防止驱赶后无资源可用影响利用的可用性。
Koordinator Reservation API 容许用户不批改 Pod Spec 或者存量的 Workload(例如 Deployment, StatefulSet）即能够预留资源。根本流程如下：1. 当用户冀望预留资源时，能够创立一个 Reservation CRD 实例，通过 ReservationSpec.Template 申明将来新建的 Pod Spec，并申明预留资源的所有权，即填写 ReservationSpec.Owners 字段。2. koord-scheduler watch 到新建的 Reservation 后，会依据 ReservationSpec 中的信息模仿为一个 Pod(称为 ReservePod) 进行调度找到适合的节点，并把调度的后果更新回 ReservationStatus。3. 用户创立新的 Pod，koord-scheduler 优先为该 Pod 寻找适合的 Reservation 实例，koord-scheduler 会依据 Reservation 中记录的资源所有权，通过 label selector 机制或者判断 controller ownerReference 的模式判断新 Pod 是否与 Reservation 匹配，如果匹配，则会进行预处理，保障后续的 Reservation 资源定向给该 Pod 应用。并在打分阶段影响调度逻辑，优先实现 Reservation 对象占用的资源。4. Pod bind 时更新 ReservationStatus，记录该 Reservation 被哪些 Pod 生产了。5. 当 Pod 销毁时，koord-scheduler 会更新 ReservationStatus 删除 Pod 生产记录，该 Reservation 会被持续应用直到超过设定的过期工夫（BTW: 默认 24 小时过期，如果 TTL 设置为 0，示意不过期）。Quick Start 1. 应用上面的 YAML 文件创建 Reservation reservation-demo apiVersion: scheduling.koordinator.sh/v1alpha1
kind: Reservation
metadata:
name: reservation-demo
spec:
template: # set resource requirements
namespace: default
spec:
containers:
- args:
- '-c'
- '1'
command:
- stress
image: polinux/stress
imagePullPolicy: Always
name: stress
resources: # reserve 500m cpu and 800Mi memory
requests:
cpu: 500m
memory: 800Mi
schedulerName: koord-scheduler # use koord-schedulerowners: # set the owner specifications
- object: # owner pods whose name is `default/pod-demo-0`
name: pod-demo-0
namespace: defaultttl: 1h # set the TTL, the reservation will get expired 1 hour later 2. 察看并期待 Reservation reservation-demo 变为 Available 状态 $ kubectl create -f reservation-demo.yaml
reservation.scheduling.koordinator.sh/reservation-demo created
$ kubectl get reservation
NAME PHASE AGE
reservation-demo Available 3h16m 3. 应用上面的文件创建 Pod pod-demo-0 apiVersion: v1
kind: Pod
metadata:
name: pod-demo-0 # match the owner spec of reservation-demo
spec:
containers:
- args:
- '-c'
- '1'
command:
- stress
image: polinux/stress
imagePullPolicy: Always
name: stress
resources:
limits:
cpu: '1'
memory: 1Gi
requests:
cpu: 200m
memory: 400MirestartPolicy: Always
schedulerName: koord-scheduler # use koord-scheduler $ kubectl create -f pod-demo-0.yaml
pod/pod-demo-0 created 4. 查看 Pod pod-demo-0 的调度后果 $ kubectl get pod pod-demo-0 -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
pod-demo-0 1/1 Running 0 32s 10.17.0.123 node-0 <none> <none> pod-demo-0 被调度到 与 Reservation reservation-demo 雷同的节点。5. 查看 Reservation reservation-demo 的状态. $ kubectl get reservation reservation-demo -oyaml
apiVersion: scheduling.koordinator.sh/v1alpha1
kind: Reservation
metadata:
name: reservation-demo
creationTimestamp: “YYYY-MM-DDT05:24:58Z”
uid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
…
spec:
owners:
-
object:
name: pod-demo-0
namespace: default
template:
spec:
containers:-
args:
- -c
- “1”
command: - stress
image: polinux/stress
imagePullPolicy: Always
name: stress
resources:
requests:
cpu: 500m
memory: 800Mi
schedulerName: koord-scheduler
ttl: 1h
-
status:
allocatable: # total reserved
cpu: 500m
memory: 800Miallocated: # current allocated
cpu: 200m
memory: 400Miconditions:
- lastProbeTime: “YYYY-MM-DDT05:24:58Z”
lastTransitionTime: “YYYY-MM-DDT05:24:58Z”
reason: Scheduled
status: “True”
type: Scheduled - lastProbeTime: “YYYY-MM-DDT05:24:58Z”
lastTransitionTime: “YYYY-MM-DDT05:24:58Z”
reason: Available
status: “True”
type: Ready
currentOwners: - name: pod-demo-0
namespace: default
uid: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy
nodeName: node-0
phase: Available 咱们能够察看到 Reservation reservation-demo 预留了 500m CPU 和 800 Mi 内存，并且 Pod pod-demo- 0 从 Reservation reservation-demo 中调配了 200m CPU 和 400Mi 内存。6. 清理 Reservation reservation-demo. $ kubectl delete reservation reservation-demo
reservation.scheduling.koordinator.sh “reservation-demo” deleted
$ kubectl get pod pod-demo-0
NAME READY STATUS RESTARTS AGE
pod-demo-0 1/1 Running 0 110s 能够察看到 Reservation 删除后，Pod pod-demo-0 还在运行中。安全可靠的 Pod 腾挪迁徙机制 – PodMigrationJob 腾挪迁徙 Pod 是许多组件（例如 descheduler）所依赖的重要性能，可用于优化调度或帮忙解决工作负载运行时品质问题。咱们认为 Pod 迁徙是一个简单的过程，波及到审计、资源分配、利用启动等步骤，还夹杂着利用的公布降级、扩容 / 缩容场景和集群管理员的资源运维操作。因而，如何治理 Pod 迁徙过程的稳定性危险，保障利用不会因为 Pod 的迁徙影响可用性，是一个十分要害的必须解决的问题。为了让大家更好的了解，举几个场景：1. 社区的重调度器内置的多个重调度策略依据本身逻辑判断某个 Pod 是否要被迁徙，须要迁徙时调用 K8s Eviction API 发动驱赶。然而这个过程并不关注被驱赶的 Pod 在未来是否能够调配到资源。因而存在大量 Pod 被驱赶后因为没有资源而处于 Pending 状态的状况。如果利用此时有大量申请进来，又因为没有足够的可用的 Pod 导致可用性异样。2. 另外，社区重调度器调用的 K8s Evcition API 尽管会查看 PDB 确保在平安范畴内驱赶，然而家喻户晓，泛滥的 workload Controller 在公布和缩容场景都是通过间接调用 Delete API 的模式销毁 Pod，此时并不会被 PDB 限度。这就导致重调度时如果遇到上述场景，是很可能引发重大的稳定性问题。3. 咱们认为 Pod 腾挪不是一个简略的后盾自动化逻辑，有相当多的场景和用户冀望由人工染指手工迁徙 Pod，甚至冀望重调度时发动的主动迁徙申请应该被拦挡掉，通过审批决定是否执行。Koordinator 基于 CRD 定义了一个名为 PodMigrationJob API[4]。重调度器或者其余自动化自愈组件通过 PodMigrationJob 能够平安的迁徙 Pod。PodMigrationJob Controller 在解决 PodMigrationJob 时会先尝试通过 Koordinator Reservation 机制预留资源，预留失败则迁徙失败；资源预留胜利后发动驱赶操作并期待预留的资源被生产。两头的过程都会记录到 PodMigrationJobStatus 中，并产生相干的 Event。Quick Start PodMigrationJob 应用起来也非常简略：1. 应用如下 YAML 文件创建一个 PodMigrationJob migrationjob-demo，迁徙 Pod pod-demo-5f9b977566-c7lvk apiVersion: scheduling.koordinator.sh/v1alpha1
kind: PodMigrationJob
metadata:
name: migrationjob-demo
spec:
paused: false
ttl: 5m
mode: ReservationFirst
podRef:
namespace: default
name: pod-demo-5f9b977566-c7lvkstatus:
phase: Pending $ kubectl create -f migrationjob-demo.yaml
podmigrationjob.scheduling.koordinator.sh/migrationjob-demo created 2. 查问 PodMigrationJob 的迁徙状态 $ kubectl get podmigrationjob migrationjob-demo
NAME PHASE STATUS AGE NODE RESERVATION PODNAMESPACE POD NEWPOD TTL
migrationjob-demo Succeed Complete 37s node-1 d56659ab-ba16-47a2-821d-22d6ba49258e default pod-demo-5f9b977566-c7lvk pod-demo-5f9b977566-nxjdf 5m0s
$ kubectl describe podmigrationjob migrationjob-demo
…
Events:
Type Reason Age From Message
—- —— —- —- ——-
Normal ReservationCreated 8m33s koord-descheduler Successfully create Reservation “d56659ab-ba16-47a2-821d-22d6ba49258e”
Normal ReservationScheduled 8m33s koord-descheduler Assigned Reservation “d56659ab-ba16-47a2-821d-22d6ba49258e” to node “node-1”
Normal Evicting 8m33s koord-descheduler Try to evict Pod “default/pod-demo-5f9b977566-c7lvk”
Normal EvictComplete 8m koord-descheduler Pod “default/pod-demo-5f9b977566-c7lvk” has been evicted
Normal Complete 8m koord-descheduler Bind Pod “default/pod-demo-5f9b977566-nxjdf” in Reservation “d56659ab-ba16-47a2-821d-22d6ba49258e” 能够察看到，PodMigrationJob Controller 把 Pod pod-demo-5f9b977566-c7lvk 迁徙到了 node-1，新 Pod 为 pod-demo-5f9b977566-nxjdf. 仲裁机制以后版本还暂未实现设计方案中定义的仲裁机制，该机制将会在 v0.7 版本中实现。仲裁机制是指 PodMigrationJob Controller 在 reconcile 前会抉择最合适的一批 PodMigrationJob 执行。该过程波及到 Group、Filter 和 Sort 三个阶段。1. Group 阶段：会依照 Workload, Namespace 和 Node 三个维度聚合。2. Filter 阶段：过滤掉危险的 PodMigrationJob。判断 Workload 对应的 PDB 或者 OpenKruise PUB，如果不合乎定义的平安阈值，则会过滤掉判断指标 Pod 关联的 Workload 有多少正在执行的 PodMigrationJob，如果达到了配置的最大数量，则会过滤掉。判断 Namespace 维度下正在迁徙的 Pod 数量，超过阈值则过滤掉判断 Node 维度下正在迁徙的 Pod 数量，超过阈值则过滤掉 3. Sort 阶段：对 PodMigrationJob 排序和打散。尽量抉择迁徙代价低的 Pod。用户能够依据理论状况，在 Pod 上追加标签 scheduling.koordinator.sh/eviction-cost 标记迁徙代价。让每个 Workload、Namespace、Node 尽可能少的驱赶 Pod 全新的重调度框架 – Descheduler Framework 咱们在 Koordinator v0.6 版本中实现了一个全新的重调度器框架 5。K8s 社区 descheduler 在过来提供了一些策略解决一些罕用的调度编排异样问题。但咱们认为社区的 descheduler 还有很多方面能够晋升：1. K8s 社区 descheduler 只反对定时执行的机制，不反对基于 Event 触发的工作模式，无奈满足一些冀望联动其余组件触发的事件或者冀望依据 Pod/Node 事件实现更踊跃的重调度等场景。2. 另外社区 descheduler 不能很好的扩大实现自定义重调度策略，每次须要实现一个自定义重调度策略时都须要把社区上游的代码拷贝到本地进行批改，而后本人保护起来，当后续社区有变动时，须要破费较大的代价进行合并。这点与 kube-scheduler 比照来看，kube-scheduler 基于 scheduling framework，反对用户无需批改上游代码既能够扩大调度能力。3. 不反对自定义驱赶逻辑。例如当须要实现下面提到的 PodMigrationJob 时，只能 fork 代码后批改适配。咱们认为重调度场景：1. 须要一个插件化机制实现自定义的重调度策略，但又不心愿这个形象过于简单；2. 须要具备根本的插件治理能力，通过配置启用和禁用插件；3. 具备对立的插件配置下发机制，不便插件自定义参数；4. 并可能不便的扩大和应用对立的 Evictor 机制；5. 另外冀望用户可能基于 controller-runtime 实现 controller 并纳入对立的插件管理机制。咱们在进行 descheduler framework 的设计时，也留神到 K8s descheduler 社区其实也留神到了这些问题，冀望实现一个相似于 K8s scheduling framework 一样的框架 (descheduler framework)，并且也提出了一些针对性的提案摸索相干的实现，例如 #753 Descheduler framework Proposal[6] 和 PoC #781[7]。这个想法与 Koordinator 团队不约而同。纵观 K8s descheduler 社区的提案，基本上解决了咱们关怀的很多问题，例如插件配置、插件形象等，然而咱们也留神到有很多相干实现还在 PoC 阶段或者局部相干实现还未合入到骨干分支。通过 Koordinator 团队的 Review 和探讨，咱们认为尽管这些提案中还有一些未解决的问题和未齐全敲定的设计，但咱们置信这是一个正确的方向。同时基于 Koordinator 制订的的里程碑，咱们冀望尽快建设重调度相干的个性，因而咱们基于上游社区 #753 PR[8]的思路，在 Koordinator 中独立实现了一套新的 descheduler framework。咱们冀望通过这样独立实现的形式解决 Koordinator 对重调度能力的需要，同时也冀望借此推动上游社区 descheduler framework 工作的演进，当上游有新的停顿时，咱们将会及时跟进，尽最大可能与上游放弃兼容。Koordinator descheduler framework 提供了插件配置管理（例如启用、禁用，对立配置等）、插件初始化、插件执行周期治理等机制。并且该框架内置了基于 PodMigrationJob 实现的 Controller，并作为 Evictor Plugin 不便被各种重调度插件应用，帮忙重调度插件平安的迁徙 Pod。基于 Koordinator descheduler framework，用户能够非常容易的扩大实现自定义重调度策略，就像基于 K8s scheduling framework 的实现自定义的调度插件一样简略。并且用户也能够以插件的模式实现 controller，反对基于 Event 触发重调度的场景。以后，咱们曾经实现了 descheduler framework 主体局部，整体都是可用的。并且提供了一个示例插件 [9] 不便大家了解和开发。在后续的版本中，咱们将会迁徙社区已有的重调度策略，以插件的模式集成到 Koordinator，作为内置能力的一部分。并且还会针对混部场景，实现针对性的重调度插件解决混部场景下的具体问题，例如负载平衡重调度，解决节点间负载不平衡、热点等问题。目前框架还处于疾速演进的初期阶段，还有很多细节须要欠缺。欢送大家有趣味一起参加建设。咱们心愿更多的人能够更释怀、更简略地实现本人须要的去调度能力。其余变更 对于大家关怀的 GPU Share Scheduling, Gang Scheduling 和 Elastic Quota Scheduling 等能力也有一些新的停顿。在 v0.6 版本中，Koordiantor 社区实现了 GPU Share Scheduling 和 Gang Scheduling 的方案设计工作，相干的 Proposal 曾经 Review 通过。Elastic Quota Scheduling 的方案设计也根本实现。这些能力将会在 v0.7 版本中实现。另外，为了摸索 GPU 超卖和 GPU 诊断剖析等场景，在 v0.6 版本中减少了 GPU Metric 上报机制。你能够通过 Github release[10]页面，来查看更多的改变以及它们的作者与提交记录。社区参加 十分欢送你通过 Github/Slack/ 钉钉 / 微信 等形式退出咱们来参加 Koordinator 开源社区。你是否曾经有一些心愿与咱们社区交换的内容呢？能够通过以下渠道参加探讨：退出社区 Slack channel11 退出社区钉钉群：搜寻群号 33383887 (Chinese) 或者扫描下方二维码
相干链接 [1] 版本 0.5：https://github.com/koordinato… [2] CPU 精细化编排计划：https://koordinator.sh/docs/u… [3] 资源预留 API 设计方案 https://koordinator.sh/docs/d… [4] PodMigrationJob API：https://koordinator.sh/docs/d… [5] 重调度器框架：https://koordinator.sh/docs/d… [6] #753 Descheduler framework Proposal：https://github.com/kubernetes… [7] PoC #781：https://github.com/kubernetes… [8] #753 PR：https://github.com/kubernetes… [9] 示例插件：https://github.com/koordinato… [10] Github release：https://github.com/koordinato… [11] Slack channel：https://koordinator-sh.slack…. 原文链接：https://click.aliyun.com/m/10… 本文为阿里云原创内容，未经容许不得转载。
