Koordinator架构
下图展示了 Koordinator 系统的整体架构和各组件的角色分工，其中绿色部分描述了 K8s 原生系统的各个组件，蓝色部分是 Koordinator 在此基础上的扩展实现。从整个系统架构来看，我们可以将 Koordinator 分为中心管控和单机资源管理两个维度。在中心侧，Koordiantor 在调度器内部和外部分别都做了相应的扩展能力增强；在单机侧，Koordinator 提供了 Koordlet 和 Koord Runtime Proxy 两个组件，负责单机资源的精细化管理和 QoS 保障能力。
- Koordinator 各组件的详细功能如下
- Koord-Manager
- SLO-Controller：提供资源超卖、混部 SLO 管理、精细化调度增强等核心管控能力。
- Recommender：围绕资源画像为应用提供相关的弹性能力。
- Colocation Profile Webhook：简化 Koordinator 混部模型的使用，为应用提供一键接入的能力，自动注入相关优先级、QoS 配置。
- Koord extensions for Scheduler：面向混部场景的调度能力增强。
- Koord descheduler：提供灵活可扩展的重调度机制。
- Koord Runtime Proxy：作为 Kubelet 和 Runtime 之间的代理，满足不同场景的资源管理需求，提供插件化的注册框架，提供相关资源参数的注入机制。
- Koordlet：在单机侧负责 Pod 的 QoS 保障，提供细粒度的容器指标采集，以及干扰检测和调节策略能力，并支持一系列的 Runtime Proxy 插件，用于精细化的隔离参数注入。
在 Koordinator 的设计模型中，一个核心的设计概念就是优先级（Priority），Koordinator 定义了四个等级，分别是 Product、Mid、Batch、Free ，Pod 需要指定申请的资源优先级，调度器会基于各资源优先级总量和分配量做调度。各优先级的资源总量会受高优先级资源的 request 和 usage 影响，例如已申请但未使用的 Product 资源会以 Batch 优先级再次分配。节点各资源优先级的具体容量，Koordinator 会以标准的 extend-resource 形式更新在 Node 信息中。
下图展示了一个节点各资源优先级的容量情况，其中黑色的直线 total 代表了节点的物理资源总量，红色折线代表了高优先级 Product 的真实使用量，蓝色折线到黑色直线之间反映了 Batch 优先级的资源超卖变化情况，可以看到当 Product 优先级处于资源消耗的低谷时，Batch 优先级可以获得更多的超卖资源。事实上，资源优先级策略的激进或保守，决定了集群资源的超卖容量，这点我们也可以从图中绿色直线对应的 Mid 资源优先级超卖情况分析看出。
如下表所示，Koordinator 以 K8s 标准的 PriorityClass 形式对各资源优先级进行了定义，代表 Pod 申请资源的优先级。在多优先级资源超卖情况下，当单机资源紧张时，低优先级 Pod 会被压制或驱逐。此外，Koordinator 还提供了 Pod 级别的子优先级（sub-priority），用于调度器层面的精细化控制（排队，抢占等）。
Koordinator 的设计中另一个核心的概念是服务质量（Quality of Service），Koordinator 将 QoS 模型在 Pod Annotation 级别进行了扩展定义，它代表了 Pod 在单机运行过程中的资源质量，主要表现为使用的隔离参数不同，当单机资源紧张时会优先满足高等级 QoS 的需求。如下表所示，Koordinator 将 QoS 整体分为 System（系统级服务），Latency Sensitive（延迟敏感性的在线服务），Best Effort（资源消耗型的离线应用）三类，根据应用性能敏感程度的差异，Latency Sensitive 又细分为 LSE，LSR 和 LS。
各场景的实际使用举例如下。
- 典型场景：
- Prod + LS：典型的在线应用，通常对应用时延要求较高，对资源质量要求较高，也需要保证一定的资源弹性能力。
- Batch + BE：用于混部场景中的低优离线，对资源质量有相当的忍耐度，例如批处理类型的 Spark/MR 任务，以及 AI 类型的训练任务
- 典型场景的增强：
- Prod + LSR/LSE：比较敏感的在线应用，可以接受牺牲资源弹性而换取更好的确定性（如CPU绑核），对应用时延要求极高。
- Mid/Free + BE：与“Batch + BE”相比主要区别是对资源质量要求的高低不同。
- 非典型的应用场景：
- Mid/Batch/Free + LS：用于低优先级的在线服务、近线计算以及AI推理类等任务，这些任务相较于大数据类型任务，它们无法接受过低的资源质量，对其他应用的干扰也相对较低；而相较于典型的在线服务，它们又可以忍受相对较低的资源质量，例如接受一定程度的驱逐。
样例
Koordinator 支持多种工作负载的灵活接入混部，这里我们以 Spark 为例，介绍如何使用混部超卖资源。在 K8s 集群中运行 Spark 任务有两种模式：一种是通过 Spark Submit 提交，也就是在本地使用 Spark 客户端直接连接 K8s 集群，这种方式比较简单快捷，不过在整体的管理能力上有所缺乏，常用于开发自测；另一种方式是通过 Spark Operator 提交，如下图所示，它定义了 SparkApplication CRD，用于 Spark 作业的描述，用户可以通过 kubectl 客户端将提交 SparkApplication CR 到 APIServer，随后由 Spark Operator 负责作业生命周期以及 Driver Pod 的管理。
- 凭借 Koordinator 能力的加持，ColocationProfile Webhook 会自动为 Spark 任务的 Pod 注入相关混部配置参数（包括QoS，Priority，extened-resource等），如下所示。Koordlet 在单机侧负责 Spark Pod 在混部后不会影响在线应用性能表现，通过将 Spark 与在线应用进行混部，可以有效提升集群整体资源利用率。
- Spark Driver Pod example
apiVersion: v1
kind: Pod
metadata:
labels:
koordinator.sh/qosClass: BE
...
spec:
containers:
- args:
- driver
...
resources:
limits:
koordinator.sh/batch-cpu: "1000"
koordinator.sh/batch-memory: 3456Mi
requests:
koordinator.sh/batch-cpu: "1000"
koordinator.sh/batch-memory: 3456Mi
