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

返回本页常规视图.

Workload API

特性状态： 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 中的每一项必须包含：

  1. 一个唯一的 name，可在 Pod 的 Workload 引用中使用。
  2. 一个调度策略（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 的调度或管理。

接下来

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

接下来

2 - Pod 组干扰和优先级

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

PodGroup 可以声明一个干扰模式。此模式规定了调度器如何干扰运行中的 PodGroup， 例如为了容纳更高优先级的 PodGroup。PodGroup 还具有优先级， 该优先级会在工作负载感知抢占 事件中覆盖来自该组的单个 Pod 的优先级。

干扰模式类型

说明：

截至 1.36 版本，PodGroup 的 priority 或 disruptionMode 字段仅被工作负载感知抢占所尊重。 在 Pod 调度阶段，调度器不考虑 PodGroup 的 priority 或 disruptionMode 字段。

API 支持两种干扰模式：Pod 和 PodGroup。默认模式是 Pod。

Pod

Pod 模式指示调度器将组中的所有 Pod 视为单独的实体， 允许从 PodGroup 中独立干扰单个 Pod。

PodGroup

PodGroup 模式强调干扰的 "全有或全无" 语义。 它指示调度器必须同时干扰 PodGroup 中的所有 Pod。

Pod 组优先级

PodGroup 使用与单个 Pod 相同的 PriorityClass 概念。 创建一个或多个 PriorityClass 后，你可以创建一个 PodGroup， 并在其规约中指定这些 PriorityClass 名称之一。 优先级准入控制器使用 priorityClassName 字段并填充优先级的整数值。 如果未找到优先级类，则 PodGroup 会被拒绝。 当 PodGroup 未设置 priorityClassName 时，Kubernetes 会寻找默认值（globalDefault 设置为 true 的 PriorityClass）。 如果没有 globalDefault 设置为 true 的 PriorityClass， 则没有 priorityClassName 的 PodGroup 优先级为零。

PodGroup 的优先级是该组中所有 Pod 在 工作负载感知抢占 事件中的权威优先级， 即使组成该 PodGroup 的各个 Pod 的优先级不同也是如此。

以下 YAML 是使用 high-priority PriorityClass 的 PodGroup 配置示例， 该 PriorityClass 映射到整数值 1000000 的优先级。 优先级准入控制器检查规约并将 PodGroup 的优先级解析为 1000000。

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  namespace: ns-1
  name: job-1
spec:
  priorityClassName: high-priority

接下来