Kubernetes支持仅在最近才为Spark添加。与其他部署模式相比，它是否值得？

... > Traditional software engineering is shifting towards k8s. Will Spark follow? (Photo by Fabio, Unsp

Apache Spark是一个开源的分布式计算框架。在几行代码（在Scala，Python，SQL或R中）中，数据科学家或工程师定义了可以处理大量数据的应用程序，Spark负责并行处理跨机器集群的工作。

Spark本身不管理这些机器。它需要一个集群管理器（有时也称为调度程序）。主要的集群管理器是：

· 独立服务器：简单的集群管理器，功能有限，内置于Spark。

· Apache Mesos：一个开源的集群管理器，曾经在大数据工作负载（不仅是Spark）中很流行，但在最近几年中呈下降趋势。

· Hadoop YARN：hadoop的基于JVM的群集管理器，于2012年发布，是迄今为止最常用的，用于内部部署（例如Cloudera，MapR）和云（例如EMR，Dataproc，HDInsight）部署。

· Kubernetes：自版本Spark 2.3（2018）起，Spark在Kubernetes上本地运行。这种部署模式以及企业的支持（Google，Palantir，Red Hat，Bloomberg，Lyft）正在迅速获得关注。截至2020年6月，它的支持仍被标记为试验性的。

作为新手，Kubernetes周围有很多炒作。在本文中，我们将介绍Spark-on-k8的核心概念，并评估这种新部署模式的优缺点。

核心概念

您可以使用spark-submit或使用spark-operator提交Spark应用程序-后者是我们的偏爱，但我们将在以后的教程中讨论它。该请求包含完整的应用程序配置，包括要运行的代码和依赖项（打包为docker图像或通过URI指定），基础结构参数（例如，分配给每个Spark执行程序的内存，CPU和存储卷规格），以及 Spark配置。

Kubernetes接受此请求，并在Kubernetes容器（k8s抽象，在这种情况下只是一个docker容器）中启动Spark驱动程序。然后，如果启用了动态分配，Spark驱动程序可以直接与Kubernetes主节点进行对话以请求执行者Pod，并在运行时根据负载对其进行缩放。 Kubernetes负责将Pod打包到Kubernetes节点（物理VM）上，并将动态扩展各种节点池以满足要求。

更深入一点，Spark的Kubernetes支持主要依赖于Spark驱动程序中的KubernetesClusterSchedulerBackend。

此类跟踪当前注册的执行者的数量以及所需的执行者总数（通过固定大小的配置或动态分配）。定期（由spark.kubernetes.allocation.batch.delay配置），它将请求创建或删除执行程序容器，并在完成其他请求之前等待该请求完成。因此，该类实现了Kubernetes爱好者所珍视的"期望状态原则"，它主张声明性而非命令性声明。

优点-Kubernetes上Spark的好处

1.货柜化

这是使用Kubernetes本身的主要动机。传统软件工程中的容器化优势同样适用于大数据和Spark。容器使您的应用程序更具可移植性，它们简化了依赖关系的包装，它们使可重复且可靠的构建工作流成为可能。它们减少了整体devops负载，并允许您更快地迭代代码。

我最喜欢的好处是依赖管理，因为它对Spark造成了极大的痛苦。您可以选择为每个应用程序构建一个新的docker图像，或者使用打包大部分所需库的较小的docker图像集，并在顶部动态添加特定于应用程序的代码。告别每次启动应用程序时都会编译C库的冗长且不稳定的初始化脚本。

2.融入丰富的生态系统

... > A representation of the rich Kubernetes Ecosystem built by Spotinst

在Kubernetes上部署Spark可免费提供强大的功能，例如使用名称空间和配额进行多租户控制，以及基于角色的访问控制（可选地与云提供商IAM集成）以实现细粒度的安全性和数据访问。

如果您的需求不在k8s范围内，那么社区非常活跃，您很可能会找到满足此需求的工具。如果您已经将Kubernetes用于其余的堆栈，则这一点尤其重要，因为您可能会重复使用现有工具，例如用于基本日志记录和管理的k8s仪表板，以及用于监视的prometheus + grafana。

3.高效的资源共享

在其他群集管理器（YARN，独立服务器，Mesos）上，如果您想为并发Spark应用程序重用同一群集（出于成本原因），则必须在隔离上做出妥协：

· 依赖隔离。这些应用必须使用相同的全局Spark和python版本。

· 性能隔离。如果其他人开始一份大工作，我的工作可能会变慢。

另一方面，通过正确配置动态分配和集群自动扩展，Kubernetes将为您带来共享基础架构的成本优势以及对不相交容器集的完全隔离。 Kubernetes从一个应用程序中删除一个空闲的Spark执行程序并将此容量分配给另一个应用程序大约需要10秒钟。

告别YARN部署的复杂负载平衡，队列和多租户权衡！

缺点-Kubernetes上Spark的缺点

1.使Spark-on-k8大规模可靠需要构建时间和专业知识

如果您是Kubernetes的新手，它引入的新语言，抽象和工具可能会令人恐惧，并使您脱离核心任务。即使您已经拥有Kubernetes的专业知识，也有很多东西可以创建：

· 创建和配置Kubernetes集群及其节点池

· 设置火花操作器和k8s自动定标器（可选，但建议使用）

· 设置Docker注册表并创建一个流程来打包您的依赖项

· 设置Spark历史记录服务器（在应用程序完成后查看Spark UI）

· 设置您的日志记录，监视和安全工具

· 优化Kubernetes的应用程序配置和I / O

这些问题大多无法通过云提供商的托管Kubernetes产品解决。

2.混洗架构造成的动态分配限制

... > How shuffle works in Spark (Source)

随机播放是在Spark中进行的昂贵的所有通讯步骤。执行程序（在映射方面）在本地磁盘上生成随机播放文件，稍后将由其他执行程序（在reduce方面）将其提取。如果丢失了映射执行器，则关联的随机播放文件也将丢失，并且映射任务将重新安排在另一个执行器上，这会影响性能。使用YARN，可以将随机播放文件存储在外部随机播放服务中，这样，在启用动态分配后，可以在缩减事件中安全地删除映射执行程序，而不会丢失宝贵的随机播放文件。

由于复杂的原因-这将是以后的主题-在Kubernetes上无法使用相同的架构。结果，动态分配必须在一个附加约束下进行操作：保存活动的shuffle文件的执行程序（由Spark驱动程序跟踪）免于缩减。 Spark 3.0（预览版）版本提供了这种"软动态分配"，它已成功为我们的客户缓解了此问题。

正在进行的激动人心的工作将进一步发展，并创建一种洗牌架构，其中计算资源（k8s节点和容器）与临时洗牌数据存储完全分开。一旦完成，这项工作将比外部洗牌服务更进一步，因为它将实现"硬动态分配"，并使Spark能够抵抗执行程序的突然丢失（在使用现货/抢先式虚拟设备时，这是一个经常出现的问题。机器）。

结论—您应该开始吗？

请注意，我对这个答案有偏见，因为他是部署在Kubernetes上的托管Spark平台Data Mechanics的创始人。近年来，向容器化和Kubernetes的重大转变已经接管了传统软件工程界，带来了关键的好处和良好实践（包括依赖管理，与云无关的接口，声明性基础结构，强大的CI / CD和测试工具）。

在Data Mechanics，我们认为大数据领域正在发生类似的转变，因此我们相信Spark-on-Kubernetes是Spark的未来。如果您要启动一个新的Spark项目，我们相信在Kubernetes上运行是不费吹灰之力的：我们所描述的优点已经克服了缺点，并且尚在积极地进行一些其他限制。

这是否意味着每个数据团队都应该成为Kubernetes专家？否。正是出于这个原因，我们创建了数据力学。我们的平台解决了我们先前概述的主要缺点：我们完成了所有设置工作，将最佳的开源项目组合在一起，以构建您自己构建的Spark平台，并在其顶部添加了强大的优化功能。因此，在我们处理开发人员/基础架构工作的同时，数据科学家和工程师可以专注于其核心任务。查看我们的网站以了解更多信息，并让我们知道您的反馈！

(本文翻译自Jean Yves的文章《The Pros and Cons of Running Apache Spark on Kubernetes》，参考：https://towardsdatascience.com/the-pros-and-cons-of-running-apache-spark-on-kubernetes-13b0e1b17093)

程序员