Spark on K8S 的最佳实践和需要注意的坑

本文来自 Data Mechanics 的 CEO Jean-Yves Stephan 和 CTO Julien Dumazert 在 Spark Summit North America 2020 的《Running Apache Spark on Kubernetes: Best Practices and Pitfalls》议题的分享。相关视频参见视频|在Kubernetes上运行Spark的较佳实践和陷阱，PPT 可以到你要的 Spark AI Summit 2020 PPT 我已经给你整理好了获取。

近年来，K8S 在业界越来越流行，由于其有很多优点，很多企业将应用部署到 K8S 中，Spark 从 2.3 版本开始支持使用 K8S 作为资源管理器，参见 https://issues.apache.org/jira/browse/SPARK-18278。本文将介绍在 K8S 上运行 Spark 作业的较佳实践和需要注意的坑。

在 Kubernetes 上运行 Spark 都有哪些经验的调查中显示：

61% 的人表示从来没用过，但是对这个感到好奇；

24% 的人表示只是在测试环境中使用，但是并没有在生产环境中使用；

15% 的人表示已经在生产环境中使用。

本文主要结构包括：Spark on Kubernetes：

核心概念；

配置和性能调优技巧；

监控和安全相关的技巧；

未来工作。

核心概念

Spark 哪个地方需要用到 K8S 呢？K8S 是 Spark 上全新的集群管理和调度系统，其他三个资源管理和调度为 Standalone、YARN 以及 Apache Mesos。

Spark on Kubernetes 的架构如下：

目前有两种方法可以将 Spark 的应用程序提交到 K8S：

•通过 Spark 提供的 spark-summit 提交

•这种方式是 Spark 原生提供的；

•配置在 Spark config（主要）和 k8s manifests 之间传递；

•在 Spark 3.0 之前支持自定义 Little pod；

•应用的管理主要是人工维护。

•通过 spark-on-k8s operator 提交

•Google 开源出来的，但是支持任意平台；

•配置通过 k8s 风格的 YAML 文件进行；

•提供一些工具用于读取日志、重启、 kill 以及调度作业；

•需要长时间运行的 system pod。

上面显示两种不同作业提交方式的应用管理实践。从上图可以看出，通过 spark-summit 方式提交的作业没有方法查看作业的运行及其参数配置等。而通过 spark-on-k8s operator 方式，可以通过一系列的内置工具，获取很多作业相关的信息。

YARN 和 K8S 两种资源管理方式比较：

YARN 集群中的 Spark 版本、Python 版本以及依赖都是全局配置的，缺乏隔离。（过往记忆大数据备注：YARN 集群上是可以运行不同版本的 Spark 以及 Python，这个我之前有相关文章介绍的。关于依赖其实也有办法进行配置的。）而 K8S 方式作业之间都是隔离的。

配置和性能调优技巧

下面我们来介绍 Spark on K8S 的配置和性能调优相关技巧。

假设我们有一个 K8S 集群，每个实例配置是 16GB 内存和4核；如果我们选择以下两种中的一种配置我们都将申请不到 executor：

设置 spark.executor.cores=4

设置 spark.executor.memory=11g

是不是觉得很奇怪？

上面设置之所以申请不到 executor，是因为：K8S 实例上的资源只有一部分是可以给 Spark pods 的。我们需要预留一部分资源给 K8S 以及系统守护进程，这部分大概占用 5%。所以我们的节点只能申请到 95% 的资源，在这些资源中 10% 需要给一些守护进程使用，所以整个实例我们只能申请到 95% * 90% = 85% 的资源。

目前 Spark on K8S 还不支持动态资源分配的全部功能。当我们杀掉 pod 时，上面的 shuffle 文件将会被丢失。

与此同时，Spark 3.0 提供了一个 soft dynamic allocation 功能。只有不持有需要的 shuffle 文件的 executor 可以被删掉。相关配置如下：

spark.dynamicAllocation.enabled=true

spark.dynamicAllocation.shuffleTracking.enabled=true

如果无法分配 pending Pods，我们可以将 k8s 配置为自动缩放。自动缩放在动态资源申请的情况下工作非常好：

如果集群有资源，我们可以在10s内获取一个新的 exec pod；

如果集群需要自动缩放，则需要 1-2 分钟。

为了进一步提高动态分配的速度，我们可以过量使用低优先级的 pause pods 来配置集群：

pause pods 强制 k8s 来动态缩放；

在需要时，Spark pods 将抢占 pause pods 的资源。

Spark on K8S 的场景下，数据的读写一般都是经过对象存储的。云厂商一般会为其对象存储提供写优化的 committers，比如 S3A Committers。

如果没有提供的话，建议使用 Spark 自带的 version 2 committer，可以通过以下参数配置：

spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version=2

如果你有很多文件需要写时，这个配置可以将性能提升近2倍！

I/O 速度对于 shuffle 很重的工作负载来说至关重要，因为 Spark 会将 shuffle 的数据写到本地文件。但是 Docker 的文件系统非常慢，我们可以通过 Kubernetes Volumes 来提升性能。具体参见 https://spark.apache.org/docs/3.0.0-preview2/running-on-kubernetes.html#using-kubernetes-volumes。

监控和安全相关的技巧

我们可以通过 k8s 提供的工具来兼监控 pod 的资源使用情况。比如 Kubernetes dashboard 或者 GKE 控制台。

已知的问题：上面的监控方法比较难与 Spark jobs/stages/tasks 进行协调；当 Spark 应用程序运行完时，Executor 的监控数据将会丢失。

上面的问题我们可以通过按照 Spark 历史服务器来解决。可以将 Spark 的事件日志存放在 S3/GCS/Azoure 存储文件，并配置 spark.eventLog.dir 参数到相关路径。但是这种方式我们无法获取资源使用相关的 metrics！

Data Mechanics 的工程师们开发了 Spark Delight，其可以解决上面的问题。关于 Spark Delight 可以参见 https://towardsdatascience.com/spark-delight-were-building-a-better-spark-ui-1b463840e243。

Spark 利用 DropWizard 类库来产生详细的 metrics。我们可以将这些 metrics 存储到时序数据库中：

InfluxDB

Prometheus，这个在 Spark 3.0 中已经内置支持将监控信息写到 Prometheus 中。

K8S 上的安全较佳实践对 Spark on K8S 来说是可以免费使用的！我们可以进行访问控制、密码配置以及网络安全配置等。

未来工作

Spark on K8S 未来工作主要包括：

Shuffle 相关问题的提升；

更友好的处理节点的关闭；

支持上传本地 python 依赖；

Job 队列以及资源管理。

经过上面的介绍，你是否打算使用 K8S 呢？

如果打算使用Spark-on-Kubernetes，上面的事项是需要你做的。关于 Spark on K8S 的更多内容可以参见 https://spark.apache.org/docs/3.0.0/running-on-kubernetes.html。