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注意kubectl get queues 是 kubectl get localqueues 的别名更方便日常使用。LocalQueue vs ClusterQueue维度 LocalQueue ClusterQueue作用域 命名空间 集群谁创建 团队自己 批处理管理员职责 将同一租户的工作负载分组指向一个 ClusterQueue 管理资源池的配额和公平共享规则一对一 多个 LocalQueue 可以指向同一个 ClusterQueue —命名空间 team-a:LocalQueue: training-queue ──┐LocalQueue: inference-queue ──┼──→ ClusterQueue: ai-team-cq命名空间 team-b: │LocalQueue: batch-queue ──────┘一句话记住LocalQueue 就是 Namespace 访问 ClusterQueue 的入口。 它不管配额只管我这个 namespace 的 Job 往哪个 ClusterQueue 送。Cohort队列之间怎么借资源如果每个 ClusterQueue 只能用自己的保底配额那 team-a 闲着 3 核、team-b 想多跑 1 核也借不到资源就浪费了。Cohort 就是解决这个的——可以理解成一个资源共享联盟加进同一个 Cohort 的 ClusterQueue 可以互相借配额。第一次看 Cohort 我也没太理解。后来发现它本身还能定义 resourceGroups共享配额池这些资源是管理员额外划拨给整个联盟的公共池而不是把各个 ClusterQueue 的 nominalQuota 自动汇总得到的。ClusterQueue 与 Cohort 的关系基本用法创建 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: hello-cohortspec:resourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 12 # Cohort 级别的共享配额额外资源ClusterQueue A 加入 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: team-a-cqspec:cohortName: hello-cohortresourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 4borrowingLimit: 4 # 最多借 4 核lendingLimit: 2 # 最多出借 2 核ClusterQueue B 也加入同一个 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: team-b-cqspec:cohortName: hello-cohortresourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 4borrowingLimit: 4lendingLimit: 2上面的配置意味着两个队列各有 4 核保底Cohort 自己配置的一组共享配额 12 核。总计可用 20 核空闲时可以互相借用如果 ClusterQueue 想从 Cohort 借用资源它必须为该资源和 Flavor 定义 nominalQuota即使值为 0分层 CohortHierarchical CohortsCohort 可以组织成树形结构CohortTree适合大型组织根 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: root-cohortAI 部门 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: ai-deptspec:parentName: root-cohort # 父节点fairSharing:weight: “0.75”大数据部门 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: bigdata-deptspec:parentName: root-cohort # 父节点fairSharing:weight: “0.25”root-cohort总资源池├── ai-dept权重 0.75 → 趋向使用 75% 公共资源│ ├── team-a-cq│ └── team-b-cq└── bigdata-dept权重 0.25 → 趋向使用 25% 公共资源├── spark-cq└── flink-cq同一个 CohortTree 中的 ClusterQueue 可以使用其中的资源遵循为 Cohort 和 ClusterQueue 指定的借用和借出限制。一句话记住Cohort 让多个 ClusterQueue 可以互相借资源。
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注意kubectl get queues 是 kubectl get localqueues 的别名更方便日常使用。LocalQueue vs ClusterQueue维度 LocalQueue ClusterQueue作用域 命名空间 集群谁创建 团队自己 批处理管理员职责 将同一租户的工作负载分组指向一个 ClusterQueue 管理资源池的配额和公平共享规则一对一 多个 LocalQueue 可以指向同一个 ClusterQueue —命名空间 team-a:LocalQueue: training-queue ──┐LocalQueue: inference-queue ──┼──→ ClusterQueue: ai-team-cq命名空间 team-b: │LocalQueue: batch-queue ──────┘一句话记住LocalQueue 就是 Namespace 访问 ClusterQueue 的入口。 它不管配额只管我这个 namespace 的 Job 往哪个 ClusterQueue 送。Cohort队列之间怎么借资源如果每个 ClusterQueue 只能用自己的保底配额那 team-a 闲着 3 核、team-b 想多跑 1 核也借不到资源就浪费了。Cohort 就是解决这个的——可以理解成一个资源共享联盟加进同一个 Cohort 的 ClusterQueue 可以互相借配额。第一次看 Cohort 我也没太理解。后来发现它本身还能定义 resourceGroups共享配额池这些资源是管理员额外划拨给整个联盟的公共池而不是把各个 ClusterQueue 的 nominalQuota 自动汇总得到的。ClusterQueue 与 Cohort 的关系基本用法创建 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: hello-cohortspec:resourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 12 # Cohort 级别的共享配额额外资源ClusterQueue A 加入 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: team-a-cqspec:cohortName: hello-cohortresourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 4borrowingLimit: 4 # 最多借 4 核lendingLimit: 2 # 最多出借 2 核ClusterQueue B 也加入同一个 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: ClusterQueuemetadata:name: team-b-cqspec:cohortName: hello-cohortresourceGroups:coveredResources: [“cpu”]flavors:name: default-flavorresources:name: cpunominalQuota: 4borrowingLimit: 4lendingLimit: 2上面的配置意味着两个队列各有 4 核保底Cohort 自己配置的一组共享配额 12 核。总计可用 20 核空闲时可以互相借用如果 ClusterQueue 想从 Cohort 借用资源它必须为该资源和 Flavor 定义 nominalQuota即使值为 0分层 CohortHierarchical CohortsCohort 可以组织成树形结构CohortTree适合大型组织根 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: root-cohortAI 部门 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: ai-deptspec:parentName: root-cohort # 父节点fairSharing:weight: “0.75”大数据部门 CohortapiVersion: kueue.x-k8s.io/v1beta2kind: Cohortmetadata:name: bigdata-deptspec:parentName: root-cohort # 父节点fairSharing:weight: “0.25”root-cohort总资源池├── ai-dept权重 0.75 → 趋向使用 75% 公共资源│ ├── team-a-cq│ └── team-b-cq└── bigdata-dept权重 0.25 → 趋向使用 25% 公共资源├── spark-cq└── flink-cq同一个 CohortTree 中的 ClusterQueue 可以使用其中的资源遵循为 Cohort 和 ClusterQueue 指定的借用和借出限制。一句话记住Cohort 让多个 ClusterQueue 可以互相借资源。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
