多 Kubernetes 集群统一调度与管理实践——在研发机器学习平台中的应用

摘要

随着机器学习平台的业务发展以及公司历史原因造成的K8S集群的容量限制等问题，单一的 Kubernetes 集群在资源容量、物理隔离和异构资源（如多种 GPU）管理方面逐渐暴露出瓶颈。为了解决这些问题，构建了一套多 Kubernetes 集群管理和调度系统。本文档旨在详细阐述在该过程中面临的核心技术挑战、设计的系统架构，并结合业界主流方案（如 Karmada）分析技术选型考量与实践经验。

1. 背景与技术挑战

1.1 业务驱动

  • 资源扩展性: 单一集群的节点和 Pod 数量存在上限，无法满足平台日益增长的计算需求。
  • 异构资源管理: 不同业务（如训练、推理）需要不同型号的 GPU（如 T4, V100, A100），需要在物理上或逻辑上进行资源池划分。
  • 高可用与容灾: 依赖单个集群存在单点故障风险，需要跨地域或跨可用区的集群部署来保证业务连续性。

1.2 核心技术挑战

根据我们的实践，多集群管理主要面临以下四大挑战：

  1. 统一的资源视图: 用户不应关心任务具体在哪个集群执行。平台需要提供一个统一的资源池视图，用户只需声明所需的资源（如 CPU, Memory, GPU 类型和数量），系统应自动为其匹配最合适的集群。

  2. 复杂的调度策略: 跨集群调度决策远比单集群复杂。需要综合考虑：

    • 成本优化: 优先使用成本更低的集群或 Spot 实例。
    • 数据局部性 (Data Locality): 将计算任务调度到离其所需数据（如存储卷、数据集）最近的集群，减少数据传输开销。
    • 负载均衡: 在多个集群间合理分配负载，避免部分集群过载而其他集群空闲。
    • 硬件亲和性: 确保任务被调度到拥有特定硬件（如指定型号 GPU、NVLink）的集群。

  3. 集群联邦与API交互: 需要一个中心化的组件来发现和管理所有成员集群，并能安全、可靠地与各集群的 API Server 进行通信，以获取状态和下发任务。

  4. 系统的可扩展性: 调度策略会随着业务发展而不断变化。调度系统必须具备良好的扩展性，能够方便地增加、修改或移除调度规则，而无需对核心架构进行大规模改动。

2. 核心架构：联邦调度层

为应对上述挑战，通过设计并实现了一个联邦调度层（Federation Scheduling Layer）。该层作为所有成员集群之上的一个逻辑层，负责接收用户的计算任务，并执行全局最优的调度决策。

  • 工作流程:
    1. 用户通过统一的入口提交 Pod 或 Job 定义。
    2. 联邦调度器接收到请求，进入调度周期。
    3. 过滤 (Filtering): 调度器根据任务的硬性要求（如 GPU 型号、特定标签），从集群列表中筛选出所有满足条件的候选集群。
    4. 打分 (Scoring): 调度器根据一系列预设的策略（如成本、负载、数据位置）为每个候选集群打分。
    5. 选择与绑定 (Select & Bind): 选择得分最高的集群，并通过与该集群的 API Server 通信，在其上创建相应的 Pod/Job 资源。

3. 业界主流方案分析：以 Karmada 为例

在进行技术选型和架构设计时，通过深入研究了业界主流的多集群管理方案，其中以 CNCF 孵化项目 Karmada 最具代表性，其设计理念与业务需求高度契合。

3.1 Karmada 核心调度策略

Karmada 的核心是其策略与应用分离的设计哲学。它通过两个核心策略CRD来实现对多集群工作负载的精细化控制：

  1. PropagationPolicy (传播策略): 定义了工作负载应该被分发到哪些集群 (placement)，以及副本数应该如何分配 (replicaScheduling)。这完美地映射了我们对“硬件亲和性”、“负载均衡”和“弹性伸缩”的需求。

  2. OverridePolicy (覆盖策略): 允许为特定集群部署的应用覆盖其配置，例如修改镜像、标签或资源请求。这对于管理不同环境（开发、测试、生产）下的异构配置至关重要。

此外，Karmada 的 FederatedHPA 能够聚合所有集群的指标，进行全局的水平自动伸缩决策，这正是解决多集群弹性伸缩挑战的理想模型。

3.2 为何选择参考 Karmada 的模式

选择将 Karmada 的模式作为联邦调度层设计的最终参考技术框架，主要基于以下几点关键原因：

  • 原生 API 兼容性: Karmada 提供了与 Kubernetes 完全兼容的 API。这意味着用户和上层应用无需学习新的 API，可以继续使用熟悉的 Deployment, Job 等原生资源，极大地降低了平台的学习和迁移成本。

  • 策略驱动的灵活性: “策略与应用分离”的模式赋予了平台管理员极大的灵活性。可以独立于用户应用，动态调整调度策略。例如，当一个新的低成本 GPU 集群上线时，只需修改 PropagationPolicy 的权重，即可无缝地将新任务引导过去，而无需用户修改任何应用配置。

  • 完美匹配机器学习场景: 机器学习任务（特别是训练任务）的复杂性，如对特定 GPU 型号的需求、海量数据的位置亲和性、以及潮汐性的资源使用模式，都可以通过 Karmada 的策略组合得到优雅解决。

    • placement 规则可以确保训练任务被调度到拥有 V100 的集群。
    • replicaScheduling 的加权分配可以优先将任务调度到离数据集最近的集群。
    • FederatedHPA 结合 Divided 模式，能够根据全局负载自动增减训练任务的并行实例数，并智能地分配到不同集群。

  • 强大的可扩展性: Karmada 的架构是开放和可扩展的。这与内部采用插件化（Scheduler Framework 思想）的设计符合，保证了平台未来能够方便地集成更多自定义的调度逻辑。

4. 实践经验：借鉴与定制

在联邦调度器实现中，借鉴了 Karmada 的核心思想，并进行了定制化实践：

  • 方案选型: 采用了与 Karmada 类似的中心化控制平面模式，构建了一个独立的“调度器的调度器”，负责全局的集群选择。

  • 调度插件化: 将 Karmada 中策略驱动的思想，在内部实现为一系列可插拔的调度插件，与 Scheduler Framework 的扩展点对齐，例如：

    • HardwareFilter 插件 (对应 placement 的硬件亲和性)
    • DataLocalityFilter 插件 (对应 placement 的数据局部性)
    • CostScorer 和 LoadBalancerScorer 插件 (对应 replicaScheduling 的加权调度)

通过这种方式，既利用了业界最佳实践的成熟思想，又保持了自研系统的可控性和定制化能力，以更好地服务于企业内部特定的机器学习平台业务。

5. 总结与展望

通过构建一个独立的、借鉴了 Karmada 设计精髓的联邦调度层，成功地解决了一系列多集群管理中的核心挑战。该系统不仅为用户提供了统一的资源视图，还通过灵活可扩展的调度策略，实现了跨集群的成本优化、负载均衡和数据亲和性调度。这套实践证明，深入理解并结合业界顶尖的开源方案，是构建复杂、健壮的上层平台的关键。

未来的演进方向是实现更深度的两级调度，让联邦调度器与成员集群的 kube-scheduler 进行更智能的协同，实现全局最优的调度效果。