这是本节的多页打印视图。点击此处打印.

Workload API

1: Pod 组策略

特性状态： Kubernetes v1.35 [alpha]（默认禁用）

Workload API 资源允许你描述一个多 Pod 应用的调度需求和结构。虽然工作负载控制器提供了运行时行为，但 Workload API 旨在为“真实”的工作负载（例如 Job 等）提供调度约束。

什么是 Workload？

Workload API 资源属于 scheduling.k8s.io/v1alpha1 API 组（在使用此 API 之前，你的集群必须启用该 API 组以及 GenericWorkload 特性门控）。此资源作为一种结构化、机器可读的定义，用于描述多 Pod 应用的调度需求。面向用户的工作负载（例如 Job）定义“运行什么”，而 Workload 资源则决定一组 Pod 应该如何被调度，以及在其整个生命周期中如何管理其调度位置。

API 结构

Workload 允许你定义一组 Pod，并为其应用调度策略。 Workload 由两个部分组成：Pod 分组列表和到某个控制器的引用。

Pod 分组

podGroups 列表定义了工作负载中的不同组件。例如，一个机器学习任务可能包含一个 driver 分组和一个 worker 分组。

podGroups 中的每一项必须包含：

一个唯一的 name，可在 Pod 的 Workload 引用中使用。
一个调度策略（basic 或 gang）。

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  controllerRef:
    apiGroup: batch
    kind: Job
    name: training-job
  podGroups:
  - name: workers
    policy:
      gang:
        # 只有当可以同时运行 4 个 Pod 时，此 gang 才可调度
        minCount: 4

引用工作负载控制对象

controllerRef 字段用于将 Workload 关联回定义此应用的具体高层对象，例如 Job 或定制 CRD。这对于可观测性和工具链非常有用。此数据不会用于 Workload 的调度或管理。

接下来

查看如何在 Pod 中引用 Workload。
了解 Pod 分组策略。
阅读 Gang 调度算法。

1 - Pod 组策略

特性状态： Kubernetes v1.35 [alpha]（默认禁用）

在 Workload 中定义的每一个 Pod 组都必须声明一个调度策略。此策略决定调度器如何处理这一组 Pod。

策略类别

当前 API 支持两种策略类别：basic 和 gang。你必须为每个 Pod 组指定一种策略。

Basic 策略

basic 策略指示调度器将组内的所有 Pod 视为独立实体，并使用标准的 Kubernetes 行为来调度这些 Pod。

使用 basic 策略的主要原因是对 Workload 中的 Pod 进行组织，以提升可观测性和管理能力。

此策略可用于那些不需要同时启动但逻辑上属于应用的 Workload 组；同时也为未来可能引入的、不一定要求“全有或全无”调度方式的组约束提供扩展空间。

policy:
  basic: {}

Gang 策略

gang 策略强制执行“全有或全无”的调度机制。这对于紧密耦合的工作负载非常重要，因为部分启动可能导致死锁或资源浪费。

此策略常用于 Job 或其他需要所有 Worker 同时运行才能推进的批处理任务。

gang 策略需要配置 minCount 参数：

policy:
  gang:
    # 组被允许调度所需的最小 Pod 数量
    minCount: 4

接下来

阅读 Gang 调度算法。