devops

Kubernetes v1.35：推出工作负载感知调度

发布: (2025年12月30日 GMT+8 02:30)
12 min read
原文: Kubernetes Blog

Source: Kubernetes Blog

请提供您希望翻译的具体文本内容，我将按照要求保留源链接并进行简体中文翻译。

Source: …

工作负载中心调度

调度大规模工作负载远比调度单个 Pod 更复杂、更脆弱。与单 Pod 调度不同，工作负载调度必须 将所有 Pod 一起考虑，并兼顾它们之间的关系和放置约束。

为什么工作负载调度很重要

  • 战略性放置 – 对于机器学习批处理任务，工作节点往往需要同址（例如在同一个机架）以降低延迟并最大化吞吐量。
  • 相同的 Pod – 属于同一工作负载的 Pod 在调度视角下通常是相同的，这会改变调度算法的假设。
  • 需求增长 – 随着 AI 和数据密集型工作负载的激增，高效的工作负载调度已成为 Kubernetes 用户的关键需求。

当前现状

已有许多自定义调度器用于处理工作负载层面的决策，但它们 位于核心 kube-scheduler 之外。这种碎片化导致：

  1. 用户体验不一致 – 运维人员必须学习并维护不同的调度组件。
  2. 集成受限 – 自定义调度器难以轻松利用默认调度器的内建特性（如优先级、抢占或 extender API）。
  3. 运维开销 – 部署、监控和升级额外调度器会增加复杂度。

行动呼吁

鉴于工作负载调度的重要性——尤其在 AI 时代——现在是时候：

  • 将工作负载提升为原生 kube-scheduler 的一等公民。
  • 暴露原生 API，让用户能够声明工作负载层面的约束（机架亲和性、分布策略等）。
  • 利用现有调度器扩展机制（例如 framework 插件），在不抛弃核心调度器的前提下实现工作负载感知的调度逻辑。

通过将工作负载中心的能力直接集成到 kube-scheduler，Kubernetes 能够为传统工作负载和新兴 AI 工作负载提供 统一、可靠且可扩展 的调度体验。

工作负载感知调度

Kubernetes v1.35 引入了首批 工作负载感知调度 改进。这些变化是更广泛的、多 SIG 合作的一部分，将在多个版本中逐步演进，目标是实现 Kubernetes 中无缝的工作负载调度与管理的 北极星 目标——包括但不限于抢占和自动伸缩。

关键亮点

功能描述
工作负载 API一个新 API，允许您描述工作负载的 期望形态 与 调度相关的需求。
组调度（初始实现）指示 kube‑scheduler 以 全有或全无 的方式调度一组 Pod，确保整个组要么全部运行，要么全部不运行。
机会批处理通过机会性批处理相同的 Pod（通常形成一个组），提升调度速度。

对用户的意义

  • 可预测的部署 – 定义工作负载所需的 Pod 的确切数量和特性，调度器将遵守这些约束。
  • 降低调度延迟 – 相同的 Pod 被分组并一起调度，缩短达到就绪状态的时间。
  • 为未来功能奠定基础 – 此次发布为更高级的功能（如复杂的抢占、自动伸缩以及跨集群工作负载放置）奠定了基础。

注意： 该功能将在后续版本和更多 SIG 中持续扩展，请关注 Kubernetes 发布说明以获取最新的改进。

Source: …

工作负载 API

新的 Workload API 资源属于 scheduling.k8s.io/v1alpha1 API 组。

它提供了 结构化、机器可读的调度需求定义，用于多 Pod 应用的调度。用户面对的工作负载（如 **Jobs）描述 要运行什么，而 Workload 描述 一组 Pod 应该如何调度以及其位置在整个生命周期中如何管理。

Workload 能让你做什么

  • 定义一组 Pod（podGroup）。
  • 为该组应用调度策略（例如，帮派调度、优先级等）。

示例：帮派调度配置

下面的片段创建了一个 Workload，定义了名为 workers 的 pod 组，并应用了 gang 策略，要求至少四个 Pod 必须一起调度。

apiVersion: scheduling.k8s.io/v1alpha1
kind: Workload
metadata:
  name: training-job-workload
  namespace: some-ns
spec:
  podGroups:
    - name: workers
      policy:
        gang:
          # The gang is schedulable only if 4 pods can run at once
          minCount: 4

将 Pod 与 Workload 关联

创建单个 Pod 时，通过 workloadRef 字段引用 Workload（以及具体的 pod 组）：

apiVersion: v1
kind: Pod
metadata:
  name: worker-0
  namespace: some-ns
spec:
  workloadRef:
    name: training-job-workload   # Workload name
    podGroup: workers            # Pod group defined in the Workload
  # ... other pod spec fields ...

有了这种设置，调度器只有在满足帮派调度约束时才会放置这些 Pod，确保整个组能够一起运行。

Source: …

Gang 调度工作原理

gang 策略强制 全有全无 的放置。没有 gang 调度时，作业可能只被部分调度，消耗资源却无法运行。这会导致资源浪费和潜在的死锁。

Gang‑调度 Pod 组的生命周期

  1. Pod 创建 – Pod（或创建它们的控制器）被标记为 gang‑调度的 pod 组的一部分。
  2. 调度器处理 – 调度器的 GangScheduling 插件管理每个 pod 组（或副本键）的生命周期。
  3. 阻塞阶段 – 在满足以下 全部 条件之前，Pod 会被阻止调度：
    • 引用的 Workload 对象存在。
    • 在该 Workload 中引用的 PodGroup 存在。
    • 组内待调度的 Pod 数量达到配置的 minCount。

Permit 门

一旦满足 minCount，调度器会尝试放置这些 Pod，但它们 不会 立即绑定到节点上，而是等待 Permit 门：

  • 调度器检查是否已经为整个组（至少 minCount）找到了 有效的分配。
  • 如果组能够全部放下：门打开，所有 Pod 在一次操作中绑定到各自的节点。
  • 如果只能放下一部分（在超时时间内，默认 = 5 分钟）：调度器 拒绝该组中的所有 Pod。被拒绝的 Pod 返回队列，释放为其他工作负载预留的资源。

未来方向

这是 Kubernetes 中 gang 调度的首次实现。后续版本计划：

  • 为整个 gang 提供 单轮调度阶段。
  • 添加 工作负载级别的抢占。
  • 引入更多功能，朝着长期的 “北极星” 目标——协同调度，迈进。

关键要点： gang 调度保证一组 Pod 要么一起运行，要么全部不运行，防止部分分配，提升整体集群效率。

机会批处理

Kubernetes v1.35 引入了 机会批处理（Beta 特性），可提升相同 Pod 的调度延迟。与 gang 调度不同，此特性无需显式 opt‑in 或 Workload API。调度器会机会性地复用对具有相同调度需求（容器镜像、资源请求、亲和性等）的 Pod 的可行性计算，从而显著加快调度过程。

注意： 大多数用户将在其 Pod 满足下列条件时自动受益。

限制

机会批处理仅在 Pod 之间用于 kube-scheduler 查找位置的所有字段完全相同 时才有效。某些调度器功能会为保证正确性而禁用批处理。

  • 检查你的 kube-scheduler 配置，确保未隐式禁用批处理。
  • 完整的限制列表请参阅官方文档：

Official Kubernetes Documentation – Opportunistic Batching

Source: …

北极星愿景

该项目的宏大目标是实现 工作负载感知调度。这些新的 API 和调度增强只是第一步。

近期目标

  • 引入工作负载调度阶段
  • 改进对多节点 Dynamic Resource Allocation (DRA) 和拓扑感知调度的支持
  • 工作负载级别的抢占
  • 更好地将调度与自动伸缩集成
  • 加强与外部工作负载调度器的交互
  • 管理工作负载在整个生命周期中的放置
  • 多工作负载调度仿真

注意： 这些关注领域的优先级和实现顺序可能会有所变动，敬请关注后续更新。

入门指南

要尝试 工作负载感知调度 的改进，请在集群组件上启用所需的功能门和 API 组。

1. 工作负载 API

  • 功能门: GenericWorkload
  • 组件: kube-apiserver 以及 kube-scheduler
  • API 组: scheduling.k8s.io/v1alpha1 (必须启用)

2. 群组调度

  • 功能门: GangScheduling
  • 组件: kube-scheduler
  • 前置条件: 必须已经启用工作负载 API（步骤 1）。

3. 机会批处理（Beta）

  • 在 v1.35 中默认启用。
  • 如需禁用，请在 kube-scheduler 上关闭 OpportunisticBatching 功能门。

我们鼓励您在测试集群中尝试工作负载感知调度并分享使用体验。您的反馈将帮助塑造 Kubernetes 调度的未来。

如何提供反馈

了解更多

Back to Blog

相关文章

阅读更多 »