版本：Next

调度多组件工作负载

概述

许多现代分布式应用程序由具有异构资源需求的多个组件组成。例如，Flink 集群包含 JobManager 和 TaskManager 组件，而 Ray 集群则包含 Head 和 Worker 节点。每个组件通常具有不同的副本数和资源规格。

从 Karmada v1.16 开始，多 Pod 模板调度功能为这些复杂工作负载提供了精确的资源感知调度能力。这确保了 Karmada 能够正确理解多组件应用程序的总资源需求，并在成员集群之间做出明智的调度决策。

在 v1.16 之前，Karmada 调度器假设工作负载中的所有副本都是相同的，使用单一的 Pod 模板来表示资源需求。这种假设对于 Deployment 等简单应用程序效果良好，但对于多组件工作负载则会导致不准确的情况。

考虑一个具有两个组件的 FlinkDeployment：

使用传统调度，调度器只能表示一个组件的需求，导致：

低估：将 JobManager 配置应用于所有副本 → 仅计算 4 个 CPU 总量（实际需要 7 个）→ 存在调度到资源不足集群的风险（Pod Pending）。
高估：将 TaskManager 配置应用于所有副本 → 估计 8 个 CPU 总量（实际需要 7 个）→ 浪费资源并限制集群选择。
配额计算不准确：FederatedResourceQuota 显示错误的使用情况。

使用多组件调度，调度器能够准确理解：

多组件调度功能专为具有多个异构 Pod 模板的 CRD 设计。常见用例包括：

类别	示例
流处理	Flink、Kafka Streams、Apache Storm
AI/ML 框架	Ray、TensorFlow、PyTorch、MXNet
机器学习训练	参数服务器、分布式训练作业
批处理	Spark、Volcano、Hadoop
数据处理	XGBoost、PaddlePaddle、分布式数据库
分布式系统	Elasticsearch、Redis Cluster、数据库集群

Karmada 为流行的 CRD 提供了内置的解释器支持。您可以在资源解释器文档中找到具有内置解释器支持的 CRD 列表。对于新的 CRD 类型或自定义工作负载，您可以实现自定义解释器（参见自定义资源解释器）或联系 Karmada 社区获取支持。

多组件调度功能目前处于 Alpha 阶段，从 Karmada v1.16 开始提供。作为 Alpha 功能，它在未来版本中可能会发生变化，但核心调度功能已完全可用，可用于评估和测试环境。

要使用多组件调度功能，您必须启用 MultiplePodTemplatesScheduling 特性门控。该特性门控必须在以下组件上启用：

下图展示了多组件调度的过程，以 FlinkDeployment 为例。相同的工作流程也适用于其他多组件应用程序，如 RayCluster、TensorFlow 集群和其他分布式系统。

Multi-Component Scheduling Architecture

上图显示了调度工作流程：

多组件应用程序（例如 FlinkDeployment、RayCluster）被提交到 Karmada API Server。需要提供 PropagationPolicy 或 ClusterPropagationPolicy 来指定工作负载应如何在成员集群之间分发。
Karmada 控制器利用资源解释器来解析每个组件的资源需求。这些需求存储在 ResourceBinding 对象的 spec.components 字段中。
调度器基于每个组件逐个评估候选集群，而不是简单地按总资源求和。例如，它检查集群是否可以容纳 JobManager，然后检查同一集群是否也可以容纳所有 TaskManager。这种方法更好地考虑了集群节点之间的资源分布和碎片化。
调度器选择可以满足所有组件需求的集群。然后将所有组件作为单个单元调度到该集群。

目前，多组件调度功能具有以下限制：

多组件工作负载通常在组件之间存在紧密耦合（共享存储、网络连接、同步需求）。将组件分发到不同集群会在资源管理、故障处理和性能优化方面带来显著的复杂性。

我们认识到，将组件分发到不同集群是更好地利用多集群资源的自然演进。这种方法可以实现更灵活的资源分配和提高基础设施的利用率。但是，支持这一点需要：

我们欢迎有关跨集群组件分发的用户反馈和用例。如果您有特定的需求或场景，请随时联系我们。