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

返回本页常规视图.

PodGroup API

特性状态: Kubernetes v1.35 (Alpha; (默认禁用))
More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the GenericWorkload feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

PodGroup 是一个运行时对象,代表一组作为单个单元一起调度的 Pod。

虽然工作负载 API 定义了调度策略模板, 但 PodGroup 是运行时对应的对象,它同时承载了策略和该组特定实例的调度状态。

什么是 PodGroup?

PodGroup API 资源是 scheduling.k8s.io/v1alpha2 API 组的一部分, 在使用此 API 之前,你的集群必须启用该 API 组以及 GenericWorkload 特性门控

PodGroup 是一个自包含的调度单元。它定义了应该一起调度的 Pod 组, 承载了控制放置的调度策略,并记录了该调度决策的运行时状态。

API 结构

PodGroup 由定义所需调度行为的 spec 和反映当前调度状态的 status 组成。

调度策略

每个 PodGroup 在 spec.schedulingPolicy 中承载一个调度策略basicGang)。当工作负载控制器创建 PodGroup 时, 此策略在创建时从 Workload 的 PodGroupTemplate 复制。 对于独立的 PodGroup,你直接设置策略。

spec:
  schedulingPolicy:
    gang:
      minCount: 4

模板引用

可选的 spec.podGroupTemplateRef 将 PodGroup 链接回它所创建自的 Workload 中的 PodGroupTemplate。 这对于可观测性和工具非常有用。

spec:
  podGroupTemplateRef:
    workload:
      workloadName: training-policy
      podGroupTemplateName: worker

为 PodGroup 请求 DRA 设备

特性状态: Kubernetes v1.36 (Alpha; (默认禁用))
More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the DRAWorkloadResourceClaims feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

通过动态资源分配(DRA) 可获得的设备 可以由 PodGroup 通过其 spec.resourceClaims 字段请求:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-group
  namespace: some-ns
spec:
  ...
  resourceClaims:
  - name: pg-claim
    resourceClaimName: my-pg-claim
  - name: pg-claim-template
    resourceClaimTemplateName: my-pg-template

与 PodGroup 关联的 ResourceClaim 可以由属于该组的所有 Pod 共享。 只需在 ResourceClaim 的 status.reservedFor 中引用 PodGroup,而不是每个单独的 Pod, 同一 PodGroup 中的任意数量的 Pod 都可以共享一个 ResourceClaim。 还可以为每个 PodGroup 从 ResourceClaimTemplate 生成 ResourceClaim,允许分配给每个生成的 ResourceClaim 的设备由每个 PodGroup 中的 Pod 共享。

有关更多详细信息和更完整的示例,请参阅 DRA 文档

状态

调度器更新 status.conditions 以报告组是否已成功调度。 主要条件是 PodGroupScheduled,当所有必需的 Pod 已放置时为 True, 当调度失败时为 False

说明:

PodGroupScheduled 条件仅反映初始调度决策。 如果 Pod 后续失败或被驱逐,调度器不会更新它。 有关详细信息,请参阅限制

有关条件和原因的完整列表,请参阅 PodGroup 生命周期页面。

创建 PodGroup

PodGroup API 资源是 scheduling.k8s.io/v1alpha2 API 组的一部分。 (在使用此 API 之前,你的集群必须启用该 API 组以及 GenericWorkload 特性门控。)

以下清单创建一个具有 gang 调度策略的 PodGroup,该策略要求至少 4 个 Pod 同时可调度:

apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-worker-0
  namespace: default
spec:
  schedulingPolicy:
    gang:
      minCount: 4

你可以在集群中检查 PodGroup:

kubectl get podgroups

要查看包括调度条件在内的完整状态:

kubectl describe podgroup training-worker-0

如何组合使用

控制器、Workload、PodGroup 和 Pod 之间的关系遵循以下模式:

  1. 工作负载控制器创建一个 Workload,该 Workload 定义带有调度策略的 PodGroupTemplates。
  2. 对于每个运行时实例,控制器从 Workload 的其中一个 PodGroupTemplate 创建一个 PodGroup。
  3. 控制器创建通过 spec.schedulingGroup.podGroupName 字段引用 PodGroup 的 Pod。

Job 控制器是目前唯一遵循此模式的内置工作负载控制器。 自定义控制器可以为自己的工作负载类型实现相同的流程。

apiVersion: scheduling.k8s.io/v1alpha2
kind: Workload
metadata:
  name: training-policy
spec:
  podGroupTemplates:
  - name: worker
    schedulingPolicy:
      gang:
        minCount: 4
---
apiVersion: scheduling.k8s.io/v1alpha2
kind: PodGroup
metadata:
  name: training-worker-0
spec:
  podGroupTemplateRef:
    workload:
      workloadName: training-policy
      podGroupTemplateName: worker
  schedulingPolicy:
    gang:
      minCount: 4
---
apiVersion: v1
kind: Pod
metadata:
  name: worker-0
spec:
  schedulingGroup:
    podGroupName: training-worker-0
  containers:
  - name: ml-worker
    image: training:v1

Workload 充当长期存在的策略定义,而 PodGroup 处理瞬态的、每个实例的运行时状态。 这种分离意味着单个 PodGroup 的状态更新不会与共享的 Workload 对象发生冲突。

接下来

1 - PodGroup 生命周期

特性状态: Kubernetes v1.35 (Alpha; (默认禁用))
More information about this feature

To use this feature, you (or a cluster administrator) will need to enable the GenericWorkload feature gate for all relevant components in your cluster.

See Enable Or Disable Feature Gates for more information.

PodGroup 作为一个单元进行调度, 并在 Pod 仍在运行时受到保护,防止提前删除。

所有权和生命周期

PodGroup 由创建它们的工作负载控制器(例如 Job)通过标准的 ownerReferences 拥有。 当拥有对象被删除时,PodGroup 会自动被垃圾回收。

PodGroup 名称在名字空间内必须是唯一的,并且必须是有效的 DNS 子域名

创建顺序

控制器必须按以下顺序创建对象:

  1. Workload — 调度策略模板。
  2. PodGroup — 运行时实例。
  3. Pod — 其 spec.schedulingGroup.podGroupName 指向 PodGroup

如果 PodGroup 包含一个指向不存在(或正在被删除)的 WorkloadpodGroupTemplateRef, API 服务器会拒绝 PodGroup 创建请求。 引用的 Workload 必须在 PodGroup 创建之前存在。

如果 Pod 引用了不存在的 PodGroup,则该 Pod 保持 pending 状态。 一旦 PodGroup 被创建,调度器会自动将 Pod 加入调度队列。

删除保护

当 PodGroup 的任何 Pod 仍在运行时,不能完全删除该 PodGroup。 一个专门的 finalizer 确保在所有引用该 PodGroup 的 Pod 达到终止阶段(SucceededFailed)之前阻止删除。

控制器管理的 PodGroup 和用户管理的 PodGroup

在大多数情况下,工作负载控制器(例如 Job)自动创建 PodGroup(控制器管理)。 控制器在创建时为每个 Pod 确定 podGroupName, 类似于 DaemonSet 为每个 Pod 设置节点亲和性的方式。

如果你需要对命名和生命周期进行更多控制,可以直接创建 PodGroup 对象, 并在 Pod 模板中自己设置 spec.schedulingGroup.podGroupName(用户管理)。 这使你可以完全控制 PodGroup 的创建和命名。

限制

  • PodGroup 中的所有 Pod 必须使用相同的 .spec.schedulerName。 如果检测到不匹配,调度器会拒绝组中的所有 Pod 为不可调度。
  • PodGroup 上的 spec.schedulingPolicy.gang.minCount 字段是不可变的。 创建后,你无法更改组准入所需的可调度 Pod 最小数量。
  • Pod 上的 spec.schedulingGroup 字段是不可变的。 设置后,Pod 无法移动到不同的 PodGroup 中。
  • 单个 WorkloadPodGroupTemplates 的最大数量为 8。
  • PodGroupScheduled 状况仅反映初始调度尝试的结果。 一旦状况设置为 True,即使后续 Pod 后续失败、被驱逐或停止运行,调度器也不会更新它。

接下来