0


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 使用经验的用户。它操作简便,无需额外组件,灵活性较高。但在大规模和自动化需求较高的场景中,管理和扩展的能力相对较弱。


本文转载自: https://blog.csdn.net/lhyandlwl/article/details/140122632
版权归原作者 放学-别走 所有, 如有侵权,请联系我们删除。

“spark on k8s两种方式的原理与对比”的评论:

还没有评论