Kueue

设置 Prometheus

Wed, 04 Feb 2026 00:00:00 +0000

此页面展示了如何设置 Prometheus 以抓取 Kueue 指标。对于使用 TLS 保护的指标端点，请参阅使用 TLS 配置 Prometheus。

本页面适用于批处理管理员。

开始之前

确保满足以下条件：

Kubernetes 集群正在运行。
kubectl 命令行工具可以与你的集群通信。
Kueue 已安装。
Prometheus Operator 已安装。

1. 设置

选择与你的 Kueue 安装匹配的设置方法。

配置外部证书管理器

Fri, 14 Mar 2025 00:00:00 +0000

此页面展示了如何使用第三方证书颁发机构管理证书的解决方案，如 Cert Manager。

该页面适用于批处理管理员。

开始之前

确保满足以下条件：

一个 Kubernetes 集群正在运行。
kubectl 命令行工具与你的集群通信。
Kueue 已安装。
Cert Manager 已安装

Kueue 支持 Kustomize 或通过 Helm chart 进行安装。

内部证书管理

在所有情况下，如果想要使用 CertManager，必须关闭 Kueue 的内部证书管理。

运行包装过的自定义工作负载

Tue, 14 Jan 2025 00:00:00 +0000

本页面展示了如何使用 AppWrapper 使 Kueue 的调度和资源管理能力可用于没有专用 Kueue 集成的工作负载类型。对于在其定义中使用 PodSpecTemplates 的工作负载，这提供了一种比构建自定义集成更简便的方法来启用与自定义工作负载类型一起使用 Kueue。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅Kueue 概述。

开始之前

确保你正在使用 Kueue v0.11.0 版本或更新版本以及 AppWrapper v1.0.2 或更新版本。
遵循运行 AppWrapper 中的步骤学习如何启用和配置 workload.codeflare.dev/appwrapper 集成。

使用 LeaderWorkerSet 作为自定义工作负载的示例

我们使用 LeaderWorkerSet 为例，来解释如何在 AppWrapper 内运行自定义类型的工作负载。

Job 故障排除

Thu, 21 Mar 2024 00:00:00 +0000

本文档介绍如何排除挂起的 Kubernetes Jobs 的故障，但大多数想法可以推广到其他支持的作业类型。

请参阅 Kueue 概览以可视化协作运行 Job 的组件。

在本文档中，假设你的 Job 名为 my-job，位于 my-namespace 命名空间中。

识别你的 Job 对应的 Workload

对于每个 Job，Kueue 创建一个 Workload 对象来保存 Job 准入的详细信息，无论它是否被准入。

要找到 Job 对应的 Workload，你可以使用以下任一步骤：

你可以通过运行以下命令从 Job 事件中获取 Workload 名称：

kubectl describe job -n my-namespace my-job

Provisioning 准入检查控制器

Mon, 23 Oct 2023 00:00:00 +0000

Provisioning 准入检查控制器(AdmissionCheck Controller)是一个专为将 Kueue 与 Kubernetes 集群自动缩放器集成而设计的准入检查控制器。其主要功能是为持有配额预留的工作负载创建 ProvisioningRequests，并保持 AdmissionCheckState 的同步。

该控制器是 Kueue 的一部分，默认启用。您可以通过编辑 ProvisioningACC 特性门控来禁用它。有关特性门控配置的详细信息，请查看安装指南。

Provisioning 准入检查控制器支持 Kubernetes 集群自动缩放器 1.29 及更高版本。但是，某些云提供商可能没有相应的实现。

请查看集群自动缩放器文档中支持的 Provisioning 类和先决条件列表。

使用方法

要使用 Provisioning 准入检查，需要创建一个 AdmissionCheck，将 kueue.x-k8s.io/provisioning-request 作为 .spec.controllerName，并使用 ProvisioningRequestConfig 对象创建 ProvisioningRequest 配置。

接下来，您需要从 ClusterQueue 引用 AdmissionCheck，详见准入检查使用。

完整设置请参见下文。

ProvisioningRequest 配置

Kueue 为您的作业创建 ProvisioningRequests 有两种配置方式：

设置 RBAC

Mon, 14 Feb 2022 00:00:00 +0000

This page shows you how to setup role-based access control (RBAC) in your cluster to control the types of users that can view and create Kueue objects.

The page is intended for a batch administrator.

本页面介绍了如何在集群中设置基于角色的访问控制（RBAC），以控制可以查看和创建 Kueue 对象的用户类型。

本页面适用于批处理管理员。

开始之前

确保满足以下条件：

Kubernetes 集群正在运行。
kubectl 命令行工具与你的集群通信。
Kueue 已安装。

本页面假设你已经熟悉 Kubernetes 中的 RBAC。

常用 Grafana 查询

Tue, 03 Feb 2026 00:00:00 +0000

此页面向你展示如何使用常见的 PromQL 查询在 Grafana 中监控 Kueue 指标。

此页面的目标读者为批处理管理员。

开始之前

确保满足以下条件：

Kubernetes 集群正在运行。
kubectl 命令行工具能够与你的集群通信。
Kueue 已安装。
kube-prometheus 已安装。
Kueue Prometheus 指标已启用（参见设置 Prometheus）。

配额利用率

注意

本部分的查询需要在 Kueue 配置中设置 metrics.enableClusterQueueResources: true。详情参见安装。

要监控 ClusterQueue 中正在使用的 CPU 配额百分比：

配置 Prometheus

Fri, 14 Mar 2025 00:00:00 +0000

此页面展示了如何配置 Kueue 以使用 Prometheus 指标。

此页面适用于批处理管理员。

开始之前

确保满足以下条件：

一个 Kubernetes 集群正在运行。
kubectl 命令行工具可以与集群通信。
Kueue 已安装。
Prometheus 已安装
Cert Manager 已安装（可选地）

Kueue 支持 Kustomize 或通过 Helm chart 安装。

Kustomize 安装

在 config/default/kustomization.yaml 中启用 prometheus，并取消注释中所有包含 ‘PROMETHEUS’ 的部分。

使用证书的 Kustomize Prometheus

如果你想为指标端点启用 TLS 验证，请遵循以下步骤。

在多集群环境中运行 Deployment

Mon, 17 Feb 2025 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。
按照运行普通 Pod的步骤，了解如何启用和配置 Pod 集成，这对于启用 Deployment 集成是必需的。

Deployment 会实时接收在工作集群创建的远程 Pod 的状态，并更新。

Feature state beta since Kueue v0.11.0

注意

在当前实现中，当在有多个工作集群的环境中创建 Deployment 时，Pod 会被分配到任意工作集群。

示例

完成设置后，你可以通过运行以下示例进行测试：

在多集群环境中运行普通 Pod

Mon, 17 Feb 2025 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。
按照运行 Plain Pod的步骤，了解如何启用和配置 pod 集成。

在管理集群上创建的 Pod 会自动被管控，并实时接收来自远程副本的状态更新。

Feature state beta since Kueue v0.11.0

示例

完成设置后，你可以通过运行以下示例进行测试：

在多集群中运行 StatefulSet

Wed, 15 Jan 2025 00:00:00 +0000

开始之前

检查 MultiKueue 安装指南以了解如何正确设置 MultiKueue 集群。

Pod 集成要求

自 Kueue v0.15 起，你不需要显式启用 "pod" 集成即可使用 "statefulset" 集成。

对于 Kueue v0.14 及更早版本，必须显式启用 "pod" 集成。

有关配置详情，请参阅运行普通 Pod。

运行 StatefulSet 示例

一旦设置完成，你可以通过运行下面的示例来测试它：

在多集群环境中运行 Job

Tue, 05 Nov 2024 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

MultiKueue 在工作集群上执行的 Job 的当前状态会实时同步到管理集群。

这样，用户和自动化工具可以在不访问工作集群的情况下，直接跟踪 Job 的状态（.status），从而实现 MultiKueue 的透明化。

示例

完成设置后，你可以通过运行以下示例进行测试：

队列故障排除

Thu, 21 Mar 2024 00:00:00 +0000

为什么 LocalQueue 中没有 workload 被准入？

LocalQueue 的状态包含 LocalQueue 上任何配置问题的详细信息，作为 Active 条件的一部分。

运行以下命令查看 LocalQueue 的状态：

kubectl get localqueue -n my-namespace my-local-queue -o yaml

LocalQueue 的状态将类似于以下内容：

status:
  admittedWorkloads: 0
  conditions:
  - lastTransitionTime: "2024-05-03T18:57:32Z"
    message: Can't submit new workloads to clusterQueue
    reason: ClusterQueueIsInactive
    status: "False"
    type: Active

在上面的示例中，Active 条件的状态为 False，因为 ClusterQueue 不活跃。

管理集群配额

Mon, 14 Mar 2022 00:00:00 +0000

本页面向你展示如何管理集群资源配额，并在租户之间建立公平共享规则。

本页面的目标读者是批处理管理员。

你开始之前

请确保满足以下条件：

Kubernetes 集群已运行。
kubectl 命令行工具能与你的集群通信。
已安装 Kueue。

安装单一 ClusterQueue 和 ResourceFlavor

在以下步骤中，你将创建一个排队系统用于管理集群的配额，它拥有一个 ClusterQueue 和一个 ResourceFlavor。

资源规格（Resource Flavor）

Mon, 14 Mar 2022 00:00:00 +0000

集群中的资源通常不是同构的。资源可能在以下方面有所不同：

价格和可用性（例如，竞价型与按需型虚拟机）
架构（例如，x86 与 ARM CPU）
品牌和型号（例如，Radeon 7000、Nvidia A100、T4 GPU）

资源规格（ResourceFlavor）是一个表示这些资源差异的对象，并允许你通过标签、污点和容忍度将它们与集群节点关联。

注意

如果你的集群资源是同构的，你可以使用空 ResourceFlavor，而无需为自定义 ResourceFlavor 添加标签。

ResourceFlavor 容忍度实现自动调度

需要 Kubernetes 1.23 或更高版本

这种方式适合希望自动将 Pod 调度到合适节点的团队。但当集群中存在多种专用硬件（如两种不同的 nvidia.com/gpu 资源，即 T4 和 A100 GPU）时，会有一个限制：系统可能无法区分它们，Pod 可能会被调度到任意一种硬件上。

要将 ResourceFlavor 与集群中某一部分节点关联，可以在 .spec.nodeLabels 字段中配置能唯一标识这些节点的标签。如果你使用 cluster autoscaler（或类似控制器），请确保控制器在添加新节点时会添加这些标签。

为了保证 Workload 中的 Pod 运行在 Kueue 选定的 flavor 所关联的节点上，Kueue 会执行以下步骤：

运行 Flux MiniCluster

Mon, 14 Feb 2022 00:00:00 +0000

此页面展示了在运行 Flux Operator 的 MiniCluster 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参见 Kueue 概述。

开始之前

查阅管理集群配额，以获取初始集群设置的详细信息。

查阅 Flux Operator 安装指南。

MiniCluster 定义

由于 Flux MiniCluster 作为 batch/Job 运行，Kueue 不需要额外的组件来管理 Flux MiniCluster。然而，需要注意以下方面：

在多集群中运行 TrainJob

Thu, 06 Nov 2025 00:00:00 +0000

开始之前

查阅 MultiKueue 安装指南以了解如何正确设置 MultiKueue 集群。

为了简化设置和使用，我们建议至少使用 Kueue v0.11.0 版本以及 Kubeflow Trainer 至少 v2.0.0 版本。

查看 Trainer 安装获取 Kubeflow Trainer v2 的安装和配置详情。

注意

TrainJob 是 Kubeflow Trainer v2 的一部分，它引入了一个统一的 API 用于所有训练框架。它取代了 Trainer v1 中特定于框架的工作类型（PyTorchJob、TFJob 等）。

对于遗留的 Kubeflow Jobs（v1），请参阅在多集群中运行 Kubeflow Job。

MultiKueue 集成

完成设置后，你可以通过运行一个 TrainJob sample-trainjob 来测试它。

在多集群环境中运行 AppWrappers

Mon, 23 Jun 2025 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

为方便安装和使用，建议至少使用 Kueue v0.11.0 及 AppWrapper Operator v1.1.1 及以上版本。

有关 AppWrapper Operator 的安装和配置详情，请参见 AppWrapper 快速入门指南。

注意

MultiKueue 对 AppWrappers 的支持在 Kueue v0.11.0 之前的版本中不可用。

MultiKueue 集成

完成设置后，你可以通过运行 AppWrapper appwrapper-pytorch-sample.yaml进行测试。

运行 Argo Workflow

Thu, 23 Jan 2025 00:00:00 +0000

此页面展示了在运行 Argo Workflow 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参见 Kueue 概述。

目前，Kueue 不直接支持 Argo Workflow 的 Workflow 资源，但你可以利用 Kueue 管理普通 Pod 的能力来集成它们。

开始之前

学习如何使用自定义管理器配置安装 Kueue。
遵循运行普通 Pod 中的步骤来学习如何启用和配置 pod 集成。
安装 Argo Workflow

Workflow 定义

a. 针对单个本地队列

如果你希望整个工作流针对单个本地队列，应在 Workflow 配置的 spec.podMetadata 部分指定它。

在多集群环境中运行 Jobset

Wed, 25 Sep 2024 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

为方便安装和使用，建议至少使用 Kueue v0.8.1 和 JobSet v0.6.0（更多详情见 JobSet 安装文档）。

运行 Jobset 示例

完成设置后，你可以通过运行 jobset-sample.yaml Job 进行测试。

Kueue 中的 Provisioning Request 故障排除

Mon, 20 May 2024 00:00:00 +0000

本文档帮助你排除 ProvisioningRequest 的故障，这是由 ClusterAutoscaler 定义的 API。

Kueue 通过 Provisioning Admission Check Controller 创建 ProvisioningRequest，并将其视为准入检查。为了让 Kueue 准入 Workload，为其创建的 ProvisioningRequest 需要成功。

开始之前

在开始故障排除之前，请确保你的集群满足以下要求：

你的集群已启用 ClusterAutoscaler，且 ClusterAutoscaler 支持 ProvisioningRequest API。检查你的云提供商文档以确定支持 ProvisioningRequest 的最低版本。如果你使用 GKE，你的集群应该运行版本 1.28.3-gke.1098000 或更新版本。
你使用支持 ProvisioningRequest 的节点类型。这可能因云提供商而异。
Kueue 的版本是 v0.5.3 或更新版本。
你已在特性门控配置中启用了 ProvisioningACC。对于 Kueue v0.7.0 或更新版本，此特性门控默认启用。

识别你的作业对应的 Provisioning Request

请参阅 Job 故障排除指南，了解如何识别你的作业对应的 Workload。

开启 pprof 端点

Fri, 21 Jul 2023 00:00:00 +0000

本页面向你展示如何为 Kueue 控制器管理器开启 pprof 端点。

本页面的目标读者是批处理管理员。

开始之前

确保满足以下条件：

Kubernetes 集群正在运行。
kubectl 命令行工具能够与你的集群进行通信。
Kueue 已安装。

开启 pprof 端点

Feature state stable since Kueue v0.5

要开启 pprof 端点，你需要在管理器的配置中设置 pprofBindAddress。

集群队列（ClusterQueue）

Tue, 14 Mar 2023 00:00:00 +0000

ClusterQueue 是一个集群范围的对象，用于管理一组资源池，如 Pod、CPU、内存和硬件加速器。ClusterQueue 定义了：

ClusterQueue 管理的资源规格的配额，包括使用上限和消耗顺序。
集群中多个 ClusterQueue 之间的公平共享规则。

只有批处理管理员才应创建 ClusterQueue 对象。

一个示例 ClusterQueue 如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  namespaceSelector: {} # 匹配所有命名空间。
  resourceGroups:
  - coveredResources: ["cpu", "memory", "pods"]
    flavors:
    - name: "default-flavor"
      resources:
      - name: "cpu"
        nominalQuota: 9
      - name: "memory"
        nominalQuota: 36Gi
      - name: "pods"
        nominalQuota: 5

只有在以下条件全部满足时，该 ClusterQueue 才会接纳工作负载：

CPU 请求总和小于等于 9。
内存请求总和小于等于 36Gi。
Pod 总数小于等于 5。

您可以将配额指定为数量。

配置自定义指标标签

Tue, 10 Mar 2026 00:00:00 +0000

本页面向你展示如何配置自定义指标标签，这些标签将 Kubernetes 标签或注解从 ClusterQueue、LocalQueue 和 Cohort 提升为额外的 Prometheus 指标标签维度。

本页面的目标受众是批处理管理员。

开始之前

确保满足以下条件：

一个 Kubernetes 集群正在运行。
kubectl 命令行工具能够与你的集群通信。
Kueue 已安装。
Prometheus 已设置以抓取 Kueue 指标。

配置自定义标签

自定义指标标签需要 CustomMetricLabels 特性门控，它是 Alpha 级别且默认禁用。关于如何启用特性门控的详情，请参见安装。

Cohort

Wed, 16 Apr 2025 00:00:00 +0000

你好，Cohort

Cohort 使你能够组织你的配额。同一个 Cohort（或对于分层 Cohort 来说是同一个 CohortTree）中的 ClusterQueue 可以相互共享资源。最简单的 Cohort 如下：

apiVersion: kueue.x-k8s.io/v1beta2
kind: Cohort
metadata:
  name: "hello-cohort"

ClusterQueue 可以通过引用来加入此 Cohort：

apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "my-cluster-queue"
spec:
  cohortName: "hello-cohort"

配置配额

资源配额可以在 Cohort 级别定义（类似于为 ClusterQueue 定义的方式），并由 Cohort 内的 ClusterQueue 来消耗使用。请注意，在 Cohort 级别定义的 nominalQuota 表示除了 Cohort 内 ClusterQueue 所定义的资源之外的额外资源。Cohort 的 nominalQuota 可以被视为其内 ClusterQueue 的共享池。此外，此配额也可能根据 LendingLimit 借给父 Cohort。

弹性工作负载

Wed, 16 Apr 2025 00:00:00 +0000

Feature state alpha since Kueue v0.13

弹性工作负载（工作负载切片）

弹性工作负载扩展了 Kueue 中核心的 Workload 抽象，以支持已接受 Job 的动态扩缩，无需暂停或重新排队。这是通过使用工作负载切片实现的，工作负载切片跟踪父 Job 扩缩操作的部分分配。

此特性使得能够更响应和高效地调度适应集群容量变化的 Job，特别是在工作负载波动或资源受限的环境中。

动态扩缩

传统上，Kueue 中的 Workload 表示单一原子性的准入单元。一旦被接纳，它反映了一组固定的 Pod 副本并消耗定义的配额。如果 Job 需要扩缩，Workload 必须被暂停、移除或完全替换。

在多集群环境中运行 KubeRay Job

Wed, 19 Mar 2025 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

为方便安装和使用，建议至少使用 Kueue v0.11.0 及 KubeRay Operator v1.3.1 及以上版本。

有关 KubeRay Operator 的安装和配置详情，请参见 KubeRay Operator 安装文档。

注意

在 Kueue（低于 v0.11.0）支持 ManagedBy 特性之前， 管理集群上的 KubeRay Operator 安装必须仅限于 CRD。

要安装 CRD，请运行：

kubectl create -k "github.com/ray-project/kuberay/ray-operator/config/crd?ref=v1.3.0"

MultiKueue 集成

完成设置后，你可以通过运行 RayJob ray-job-sample.yaml进行测试。

在多集群环境中运行 Kubeflow Job

Wed, 25 Sep 2024 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

为方便安装和使用，建议使用 Kueue v0.11.0 和 Kubeflow Trainer v1.9.0 以上版本。

有关 Trainer 的安装和配置详情，请参见 Trainer 安装文档。

注意

在 Kueue（低于 v0.11.0）支持 ManagedBy 特性之前，管理集群上的 Kubeflow Trainer 安装必须仅限于 CRD。

要安装 CRD，请运行：

kubectl apply -k "github.com/kubeflow/trainer.git/manifests/base/crds?ref=v1.9.0"

MultiKueue 集成

完成设置后，你可以通过运行其中一个 Kubeflow Job（如 PyTorchJob sample-pytorchjob.yaml）进行测试。

Pod 故障排除

Thu, 21 Mar 2024 00:00:00 +0000

本文档介绍如何排除由 Kueue 直接管理的普通 Pod 的故障，换句话说，就是不由 Kubernetes Job 或支持的 CRD 管理的 Pod。

注意

本文档重点介绍 Kueue 管理 Pod 时与其他作业集成不同的行为。你可以阅读 Job 故障排除了解更多通用的故障排除步骤。

我的 Pod 是否由 Kueue 直接管理？

Kueue 向其管理的 Pod 添加标签 kueue.x-k8s.io/managed，值为 true。如果 Pod 上没有此标签，意味着 Kueue 不会直接准入或统计此 Pod 的资源使用情况。

Pod 可能没有 kueue.x-k8s.io/managed 标签的原因如下：

使用工作负载优先级（`WorkloadPriority`）运行作业（Job）

Mon, 02 Oct 2023 00:00:00 +0000

通常，在 Kueue 中，工作负载的优先级是使用 Pod 的优先级来计算的，用于排队和抢占。

通过使用 WorkloadPriorityClass，你可以独立管理工作负载的优先级，以便进行排队和抢占，与 Pod 的优先级分开。

此页面包含如何使用工作负载优先级运行作业的说明。

在你开始之前

确保满足以下条件：

一个正在运行的 Kubernetes 集群。
kubectl 命令行工具能够与你的集群通信。
Kueue 已安装。

0. 创建 WorkloadPriorityClass

首先应该创建 WorkloadPriorityClass。

本地队列（Local Queue）

Mon, 14 Mar 2022 00:00:00 +0000

LocalQueue 是一个命名空间对象，用于将属于单个命名空间的紧密相关的工作负载进行分组。一个命名空间通常分配给组织的一个租户（团队或用户）。 LocalQueue 指向一个 ClusterQueue，并从中分配资源以运行其工作负载。

LocalQueue 定义如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: team-a 
  name: team-a-queue
spec:
  clusterQueue: cluster-queue

用户将作业（Job）提交到 LocalQueue，而不是直接提交到 ClusterQueue。租户可以通过列出其命名空间中的本地队列来发现他们可以向哪些队列提交作业。该命令类似于以下内容：

kubectl get -n my-namespace localqueues
# 或者，使用别名 `queue` 或 `queues`
kubectl get -n my-namespace queues

queue 和 queues 是 localqueue 的别名。

下一步是什么？

通过本地队列启动工作负载
阅读 LocalQueue 的 API 参考

运行 Kubernetes Job

Mon, 14 Feb 2022 00:00:00 +0000

本页面向您展示如何在启用了 Kueue 的 Kubernetes 集群中运行 Job。

本页面的目标受众是批量用户。

开始之前

确保满足以下条件：

Kubernetes 集群正在运行。
kubectl 命令行工具能够与您的集群通信。
已安装 Kueue。
集群已配置配额。

下图显示了您在本教程中将要学习的所有概念：

0. 识别命名空间中可用的队列

运行以下命令列出您命名空间中可用的 LocalQueues。

在多集群中运行外部框架 Job

Fri, 19 Sep 2025 00:00:00 +0000

Feature state alpha since Kueue v0.14

开始之前

检查多 Kueue 安装指南以了解如何正确设置多 Kueue 集群。
启用 MultiKueueAdaptersForCustomJobs 特性门控。此特性处于 Alpha 阶段，默认情况下是禁用的。

要启用此特性，请将 --feature-gates=MultiKueueAdaptersForCustomJobs=true 标志添加到 Kueue 控制器管理器的参数中。例如，你可以使用以下命令将其应用到你的部署中：
```
kubectl patch deployment kueue-controller-manager -n kueue-system \
  --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/args/-", "value": "--feature-gates=MultiKueueAdaptersForCustomJobs=true"}]'
```
确保 Kueue 控制器对你的外部 GVK 有权限。以 Tekton PipelineRuns 为例：

在多集群环境中运行 MPIJob

Fri, 25 Oct 2024 00:00:00 +0000

开始之前

请查阅 MultiKueue 安装指南了解如何正确设置 MultiKueue 集群。

为保证正确安装和使用，需至少使用 Kueue v0.9.0 及 MPI Operator v0.6.0。

集群上的安装

注意

注意：MPI Operator 和 Trainer 必须同时运行在同一集群上，但 Trainer 部署需做特殊配置。详见与 MPI Operator 协同工作。

有关 MPI Operator 的安装和配置详情，请参见 MPI Operator 安装文档。

删除 ClusterQueue 故障排除

Wed, 28 Aug 2024 00:00:00 +0000

当 ClusterQueue 有活跃的 Workload 时，删除它可能需要额外的步骤。

本指南提供了安全删除 ClusterQueue 的清晰方法，解释了删除过程并提供了处理特定场景的替代方法。

在本示例中，假设你的 ClusterQueue 名为 my-cq。

理解 `kubectl delete clusterqueue`

当你运行以下命令时：

kubectl delete clusterqueue my-cq

你正在启动删除 ClusterQueue 对象的操作。但是，如果仍有 Workload 在使用该 ClusterQueue，命令可能会挂起或需要一些时间才能完成。

为什么会发生这种情况？

Kueue 为每个 Job 创建一个 Workload 对象来跟踪其准入状态。如果 Workload 被准入，它会与特定的 ClusterQueue 关联。 Kueue 使用名为 kueue.x-k8s.io/resource-in-use 的 finalizer 来防止在资源仍在使用时删除 ClusterQueue。因此，具有此 finalizer 的 ClusterQueue 在释放所有资源之前无法被删除。

运行 CronJob

Tue, 12 Dec 2023 00:00:00 +0000

本页面展示了如何在 Kubernetes 集群中运行带有 Kueue 的 CronJob。

本页面的受众是批处理用户。

开始之前

请确保满足以下条件：

已运行 Kubernetes 集群。
kubectl 命令行工具已与你的集群建立通信。
Kueue 安装文档。
集群已配置配额。

0. 识别你命名空间中的可用队列

运行以下命令以列出你命名空间中的 LocalQueues。

使用就绪态 Pod 配置全有或全无调度

Mon, 14 Mar 2022 00:00:00 +0000

有些作业需要所有 Pod 同时运行才能工作；例如，同步的分布式训练或基于 MPI 的作业需要 Pod 间通信。在默认的 Kueue 配置下，如果可用的物理资源与 Kueue 中配置的配额不匹配，这类作业可能会死锁。而如果这些作业的 Pod 能够顺序调度，则可以顺利完成。

为了解决这一需求，从 0.3.0 版本开始，我们引入了一个可选机制，通过 waitForPodsReady 标志进行配置，提供了全有或全无调度的简单实现。启用后，Kueue 会监控工作负载，直到其所有 Pod 就绪（即已调度、运行并通过可选的就绪态检测）。如果在配置的超时时间内工作负载对应的所有 Pod 并未完全就绪，则该工作负载会被驱逐并重新排队。

本页面向你展示如何配置 Kueue 使用 waitForPodsReady，这是全有或全无调度的简单实现。本页面面向批处理管理员。

开始之前

请确保满足以下条件：

Kubernetes 集群已运行。
kubectl 命令行工具已能与你的集群通信。
已安装 Kueue，版本为 0.3.0 或更高。

启用 waitForPodsReady

请按照此处的说明，使用如下字段扩展配置来安装某个发布版本：

工作负载(Workload)

Mon, 14 Feb 2022 00:00:00 +0000

工作负载(Workload) 是将运行至完成的应用程序。它可以由一个或多个 Pod 组成，这些 Pod 松散或紧密耦合，作为一个整体完成任务。工作负载是 Kueue 中的准入(admission)单位。

典型的工作负载可以用 Kubernetes batch/v1.Job 来表示。因此，我们有时使用_作业(job)_一词来指代任何工作负载，而 Job 则专门指 Kubernetes API。

但是，Kueue 不直接操作 Job 对象。相反，Kueue 管理代表任意工作负载资源需求的 Workload 对象。Kueue 自动为每个 Job 对象创建一个 Workload，并同步决策和状态。

Workload 的清单如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: Workload
metadata:
  name: sample-job
  namespace: team-a
spec:
  active: true
  queueName: team-a-queue
  podSets:
  - count: 3
    name: main
    template:
      spec:
        containers:
        - name: container
          image: registry.k8s.io/e2e-test-images/agnhost:latest
          args: ["pause"]
          imagePullPolicy: Always
          resources:
            requests:
              cpu: "1"
              memory: 200Mi
        restartPolicy: Never

活跃状态

您可以通过设置 Active 字段来停止或恢复正在运行的工作负载。active 字段决定工作负载是否可以被准入到队列中或继续运行（如果已经被准入）。将 .spec.Active 从 true 更改为 false 将导致正在运行的工作负载被驱逐且不会重新排队。

Topology

Thu, 29 Jan 2026 00:00:00 +0000

Topology 是一个集群范围的对象，定义了数据中心内节点的层次结构。它通过提供一种使用节点标签表示组织单元（如区域、块和机架）层次结构的模型，启用了拓扑感知调度。

Topology 对象通过 ResourceFlavor 中的 .spec.topologyName 字段引用，以将规约与特定的拓扑结构关联。

Topology 定义如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: Topology
metadata:
  name: "default"
spec:
  levels:
  - nodeLabel: "topology.kubernetes.io/zone"
  - nodeLabel: "cloud.provider.com/topology-block"
  - nodeLabel: "cloud.provider.com/topology-rack"
  - nodeLabel: "kubernetes.io/hostname"

Topology 层级

.spec.levels 字段定义了拓扑层级的层次结构，从最高（最粗略）级别到最低（最细致）级别排序。每个层级由一个节点标签标识，你的集群中的节点必须拥有这个标签。

例如，在典型的数据中心中：

区域层级：区域或可用区，由类似 topology.kubernetes.io/zone 的标签标识
块层级：机架组，由类似 cloud.provider.com/topology-block 的标签标识
机架层级：块内的单独机架，由类似 cloud.provider.com/topology-rack 的标签标识
节点层级：单独节点，通常由 kubernetes.io/hostname 标识

在同一拓扑域（例如，相同的机架）内运行的 Pod 相比不同域的 Pod 具有更好的网络带宽。

使用 HAMi

Mon, 15 Dec 2025 00:00:00 +0000

此页面演示了如何将 Kueue 与 HAMi（异构 AI 计算虚拟化中间件）结合使用，以进行 vGPU 资源管理的工作负载运行。

当通过 HAMi 使用 vGPU 资源时，Pod 会请求每个 vGPU 的资源（nvidia.com/gpumem、nvidia.com/gpucores）以及 vGPU 的数量（nvidia.com/gpu）。对于配额管理，你需要跟踪所有 vGPU 实例的总资源消耗。

下面我们将演示如何在 Kueue 中使用用于配额管理的资源转换来支持这一点。

本指南适用于对 Kueue 有基本了解的批处理用户。有关更多信息，请参阅 Kueue 概述。

在你开始之前

Deployment 集成默认启用。
请按照使用自定义配置的安装说明配置带有 ResourceTransformation 的 Kueue。
确保你的集群已安装 HAMi 并拥有可用的 vGPU 资源。 HAMi 通过诸如 nvidia.com/gpu、nvidia.com/gpucores 和 nvidia.com/gpumem 等资源提供 vGPU 资源管理。

运行 RayService

Mon, 30 Jun 2025 00:00:00 +0000

本页演示如何利用 Kueue 的调度与资源管理能力运行 RayService 。

在v0.17.0之前，Kueue 通过为 RayService 创建的 RayCluster 来管理 RayService。从v0.17.0开始，Kueue 可以直接管理 RayService，类似其直接管理 RayJob，不再通过 RayCluster。

本指南面向对 Kueue 有基本了解的、对外提供服务的用户。更多信息，请参见 Kueue 概览。

开始之前

请确保你使用的是 Kueue v0.6.0 版本或更高版本，以及 KubeRay v1.3.0 或更高版本。
请参见管理集群配额了解初始 Kueue 设置的详细信息。
请参见 KubeRay 安装说明了解 KubeRay 的安装和配置详情。

注意

RayService 通过 RayCluster 由 Kueue 管理；在 v0.17.0 之前，你需要在完成安装后重启 Kueue 才能使用 RayCluster。你可以通过运行 kubectl delete pods -l control-plane=controller-manager -n kueue-system 来完成此操作。

RayService 定义

在 Kueue 上运行 RayService 时，请考虑以下方面：

公平共享（Fair Sharing）

Wed, 28 May 2025 00:00:00 +0000

准入公平共享

一种根据源 LocalQueue 的历史资源使用情况对工作负载进行排序的机制，优先考虑那些随着时间的推移消耗较少资源的工作负载。

基于抢占的公平共享

准入公平分共享（Admission Fair Sharing）

Wed, 28 May 2025 00:00:00 +0000

Feature state alpha since Kueue v0.12

注意

AdmissionFairSharing 目前是一个 Alpha 特性，默认未启用。

您可以通过编辑 AdmissionFairSharing 特性门控来启用它。有关特性门控配置的详细信息，请查阅安装指南。

准入公平共享有助于在多个指向同一 ClusterQueue 的 LocalQueue 之间公平分配资源。它会根据各自 LocalQueue 的历史资源使用情况对工作负载进行排序，优先考虑那些随着时间推移消耗资源较少的工作负载。

工作原理

当多个工作负载在同一个 ClusterQueue 中竞争资源时：

运行 JAXJob

Wed, 23 Apr 2025 00:00:00 +0000

此页面展示了在运行 Trainer JAXJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅 Kueue 概述。

开始之前

检查管理集群配额，以获取有关初始集群设置的详细信息。

查阅 Trainer 安装指南。

请注意，Trainer 的最低要求版本是 v1.9.0。

你可以修改已安装版本的 Kueue 配置，以将 JAXJob 添加到允许的工作负载中。

Note

为了使用 Trainer，在 v0.8.1 之前，你需要在安装后重启 Kueue。你可以通过运行以下命令来实现：kubectl delete pods -l control-plane=controller-manager -n kueue-system。

JAXJob 定义

a. 队列选择

目标本地队列应当在 JAXJob 配置的 metadata.labels 部分中指定。

运行 LeaderWorkerSet

Mon, 17 Feb 2025 00:00:00 +0000

本页面展示了如何通过运行 LeaderWorkerSet 来利用 Kueue 的调度和资源管理能力。

我们演示了如何支持调度 LeaderWorkerSet，其中一组 Pod 构成由工作负载所表示的准入单元。这允许逐组扩大和缩小 LeaderWorkerSet。

此集成基于普通的 Pod 组集成。

本指南适用于对 Kueue 有基本了解的服务用户。有关更多信息，请参见 Kueue 概述。

开始之前

leaderworkerset.x-k8s.io/leaderworkerset 集成默认启用。
对于 Kueue v0.15 及更早版本，学习如何安装 Kueue 并使用自定义管理器配置，并确保你已启用 leaderworkerset.x-k8s.io/leaderworkerset 集成，例如：
```
apiVersion: config.kueue.x-k8s.io/v1beta2
kind: Configuration
integrations:
  frameworks:
   - "leaderworkerset.x-k8s.io/leaderworkerset"
```
Pod 集成要求

自 Kueue v0.15 起，你不需要显式启用 "pod" 集成即可使用 "leaderworkerset.x-k8s.io/leaderworkerset" 集成。

运行 AppWrapper

Wed, 08 Jan 2025 00:00:00 +0000

本页面展示了在运行 AppWrapper 时，如何利用 Kueue 的调度和资源管理能力。

AppWrapper 提供了一种灵活且与工作负载无关的机制，使 Kueue 能够将一组 Kubernetes 资源作为一个单一的逻辑单元进行管理，而无需这些资源的控制器具备任何 Kueue 特定的支持。

AppWrapper 旨在通过提供额外的自动故障检测和恢复机制来增强工作负载的健壮性。 AppWrapper 控制器会监控工作负载的健康状况，如果主要资源控制器在指定的截止时间内未采取纠正措施，AppWrapper 控制器将协调工作负载级别的重试和资源删除，以确保工作负载要么恢复到健康状态，要么被干净地从集群中移除，并释放其配额供其他工作负载使用。

本指南适用于对 Kueue 有基本了解的批用户。更多信息请参见 Kueue 概述。

开始之前

请查阅管理集群配额以了解 Kueue 的初始设置详情。

为简化设置，请确保你使用的是 Kueue v0.11.0 和 AppWrapper v1.1.1 及以上版本。

有关 AppWrapper Operator 的安装和配置详情，请参见 AppWrapper 快速入门指南。

AppWrapper 定义

在 Kueue 上运行 AppWrapper 时，请注意以下方面：

运行 RayCluster

Wed, 07 Aug 2024 00:00:00 +0000

本页面展示了如何利用 Kueue 的调度和服务管理能力来运行 RayCluster。

本指南适用于批处理用户，他们需要对 Kueue 有基本的了解。更多信息，请参见 Kueue 概述。

开始之前

请确保你使用的是 Kueue v0.6.0 版本或更高版本，以及 KubeRay v1.1.0 或更高版本。
请参见 Administer cluster quotas 了解初始 Kueue 设置的详细信息。
请参见 KubeRay Installation 了解 KubeRay 的安装和配置详情。

注意

在 v0.8.1 之前，你需要重启 Kueue 才能使用 RayCluster。你可以通过运行 kubectl delete pods -l control-plane=controller-manager -n kueue-system 来完成此操作。

RayCluster 定义

当在 Kueue 上运行 RayClusters时，请考虑以下方面：

运行 RayJob

Wed, 07 Aug 2024 00:00:00 +0000

本页面展示了如何利用 Kueue 的调度和服务管理能力来运行 KubeRay 的 RayJob。

本指南适用于批处理用户，他们基本了解 Kueue。更多信息，请参见 Kueue 概览。

开始之前

请确保你使用 Kueue v0.6.0 版本或更高版本，以及 KubeRay v1.1.0 或更高版本。
请参见管理集群配额了解初始 Kueue 设置的详细信息。
请参见 KubeRay 安装文档了解 KubeRay 的安装和配置详情。

注意

在 v0.8.1 之前，你需要重启 Kueue 才能使用 RayJob。你可以通过运行 kubectl delete pods -l control-plane=controller-manager -n kueue-system 来完成此操作。

RayJob 定义

当运行 RayJobs时，请考虑以下方面：

运行 Deployment

Thu, 25 Jul 2024 00:00:00 +0000

本页面展示了在运行 Deployment 时如何利用 Kueue 的调度和资源管理能力。虽然 Kueue 尚不支持将 Deployment 作为单个工作负载进行管理，但仍然可以利用 Kueue 的调度和资源管理能力来管理 Deployment 中的各个 Pod。

我们演示了如何基于 Plain Pod 集成在 Kueue 中支持调度 Deployment，其中 Deployment 中的每个 Pod 都被表示为一个独立的 Plain Pod。这种方法允许对 Pod 进行独立的资源管理，从而实现 Deployment 的扩容和缩容。

本指南适用于对 Kueue 有基本了解的服务用户。更多信息，请参见 Kueue 概述。

开始之前

deployment 集成默认启用。

运行 StatefulSet

Thu, 25 Jul 2024 00:00:00 +0000

本页面展示了如何利用 Kueue 的调度和服务资源管理能力来运行 StatefulSet。

我们演示了如何支持基于 Plain Pod Group 集成来调度 StatefulSet，其中 StatefulSet 被表示为一个独立的负载。

本指南适用于服务用户他们具有基本的 Kueue 理解。更多信息，请参见 Kueue 概览。

开始之前

默认情况下已启用 statefulset 集成。
对于 Kueue v0.15 及更早版本，学习如何安装 Kueue 并配置自定义管理器版本，并确保你启用了 v1/statefulset 集成，例如：
```
apiVersion: config.kueue.x-k8s.io/v1beta2
kind: Configuration
integrations:
  frameworks:
   - "pod" # required by statefulset
   - "statefulset"
```
同时，请参见运行 Plain Pod 了解如何启用和配置 pod 集成。

拓扑感知调度

Thu, 11 Apr 2024 00:00:00 +0000

Feature state alpha since Kueue v0.9

AI/ML 工作负载通常需要大量的 Pod 间通信。因此，运行 Pod 之间的网络带宽会直接影响工作负载的执行时间和运行成本。 Pod 之间的可用带宽取决于运行这些 Pod 的节点在数据中心中的分布。

我们观察到，数据中心的组织单元具有层次结构，如机架（rack）和区块（block），一个机架内有多个节点，一个区块内有多个机架。运行在同一组织单元内的 Pod 之间的网络带宽优于运行在不同单元的 Pod。我们认为，不同机架上的节点比同一机架内的节点距离更远。同理，不同区块的节点比同一区块内的节点距离更远。

本特性（称为拓扑感知调度，简称 TAS）引入了一种约定，用于表示分层节点拓扑信息，并为 Kueue 管理员和用户提供一组 API，以利用这些信息优化 Pod 的放置。

节点拓扑信息

我们提出了一种轻量级模型，通过节点标签来表示数据中心内节点的层次结构。在该模型中，节点标签由云服务商设置，或由本地集群管理员手动设置。

此外，我们假设用于 TAS 的每个节点都带有一组标签，这些标签能唯一标识其在树状结构中的位置。我们不要求每一层标签全局唯一，即可能存在两个节点具有相同的 “rack” 标签，但位于不同的 “block”。

例如，数据中心层次结构的表示如下：

节点	cloud.provider.com/topology-block	cloud.provider.com/topology-rack
node-1	block-1	rack-1
node-2	block-1	rack-2
node-3	block-2	rack-1
node-4	block-2	rack-3

注意，node-1 和 node-3 虽然 “cloud.provider.com/topology-rack” 标签值相同，但位于不同的 block。

Workload 优先级类

Mon, 02 Oct 2023 00:00:00 +0000

WorkloadPriorityClass 允许你控制 Workload 的优先级，而不会影响 Pod 的优先级。此功能适用于以下场景：

希望优先调度那些长时间处于非活跃状态的工作负载
希望为开发环境工作负载设置较低优先级，为生产环境工作负载设置较高优先级

一个示例 WorkloadPriorityClass 如下所示：

apiVersion: kueue.x-k8s.io/v1beta2
kind: WorkloadPriorityClass
metadata:
  name: sample-priority
value: 10000
description: "示例优先级"

WorkloadPriorityClass 对象是集群范围的，因此可以被任何命名空间下的作业使用。

如何在 Job 上使用 WorkloadPriorityClass

你可以通过设置标签 kueue.x-k8s.io/priority-class 来指定 WorkloadPriorityClass。

apiVersion: batch/v1
kind: Job
metadata:
  name: sample-job
  labels:
    kueue.x-k8s.io/queue-name: user-queue
    kueue.x-k8s.io/priority-class: sample-priority
spec:
...

Kueue 会为上述 Job 生成如下 Workload。 PriorityClassName 字段可以接受 PriorityClass 或 WorkloadPriorityClass 的名称。为区分两者，当使用 WorkloadPriorityClass 时，priorityClassSource 字段为 kueue.x-k8s.io/workloadpriorityclass；当使用 PriorityClass 时，priorityClassSource 字段为 scheduling.k8s.io/priorityclass。

运行普通 Pod

Wed, 27 Sep 2023 00:00:00 +0000

本页面展示了如何在运行普通 Pod 时利用 Kueue 的调度和资源管理功能。 Kueue 支持管理单个 Pod 或一组 Pod。

本指南适用于对 Kueue 有基本了解的批处理用户。更多信息请参见 Kueue 概述。

开始之前

pod 集成默认启用。
对于 Kueue v0.15 及更早版本，学习如何使用自定义管理器配置安装 Kueue 并启用 pod 集成。

为了允许 Kubernetes 系统 Pod 成功调度，您必须限制 pod 集成的范围。推荐的机制是使用 managedJobsNamespaceSelector。

一种方法是仅对特定命名空间启用管理：
```
apiVersion: config.kueue.x-k8s.io/v1beta2
kind: Configuration
managedJobsNamespaceSelector:
  matchLabels:
   kueue-managed: "true"
integrations:
  frameworks:
   - "pod"
```
另一种方法是免除系统命名空间的管理：

运行 PaddleJob

Fri, 22 Sep 2023 00:00:00 +0000

此页面展示了在运行 Trainer PaddleJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅 Kueue 概述。

开始之前

查阅管理集群配额，以获取初始集群设置的详细信息。

查阅 Trainer 安装指南。

请注意，Trainer 最低版本要求为 v1.7.0。

你可以修改已安装版本的 Kueue 配置，以添加 PaddleJob 到允许的工作负载中。

注意

要使用 Trainer，在 v0.8.1 之前，你需要在安装后重启 Kueue。你可以通过运行以下命令来实现：kubectl delete pods -l control-plane=controller-manager -n kueue-system。

PaddleJob 定义

a. 队列选择

目标本地队列应在 PaddleJob 配置的 metadata.labels 部分中指定。

运行 XGBoostJob

Thu, 14 Sep 2023 00:00:00 +0000

此页面展示了在运行 Trainer XGBoostJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅 Kueue 概述。

开始之前

请查看管理集群配额，以了解初始集群设置的详细信息。

查阅 Trainer 安装指南。

请注意，Trainer 的最低要求版本是 v1.7.0。

你可以修改已安装版本的 Kueue 配置，以包含 XGBoostJobs 作为允许的工作负载。

Note

要 v0.8.1 版本之前使用 Trainer，你需要在安装后重启 Kueue。你可以通过运行以下命令来实现：kubectl delete pods -l control-plane=controller-manager -n kueue-system。

XGBoostJob 定义

a. 队列选择

目标本地队列应在 XGBoostJob 配置的 metadata.labels 部分中指定。

运行 TFJob

Wed, 23 Aug 2023 00:00:00 +0000

此页面展示了在运行 Trainer TFJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅 Kueue 概述。

开始之前

请查看管理集群配额，以获取初始集群设置的详细信息。

请查阅 Trainer 安装指南。

请注意，Trainer 的最低要求版本是 v1.7.0。

你可以修改已安装版本的 Kueue 配置，以将 TFJob 添加到允许的工作负载中。

注意

TFJob 定义

a. 队列选择

目标本地队列应当在 TFJob 配置的 metadata.labels 部分指定。

运行 PyTorchJob

Wed, 09 Aug 2023 00:00:00 +0000

本页面展示了在运行 Trainer PyTorchJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多详情，请参见 Kueue 概述。

开始之前

查阅管理集群配额，了解初始集群设置的详细信息。

查阅 Trainer 安装指南。

请注意，Trainer 的最低版本要求是 v1.7.0。

你可以修改已安装版本的 Kueue 配置，以将 PyTorchJob 包括为允许的工作负载。

注意

PyTorchJob 定义

a. 队列选择

目标本地队列应当在 PyTorchJob 配置的 metadata.labels 部分指定。

运行 MPIJob

Tue, 16 May 2023 00:00:00 +0000

本页面展示了在运行 MPI Operator MPIJob 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。更多信息，请参阅 Kueue 概述。

开始之前

查阅管理集群配额，以获取初始集群设置的详细信息。

查阅 MPI Operator 安装指南。

Note

MPI Operator 的最低版本要求为 v0.8.0。

你可以修改已安装版本的 Kueue 配置，以将 MPIJob 添加到允许的工作负载中。

Note

要在 v0.8.1 版本之前使用 Trainer，你需要在安装后重启 Kueue。你可以通过运行以下命令来实现：kubectl delete pods -l control-plane=controller-manager -n kueue-system。

Note

在同时使用 MPI Operator 和 Trainer 时，需要禁用 Trainer 的 MPIJob 选项。需要修改 Trainer 部署，以启用除 MPIJob 之外的所有 Kubeflow 作业，如此处所述。

MPI Operator 定义

a. 队列选择

目标本地队列应在 MPIJob 配置的 metadata.labels 部分中指定。

运行 SparkApplication

Mon, 17 Nov 2025 00:00:00 +0000

Feature state alpha since Kueue v0.17

Note

SparkApplicationIntegration 目前仍处于 Alpha 测试阶段，默认情况下处于禁用状态。

你可以通过编辑 SparkApplicationIntegration 特性门控来启用它。有关特性门控配置的详细信息，请参阅安装指南。

此页面展示了在运行 Spark Operator SparkApplication 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多信息，请参阅 Kueue 概述。

在你开始之前

检查管理集群配额，以获取初始集群设置的详细信息。

查阅 Spark Operator 安装指南。

你可以修改已安装版本的 Kueue 配置，以将 SparkApplication 纳入支持的工作负载中。

注意

要使用 SparkApplication 集成，必须安装 Spark Operator v2.4.0 或以上版本。

运行 Tekton Pipeline

Sat, 01 Feb 2025 00:00:00 +0000

此页面展示了在运行 Tekton Pipeline 时，如何利用 Kueue 的调度和资源管理能力。

本指南适用于对 Kueue 有基本了解的批处理用户。欲了解更多，请参阅 Kueue 概述。

我们将演示如何基于 Plain Pod 集成，在 Kueue 中支持 Tekton Pipeline 任务的调度，其中来自 Pipeline 的每个 Pod 都表现为单个独立的 Plain Pod。

开始之前

学习如何安装具有自定义管理器配置的 Kueue。
按照运行 Plain Pod 中的步骤学习如何启用和配置 pod 集成。
查看管理员集群配额以获取初始 Kueue 步骤的详细信息。
确保你的集群已安装 Tekton Pipeline：安装指南。

Tekton 背景

Tekton 有 Pipeline、 Task 和 PipelineRun 的概念。

抢占（Preemption）

Tue, 28 May 2024 00:00:00 +0000

在抢占过程中，以下术语相关：

被抢占者（Preemptees）：被抢占的 Workload。
目标 ClusterQueue：被抢占者所属的 ClusterQueue。
抢占者（Preemptor）：需要被容纳的 Workload。
抢占 ClusterQueue：抢占者所属的 ClusterQueue。

抢占的原因

如果 Workload 被准入到启用了抢占的 ClusterQueue，并且发生以下任一事件，则该 Workload 可以抢占一个或多个 Workload：

被抢占者与抢占者属于同一个 ClusterQueue，且被抢占者的优先级较低。
被抢占者与抢占者属于同一个 cohort，且被抢占者的 ClusterQueue 至少有一种资源的使用量高于名义配额，而该资源是被抢占者和抢占者都需要的。

在 Kueue 配置和 ClusterQueue 中配置的抢占设置，除了上述标准外，还可以限制 Workload 是否可以抢占其他 Workload。

当抢占 Workload 时，Kueue 会在被抢占 Workload 的 .status.conditions 字段中添加类似如下的条目：

status:
  - lastTransitionTime: "2025-03-07T21:19:54Z"
    message: '为容纳另一个 workload（UID: 5c023c28-8533-4927-b266-56bca5e310c1，JobUID: 4548c8bd-c399-4027-bb02-6114f3a8cdeb）而被抢占，原因是 ClusterQueue 中的优先级调整'
    observedGeneration: 1
    reason: Preempted
    status: "True"
    type: Evicted
  - lastTransitionTime: "2025-03-07T21:19:54Z"
    message: '为容纳另一个 workload（UID: 5c023c28-8533-4927-b266-56bca5e310c1，JobUID: 4548c8bd-c399-4027-bb02-6114f3a8cdeb）而被抢占，原因是 ClusterQueue 中的优先级调整'
    reason: InClusterQueue
    status: "True"
    type: Preempted

Evicted 条件表示该 Workload 因 Preempted 原因被驱逐，而 Preempted 条件则给出了更多关于抢占原因的细节。

运行 JobSet

Fri, 16 Jun 2023 00:00:00 +0000

本指南解释了如何使用 Kueue 的调度和资源管理功能运行 JobSet Operator JobSet。

本指南适用于批处理用户，他们需要对 Kueue 有基本的了解。更多信息，请参见 Kueue 概览。

开始之前

请参见管理集群配额了解初始 Kueue 设置的详细信息。
请参见 JobSet 安装文档了解 JobSet Operator 的安装和配置详情。

注意

在 v0.8.1 之前，为了使用 JobSet，你需要重启 Kueue。你可以通过运行 kubectl delete pods -l control-plane=controller-manager -n kueue-system 来完成此操作。

JobSet 定义

当在 Kueue 上运行 JobSet时，请考虑以下方面：

外部框架

Fri, 17 Jan 2025 00:00:00 +0000

参见外部框架以查看使用现有集成来集成外部框架的示例。

MultiKueue

Mon, 11 Nov 2024 00:00:00 +0000

Feature state beta since Kueue v0.9

Note

MultiKueue 目前是一个 Beta 特性，默认启用。

你可以通过编辑 MultiKueue 特性门控来禁用它。关于特性门控配置的详情，请参阅安装指南。

MultiKueue 设置由一个管理集群和至少一个工作集群组成。

集群角色

管理集群

管理者的首要职责包括：

将自定义 Job 与 Kueue 集成

Tue, 25 Jul 2023 00:00:00 +0000

Kueue 为多种 Job 类型提供了内置集成，包括 Kubernetes batch Job、MPIJob、RayJob 和 JobSet。

使用 Kueue 管理缺乏内置集成的类 Job CRD 有三种选择：

通过将自定义 Job 实例包装在 AppWrapper 中来利用内置的 AppWrapper 集成。详情请参阅运行包装的自定义工作负载。
作为 Kueue 仓库的一部分构建新的集成。
作为外部控制器构建新的集成。

本指南面向平台开发者，描述如何构建新的集成。集成应该使用 Kueue 的 jobframework 包提供的 API 来构建。这既会简化开发，也会确保如果你的 Job 类型被社区广泛使用，你的控制器将被正确构造以成为核心内置集成。

需求概览

Kueue 使用 controller-runtime。我们建议在开始构建 Kueue 集成之前，先熟悉它和 Kubebuilder。

开发 AdmissionCheck 控制器

Tue, 03 Sep 2024 00:00:00 +0000

准入检查控制器，以下简称 ACC，是管理与其关联的准入检查（由 spec.controllerName 对应值指定）及针对配置了这些准入检查的 ClusterQueues 排队的工作负载的组件。

阅读准入检查以从用户角度了解更多机制。

子组件

ACC 可以内置在 Kueue 中或运行在不同的 Kubernetes 控制器管理器中，并且应当实现对准入检查和工作负载的协调器。

AdmissionCheck 协调器

监控集群中的准入检查，并维护与其关联（通过 spec.controllerName）的准入检查的 Active 状态。

设置 MultiKueue 环境

Mon, 26 Feb 2024 00:00:00 +0000

本教程解释了如何在 MultiKueue 环境中配置管理集群和一个工作集群来运行 JobSets 和 batch/Jobs。

请查看概念部分了解 MultiKueue 概述。

假设您的管理集群名为 manager-cluster，工作集群名为 worker1-cluster。要遵循本教程，请确保所有这些集群的凭据都存在于您本地机器的 kubeconfig 中。查看 kubectl 文档了解更多关于如何配置多集群访问的信息。

在工作集群中

注意

确保您当前的 kubectl 配置指向工作集群。

运行：

kubectl config use-context worker1-cluster

当 MultiKueue 将工作负载从管理集群分发到工作集群时，它期望作业的命名空间和 LocalQueue 也存在于工作集群中。换句话说，您应该确保工作集群配置在命名空间和 LocalQueues 方面与管理集群的配置保持一致。

要在 default 命名空间中创建示例队列设置，您可以应用以下清单：

apiVersion: kueue.x-k8s.io/v1beta2
kind: ResourceFlavor
metadata:
  name: "default-flavor"
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: ClusterQueue
metadata:
  name: "cluster-queue"
spec:
  namespaceSelector: {} # match all.
  resourceGroups:
  - coveredResources: ["cpu", "memory"]
    flavors:
    - name: "default-flavor"
      resources:
      - name: "cpu"
        nominalQuota: 9
      - name: "memory"
        nominalQuota: 36Gi
---
apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  namespace: "default"
  name: "user-queue"
spec:
  clusterQueue: "cluster-queue"

MultiKueue 专用 kubeconfig

为了在工作集群中委托 Job，管理集群需要能够创建、删除和监视工作负载及其父 Job。

在多集群中运行 LeaderWorkerSet

Fri, 16 Jan 2026 00:00:00 +0000

在你开始之前

查阅 MultiKueue 安装指南以了解如何正确设置 MultiKueue 集群。

工作原理

LeaderWorkerSet 每个副本创建一个 Workload，这在 MultiKueue 中需要特殊处理。

来自 LeaderWorkerSet 的所有 Workload 会被原子性地分配到同一个工作集群：

设置默认的 LocalQueue

Thu, 12 Dec 2024 00:00:00 +0000

Feature state stable since Kueue v0.17

此页面描述了如何设置默认 LocalQueue，以确保所有提交到特定命名空间的工作负载由 Kueue 管理，即使未明确指定 kueue.x-k8s.io/queue-name 标签。

设置默认 LocalQueue

LocalQueueDefaulting 是一个特性，允许使用一个名为 default 的 LocalQueue 作为同命名空间下没有 kueue.x-k8s.io/queue-name 标签的工作负载的默认 LocalQueue。

要使用此特性：

在命名空间中创建一个名称为 default 的 LocalQueue。

就是这样！现在，为了测试此特性，在同一命名空间中创建一个 Job。观察到 Job 被更新为带有 kueue.x-k8s.io/queue-name: default 标签。

请注意，在不同命名空间中创建的工作负载或已经具有 kueue.x-k8s.io/queue-name 标签的工作负载不会被修改。

Pending Workloads on-demand

Mon, 30 Sep 2024 00:00:00 +0000

This page shows you how to monitor pending workloads with VisibilityOnDemand feature.

The intended audience for this page are batch administrators for Cluster Queue visibility section, and batch users for Local Queue Visibility section.

From version v0.6.0, Kueue provides the ability for a batch administrators to monitor the pipeline of pending jobs, and help users to estimate when their jobs will start.

Before you begin

Make sure the following conditions are met:

设置 manageJobsWithoutQueueName

Fri, 28 Jun 2024 00:00:00 +0000

本页面描述了如何配置 Kueue，以确保所有在命名空间中提交的、旨在供批处理用户使用的 Workload 都将由 Kueue 管理，即使它们缺少 kueue.x-k8s.io/queue-name 标签。

在你开始之前

学习如何安装带有自定义管理器配置的 Kueue。

配置

你需要修改管理配置，将 manageJobsWithoutQueueName 设置为 true。

制定 Job 准入策略

Fri, 28 Jun 2024 00:00:00 +0000

此页面展示了如何使用 Kubernetes 验证准入策略，基于通用表达语言（CEL）为 Kueue 设置 Job 准入策略。

开始之前

确保满足以下条件：

一个 Kubernetes 集群正在运行。
已启用 ValidatingAdmissionPolicy 特性门控。在 Kubernetes 1.30 或更新版本中，默认启用该特性门控。
kubectl 命令行工具能够与你的集群通信。
Kueue 已安装。

示例

下面的例子展示了如何设置 Job 准入策略，以拒绝所有未包含 queue-name 且发送到标记为 kueue-managed 命名空间的 Job 或 JobSets。

特性门控（已移除）

Mon, 01 Jan 0001 00:00:00 +0000

此页面包含已被移除的特性门控列表，其中信息供参考使用。被移除的特性门控与已 GA 或已弃用的特性门控不同，因为被移除的特性门控不再被视为有效的特性门控。然而，已 GA 或已弃用的特性门控仍然被相应的 Kueue 组件识别，尽管它们无法在集群中引起任何行为差异。

对于仍被 Kueue 组件识别的特性门控，请参阅 Alpha/Beta 特性门控表或 Graduated/Deprecated 特性门控表。

已移除的特性门控

在以下表格中：

“From” 列包含了特性引入或其发布阶段更改时的 Kueue 版本。
“To” 列（如果不为空）包含了你仍然可以使用一个特性门控的最后一个 Kueue 版本。如果特性阶段为 “Deprecated” 或 “GA”，“To” 列是特性被移除时的 Kueue 版本。

Feature	Default	Stage	From	To
`AdmissionCheckValidationRules`	`false`	Deprecated	0.9	0.12
`KeepQuotaForProvReqRetry`	`false`	Deprecated	0.9	0.12
`MultiplePreemptions`	`false`	Alpha	0.8	0.8
`MultiplePreemptions`	`true`	Beta	0.9	0.9
`MultiplePreemptions`	`true`	GA	0.10	0.13
`WorkloadResourceRequestsSummary`	`false`	Alpha	0.9	0.10
`WorkloadResourceRequestsSummary`	`true`	Beta	0.10	0.11
`WorkloadResourceRequestsSummary`	`true`	GA	0.11	0.13
`QueueVisibility`	`false`	Alpha	0.5	0.9
`QueueVisibility`	`false`	Deprecated	0.9	0.14
`ManagedJobsNamespaceSelector`	`true`	Beta	0.10	0.13
`ManagedJobsNamespaceSelector`	`true`	GA	0.13	0.15
`ProvisioningACC`	`false`	Alpha	0.5	0.6
`ProvisioningACC`	`true`	Beta	0.7	0.14
`ProvisioningACC`	`true`	GA	0.14	0.15
`ExposeFlavorsInLocalQueue`	`false`	Beta	0.9	0.15
`ExposeFlavorsInLocalQueue`	`false`	Deprecated	0.15	0.15
`ConfigurableResourceTransformations`	`false`	Alpha	0.9	0.9
`ConfigurableResourceTransformations`	`true`	Beta	0.10	0.13
`ConfigurableResourceTransformations`	`true`	GA	0.14	0.16
`FlavorFungibilityImplicitPreferenceDefault`	`false`	Alpha	0.13	0.15
`FlavorFungibilityImplicitPreferenceDefault`	`false`	Deprecated	0.15	0.16
`TASProfileLeastFreeCapacity`	`false`	Alpha	0.10	0.10
`TASProfileLeastFreeCapacity`	`false`	Deprecated	0.11	0.16

设置 Workload 的垃圾回收

Fri, 16 May 2025 00:00:00 +0000

本指南演示如何在 Kueue 中启用并配置可选的对象保留策略，以在指定时间后自动删除已完成或已停用的 Workload。默认情况下，Kueue 会在集群中永久保留所有 Workload 对象；通过对象保留策略，可以释放 etcd 存储并降低 Kueue 的内存占用。

前置条件

可正常运行的 Kueue v0.12 或更高版本。

设置保留策略

按照此处描述的说明安装自定义配置的发布版本，并通过添加以下字段扩展配置：

启用 Dashboard（KueueViz）

Fri, 18 Jul 2025 00:00:00 +0000

注意

为了简化安装和升级过程，我们建议使用 Helm 部署 Kueue。
你可以使用本地 values.yaml 文件来自定义部署以适应你的环境。
有关完整说明，请参阅 Helm chart 安装指南。

KueueViz 是一个基于 Web 的可视化工具，提供对 Kueue 工作负载、队列和资源分配的实时监控。它提供了直观的 Dashboard，用于观察作业队列状态、资源利用率和工作负载进展。

本页面展示如何在你的集群中安装和配置 KueueViz。

本页面的目标读者是批处理管理员。

开始之前

请确保满足以下条件：

Kubernetes 集群正在运行
kubectl 命令行工具可以与你的集群通信
已安装 Helm 命令行工具
你的集群中已安装 Kueue
（可选）用于外部访问的入口控制器（例如 Nginx Ingress Controller）

KueueViz 可以使用 Helm（推荐）或 kubectl 进行安装。选择最适合你工作流程的方法。

Grafana 中监控待处理的工作负载

Thu, 12 Jun 2025 00:00:00 +0000

本指南解释了如何使用 VisibilityOnDemand 特性在 Grafana 中监控待处理的工作负载。

本文的受众是批处理管理员，用于 ClusterQueue 可见性，以及批处理用户用于 LocalQueue 可见性。

开始之前

确保满足以下条件：

正在运行一个 Kubernetes 集群。
已安装 Kueue
已安装 Kube-prometheus operator 版本 v0.15.0 或更新版本。
已启用 VisibilityOnDemand 特性。

配置 Grafana 监控待处理工作负载

步骤 1：配置集群权限

为了启用可见性，为 ClusterQueue 或 LocalQueue 创建 ClusterRole 和 ClusterRoleBinding：

安装

Thu, 09 May 2024 00:00:00 +0000

通过 Krew 安装

kubectl krew install kueue

从发布的二进制文件安装

1. 下载最新版本：

在 Linux 上：

运行和调试测试

Mon, 01 Jan 0001 00:00:00 +0000

运行预提交验证测试

make verify

运行单元测试

运行所有单元测试：

make test

运行 Webhook 的单元测试：

go test ./pkg/webhooks

参考文档运行与 TestValidateClusterQueue 正则表达式匹配的测试：

go test ./pkg/webhooks -run TestValidateClusterQueue

使用竞态检测运行单元测试

使用 -race 启用 Go 内置的竞态检测器：

采用者

Mon, 01 Jan 0001 00:00:00 +0000

以下是在生产环境中使用了 Kueue 的各个组织列表及其使用的集成组件。如果你正在使用 Kueue，可以通过打开一个 PR 来添加你的组织到此列表。

采用者

组织	类型	描述	集成	联系
CyberAgent, Inc.	最终用户	企业内部 ML 平台	batch/job kubeflow.org/mpijob	@tenzen-y
DaoCloud, Inc.	最终用户	AI 平台的一部分，用于管理各类 Jobs。	batch/job RayJob …	@kerthcet
WattIQ, Inc.	最终用户	SaaS/IoT 产品	batch/job RayJob	@madsenwattiq
Horizon, Inc.	最终用户	AI 训练平台	batch/job …	@GhangZh
FAR AI	最终用户	AI 对齐研究非营利组织	batch/job	@rhaps0dy
Shopee, Inc.	最终用户	在 AI 平台测试环境中进行训练/batch 推理/数据处理	自定义 job RayJob …	@denkensk
Mondoo, Inc.	最终用户	为 Mondoo 的托管安全扫描器提供支持	batch/job	@jaym
Google Cloud	提供商	是用于在 TPU 上训练 ML 工作负载的套件的一部分	JobSet	@mrozacki
Onna Technologies, Inc	最终用户	非结构化数据管理平台	batch/job	@gitcarbs
IBM Research	最终用户	作为运行 AI/ML 工作负载的 MLBatch 栈的一部分	AppWrapper PyTorchJob RayJob	dgrove-oss
Innovatrics	最终用户	企业内部 ML 平台	batch/job pod	@mmolisch
Red Hat, Inc.	最终用户	云/企业内部 ML 平台	Ray Cluster RayJob Pytorch Job TensorFlow Job …	@varshaprasad96
Octue	最终用户	科学数据服务框架	batch/job	@cortadocodes
LY Corporation	最终用户	本地部署人工智能平台	batch/job TensorFlow Job Ray Cluster pod …	@everpeace
Preferred Networks, Inc.	最终用户	云端/本地部署机器学习平台	batch/job pod …	@wafrelka
Wayve	最终用户	作为 Wayve AI 驱动背后 AI 平台的一部分	RayJob pod	@mukund-wayve

Labels and Annotations

Thu, 19 Mar 2026 00:00:00 +0000

This page serves as a reference for all labels and annotations in Kueue.

kueue.x-k8s.io/admission-gated-by

Type: Annotation

Example: kueue.x-k8s.io/admission-gated-by: "example.com/mygate,example.com/mygate2"

Used on: Kueue-managed Jobs.

This annotation requires the AdmissionGatedBy feature that is disabled by default.

When it contains a value, the annotation prevents the Job from entering the Quota Reservation phase of Kueue’s Admission Flow. The annotation value is a comma-separated list of 1 or more gate names and can only be added during Job creation. After creation, the annotation may only be deleted or modified to remove 1 or more gates.

Prometheus 指标

Mon, 14 Feb 2022 00:00:00 +0000

Note

要启用指标抓取，请参阅设置 Prometheus。

Kueue 暴露了 prometheus 指标来监控系统的健康状况和 ClusterQueues 以及 LocalQueues 的状态。

Kueue 健康状态

使用以下指标来监控 kueue 控制器的健康状况：

指标名称	类型	描述	标签
`kueue_cohort_subtree_admitted_workloads_total`	计数器	每个队列子树中已接受的工作负载总数	`cohort`：队列的名称 `priority_class`：优先级类名称 `replica_role`：其中之一 `leader`、`follower` 或 `standalone`
`kueue_admission_attempt_duration_seconds`	直方图	一次准入尝试的延迟。标签 ‘result’ 可以有以下值： - ‘success’ 表示至少有一个工作负载被接纳， - ‘inadmissible’ 表示没有工作负载被接纳。	`result`: 可能的值为 `success` 或 `inadmissible` `replica_role`: 可以为 `leader`、`follower` 或 `standalone`
`kueue_admission_attempts_total`	计数器	尝试接纳工作负载的总次数。每次接纳尝试可能尝试接纳多于一个工作负载。标签 ‘result’ 可以有以下值： - ‘success’ 表示至少有一个工作负载被接纳， - ‘inadmissible’ 表示没有工作负载被接纳。	`result`: 可能的值为 `success` 或 `inadmissible` `replica_role`: 可以为 `leader`、`follower` 或 `standalone`

ClusterQueue 状态

使用以下指标来监控你的 ClusterQueues 的状态：

Mon, 01 Jan 0001 00:00:00 +0000

title: “使用 Python 运行 Job” linkTitle: “Python” date: 2023-07-05 weight: 7 description: 在启用了 Kueue 的环境里运行 Job

本指南适用于批处理用户他们具有基本的 Python 与 Kubernetes 交互经验。更多信息，请参见 Kueue 概述。

开始之前

检查管理集群配额了解初始集群设置的详细信息。你还需要安装 kubernetes python。我们建议使用虚拟环境。

Kueue API

Mon, 01 Jan 0001 00:00:00 +0000

Resource Types

`AdmissionCheck`

Appears in:

AdmissionCheck is the Schema for the admissionchecks API

Kueue Configuration API

Mon, 01 Jan 0001 00:00:00 +0000

Resource Types

Configuration

`AdmissionFairSharing`

Appears in:

Field Description

usageHalfLifeTime [Required]
k8s.io/apimachinery/pkg/apis/meta/v1.Duration

usageHalfLifeTime indicates the time after which the current usage will decay by a half If set to 0, usage will be reset to 0 immediately.

kueuectl

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Controls Kueue queueing manager

Options

--as string

Username to impersonate for the operation. User could be a regular user or a service account in a namespace.

kueuectl create clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用给定名称创建 ClusterQueue。

kueuectl create clusterqueue NAME [--cohort COHORT_NAME] [--queuing-strategy QUEUEING_STRATEGY] [--namespace-selector KEY=VALUE] [--reclaim-within-cohort PREEMPTION_POLICY] [--preemption-within-cluster-queue PREEMPTION_POLICY] [--nominal-quota RESOURCE_FLAVOR:RESOURCE=VALUE] [--borrowing-limit RESOURCE_FLAVOR:RESOURCE=VALUE] [--lending-limit RESOURCE_FLAVOR:RESOURCE=VALUE] [--dry-run STRATEGY]

示例

  # 创建 ClusterQueue
  kueuectl create clusterqueue my-cluster-queue
  
  # 创建具有队列组、命名空间选择器和其他详细信息的 ClusterQueue
  kueuectl create clusterqueue my-cluster-queue \
  --cohort cohortname \
  --queuing-strategy StrictFIFO \
  --namespace-selector fooX=barX,fooY=barY \
  --reclaim-within-cohort Any \
  --preemption-within-cluster-queue LowerPriority
  
  # 创建具有标称配额和一个名为 alpha 的资源类型的 ClusterQueue
  kueuectl create clusterqueue my-cluster-queue --nominal-quota "alpha:cpu=9;memory=36Gi"
  
  # 创建具有多个资源类型（名为 alpha 和 beta）的 ClusterQueue
  kueuectl create clusterqueue my-cluster-queue \
  --cohort cohortname \
  --nominal-quota "alpha:cpu=9;memory=36Gi;nvidia.com/gpu=10,beta:cpu=18;memory=72Gi;nvidia.com/gpu=20" \
  --borrowing-limit "alpha:cpu=1;memory=1Gi;nvidia.com/gpu=1,beta:cpu=2;memory=2Gi;nvidia.com/gpu=2" \
  --lending-limit "alpha:cpu=1;memory=1Gi;nvidia.com/gpu=1,beta:cpu=2;memory=2Gi;nvidia.com/gpu=2"

选项

--allow-missing-template-keys Default: true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl create localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

在指定命名空间中使用给定名称创建本地队列。

kueuectl create localqueue NAME -c CLUSTER_QUEUE_NAME [--ignore-unknown-cq] [--dry-run STRATEGY]

示例

  # 创建本地队列
  kueuectl create localqueue my-local-queue -c my-cluster-queue
  
  # 创建具有未知集群队列的本地队列
  kueuectl create localqueue my-local-queue -c my-cluster-queue -i

选项

--allow-missing-template-keys Default: true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl create resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

使用给定名称创建资源类型。

kueuectl create resourceflavor NAME [--node-labels KEY=VALUE] [--node-taints KEY[=VALUE]:EFFECT] [--tolerations KEY[=VALUE][:EFFECT]]|:EFFECT [--dry-run STRATEGY]

示例

  # 创建资源类型
  kueuectl create resourceflavor my-resource-flavor
  
  # 创建具有标签的资源类型
  kueuectl create resourceflavor my-resource-flavor \
  --node-labels kubernetes.io/arch=arm64,kubernetes.io/os=linux
  
  # 创建具有节点污点的资源类型
  kueuectl create resourceflavor my-resource-flavor \
  --node-taints key1=value:NoSchedule,key2:NoExecute
  
  # 创建具有容忍度的资源类型
  kueuectl create resourceflavor my-resource-flavor \
  --tolerations key1=value:NoSchedule,key2:NoExecute,key3=value,key4,:PreferNoSchedule

选项

--allow-missing-template-keys Default: true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl delete clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将"delete clusterqueue"透传给 kubectl

kueuectl delete clusterqueue [flags]

选项

-h, --help

clusterqueue 命令的帮助信息

kueuectl delete localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将"delete localqueue"透传给 kubectl

kueuectl delete localqueue [flags]

选项

-h, --help

localqueue 命令的帮助信息

kueuectl delete resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

将"delete resourceflavor"透传给 kubectl

kueuectl delete resourceflavor [flags]

选项

-h, --help

resourceflavor 命令的帮助信息

kueuectl delete workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

如果 Workload 有关联的 Jobs，命令将提示删除受影响 Jobs 的批准，并删除它们。然后 Workload 将由垃圾收集器异步删除。如果没有关联的 Jobs，命令将直接删除 Workload。

kueuectl delete workload NAME [--yes] [--all] [--dry-run STRATEGY]

示例

  # 删除 Workload
  kueuectl delete workload my-workload

选项

--all

删除指定命名空间中的所有 Workload。

kueuectl describe clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

传递 describe clusterqueue 给 kubectl

kueuectl describe clusterqueue [flags]

选项

-h, --help

clusterqueue 命令的帮助信息

kueuectl describe localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

传递 describe localqueue 给 kubectl

kueuectl describe localqueue [flags]

选项

-h, --help

localqueue 命令的帮助信息

kueuectl describe resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

传递 describe resourceflavor 给 kubectl

kueuectl describe resourceflavor [flags]

选项

-h, --help

resourceflavor 命令的帮助信息

kueuectl describe workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

传递 describe workload 给 kubectl

kueuectl describe workload [flags]

选项

-h, --help

workload 命令的帮助信息

kueuectl edit clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 edit clusterqueue 透传给 kubectl

kueuectl edit clusterqueue [flags]

选项

-h, --help

clusterqueue 命令的帮助信息

kueuectl edit localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 edit localqueue 透传给 kubectl

kueuectl edit localqueue [flags]

选项

-h, --help

localqueue 命令的帮助信息

kueuectl edit resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 edit resourceflavor 透传给 kubectl

kueuectl edit resourceflavor [flags]

选项

-h, --help

resourceflavor 命令的帮助信息

kueuectl edit workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 edit workload 透传给 kubectl

kueuectl edit workload [flags]

选项

-h, --help

workload 命令的帮助信息

kueuectl get clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

把 get clusterqueue 透传给 kubectl。

kueuectl get clusterqueue [flags]

选项

-h, --help

clusterqueue 命令的帮助信息

kueuectl get localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

把 get localqueue 透传给 kubectl。

kueuectl get localqueue [flags]

选项

-h, --help

localqueue 命令的帮助信息

kueuectl get resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

把 get resourceflavor 透传给 kubectl。

kueuectl get resourceflavor [flags]

选项

-h, --help

resourceflavor 命令的帮助信息

kueuectl get workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

把 get workload 透传给 kubectl。

kueuectl get workload [flags]

选项

-h, --help

workload 命令的帮助信息

kueuectl list clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

列出所有 ClusterQueue，可能将输出限制为活跃/非活跃且与标签选择器匹配的输出。

kueuectl list clusterqueue [--selector key1=value1] [--field-selector key1=value1] [--active=true|false]

示例

# 列出 ClusterQueue
kueuectl list clusterqueue

选项

--active bools 默认：[]

按活跃状态过滤。有效值："true" 和 "false"。

kueuectl list localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

列出符合给定条件的 LocalQueue：指向特定的 CQ、处于活跃/非活动状态、属于指定的命名空间、匹配标签选择器或字段选择器。

kueuectl list localqueue [-–clusterqueue CLUSTER_QUEUE_NAME] [--selector key1=value1] [--field-selector key1=value1] [--all-namespaces]

示例

# 列出 LocalQueue
kueuectl list localqueue

选项

-A, --all-namespaces

如果存在，跨所有命名空间列出请求的对象。即使使用 --namespace 指定了当前上下文中的命名空间，也会被忽略。

kueuectl list pods

Mon, 01 Jan 0001 00:00:00 +0000

概要

列出所有符合给定条件的 Pod：属于指定的 Job 类型、隶属于指定的命名空间、匹配标签选择器或字段选择器。

--for=pod/pod-name 选项允许查找与指定 Pod 属于同一 Pod 组的 Pod，包括该 Pod 本身。

kueuectl list pods --for TYPE[.API-GROUP]/NAME

示例

# 列出 Job 下的 Pod
kueuectl list pods --for job/job-name
  
# 列出 Pod 组下的 Pod
kueuectl list pods --for pod/pod-name

选项

-A, --all-namespaces

如果存在，跨所有命名空间列出请求的对象。即使使用 --namespace 指定了当前上下文中的命名空间，也会被忽略。

kueuectl list resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

列出 ResourceFlavor

kueuectl list resourceflavor [--selector KEY=VALUE] [--field-selector FIELD_NAME=VALUE]

示例

# 列出 ResourceFlavor
kueuectl list resourceflavor

选项

--allow-missing-template-keys 默认值：true

如果为 true，则在模板中缺少字段或映射键时忽略任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl list workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

列出符合条件的工作负载。

kueuectl list workload [--clusterqueue CLUSTER_QUEUE_NAME] [--localqueue LOCAL_QUEUE_NAME] [--status STATUS] [--selector key1=value1] [--field-selector key1=value1] [--all-namespaces] [--for TYPE[.API-GROUP]/NAME]

示例

# 列出工作负载
kueuectl list workload

Options

-A, --all-namespaces

如果存在，跨所有命名空间列出请求的对象。即使使用 --namespace 指定了当前上下文中的命名空间，也会被忽略。

kueuectl patch clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 patch clusterqueue 透传给 kubectl

kueuectl patch clusterqueue [flags]

选项

-h, --help

clusterqueue 命令的帮助信息

kueuectl patch localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 patch localqueue 透传给 kubectl

kueuectl patch localqueue [flags]

选项

-h, --help

localqueue 命令的帮助信息

kueuectl patch resourceflavor

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 patch resourceflavor 透传给 kubectl

kueuectl patch resourceflavor [flags]

选项

-h, --help

resourceflavor 的帮助命令

kueuectl patch workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

将 patch workload 透传给 kubectl

kueuectl patch workload [flags]

选项

-h, --help

workload 命令的帮助命令

kueuectl resume clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

恢复之前暂停的 ClusterQueue。

kueuectl resume clusterqueue NAME

示例

  # 恢复集群队列
  kueuectl resume clusterqueue my-clusterqueue

选项

--allow-missing-template-keys 默认值： true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl resume localqueue

Mon, 01 Jan 0001 00:00:00 +0000

概要

恢复之前暂停的 LocalQueue。

kueuectl resume localqueue NAME

示例

  # 恢复本地队列
  kueuectl resume localqueue my-localqueue

选项

--allow-missing-template-keys 默认值： true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl resume workload

Mon, 01 Jan 0001 00:00:00 +0000

概要

恢复 Workload，允许其根据常规 ClusterQueue 规则进行准入。

kueuectl resume workload NAME [--namespace NAMESPACE] [--dry-run STRATEGY]

示例

  # 恢复工作负载
  kueuectl resume workload my-workload

选项

--allow-missing-template-keys 默认值： true

如果为 true，当模板中缺少字段或映射键时忽略模板中的任何错误。仅适用于 golang 和 jsonpath 输出格式。

kueuectl stop clusterqueue

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Puts the given ClusterQueue on hold.

kueuectl stop clusterqueue NAME [--keep-already-running]

Examples

  # Stop the clusterqueue
  kueuectl stop clusterqueue my-clusterqueue

Options

--allow-missing-template-keys Default: true

If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.

kueuectl stop localqueue

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Puts the given LocalQueue on hold.

kueuectl stop localqueue NAME [--keep-already-running]

Examples

  # Stop the localqueue
  kueuectl stop localqueue my-localqueue

Options

--allow-missing-template-keys Default: true

If true, ignore any errors in templates when a field or map key is missing in the template. Only applies to golang and jsonpath output formats.

kueuectl stop workload

Mon, 01 Jan 0001 00:00:00 +0000

Synopsis

Puts the given Workload on hold. The Workload will not be admitted and if it is already admitted it will be put back to queue just as if it was preempted (using .spec.active field).

Multikueue

Mon, 01 Jan 0001 00:00:00 +0000

MultiKueue AdmissionCheck 是负责准入管理集群上创建的工作负载的核心组件，它基于所选工作集群上的工作负载。