Spark Operator 项目探讨：扩展 kube-scheduler 作为批处理调度器的可行性分析

在 Kubernetes 生态系统中，GoogleCloudPlatform 的 spark-on-k8s-operator 项目为 Apache Spark 工作负载提供了原生支持。近期社区中关于是否支持扩展 kube-scheduler 作为批处理调度器的讨论值得深入探讨。

背景与现状

目前 spark-on-k8s-operator 主要支持 Volcano 和 Yunikorn 作为批处理调度器。这两种调度器都能有效处理 Spark 这类批处理工作负载的调度需求，特别是对资源组调度（coscheduling）的支持。

扩展 kube-scheduler 是 Kubernetes SIG 维护的一个插件项目，它通过 PodGroup CRD 实现了类似的资源组调度功能。这种实现方式与 Kubernetes 原生调度器深度集成，理论上可以提供更轻量级的批处理调度方案。

技术价值分析

1. 架构优势：扩展 kube-scheduler 作为 Kubernetes 原生的扩展方案，避免了引入额外调度器组件带来的运维复杂度。

2. 功能对等：通过 PodGroup 机制，它能够实现与 Volcano/Yunikorn 类似的资源组调度能力，确保 Spark 作业的所有 executor 能够同时调度或都不调度。

3. 生态系统整合：作为 Kubernetes 官方维护的项目，它与 Kubernetes 版本演进保持同步，长期维护性更有保障。

实现考量

要实现这一功能，需要考虑以下技术点：

1. CRD 兼容性：需要确保 spark-operator 能够正确处理 scheduling.x-k8s.io/v1alpha1 版本的 PodGroup 资源。

2. 调度器配置：需要支持配置使用扩展调度器作为批处理调度后端，同时保持与现有调度器的兼容。

3. 功能验证：需要验证扩展调度器是否能满足 Spark 作业的所有调度需求，特别是大规模作业的场景。

未来展望

这一改进将为用户提供更多调度器选择，特别是对那些希望保持 Kubernetes 原生性的用户群体。同时，这也体现了 spark-on-k8s-operator 项目对 Kubernetes 生态系统发展的积极响应。

对于开发者而言，理解不同调度器后端的特性和适用场景，将有助于为 Spark on Kubernetes 部署选择最合适的调度方案。随着 Kubernetes 调度能力的不断增强，未来可能会出现更多值得集成的调度扩展方案。