深入理解 Koordinator 调度框架
复制
AI
智能创作
通用
图片
表格
分栏
附件
代码块
公式
超链接
提及
统计 (原阅读统计)
高亮信息
流程图
思维导图
在此处拆分卡片
布局
布局块
默认分栏
模块分栏
编号分栏
时间线分栏
箭头分栏
文本格式
正文
一级标题
二级标题
三级标题
四级标题
五级标题
六级标题
无序列表
有序列表
待办列表
引用
分割线
数据表
表格视图
相册视图
看板视图
甘特视图
日历视图
架构视图
图表
柱状图
条形图
饼状图
折线图
散点图
功能卡片（插入后会切换到卡片视图）
目录卡片
子文档列表卡
第三方应用
DuChatBeta
百度地图
CodePen
Figma
概念
Koordinator 是一个现代的调度系统，可以将微服务、AI、大数据的工作负载托管在Kubernetes上。
通过弹性资源配额、高效的 Pod 装箱、资源超售、资源共享与容器资源隔离相结合，实现了高利用率。
Koordinator 是具有高性能、可扩展的， ***在大规模生产环境中得到了验证的，***可以构建支持企业生产环境的容器编排系统。
关键特性
Koordinator 通过提供以下功能增强了在 Kubernetes 中管理工作负载的用户体验：
-
精心设计的优先级和 QoS 机制，可将不同类型的工作负载混跑在集群中，并在单个节点上运行不同类型的 Pod 。
-
允许资源超卖以实现高资源利用率，但仍通过利用应用程序分析机制来满足 QoS 保证。
-
细粒度的资源协调和隔离机制，以提高延迟敏感的工作负载和批处理作业的效率。
-
灵活的作业调度机制，支持特定领域的工作负载，例如大数据、人工智能、音频和视频。
-
一整套用于监控、故障排除和操作的工具。
QoS：
Kubernetes 提供三种类型的 QoS： Guaranteed/Burstable/BestEffort，其中 Guaranteed/Burstable 被广泛使用 BestEffort 很少使用。
Koordinator 与 Kubernetes QoS 兼容，为了避免干扰原生 QoS 语义，Koordinator 引入了一个独立的字段 koordinator.sh/qosClass 来描述混部 QoS。该 QoS 描述了在混部场景中节点上运行的 Pod 的服务质量。它是混合系统最关键的语义。
**Koordinator 调度器：**Koordinator 调度器是基于 schedule-framework 开发的，在原生调度能力之上增加了与混部和优先级抢占相关的调度插件。
整体架构
Koordinator 相关的架构、组件和核心概念如上所示。Koordinator 由两个控制面（Koordinator Scheduler/Koordinator Manager）和一个 DaemonSet 组件(Koordlet)组成。Koordinator 在 Kubernetes 原有的能力基础上增加了混部功能，并兼容了 Kubernetes 原有的工作负载。
-
Koordinator系统架构概述
-
Koordinator系统包括中心管控和单机资源管理两个维度。
-
图中绿色部分表示K8s原生系统组件，蓝色部分是Koordinator的扩展实现。
-
Koordinator在调度器内部和外部增强了扩展能力。
-
单机侧提供了Koordlet和Koord Runtime Proxy组件，实现资源的精细化管理和QoS保障。
Koord-Scheduler
Koord-Scheduler 以 Deployment 的形式部署在集群中，用于增强 Kubernetes 在 QoS-aware，差异化 SLO 以及任务调度场景的资源调度能力，具体包括:
-
QoS-aware 调度，包括负载感知调度让节点间负载更佳平衡，资源超卖的方式支持运行更多的低优先级工作负载。
-
差异化 SLO，包括 CPU 精细化编排，为不同的工作负载提供不同的 QoS 隔离策略（cfs，LLC，memory 带宽，网络带宽，磁盘io）。
-
任务调度，包括弹性额度管理，Gang 调度，异构资源调度等，以支持更好的运行大数据和 AI 工作负载。
为了更好的支持不同类型的工作负载，Koord-scheduler 还包括了一些通用性的能力：
-
Reservation，支持为特定的 Pod 或者工作负载预留节点资源。资源预留特性广泛应用于重调度，资源抢占以及节点碎片整理等相关优化过程。
-
Node Reservation，支持为 kubernetes 之外的工作负载预留节点资源，一般应用于节点上运行着非容器化的负载场景。
Koord-Descheduler
Koord-Decheduler 以 Deployment 的形式部署在集群中，它是 kubernetes 上游社区的增强版本，当前包含:
-
重调度框架，Koord-Decheduler 重新设计了全新重调度框架，在可扩展性、资源确定性以及安全性上增加了诸多的特性。
-
负载感知重调度，基于新框架实现的一个负载感知重调度插件，支持用户配置节点的安全水位，以驱动重调度器持续优化集群编排，从而规避集群中出现局部节点热点。
Koord-Manager
Koord-Manager 以 Deployment 的形式部署，通常由两个实例组成，一个 leader 实例和一个 backup 实例。Koordinator Manager 由几个控制器和 webhooks 组成，用于协调混部场景下的工作负载，资源超卖(resource overcommitment)和 SLO 管理。
目前，提供了三个组件:
-
Colocation Profile，用于支持混部而不需要修改工作负载。用户只需要在集群中做少量的配置，原来的工作负载就可以在混部模式下运行，了解更多关于Colocation Profile。
-
SLO 控制器，用于资源超卖(resource overcommitment)管理，根据节点混部时的运行状态，动态调整集群的超发(overcommit)配置比例。该控制器的核心职责是管理混部时的 SLO，如智能识别出集群中的异常节点并降低其权重，动态调整混部时的水位和压力策略，从而保证集群中 pod 的稳定性和吞吐量。
-
Recommender，它使用 histograms 来统计和预测工作负载的资源使用细节，用来预估工作负载的峰值资源需求，从而支持更好地分散热点，提高混部的效率。此外，资源 profiling 还将用于简化用户资源规范化配置的复杂性，如支持 VPA。
Koordlet
Koordlet 以 DaemonSet 的形式部署在 Kubernetes 集群中，用于支持混部场景下的资源超卖(resource overcommitment)、干扰检测、QoS 保证等。
在Koordlet内部，它主要包括以下模块:
-
资源 Profiling，估算 Pod 资源的实际使用情况，回收已分配但未使用的资源，用于低优先级 Pod 的 overcommit。
-
资源隔离，为不同类型的 Pod 设置资源隔离参数，避免低优先级的 Pod 影响高优先级 Pod 的稳定性和性能。
-
干扰检测，对于运行中的 Pod，动态检测资源争夺，包括 CPU 调度、内存分配延迟、网络、磁盘 IO 延迟等。
-
QoS 管理器，根据资源剖析、干扰检测结果和 SLO 配置，动态调整混部节点的水位，抑制影响服务质量的 Pod。
-
资源调优，针对混部场景进行容器资源调优，优化容器的 CPU Throttle、OOM 等，提高服务运行质量。
Koord-RuntimeProxy
Koord-RuntimeProxy 以 systemd service 的形式部署在 Kubernetes 集群的节点上，用于代理 Kubelet 与 containerd/docker 之间的 CRI 请求。这一个代理被设计来支持精细化的资源管理策略，比如为不同 QoS Pod 设置不同的 cgroup 参数，包括内核 cfs quota，resctl 等等技术特性，以改进 Pod 的运行时质量。
资源模型
混部是一套资源调度解决方案，用于对延迟敏感的工作负载与大数据计算工作负载进行精细化编排。它需要解决两个主要问题:
-
如何为延迟敏感的工作负载调度资源，以满足性能和长尾延迟的要求。这里涉及到的关键点是资源调度策略和 QoS 感知策略。
-
如何调度和编排大数据计算工作负载，以较低的成本满足任务对计算资源的需求。这里涉及到的关键是如何在极端异常情况下实现合理的资源超额配置和 QoS 保障。
上图是 Koordinator 的混部资源模型，其基本思想是利用那些已分配但未使用的资源来运行低优先级的 pod。如图所示，有四条线:
-
limit：灰色，高优先级 Pod 所请求的资源量，对应于 Kubernetes 的 Pod 请求。
-
usage：红色，Pod 实际使用的资源量，横轴为时间线，红线为 Pod 负载随时间变化的波动曲线。
-
short-term reservation：深蓝色，这是基于过去（较短）时期内的资源使用量，对未来一段时间内其资源使用量的估计。预留和限制的区别在于，分配的未使用（未来不会使用的资源）可以用来运行短期执行的批处理 Pod。
-
long-term reservation：浅蓝色，与 short-term reservation 类似，但估计的历史使用期更长，从保留到限制的资源可以用于生命周期较长的Pod，与短期的预测值相比，可用的资源较少，但更稳定。
优先级
Koordinator 在 Kubernetes 优先级类型的基础上定义了一套规范，并扩展了优先级的一个维度以对混部场景的细粒度支持。
Koordinator 将不同类型的工作负载匹配到不同的优先级:
-
koord-prod，运行典型的延迟敏感型服务，一般是指需要 "实时 "响应的服务类型，比如通过点击移动APP中的按钮调用的典型服务。
-
koord-mid，对应于长周期的可用资源，一般用于运行一些实时计算、人工智能训练任务/作业，如 tensorflow/pytorch 等。
-
koord-batch，对应于的短周期可用资源，运行典型的离线批处理作业，一般指离线分析类作业，如日级大数据报告、非交互式 SQL 查询。
-
koord-free，运行低优先级的离线批处理作业，一般指不做资源预算，利用闲置资源尽量完成，如开发人员为测试目提交的作业。
QoS
QoS 用于表达节点上 Pod 的运行质量，如获取资源的方式、获取资源的比例、QoS 保障策略等。Koordinator 调度系统支持的 QoS 有五种类型:
| QoS | 特点 | 说明 |
|---|---|---|
| SYSTEM | 系统进程，资源受限 | 对于 DaemonSets 等系统服务，虽然需要保证系统服务的延迟，但也需要限制节点上这些系统服务容器的资源使用，以确保其不占用过多的资源 |
| LSE(Latency Sensitive Exclusive) | 保留资源并组织同 QoS 的 pod 共享资源 | 很少使用，常见于中间件类应用，一般在独立的资源池中使用 |
| LSR(Latency Sensitive Reserved) | 预留资源以获得更好的确定性 | 类似于社区的 Guaranteed，CPU 核被绑定 |
| LS(Latency Sensitive) | 共享资源，对突发流量有更好的弹性 | 微服务工作负载的典型QoS级别，实现更好的资源弹性和更灵活的资源调整能力 |
| BE(Best Effort) | 共享不包括 LSE 的资源，资源运行质量有限，甚至在极端情况下被杀死 | 批量作业的典型 QoS 水平，在一定时期内稳定的计算吞吐量，低成本资源 |
Koordlet 根据 Pod 的优先级和 QoS 定义，触发相应的资源隔离和 QoS 保障，Koordinator 和 Kubernetes QoS 之间是有对应关系，如下所示：
| Koordinator QoS | Kubernetes QoS |
|---|---|
| SYSTEM | --- |
| LSE | Guaranteed |
| LSR | Guaranteed |
| LS | Guaranteed/Burstable |
| BE | BestEffort |
核心算法
核心算法可参见
评论区