Apache Spark 与 Kubernetes？或两者？在过去的几年里，使用 Spark on Kubernetes (K8s) 的公司数量急剧增加。考虑到 K8s 带来的好处，这并不奇怪。根据我们最近的调查，77% 的企业正在采用 Kubernetes 技术来提高资源利用率并减少云费用。

在向云的广泛迁移的推动下，在 Kubernetes 上部署 Spark 的公司数量正在增长。然而，公司应该知道以这种方式在 Kubernetes 上运行 Spark 有其缺点。使用 Kubernetes 运行 Spark 的企业必须准备好应对此解决方案带来的挑战。最重要的是，他们需要对其基础架构具有可观察性，并轻松优化其性能的多个方面。

Spark 是一种开源分析引擎，旨在处理大量数据。它为用户提供了一个统一的接口，用于使用数据并行性和容错对整个集群进行编程。 Kubernetes 是一个开源容器编排平台，可自动执行计算机应用程序部署、扩展和管理。

将 Kubernetes 上的 Apache Spark 想象成这样：Spark 提供计算框架，而 Kubernetes 管理集群。 Kubernetes 为用户提供了一种用于管理多个集群的操作系统。因此，该技术提供了卓越的集群使用和分配灵活性，从而节省了大量成本。

没有 Spark 与 Kubernetes 的争论。我们建议企业在 Kubernetes 上部署 Spark，因为与在 YARN 上运行 Spark 相比，这是一种更符合逻辑和实用的方法。一方面，Spark K8s 环境没有 YARN 的限制。 YARN 的集群很复杂，消耗的计算资源比作业所需的多。此外，用户需要为 YARN 中的每个作业创建和拆除集群。这种设置不仅会浪费大量资源，转化为更多成本，还会导致任务管理效率低下。

另一方面，Kubernetes在大数据场景中爆发，几乎触及了包括Spark在内的所有企业技术。随着其日益流行和无处不在，以及其用户社区的迅速扩大，Kubernetes 将取代 YARN 成为世界主要的大数据处理引擎。

Spark 与 Kubernetes 的争论是否有道理？最近的趋势表明我们正朝着这个方向前进。

许多 Spark 用户指出了在 Kubernetes 上运行 Spark 作业比 YARN 有优势。首先，将 Spark 应用程序部署到组织现有的 Kubernetes 基础设施中并不困难。这导致跨多个软件交付团队的努力和目标快速无缝地对齐。

其次，最新的 Spark 版本 (3.2) 已经解决了 Kubernetes 之前的性能和可靠性问题。使用 Kubernetes 管理 Spark 作业可带来更好的性能和成本节约，超过 YARN 提供的功能。 Amazon 进行的多次测试表明，使用 Kubernetes 而非 YARN 可节省 5% 的时间。

在 K8s 上运行 Spark 的其他好处现在正在显现。但企业应该采用 Kubernetes 的最大原因是什么？企业和云供应商已经通过 CNCF（云原生计算基金会）表达了对该框架的支持。 Kubernetes 上的 Spark 简直就是大数据分析的未来。

是的。当您在 Kubernetes 上运行 Spark 时，Spark 会生成一个在 Kubernetes pod 内部运行的 Spark 驱动程序。然后驱动程序创建执行器，这些执行器在 Kubernetes pod 中运行，连接到它们，并实现应用程序代码。

一旦应用程序完成，执行器 pod 就会终止。然后这些被清理，但驱动程序 pod 继续记录并在 Kubernetes API 中保持“完成”状态。它一直保持这种状态，直到最终成为收集或手动清理的垃圾。

企业正在采用 Spark Kubernetes 设置来提高云资源的利用率。 Spark Kubernetes 动态分配资源有助于简化云流程并缩短部署时间。根据我们的调查，近 30% 的企业转向 Kubernetes 以实现高效的资源利用。最重要的是，超过 17% 的受访者表示他们采用了 Kubernetes Spark，旨在加快他们的应用程序部署周期。

软件工程师、开发人员和 IT 专家都喜欢 Spark，因为它能够以比 MapReduce 框架快 100 倍的速度实施和执行计算任务。

现在，如果他们使用 Spark Kubernetes 方法，由于容器化，迭代周期最多可加快 10 倍，五分钟的开发工作流程报告可缩短至 30 秒。 Spark Kubernetes 动态分配不仅导致处理量急剧增加，使用 Kubernetes 的容器化也不像硬件级虚拟化那样占用资源。

对于 Kubernetes Spark 项目来说，混合可用于数据处理和 Spark 作业编排的不同元素是很常见的。当用户将这些 Spark 组件作为类似 Kubernetes 集群中的工作负载运行时，这些组件可以包括各种后端和 Spark SQL 数据存储（仅举几例），从而获得更好的性能。这是因为 Kubernetes 确保每个工作负载都有足够的资源和与所有依赖项的连接，无论是在同一个集群中还是在集群外。

在大数据、云计算、按需付费的时代，每个企业都想降低成本。这就是为什么许多企业希望通过 K8s Spark 来实现高效的资源共享和利用。

在我们调查的 IT 领导者中，近 30% 正在考虑使用 Kubernetes 来帮助降低他们的云成本。在 K8s 上运行 Apache Spark 已被证明可以通过完全隔离和强大的资源共享帮助企业大幅降低云成本。
这种成本降低是如何发生的？用户可以将所有应用程序部署在一个 Kubernetes 集群中。当应用程序完成时，Kubernetes 可以快速拆除其容器并将资源快速重新分配给另一个应用程序，并根据 Spark 指标和其他性能基准优化 Spark Kubernetes 配置。整个过程只需要 10 秒钟就可以将资源转移到其他地方。

那么我们说的是节省多少呢？在一个案例中，一家公司在从 YARN 切换到 Kubernetes 模型上的 Spark 后削减了 65% 的云成本。

Kubernetes 对于统一的 IT 基础架构越来越重要，而 Spark 是第一个迁移到云端的大数据应用程序。然而，Spark 应用程序往往效率很低。

这些低效率表现在各种方面。我们向受访者询问了他们在流程中使用 Kubernetes Spark 设置时面临的主要挑战。以下是他们最大的三个绊脚石：

初始部署

一些 Spark 挑战阻碍了成功实施。我们的调查将初始部署列为受访者在 Kubernetes 上运行 Spark 时面临的最大挑战。技术很复杂。对于那些不熟悉 Kubernetes Spark 平台的人来说，框架、语言、工具等可能会让人望而生畏。

在 Kubernetes 基础设施上大规模运行 Spark 应用程序需要大量的技术专业知识。即使那些具有丰富 Kubernetes 知识的人也认识到在部署之前需要构建一些部分，例如集群、节点池、spark-operator、K8s 自动缩放器、docker 注册表等。

移民

迁移到 Kubernetes 可以让您的企业处于优势地位，就像迁移到云端或采用大数据一样。但这只有在您在迁移之前有一个健全而强大的策略时才有可能。迁移到 Kubernetes 可能很困难（或导致彻底失败）的众多原因之一是，领导者决定采用一项技术，但没有明确的理由进行如此大的迁移。

此外，许多企业在其组织内不具备必备技能。在 K8s 架构上切换到 Spark 需要相当多的人才才能使过渡顺利和成功。忽略或未能识别应用程序或基础架构的潜在问题，例如扩展或可靠性，可能会导致迁移挑战。

监控和警报

Kubernetes 是一项复杂的技术，监控可能很困难。当您将 Spark 与 Kubernetes 结合使用时更是如此。选择合适的工具来监控和评估您的 Kubernetes 实施增加了这种复杂性。根据我们的调查，28% 的受访者使用手动方法或自行开发的解决方案，而 27% 的受访者利用应用程序性能监控 (APM) 软件。

性能监控和优化已经超出了人类的能力范围。通用 APM 通常未设计或配置为处理 K8s 工作负载和其他大数据基础设施上的大型 Spark。有效而强大的 Kubernetes 和 Spark 监控现在需要全面而强大的工具，这些工具专为 Kubernetes 上的大数据工作负载而设计。

随着 Spark Kubernetes 设置的优势变得更加明显，整个 Spark 与 Kubernetes 的争论已经退居二线。在 Kubernetes 上运行 Spark 有效地实现了加速产品周期和持续运营。

数据科学和机器学习技术的扩展加速了容器化的采用。这一发展有效地推动了 Spark on Kubernetes 方法成为数据集群和建模生态系统的首选设置。 Spark on Kubernetes 为用户提供了抽象弹性 GPU 和 CPU 的能力，以及它的按需可扩展性。