Spark on K8S 的最佳实践和需要注意的坑-白红宇的个人博客

发布日期：2021-06-30 11:28:42 浏览次数：2 分类：技术文章

本文共 3469 字，大约阅读时间需要 11 分钟。

本文来自 Data Mechanics 的 CEO Jean-Yves Stephan 和 CTO Julien Dumazert 在 Spark Summit North America 2020 的《Running Apache Spark on Kubernetes: Best Practices and Pitfalls》议题的分享。相关视频参见，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=truespark.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 Hadoop 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。‍‍‍