spark on k8s两种方式的原理与对比

spark on k8s两种方式的原理与对比

1、spark on k8s 方式

spark-submit可以直接用来向 Kubernetes 集群提交 Spark 应用，提交机制如下：

1、Spark 创建一个在Kubernetes pod中运行的 Spark 驱动程序。
2、驱动程序创建在 Kubernetes Pod 中运行的执行器并连接到它们，然后执行应用程序代码。
3、当应用程序完成时，执行器容器终止并被清理，但驱动程序容器会保留日志并在 Kubernetes API 中保持“完成”状态，直到最终被垃圾收集或手动清理。

优点

简单直接：

使用 spark-submit 命令直接提交作业，无需额外学习和配置 Spark Operator。

原生 Spark 体验：

提供原生的 Spark 使用体验，熟悉 Spark 的用户可以更快上手。

灵活性高：

通过 spark-submit 可以直接控制 Spark 作业的配置和运行参数，适应不同的需求。

无需额外组件：

不需要安装和维护 Spark Operator 这个额外的组件，减少了系统复杂性。

缺点

手动管理：

需要手动管理 Spark 作业的生命周期，包括提交、监控、重启等任务，增加了运维负担。

缺乏集中管理：

每次提交作业都需要单独配置，缺乏集中化管理和版本控制的能力。

2、spark on k8s Operator 方式

使用 Spark Operator 是一种更高级的方式，它提供了一个 Kubernetes 原生的方法来管理 Spark 作业。Spark Operator 是一个 Kubernetes 控制器，负责处理 SparkApplication CRD（自定义资源定义）。
1、安装 Spark Operator，然后定义 spark-app.yaml，再执行 kubectl apply -f spark-app.yaml，这种申明式 API 和调用方式是 K8S 的典型应用方式。
2、使用 Kubernetes 自定义资源来指定、运行和显示 Spark 应用程序的状态。

核心组件
Custom Resource Definition (CRD)：

Spark Operator 定义了一个自定义资源类型，称为 SparkApplication。这个 CRD 描述了一个 Spark 应用程序的配置，包括应用程序名称、主类、部署模式（Cluster 或 Client）、资源配置等。

Spark Operator Controller：
Spark Operator Controller 是一个 Kubernetes 控制器，它负责监视 SparkApplication CRD 的变化（如创建、更新、删除）。当检测到变化时，它会根据 CRD 的配置来创建和管理相应的 Kubernetes 资源。

工作流程

1、提交 Spark 应用：

用户通过 kubectl 或 CI/CD 管道等方式提交一个 SparkApplication CRD 对象到 Kubernetes 集群。

监视和响应：

Spark Operator Controller 监视 Kubernetes 集群中的 SparkApplication 对象。当检测到一个新的 SparkApplication 对象时，控制器会读取其配置，并创建相应的 Kubernetes 资源（如 Pod、Service 等）来运行 Spark 应用程序。

创建 Driver 和 Executor Pods：

根据 SparkApplication 的配置，Spark Operator 会创建 Spark Driver Pod 和相应数量的 Executor Pods。Driver Pod 负责协调 Spark 应用的执行，而 Executor Pods 则执行具体的计算任务。

管理生命周期：

Spark Operator 负责管理整个 Spark 应用程序的生命周期，包括启动、监视、失败重启和删除等操作。它会根据 Spark 应用的状态更新 SparkApplication 对象的状态字段，用户可以通过查询 SparkApplication 对象来了解应用的当前状态。

优点

1、自动化管理：

Spark Operator 提供声明式配置，简化了 Spark 作业的提交和管理过程。自动处理作业的创建、监控、重启等任务。

2、Kubernetes 原生集成：

使用 CRD（自定义资源定义）和控制器，深度集成 Kubernetes 的功能，充分利用其调度、扩展和管理能力。

3、作业配置集中化：

SparkApplication CRD 提供了集中管理和版本控制的能力，可以通过 GitOps 等工具更好地管理作业配置。

4、易于扩展和管理：

通过 Helm Charts 部署和管理 Spark Operator 及其相关资源，简化了安装和维护过程。

缺点

增加了复杂性：

需要额外学习和维护 Spark Operator，自带的控制器和 CRD 增加了系统复杂性。

调试困难：

调试 Spark Operator 相关问题可能较为复杂，需要了解 Kubernetes 和 Spark 的运行机制和日志分析。

版本兼容性：

可能存在 Spark Operator 和 Spark 版本之间的兼容性问题，需要确保两者的版本匹配。

总结

Spark on k8s Operator 更适合大规模、需要自动化和集中管理的场景。它利用 Kubernetes 的原生功能，实现自动化管理和配置集中化，虽然增加了一些复杂性，但在动态和多租户环境中表现出色。

Spark on k8s 适合简单、直接的 Spark 作业提交和管理场景，特别是对于那些已有 Spark 使用经验的用户。它操作简便，无需额外组件，灵活性较高。但在大规模和自动化需求较高的场景中，管理和扩展的能力相对较弱。