很多人刚接触 Kueue 时最大的困惑不是 YAML 怎么写而是看着一堆 CRDResourceFlavor、ClusterQueue、LocalQueue、Cohort、Workload不知道它们之间到底是什么关系。本文不会逐个照着 API 文档介绍字段而是把这五个对象放到同一条资源准入链路中一次讲清楚它们各自负责什么、为什么要存在以及它们之间如何协作。上一篇文章中分析了 Kueue 的完整工作流kueue-workflow.png涉及到多个核心对象下面逐个拆开讲。ResourceFlavor资源长什么样Kueue 要管资源第一步得知道集群里有哪些种类的资源。集群里的 CPU、GPU 通常不是同构的价格和可用性 竞价型 vs 按需型虚拟机架构 x86 vs ARM CPU品牌和型号 Nvidia A100 vs T4 GPUResourceFlavor 就是干这个的——给资源分个类贴个标签后面 ClusterQueue 按这个分类来管配额。Kueue 在 Admission 阶段会根据 ClusterQueue 中配置的 Flavor 顺序、Quota 是否满足、Flavor 是否匹配 Pod 等因素选择一个可用的 ResourceFlavor。空 Flavor如果集群资源是同构的或者不需要为不同资源规格分别管理配额那直接创建一个不包含任何标签或污点的空 ResourceFlavor 即可apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: default-flavor这类 ResourceFlavor 不承担节点筛选或污点控制的职责仅作为统一的资源抽象存在方便后续扩展不同资源类型。只分类不加污点apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “gpu”spec:nodeLabels:instance-type: gpu新增参数spec.nodeLabels 通过 label 关联到对应的节点。具体实现上则是通过将 flavor 中 nodeLabels 部分自动注入到 Pod Spec 中的 nodeSelector从而达到只将 Pod 调度到该 flavor 关联的节点上。这类 Flavor 实现了根据 label 将节点进行分类算是名副其实。管理员先给节点打上对应 label 即可实现分类rootlixd-dev-4:~# kubectl label node lixd-dev-4 instance-typegpunode/lixd-dev-4 labeled但也只是简单做了分类不是该 Flavor 中的 Job 也能手动调度到这些 GPU 节点。比较推荐的做法是给节点再打上污点这样就不是随便能调度上去了kubectl taint node xxx nvidia.com/gputrue:NoSchedule节点打上污点后Flavor 中的 Job 也不能调度了。Kueue 提供了两种模式来解决这个问题自动容忍模式 将污点容忍信息写到 ResourceFlavorKueue 自动给使用该 Flavor 的 Pod 加上容忍手动容忍模式 将污点信息写到 ResourceFlavorKueue 做匹配拦截只允许带了对应容忍的 Pod 使用该 Flavor带污点自动污点容忍调度apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “spot”spec:nodeLabels:instance-type: spottolerations:key: “spot-taint” # 节点上已有污点的 keyoperator: “Exists”effect: “NoSchedule” # 支持 NoSchedule 和 NoExecute新增参数spec.tolerations 声明该 flavor 关联节点上的污点容忍信息。Kueue 准入时自动注入到 Pod 的 .spec.template.spec.tolerations确保 Pod 能容忍节点污点从而正常调度。手动污点容忍apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “spot”spec:nodeLabels:instance-type: spotnodeTaints:effect: NoSchedule # 只支持 NoSchedule 和 NoExecutePreferNoSchedule 会被忽略key: spotvalue: “true”新增参数spec.nodeTaints 在 flavor 上定义准入门槛。Kueue 不会自动注入容忍度Pod 必须自己带对应 toleration 才能通过准入、拿到配额。用户提交 Job 时必须自己带上 toleration否则 Kueue 不批配额spec:template:spec:tolerations:- key: spotoperator: Existseffect: NoSchedule注意 spec.nodeTaints 通常应与节点上的真实污点保持一致。否则可能出现 Pod 过了 Kueue 准入、拿到配额但 K8s 调度器发现节点有真污点而 Pod 没对应 toleration最终调度失败——白白占了配额。本质就是把调度层面的拦截提前到 Kueue 准入层面。两种模式怎么选自动模式spec.tolerations 手动模式spec.nodeTaints谁给 Pod 加 toleration Kueue 自动注入 用户自己写用户需要关心节点污点吗 不需要提交 Job 就行 必须自己写 toleration用在哪 生产默认对用户最友好 保护昂贵资源强制用户显式声明选型建议优先用自动模式只有当你需要强制用户显式声明才能使用某种昂贵资源时才用手动模式。一句话记住ResourceFlavor 定义资源的属性标签、污点、容忍等真正决定资源配额和公平性的仍然是 ClusterQueue。ClusterQueue谁是配额的真正管家如果 ResourceFlavor 是给资源分类那真正决定谁能用、用多少的是谁答案就是 ClusterQueue。它才是 Kueue 配额管理的核心定义了使用上限和公平共享规则。基础用法一个基础的 ClusterQueue 示例如下apiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: “cluster-queue”spec:namespaceSelector: {} # 匹配所有命名空间。resourceGroups:coveredResources: [“cpu”, “memory”, “pods”]flavors:name: “default-flavor”resources:name: “cpu”nominalQuota: 9name: “memory”nominalQuota: 36Giname: “pods”nominalQuota: 5字段解析spec.namespaceSelector 指定该 ClusterQueue 可以在哪些 namespace 被使用。当前 ClusterQueue 可以被任意 Namespace 使用。resourceGroups 资源组定义 ClusterQueue 的资源额度可以有多个每个组都是独立的。coveredResources 管哪些资源同一个 group 里面的资源必须在同一个 flavor 里面分配。flavors 可以有多个分配是按顺序尝试。name 使用名称引用前面创建的 ResourceFlavor。resources 在这个 flavor 下每种资源的配额上限。nominalQuota 保底配额表示该 ClusterQueue 的名义配额优先保障自身使用未使用的部分可以按照 borrowing/lending 规则被其他 Queue 借用。borrowingLimit 你最多能从 Cohort 里借入多少所以你最多能用 nominalQuota borrowingLimit。lendingLimit 你最多允许别人从你这借走多少当你空闲时需要时可通过预抢占收回。以 cpu 为例基于上面三个配额字段你可以使用的范围是 nominalQuota ~ (nominalQuota borrowingLimit)。高级用法在基础配置之上ClusterQueue 还支持以下进阶字段按用途分组调度顺序排队策略spec:queueingStrategy: BestEffortFIFOBestEffortFIFO默认 前面的 Job 拿不到配额后面的能插队先跑资源利用率高。StrictFIFO 前面的 Job 拿不到配额后面的必须等适合有顺序依赖的 Pipeline。资源共享加入 Cohortspec:cohortName: research-cohortcohortName 关联到一个 Cohort同一个 Cohort 里的 ClusterQueue 可以互相共享资源。抢占相关当 ClusterQueue 或其 Cohort 中没有足够的配额时新进入的 Workload 可以触发预抢占挤掉低优先级的 Workload。涉及两个配置项预抢占策略spec:preemption:reclaimWithinCohort: Any # 可抢占 Cohort 中超过名义配额的 WorkloadborrowWithinCohort:policy: LowerPriority # 借用时只抢占低优先级不能与 Fair Sharing 一同使用maxPriorityThreshold: 100 # 且仅抢占优先级 ≤ 100 的 WorkloadwithinClusterQueue: LowerPriority # 同队列内低优先级让路给高优先级withinClusterQueue 同队列内当待处理 Workload 不适合配额时是否可抢占同队列中的活动 Workload。Never默认不抢占LowerPriority 仅抢占低优先级LowerOrNewerEqualPriority 抢占低优先级或同优先级的。reclaimWithinCohort 是否可抢占 Cohort 中使用了超过其名义配额的 Workload。Never默认不抢占LowerPriority 仅抢占低优先级Any 可抢占任意优先级。borrowWithinCohort 当需要借用配额时是否触发抢占。Never默认不触发LowerPriority 仅抢占 Cohort 中低优先级的 Workload需同时启用 reclaimWithinCohort。注意只能配置经典抢占不能与 Fair Sharing 一同使用。优先抢占还是借用当 ClusterQueue 有多个 flavor 时Kueue 按顺序尝试。当当前 flavor 配额用完时你可以影响 Kueue 的行为whenCanBorrow 能从 Cohort 借的时候。MayStopSearch默认借了就停不再试下一个TryNextFlavor不借先试下一个 flavor。whenCanPreempt 能抢占低优先级 Job 的时候。TryNextFlavor默认先试下一个 flavorMayStopSearch不试了直接抢占。spec:flavorFungibility:whenCanBorrow: TryNextFlavorwhenCanPreempt: MayStopSearch运维控制停止策略控制队列的运行状态ClusterQueue 和 LocalQueue 都支持。None默认 正常运行新 Job 正常准入已运行的不受影响。Hold 停止新的准入已准入的不受影响适合维护、配额调整等临时场景。HoldAndDrain 停止新的准入 触发已准入工作负载的驱逐适合紧急情况需要立刻清场。维护完恢复为 None 或直接删掉这个字段即可。这是运维操作不是常态配置。spec:stopPolicy: Hold把上面的都放在一起一个包含所有字段的完整 ClusterQueueapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: ai-team-cqspec:1. 加入 Cohort允许和其他 ClusterQueue 共享资源cohortName: research-cohort2. 排队策略queueingStrategy: BestEffortFIFO # 默认。StrictFIFO 会阻塞3. 命名空间选择器谁能用这个 ClusterQueuenamespaceSelector:matchLabels:team: ai4. 抢占策略preemption:reclaimWithinCohort: Any # 可抢占 Cohort 中超过名义配额的 WorkloadborrowWithinCohort:policy: LowerPriority # 借用时只抢占低优先级不能与 Fair Sharing 一同使用maxPriorityThreshold: 100 # 且仅抢占优先级 ≤ 100 的 WorkloadwithinClusterQueue: LowerPriority # 同队列内低优先级让路给高优先级5. 配置是优先抢占还是借用flavorFungibility:whenCanBorrow: TryNextFlavorwhenCanPreempt: MayStopSearch6. 停止策略stopPolicy: Hold7. 资源组定义resourceGroups:coveredResources: [“cpu”, “memory”] # 第一组计算资源flavors:name: default-flavorresources:name: cpunominalQuota: 16 # 保底配额borrowingLimit: 8 # 最多能从 Cohort 借多少lendingLimit: 8 # 最多允许别人借多少name: memorynominalQuota: 64GiborrowingLimit: 32GilendingLimit: 32GicoveredResources: [“nvidia.com/gpu”] # 第二组GPU 资源flavors:name: a100resources:name: nvidia.com/gpunominalQuota: 4borrowingLimit: 2name: t4resources:name: nvidia.com/gpunominalQuota: 8一句话记住ClusterQueue 才是真正管配额和公平性的地方。 第一次看会和 LocalQueue 搞混其实记住一句就够了——ClusterQueue 管资源LocalQueue 管用户。LocalQueue用户怎么进队列ClusterQueue 是集群级别的但用户不能直接往里塞 Job。中间还需要一层 LocalQueue——它是一个命名空间对象指向一个 ClusterQueue作为用户提交 Job 的入口。apiVersion: kueue.x-k8s.io/v1beta2kind: LocalQueuemetadata:namespace: team-aname: team-a-queuespec:clusterQueue: cluster-queue
很多人刚接触 Kueue 时最大的困惑不是 YAML 怎么写而是看着一堆 CRDResourceFlavor、ClusterQueue、LocalQueue、Cohort、Workload不知道它们之间到底是什么关系。本文不会逐个照着 API 文档介绍字段而是把这五个对象放到同一条资源准入链路中一次讲清楚它们各自负责什么、为什么要存在以及它们之间如何协作。上一篇文章中分析了 Kueue 的完整工作流kueue-workflow.png涉及到多个核心对象下面逐个拆开讲。ResourceFlavor资源长什么样Kueue 要管资源第一步得知道集群里有哪些种类的资源。集群里的 CPU、GPU 通常不是同构的价格和可用性 竞价型 vs 按需型虚拟机架构 x86 vs ARM CPU品牌和型号 Nvidia A100 vs T4 GPUResourceFlavor 就是干这个的——给资源分个类贴个标签后面 ClusterQueue 按这个分类来管配额。Kueue 在 Admission 阶段会根据 ClusterQueue 中配置的 Flavor 顺序、Quota 是否满足、Flavor 是否匹配 Pod 等因素选择一个可用的 ResourceFlavor。空 Flavor如果集群资源是同构的或者不需要为不同资源规格分别管理配额那直接创建一个不包含任何标签或污点的空 ResourceFlavor 即可apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: default-flavor这类 ResourceFlavor 不承担节点筛选或污点控制的职责仅作为统一的资源抽象存在方便后续扩展不同资源类型。只分类不加污点apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “gpu”spec:nodeLabels:instance-type: gpu新增参数spec.nodeLabels 通过 label 关联到对应的节点。具体实现上则是通过将 flavor 中 nodeLabels 部分自动注入到 Pod Spec 中的 nodeSelector从而达到只将 Pod 调度到该 flavor 关联的节点上。这类 Flavor 实现了根据 label 将节点进行分类算是名副其实。管理员先给节点打上对应 label 即可实现分类rootlixd-dev-4:~# kubectl label node lixd-dev-4 instance-typegpunode/lixd-dev-4 labeled但也只是简单做了分类不是该 Flavor 中的 Job 也能手动调度到这些 GPU 节点。比较推荐的做法是给节点再打上污点这样就不是随便能调度上去了kubectl taint node xxx nvidia.com/gputrue:NoSchedule节点打上污点后Flavor 中的 Job 也不能调度了。Kueue 提供了两种模式来解决这个问题自动容忍模式 将污点容忍信息写到 ResourceFlavorKueue 自动给使用该 Flavor 的 Pod 加上容忍手动容忍模式 将污点信息写到 ResourceFlavorKueue 做匹配拦截只允许带了对应容忍的 Pod 使用该 Flavor带污点自动污点容忍调度apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “spot”spec:nodeLabels:instance-type: spottolerations:key: “spot-taint” # 节点上已有污点的 keyoperator: “Exists”effect: “NoSchedule” # 支持 NoSchedule 和 NoExecute新增参数spec.tolerations 声明该 flavor 关联节点上的污点容忍信息。Kueue 准入时自动注入到 Pod 的 .spec.template.spec.tolerations确保 Pod 能容忍节点污点从而正常调度。手动污点容忍apiVersion: kueue.x-k8s.io/v1beta2kind: ResourceFlavormetadata:name: “spot”spec:nodeLabels:instance-type: spotnodeTaints:effect: NoSchedule # 只支持 NoSchedule 和 NoExecutePreferNoSchedule 会被忽略key: spotvalue: “true”新增参数spec.nodeTaints 在 flavor 上定义准入门槛。Kueue 不会自动注入容忍度Pod 必须自己带对应 toleration 才能通过准入、拿到配额。用户提交 Job 时必须自己带上 toleration否则 Kueue 不批配额spec:template:spec:tolerations:- key: spotoperator: Existseffect: NoSchedule注意 spec.nodeTaints 通常应与节点上的真实污点保持一致。否则可能出现 Pod 过了 Kueue 准入、拿到配额但 K8s 调度器发现节点有真污点而 Pod 没对应 toleration最终调度失败——白白占了配额。本质就是把调度层面的拦截提前到 Kueue 准入层面。两种模式怎么选自动模式spec.tolerations 手动模式spec.nodeTaints谁给 Pod 加 toleration Kueue 自动注入 用户自己写用户需要关心节点污点吗 不需要提交 Job 就行 必须自己写 toleration用在哪 生产默认对用户最友好 保护昂贵资源强制用户显式声明选型建议优先用自动模式只有当你需要强制用户显式声明才能使用某种昂贵资源时才用手动模式。一句话记住ResourceFlavor 定义资源的属性标签、污点、容忍等真正决定资源配额和公平性的仍然是 ClusterQueue。ClusterQueue谁是配额的真正管家如果 ResourceFlavor 是给资源分类那真正决定谁能用、用多少的是谁答案就是 ClusterQueue。它才是 Kueue 配额管理的核心定义了使用上限和公平共享规则。基础用法一个基础的 ClusterQueue 示例如下apiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: “cluster-queue”spec:namespaceSelector: {} # 匹配所有命名空间。resourceGroups:coveredResources: [“cpu”, “memory”, “pods”]flavors:name: “default-flavor”resources:name: “cpu”nominalQuota: 9name: “memory”nominalQuota: 36Giname: “pods”nominalQuota: 5字段解析spec.namespaceSelector 指定该 ClusterQueue 可以在哪些 namespace 被使用。当前 ClusterQueue 可以被任意 Namespace 使用。resourceGroups 资源组定义 ClusterQueue 的资源额度可以有多个每个组都是独立的。coveredResources 管哪些资源同一个 group 里面的资源必须在同一个 flavor 里面分配。flavors 可以有多个分配是按顺序尝试。name 使用名称引用前面创建的 ResourceFlavor。resources 在这个 flavor 下每种资源的配额上限。nominalQuota 保底配额表示该 ClusterQueue 的名义配额优先保障自身使用未使用的部分可以按照 borrowing/lending 规则被其他 Queue 借用。borrowingLimit 你最多能从 Cohort 里借入多少所以你最多能用 nominalQuota borrowingLimit。lendingLimit 你最多允许别人从你这借走多少当你空闲时需要时可通过预抢占收回。以 cpu 为例基于上面三个配额字段你可以使用的范围是 nominalQuota ~ (nominalQuota borrowingLimit)。高级用法在基础配置之上ClusterQueue 还支持以下进阶字段按用途分组调度顺序排队策略spec:queueingStrategy: BestEffortFIFOBestEffortFIFO默认 前面的 Job 拿不到配额后面的能插队先跑资源利用率高。StrictFIFO 前面的 Job 拿不到配额后面的必须等适合有顺序依赖的 Pipeline。资源共享加入 Cohortspec:cohortName: research-cohortcohortName 关联到一个 Cohort同一个 Cohort 里的 ClusterQueue 可以互相共享资源。抢占相关当 ClusterQueue 或其 Cohort 中没有足够的配额时新进入的 Workload 可以触发预抢占挤掉低优先级的 Workload。涉及两个配置项预抢占策略spec:preemption:reclaimWithinCohort: Any # 可抢占 Cohort 中超过名义配额的 WorkloadborrowWithinCohort:policy: LowerPriority # 借用时只抢占低优先级不能与 Fair Sharing 一同使用maxPriorityThreshold: 100 # 且仅抢占优先级 ≤ 100 的 WorkloadwithinClusterQueue: LowerPriority # 同队列内低优先级让路给高优先级withinClusterQueue 同队列内当待处理 Workload 不适合配额时是否可抢占同队列中的活动 Workload。Never默认不抢占LowerPriority 仅抢占低优先级LowerOrNewerEqualPriority 抢占低优先级或同优先级的。reclaimWithinCohort 是否可抢占 Cohort 中使用了超过其名义配额的 Workload。Never默认不抢占LowerPriority 仅抢占低优先级Any 可抢占任意优先级。borrowWithinCohort 当需要借用配额时是否触发抢占。Never默认不触发LowerPriority 仅抢占 Cohort 中低优先级的 Workload需同时启用 reclaimWithinCohort。注意只能配置经典抢占不能与 Fair Sharing 一同使用。优先抢占还是借用当 ClusterQueue 有多个 flavor 时Kueue 按顺序尝试。当当前 flavor 配额用完时你可以影响 Kueue 的行为whenCanBorrow 能从 Cohort 借的时候。MayStopSearch默认借了就停不再试下一个TryNextFlavor不借先试下一个 flavor。whenCanPreempt 能抢占低优先级 Job 的时候。TryNextFlavor默认先试下一个 flavorMayStopSearch不试了直接抢占。spec:flavorFungibility:whenCanBorrow: TryNextFlavorwhenCanPreempt: MayStopSearch运维控制停止策略控制队列的运行状态ClusterQueue 和 LocalQueue 都支持。None默认 正常运行新 Job 正常准入已运行的不受影响。Hold 停止新的准入已准入的不受影响适合维护、配额调整等临时场景。HoldAndDrain 停止新的准入 触发已准入工作负载的驱逐适合紧急情况需要立刻清场。维护完恢复为 None 或直接删掉这个字段即可。这是运维操作不是常态配置。spec:stopPolicy: Hold把上面的都放在一起一个包含所有字段的完整 ClusterQueueapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: ai-team-cqspec:1. 加入 Cohort允许和其他 ClusterQueue 共享资源cohortName: research-cohort2. 排队策略queueingStrategy: BestEffortFIFO # 默认。StrictFIFO 会阻塞3. 命名空间选择器谁能用这个 ClusterQueuenamespaceSelector:matchLabels:team: ai4. 抢占策略preemption:reclaimWithinCohort: Any # 可抢占 Cohort 中超过名义配额的 WorkloadborrowWithinCohort:policy: LowerPriority # 借用时只抢占低优先级不能与 Fair Sharing 一同使用maxPriorityThreshold: 100 # 且仅抢占优先级 ≤ 100 的 WorkloadwithinClusterQueue: LowerPriority # 同队列内低优先级让路给高优先级5. 配置是优先抢占还是借用flavorFungibility:whenCanBorrow: TryNextFlavorwhenCanPreempt: MayStopSearch6. 停止策略stopPolicy: Hold7. 资源组定义resourceGroups:coveredResources: [“cpu”, “memory”] # 第一组计算资源flavors:name: default-flavorresources:name: cpunominalQuota: 16 # 保底配额borrowingLimit: 8 # 最多能从 Cohort 借多少lendingLimit: 8 # 最多允许别人借多少name: memorynominalQuota: 64GiborrowingLimit: 32GilendingLimit: 32GicoveredResources: [“nvidia.com/gpu”] # 第二组GPU 资源flavors:name: a100resources:name: nvidia.com/gpunominalQuota: 4borrowingLimit: 2name: t4resources:name: nvidia.com/gpunominalQuota: 8一句话记住ClusterQueue 才是真正管配额和公平性的地方。 第一次看会和 LocalQueue 搞混其实记住一句就够了——ClusterQueue 管资源LocalQueue 管用户。LocalQueue用户怎么进队列ClusterQueue 是集群级别的但用户不能直接往里塞 Job。中间还需要一层 LocalQueue——它是一个命名空间对象指向一个 ClusterQueue作为用户提交 Job 的入口。apiVersion: kueue.x-k8s.io/v1beta2kind: LocalQueuemetadata:namespace: team-aname: team-a-queuespec:clusterQueue: cluster-queue
