工作负载
工作负载是一个将运行至完成的应用程序。它可以由一个或多个 Pod 组成，这些 Pod 松散或紧密耦合，作为一个整体完成一项任务。工作负载是 Kueue 中的准入单元。
原型工作负载可以用 Kubernetes batch/v1.Job 表示。因此，我们有时使用术语作业来指代任何工作负载，而当我们具体指代 Kubernetes API 时，则使用作业。
但是，Kueue 不会直接操作作业对象。相反，Kueue 管理表示任意工作负载的资源需求的工作负载对象。Kueue 会自动为每个作业对象创建一个工作负载并同步决策和状态。
工作负载清单如下所示
apiVersion: kueue.x-k8s.io/v1beta1
kind: Workload
metadata:
name: sample-job
namespace: team-a
spec:
active: true
queueName: team-a-queue
podSets:
- count: 3
name: main
template:
spec:
containers:
- image: gcr.io/k8s-staging-perf-tests/sleep:latest
imagePullPolicy: Always
name: container
resources:
requests:
cpu: "1"
memory: 200Mi
restartPolicy: Never
活动
你可以通过设置 Active 字段来停止或恢复正在运行的工作负载。active 字段决定了工作负载是否可以被准入队列或继续运行（如果已经准入）。将 .spec.Active 从 true 更改为 false 将导致正在运行的工作负载被驱逐，并且不会重新排队。
队列名称
要指示你希望你的工作负载在哪个 LocalQueue 中排队，请在 .spec.queueName 字段中设置 LocalQueue 的名称。
Pod 集
工作负载可能由具有不同 Pod 规范的多个 Pod 组成。
.spec.podSets 列表的每个项目都表示一组同质 Pod，并具有以下字段
spec使用v1/core.PodSpec描述 Pod。count是使用相同spec的 Pod 数。name是 Pod 集的人类可读标识符。你可以使用 Pod 在工作负载中的角色，例如driver、worker、parameter-server等。
资源请求
Kueue 使用 podSets 资源请求来计算工作负载使用的配额，并决定是否以及何时允许工作负载。
Kueue 将工作负载的总资源使用量计算为每个 podSet 的资源请求的总和。podSet 的资源使用量等于 pod 规范的资源请求乘以 count。
请求值调整
根据集群设置，Kueue 将根据以下内容调整工作负载的资源使用量
请求值验证
在集群定义限制范围的情况下，上述调整产生的值将针对范围进行验证。如果范围验证失败，Kueue 将把工作负载标记为 Inadmissible。
保留的资源名称
除了常规的资源命名限制之外，你不能在 Pod 规范中使用 pods 资源名称，因为它已预留给 Kueue 内部使用。你可以在 ClusterQueue 中使用 pods 资源名称来设置 Pod 的最大数量配额。
优先级
工作负载具有优先级，该优先级影响 ClusterQueue 允许它们加入的顺序。有两种方法可以设置工作负载优先级
Pod 优先级：你可以在
.spec.priority字段中看到工作负载的优先级。对于batch/v1.Job，Kueue 根据 Job 的 Pod 模板的 Pod 优先级 设置工作负载的优先级。WorkloadPriority：有时，开发人员希望控制工作负载的优先级，而不影响 Pod 的优先级。通过使用
WorkloadPriority，你可以独立管理工作负载的优先级，以便排队和抢占，而无需考虑 Pod 的优先级。
自定义工作负载
如前所述，Kueue 内置了对使用 Job API 创建的工作负载的支持。但是，任何自定义工作负载 API 都可以通过为其创建相应的 Workload 对象来与 Kueue 集成。
动态回收
它是一种机制，允许当前已允许的工作负载释放其不再需要的配额预留的一部分。
Job 集成通过设置 reclaimablePods 状态字段来传达此信息，枚举不再需要配额预留的每个 Pod 集的 Pod 数量。
status:
reclaimablePods:
- name: podset1
count: 2
- name: podset2
count: 2
在工作负载持有配额预留期间，count 只能增加。
作业资源分配的全有或全无语义
此机制允许在作业未准备就绪时将其驱逐并重新排队。有关更多详细信息，请参阅准备就绪的 Pod 的全有或全无。
指数退避重新排队
一旦出现带有PodsReadyTimeout原因的驱逐，工作负载将重新排队并进行退避。工作负载状态允许您了解以下内容
.status.requeueState.count表示工作负载由于PodsReadyTimeout原因而被退避重新排队的次数.status.requeueState.requeueAt表示工作负载下次重新排队的时间
status:
requeueState:
count: 5
requeueAt: 2024-02-11T04:51:03Z
当准备就绪的 Pod 的全有或全无停用的工作负载重新激活时，重新排队状态（.status.requeueState）将重置为 null。
将标签从作业复制到工作负载
您可以在创建工作负载时配置 Kueue，将标签从基础作业或 Pod 对象复制到新工作负载中。这对于工作负载识别和调试非常有用。您可以通过在配置 API（在integrations下）中设置labelKeysToCopy字段来指定应复制哪些标签。默认情况下，Kueue 不会将任何作业或 Pod 标签复制到工作负载中。