Koordinator
约 6169 字大约 21 分钟
2026-05-27
一句话理解
Koordinator 是一个面向 Kubernetes 的 QoS 感知调度和资源优化系统。它在原生 Kubernetes 之上增强调度、混部、资源超卖、运行时隔离、重调度和异构资源管理能力,用来让在线服务、离线批任务、AI 训练、Spark / Presto 等不同类型的 workload 更高效、更稳定地运行在同一个集群里。
换句话说:
Kubernetes 负责把 Pod 跑起来,Koordinator 进一步解决“怎么调得更准、怎么混得更稳、怎么把机器资源用得更满”的问题。
Koordinator 不是一个新的容器运行时,也不是 kubelet 的替代品。它更像是一组围绕 Kubernetes 调度链路和节点资源管理链路的增强组件:控制面负责调度、配额、Profile、SLO 和重调度,节点侧负责指标采集、资源隔离、干扰检测和 QoS 执行。
为什么需要 Koordinator
原生 Kubernetes 已经有 scheduler、requests / limits、PriorityClass、QoS Class、HPA、VPA、Cluster Autoscaler 等能力,但在大规模生产集群里,仍然会遇到几个典型问题。
1. requests 和真实用量之间有差距
Kubernetes 调度时主要看 Pod 的 requests。业务为了稳定性,通常会把 requests 设置得比平均用量高很多。这样可以降低资源不足的风险,但也会带来一个问题:节点上看起来资源已经被分配完了,实际上 CPU、内存可能长期处于低使用率。
例如一个在线服务申请了 8 核 CPU,但大多数时间只用 2 核。如果调度器只看 request,剩下的 6 核就很难被合理利用。Koordinator 的混部模型就是希望识别这些“已分配但短期不会使用”的资源,把它们以可回收资源的形式提供给低优先级任务使用。
2. 在线服务和离线任务的目标不同
在线服务关注延迟、抖动和可用性,例如 Web 服务、RPC 服务、网关、数据库中间件等。离线任务关注吞吐和成本,例如大数据报表、日志处理、模型训练、视频转码等。
如果把它们简单地放在同一个节点上,很容易出现资源争抢:
- 离线任务把 CPU 打满,在线服务 P99 延迟升高。
- 离线任务占用大量内存,在线服务触发 OOM 或频繁 GC。
- 磁盘 IO、网络带宽、LLC、内存带宽等共享资源互相干扰。
- 节点负载突然升高,调度器却没有及时感知。
Koordinator 的目标不是“无脑超卖”,而是在资源复用和 QoS 保障之间建立一套可控机制:高优先级 workload 优先获得确定性资源,低优先级 workload 使用可回收资源,并且在压力升高时被限制、压制或驱逐。
3. 调度不仅仅是找一台有资源的 Node
生产调度往往还需要考虑更多维度:
- 当前节点真实负载,而不是只看已声明的 request。
- NUMA、CPU 拓扑、GPU、RDMA、网卡等异构资源。
- 大数据和 AI 任务的 gang scheduling。
- 多租户资源配额和弹性借用。
- 资源碎片整理、预留和抢占。
- 热点节点迁移和负载再平衡。
这些能力如果全部在业务侧或调度器插件里零散实现,复杂度会很高。Koordinator 把这些能力抽象成一套完整的调度和运行时资源管理体系。
核心架构
Koordinator 由控制面组件和节点侧组件组成。一个典型部署中会包含:
koord-schedulerkoord-managerkoordletkoord-descheduler- 可选的
koord-runtime-proxy - 可选的
koord-device-daemon - 可选的
koord-queue
整体关系可以简化成下面这样:
这里最重要的一点是:Koordinator 保持和原生 Kubernetes workload 的兼容。你仍然使用 Pod、Deployment、Job、PriorityClass、SchedulerName、CRD、Webhook 等 Kubernetes 机制,只是把某些 workload 交给 koord-scheduler 调度,并通过 Koordinator 的标签、注解、扩展资源和 CRD 表达更细的调度语义。
主要组件
1. koord-scheduler
koord-scheduler 是 Koordinator 的增强调度器,通常以 Deployment 形式运行。
它不是简单替换 kube-scheduler,而是在 Kubernetes scheduling framework 的基础上增加一系列插件和能力。典型能力包括:
QoS 感知调度 根据 workload 的 QoS、优先级、资源模型等信息做调度决策。
负载感知调度 调度时参考节点真实负载,尽量避免把新 Pod 调度到已经很热的节点上。
资源超卖调度 把高优先级 Pod 已经申请但暂时未使用的资源,转化成低优先级 Pod 可使用的 batch 资源。
任务调度 支持 gang scheduling、ElasticQuota、资源预留、异构资源调度等,适合大数据和 AI workload。
细粒度调度 支持 CPU 拓扑、NUMA、设备拓扑等更细的资源选择。
使用 koord-scheduler 的 Pod 通常需要显式指定:
spec:
schedulerName: koord-scheduler如果没有指定,Pod 仍然会走默认的 default-scheduler,也就无法使用 Koordinator 调度器提供的增强能力。
2. koord-manager
koord-manager 是 Koordinator 的控制面管理组件,通常以 Deployment 形式运行,并通过 leader election 保证高可用。
它主要负责:
- 管理 Koordinator 相关 CRD。
- 提供 mutating / validating webhook。
- 维护混部相关配置。
- 管理 SLO 策略。
- 根据节点指标动态计算可回收资源。
- 维护
ClusterColocationProfile等配置对象。
一个很常见的用法是通过 ClusterColocationProfile 自动给 Pod 注入 Koordinator 语义。例如把某类 batch workload 自动设置成 BE QoS、koord-batch priority,并指定 koord-scheduler。
3. koordlet
koordlet 是节点侧组件,通常以 DaemonSet 形式运行在每个 Node 上。
它是 Koordinator 能做混部和 QoS 保障的关键,因为调度器只能决定 Pod 放到哪里,真正的运行时状态必须在节点上观察和执行。
koordlet 主要负责:
- 采集节点、Pod、Container 的资源使用情况。
- 生成并上报
NodeMetric等指标对象。 - 做资源画像,估算可回收资源。
- 检测 CPU、内存、网络、磁盘等维度的干扰。
- 根据 QoS 和优先级设置 cgroup、CPU、内存等隔离参数。
- 在压力升高时压制或驱逐低优先级 Pod。
- 通过 NRI 或 runtime hooks 在容器生命周期中注入资源策略。
可以把 koordlet 理解成 Koordinator 的“节点资源代理”。没有 koordlet,调度器就很难知道节点真实负载,也很难在节点侧执行 QoS 策略。
4. koord-descheduler
koord-descheduler 是增强版重调度组件。它关注的是已经运行起来的 Pod 是否还处在合适的位置。
典型场景包括:
- 某些节点负载过高,需要迁移部分 Pod。
- 集群资源分布不均衡,需要重新打散。
- 节点池成本不同,希望 workload 逐步迁移到更合适的节点池。
- 调度时条件满足,但运行一段时间后节点状态发生变化。
它的基本动作不是直接“搬迁容器”,而是根据策略驱逐某些 Pod,让这些 Pod 重新进入调度流程,再由调度器选择更合适的节点。
5. koord-runtime-proxy
koord-runtime-proxy 是可选组件,通常以 systemd service 方式部署在节点上。它位于 kubelet 和容器运行时之间,拦截 CRI 请求,并在 Pod sandbox 或 container 创建过程中注入一些资源管理策略。
它适合那些必须在容器启动前完成的策略,例如提前设置 cpuset、RDT、某些 GPU Share 相关环境等。
生产里不要把它当成默认必装组件。现在很多节点侧资源管理能力可以通过 NRI 或 koordlet 的 runtime hook 完成,只有明确需要 runtime proxy 支持的特性时再安装它。
6. koord-device-daemon
在异构资源场景里,Koordinator 通过 Device CRD 抽象节点上的 GPU、RDMA、FPGA 等设备信息。koordlet 和 koord-device-daemon 可以协同完成设备发现、设备信息上报和健康状态维护。
调度时,koord-scheduler 不只看 Node 上有没有某种设备,还可以结合设备拓扑、部分设备资源、虚拟 GPU、RDMA VF、故障隔离等信息做决策。
这类能力主要面向 AI、HPC、大数据加速等场景。普通 Web 服务通常不需要重点关注。
7. koord-queue
koord-queue 是 Koordinator v1.8 引入的可选组件,面向多租户 AI / batch 集群的作业级排队和准入控制。
原生 Kubernetes scheduler 的调度对象是 Pod,但很多 batch 和 AI workload 的自然单位是“一个 Job”。例如一个 PyTorchJob 可能包含多个 worker,一个 Spark 应用可能包含 driver 和 executor。只按 Pod 调度,容易出现部分 Pod 已经占资源、部分 Pod 还 Pending 的问题。
koord-queue 解决的是“作业先排队、满足条件后再进入调度”的问题。它可以和 ElasticQuota 集成,支持多队列、公平共享、优先级、阻塞策略、预调度准入等能力。
如果集群主要跑在线服务,可能不需要 koord-queue。如果集群里有大量 AI 训练、Spark、Ray、Argo Workflow、原生 Job 等任务,作业级队列会更有价值。
Koordinator 的核心概念
1. Priority
Kubernetes 已经有 PriorityClass。Koordinator 在此基础上定义了更适合混部场景的优先级分层。
常见的 Koordinator PriorityClass 包括:
| PriorityClass | 优先级范围 | 典型 workload |
|---|---|---|
koord-prod | [9000, 9999] | 核心在线服务、延迟敏感服务 |
koord-mid | [7000, 7999] | 重要但可一定程度弹性的服务、实时计算、部分 AI 任务 |
koord-batch | [5000, 5999] | 离线批处理、分析任务、训练任务 |
koord-free | [3000, 3999] | 低优先级任务、测试任务、尽力而为任务 |
PriorityClass 决定大方向,Pod 上的 koordinator.sh/priority 可以表达更细的子优先级。例如:
apiVersion: v1
kind: Pod
metadata:
name: batch-demo
labels:
koordinator.sh/priority: "5300"
spec:
priorityClassName: koord-batch
schedulerName: koord-scheduler
containers:
- name: app
image: nginx这样 Koordinator 既能兼容 Kubernetes 原生优先级机制,也能在同一优先级大类内部做更细的排序和资源控制。
2. QoS
Kubernetes 原生 QoS 主要有三类:
GuaranteedBurstableBestEffort
这些 QoS 对 kubelet 驱逐顺序和资源保障有影响,但对复杂混部场景来说不够细。Koordinator 引入了独立的 koordinator.sh/qosClass,用来描述 Pod 在混部场景下的运行质量。
Koordinator 支持的 QoS 可以概括为:
| Koordinator QoS | 含义 | 典型场景 |
|---|---|---|
SYSTEM | 系统组件,延迟需要保障,但资源使用也需要约束 | DaemonSet、节点系统服务 |
LSE | Latency Sensitive Exclusive,延迟敏感且资源隔离要求高 | 中间件、独占资源池应用 |
LSR | Latency Sensitive Reserved,预留资源,确定性更强 | Guaranteed 类在线服务、绑核服务 |
LS | Latency Sensitive,共享资源但要求延迟稳定 | 常见微服务、Web 服务 |
BE | Best Effort,使用可回收资源,必要时可被压制或驱逐 | 离线任务、批处理、低成本计算 |
Koordinator QoS 和 Kubernetes QoS 有大致对应关系:
| Koordinator QoS | Kubernetes QoS |
|---|---|
SYSTEM | 无直接对应 |
LSE | Guaranteed |
LSR | Guaranteed |
LS | Guaranteed / Burstable |
BE | BestEffort |
这里要注意:koordinator.sh/qosClass 不等于 Kubernetes 原生 QoS Class。原生 QoS 由 requests 和 limits 自动推导;Koordinator QoS 是混部语义,需要通过 label、Profile 或 webhook 注入。
3. 资源模型
Koordinator 的混部资源模型可以用四条线理解:
limit / request 高优先级 Pod 申请的资源,也是 Kubernetes 调度时常用的资源声明。
usage Pod 实际使用的资源,会随时间波动。
short-term reservation 根据短周期历史用量预测的资源保留量。它比真实 usage 更稳一点,但比 request 更低。
long-term reservation 根据更长周期历史用量估算的保留量。它更保守,适合生命周期更长的任务。
Koordinator 的基本思路是:
request 和 reservation 之间的差值,在可控条件下可以变成低优先级 workload 使用的可回收资源。
这些可回收资源通常会以扩展资源的形式暴露给 batch workload,例如:
resources:
requests:
kubernetes.io/batch-cpu: "1000"
kubernetes.io/batch-memory: 2Gi
limits:
kubernetes.io/batch-cpu: "1000"
kubernetes.io/batch-memory: 2Gi其中 kubernetes.io/batch-cpu 和 kubernetes.io/batch-memory 来自节点的可回收资源池。它们不是凭空产生的资源,而是 Koordinator 根据在线 workload 的申请量、真实用量、节点负载和 SLO 策略计算出来的。
4. SLO
SLO 是 Service Level Objective,也就是服务等级目标。在 Koordinator 里,SLO 不是只用来描述业务可用性,它还会影响节点资源管理策略。
常见策略包括:
- CPU 使用率水位线。
- 内存使用率水位线。
- BE workload 的 CPU suppress。
- BE workload 的内存驱逐。
- LS workload 的 CPU Burst。
- Memory QoS。
- LLC、内存带宽、网络带宽、blkio 等隔离策略。
当节点压力升高时,Koordinator 会优先保护高优先级、高 QoS 的 workload,再限制低优先级 workload 的资源使用。
一个典型混部流程
假设集群中有两类 workload:
- 在线微服务:
LS,koord-prod,需要稳定延迟。 - 离线批任务:
BE,koord-batch,可以被压制或重试。
整体流程大致如下:
关键点有三个:
koord-manager负责把 workload 转成 Koordinator 能理解的语义。koord-scheduler负责基于这些语义做调度决策。koordlet负责在节点侧持续观察并执行资源保障策略。
使用 ClusterColocationProfile 自动注入混部配置
如果已经有很多业务控制器和 Job 模板,不希望每个模板都手动加 koordinator.sh/qosClass、priorityClassName、schedulerName,可以用 ClusterColocationProfile。
例如,把带有 app-type=batch 标签的 Pod 自动作为 batch workload 运行:
apiVersion: config.koordinator.sh/v1alpha1
kind: ClusterColocationProfile
metadata:
name: batch-workload-profile
spec:
namespaceSelector:
matchLabels:
koordinator.sh/enable-colocation: "true"
selector:
matchLabels:
app-type: batch
qosClass: BE
priorityClassName: koord-batch
schedulerName: koord-scheduler
labels:
koordinator.sh/mutated: "true"然后给 namespace 打标签:
kubectl create namespace batch-demo
kubectl label namespace batch-demo koordinator.sh/enable-colocation=true之后创建的 batch Pod 只要带上匹配标签:
apiVersion: batch/v1
kind: Job
metadata:
name: data-processing-job
namespace: batch-demo
spec:
template:
metadata:
labels:
app-type: batch
spec:
containers:
- name: worker
image: python:3.9
command: ["python", "-c", "print('hello koordinator')"]
resources:
requests:
cpu: "2"
memory: 4Gi
limits:
cpu: "2"
memory: 4Gi
restartPolicy: NeverWebhook 就可以根据 Profile 注入 Koordinator 相关配置。实际注入后的 Pod 可能包含:
metadata:
labels:
koordinator.sh/qosClass: BE
koordinator.sh/mutated: "true"
spec:
priorityClassName: koord-batch
schedulerName: koord-scheduler如果需要完全显式声明,也可以直接写成下面这样:
apiVersion: batch/v1
kind: Job
metadata:
name: manual-batch-job
namespace: batch-demo
spec:
template:
metadata:
labels:
koordinator.sh/qosClass: BE
spec:
priorityClassName: koord-batch
schedulerName: koord-scheduler
containers:
- name: worker
image: busybox:stable
command: ["sh", "-c", "sleep 60"]
resources:
requests:
kubernetes.io/batch-cpu: "1000"
kubernetes.io/batch-memory: 2Gi
limits:
kubernetes.io/batch-cpu: "1000"
kubernetes.io/batch-memory: 2Gi
restartPolicy: Never安装和基本检查
Koordinator 通常通过 Helm 安装。以 v1.8.0 为例:
helm repo add koordinator-sh https://koordinator-sh.github.io/charts/
helm repo update
helm install koordinator koordinator-sh/koordinator --version 1.8.0安装后可以检查组件状态:
kubectl get pod -n koordinator-system常见组件包括:
koord-manager
koord-scheduler
koord-descheduler
koordlet
koord-device-daemon检查 PriorityClass:
kubectl get priorityclass | grep koord检查节点是否有 Koordinator 上报的指标:
kubectl get nodemetric
kubectl get nodemetric -o yaml如果要验证 batch 可回收资源,可以查看 Node allocatable:
kubectl get node <node-name> -o yaml | grep -A 20 allocatable可能会看到类似资源:
allocatable:
cpu: "8"
memory: 16Gi
kubernetes.io/batch-cpu: "15000"
kubernetes.io/batch-memory: 20Gi这说明 Koordinator 已经计算出了可用于 batch workload 的可回收资源。
Koordinator 和原生 Kubernetes 的关系
Koordinator 不替代 kube-scheduler
Koordinator 提供 koord-scheduler,但它并不要求所有 Pod 都走 Koordinator 调度器。
生产里常见做法是:
- 普通 workload 继续使用
default-scheduler。 - 需要混部、负载感知、异构资源、Gang Scheduling、ElasticQuota 的 workload 使用
koord-scheduler。 - 通过
schedulerName明确区分调度入口。
这样可以逐步接入,降低风险。
Koordinator 不替代 kubelet
kubelet 仍然负责:
- 监听分配到本节点的 Pod。
- 调用容器运行时创建容器。
- 管理 volume、probe、Pod status。
- 执行驱逐、上报节点状态。
Koordinator 的节点侧组件 koordlet 是增强节点资源管理,不是替代 kubelet。它观察节点状态、调整资源隔离参数、执行 Koordinator 的 QoS 策略,但不会接管 kubelet 的核心生命周期管理。
Koordinator 不替代 HPA / VPA / Cluster Autoscaler
这些组件解决的问题不同:
| 组件 | 主要解决的问题 |
|---|---|
| HPA | 根据指标调整副本数 |
| VPA | 推荐或调整 Pod requests |
| Cluster Autoscaler | 根据 Pod Pending 情况扩缩节点 |
| Koordinator | 调度增强、混部、QoS 保障、资源超卖和重调度 |
它们可以组合使用。例如 HPA 扩容产生的新 Pod 可以由 koord-scheduler 调度;Cluster Autoscaler 仍然可以在资源不足时扩容节点;Koordinator 则提升已有节点的资源利用率和调度质量。
适合什么场景
1. 在线和离线混部
这是 Koordinator 最典型的场景。
在线服务保留确定性资源,离线任务使用可回收资源。节点压力上升时,离线任务先被压制或驱逐,从而保护在线服务延迟。
适合:
- 微服务 + 大数据任务。
- Web 服务 + 日志处理。
- 在线推理 + 离线训练。
- 常驻服务 + 周期性批任务。
2. 提升集群资源利用率
如果集群长期 CPU 利用率低,但 requests 已经把节点“占满”,Koordinator 可以帮助把闲置资源变成可调度的 batch 资源。
不过这需要配套做资源画像、压测和 SLO 配置。否则资源利用率上去了,线上延迟也可能一起上去。
3. 大数据和 AI 任务调度
Koordinator 支持 ElasticQuota、Gang Scheduling、Job 级队列、资源预留、异构设备调度等能力。对于多租户 AI / batch 集群,它能解决很多默认 scheduler 不擅长的问题:
- 多 Pod 任务要么一起调度,要么先等待。
- 多租户之间需要 min / max 配额和弹性借用。
- GPU、RDMA、NUMA 拓扑需要全局调度。
- 高优先级任务需要预留或抢占资源。
4. 负载感知和重调度
如果集群经常出现某些节点很热、某些节点很空的情况,Koordinator 可以通过负载感知调度和 descheduler 做持续优化。
这类能力尤其适合 workload 波动明显、节点规格复杂、调度约束很多的集群。
不适合什么场景
Koordinator 很强,但不应该把它当成所有 Kubernetes 资源问题的默认答案。
1. 小集群或低复杂度集群
如果集群规模很小,workload 类型简单,资源利用率也不是问题,引入 Koordinator 可能增加不必要的组件复杂度。
2. 没有明确 SLO 的混部
混部的前提是知道谁应该被保护、谁可以被牺牲、节点压力到什么程度要压制、什么程度要驱逐。
如果这些规则没有定义清楚,只是为了提高利用率而上混部,风险会比较大。
3. 不可重试的离线任务
BE workload 在资源压力下可能被限制或驱逐。因此离线任务最好具备:
- 重试能力。
- 幂等性。
- Checkpoint。
- 合理的
backoffLimit。 - 可接受的完成时间波动。
如果任务不能中断,也不能变慢,就不适合放在 BE 资源上。
4. 运行时和内核能力不满足
Koordinator 的部分 QoS 能力依赖 cgroup、NRI、内核能力、容器运行时能力以及节点文件系统挂载方式。官方推荐 Linux kernel 4.19 及以上以获得更好的体验。
在 Kind、本地测试集群、老内核、特殊容器运行时、托管 Kubernetes 集群中,需要先确认兼容性和组件权限。
生产使用建议
1. 先从观测开始
不要一开始就打开 aggressive 的资源超卖策略。更稳妥的路径是:
- 部署 Koordinator。
- 观察
NodeMetric、节点真实负载、在线服务延迟。 - 小范围接入 batch workload。
- 配置保守的 SLO 水位线。
- 逐步提高 batch 资源使用比例。
2. 明确区分 workload 等级
至少要定义清楚:
- 哪些是
koord-prod。 - 哪些是
koord-mid。 - 哪些是
koord-batch。 - 哪些允许使用
BE。 - 哪些 workload 永远不能被混部。
这类规则最好沉淀到 namespace、label、Profile 和准入策略里,而不是让每个业务手动理解。
3. 给 batch workload 做容错设计
使用 BE 和 batch 资源的任务要默认接受“可能变慢、可能被驱逐、可能要重试”的现实。
建议:
- 设置合理的
requests和limits。 - 使用 Job / Workflow 自带重试机制。
- 关键任务做 checkpoint。
- 避免把有强 SLA 的任务标成
BE。 - 对 batch 任务的完成时间设置合理预期。
4. 不要让所有 Pod 一次性切到 koord-scheduler
更稳妥的做法是按 namespace、业务线或 workload 类型逐步接入。
例如:
- 先接低风险 batch namespace。
- 再接 AI / 大数据任务。
- 最后再考虑对在线服务启用更细的 QoS 策略。
5. 关注 Webhook 和 CRD 兼容性
Koordinator 会安装 CRD 和 webhook。生产升级前要关注:
- CRD 是否被云厂商托管集群预置。
- webhook failurePolicy 是否符合预期。
- 升级是否涉及 breaking changes。
- 老版本 Kubernetes 是否支持对应 API。
- 是否存在自定义 CNI 导致 apiserver 无法访问 webhook 的问题。
6. 把监控和回滚放在前面
至少要监控:
- 在线服务 P95 / P99 延迟。
- 节点 CPU、内存、IO、网络使用率。
- BE Pod suppress 和 eviction 次数。
- scheduler 调度延迟和失败原因。
- descheduler 驱逐行为。
- Koordinator 组件自身健康状态。
如果上线后发现在线服务抖动,应该能快速降低超卖比例、关闭某些 Profile、暂停 batch workload 或回滚 Helm release。
常用排查命令
查看 Koordinator 组件:
kubectl get pod -n koordinator-system -o wide查看 Pod 是否被注入 Koordinator 配置:
kubectl get pod <pod-name> -n <namespace> -o yaml重点看:
metadata:
labels:
koordinator.sh/qosClass: BE
koordinator.sh/priority: "5300"
spec:
priorityClassName: koord-batch
schedulerName: koord-scheduler查看调度失败原因:
kubectl describe pod <pod-name> -n <namespace>查看节点可回收资源:
kubectl get node <node-name> -o yaml | grep -A 30 allocatable查看 Koordinator 节点指标:
kubectl get nodemetric
kubectl get nodemetric <node-name> -o yaml查看 koordlet 日志:
kubectl logs -n koordinator-system <koordlet-pod-name>查看 descheduler 行为:
kubectl logs -n koordinator-system deploy/koord-descheduler
kubectl get events -A --sort-by='.lastTimestamp'总结
Koordinator 的核心价值是把 Kubernetes 的调度和节点资源管理从“按声明资源静态分配”推进到“按 workload 等级、真实负载、QoS 目标和资源画像动态优化”。
它适合解决大规模集群里的资源利用率、在线离线混部、AI / batch 调度、多租户配额、异构设备调度和负载再平衡问题。它的能力来自多个组件协同:koord-scheduler 负责增强调度,koord-manager 负责控制面策略和 webhook,koordlet 负责节点侧观测和 QoS 执行,koord-descheduler 负责运行后的再平衡。
但 Koordinator 不是“装上就自动省机器”的工具。真正落地时,关键在于先定义 workload 等级和 SLO,再小范围灰度,持续观察在线服务延迟和节点压力,最后逐步扩大混部比例。资源利用率提升必须建立在可观测、可回滚、可解释的 QoS 策略之上。
参考资料
更新日志
4ee05-add koordinator docs于