深入解析 Spark on Kubernetes 核心原理与架构 – wiki基地

作者： /

深入解析 Spark on Kubernetes 核心原理与架构

引言：云原生浪潮下的数据处理新范式

在数字化转型的浪潮中，Apache Spark 已成为大规模数据处理领域无可争议的王者。然而，随着云原生技术的兴起和 Kubernetes（K8s）一统容器编排江湖，传统的基于 YARN 或 Mesos 的 Spark 部署模式正面临着新的挑战与机遇。将 Spark 迁移到 Kubernetes 之上，不仅仅是一次简单的“容器化”，它代表着数据处理平台向现代化、弹性化、一体化架构演进的必然趋势。

本文将深入剖析 Spark on Kubernetes 的核心工作原理、系统架构、关键技术组件以及最佳实践，旨在为希望在云原生环境中构建高效、稳定、可扩展数据平台的工程师和架构师提供一份详尽的指南。

一、为什么选择 Spark on Kubernetes？动机与优势

在深入技术细节之前，我们必须首先理解促使这一技术融合的强大动因。相较于传统的 YARN 模式，Spark on K8s 提供了以下核心优势：

  1. 资源统一与隔离：在传统架构中，企业往往需要维护两套独立的集群：一套用于运行大数据任务的 YARN 集群，另一套用于运行在线服务、中间件的 Kubernetes 集群。这造成了资源孤岛和运维复杂性。Spark on K8s 实现了真正的资源池统一，所有应用（无论是无状态服务、有状态服务还是大数据作业）共享同一个 K8s 集群。Kubernetes 原生的 Namespace、ResourceQuota、NetworkPolicy 等机制为不同团队、不同类型的 Spark 作业提供了比 YARN 更强大、更精细的资源隔离和安全保障。

  2. 极致的弹性和成本效益：Kubernetes 的弹性伸缩能力是其核心魅力之一。结合云厂商的 Cluster Autoscaler，K8s 集群可以根据负载自动增减节点。对于 Spark 而言，这意味着可以实现真正的按需分配资源。当没有 Spark 作业运行时，计算资源可以被完全释放或缩减至零，供其他应用使用，从而极大地降低了闲置资源成本。Spark 的动态资源分配（Dynamic Resource Allocation）与 K8s 的弹性能力相结合，构成了完美的成本优化闭环。

  3. 强大的生态系统与开发体验：Kubernetes 拥有一个无与伦比的、蓬勃发展的云原生生态系统。无论是监控（Prometheus）、日志（Fluentd/Loki）、服务网格（Istio）、工作流编排（Argo Workflows），都可以无缝地与 Spark on K8s 集成。对于开发者而言，使用 Docker 容器封装依赖，意味着告别了繁琐的环境配置和版本冲突问题。一次构建，处处运行，极大地简化了开发、测试和部署流程，完美契合现代 DevOps 和 CI/CD 理念。

  4. 混合云与多云部署的灵活性：Kubernetes 作为云原生应用的事实标准，屏蔽了底层基础设施的差异。这使得 Spark 作业可以轻松地在不同的公有云、私有云或混合云环境中迁移和部署，避免了厂商锁定，为企业提供了更大的战略灵活性。

二、核心架构与作业执行流程

理解 Spark on K8s 的工作方式，关键在于理解其组件如何映射到 K8s 的原生资源上，以及它们之间如何交互。

核心组件映射

  • Spark Driver：Spark 作业的总控制器（Master），负责任务调度和协调。在 K8s 环境中，Driver 运行在一个独立的 Pod 中。
  • Spark Executor：实际执行计算任务的工作单元（Worker）。每个 Executor 也运行在一个独立的 Pod 中。
  • Kubernetes Master：K8s 集群的控制平面，包括 API Server、Scheduler、Controller Manager 等。Spark Driver 通过与 API Server 通信来请求和管理 Executor Pods。

作业提交流程详解

Spark on K8s 的作业生命周期是一个精心设计的、与 K8s API 深度集成的过程。我们以最常用的 Cluster 模式 为例，分步解析其执行流程：

(这是一个示意图，实际内容在文字中)

  1. 提交作业 (spark-submit)：
    用户在客户端（可以是本地机器、CI/CD Runner 或 K8s 集群内的某个 Pod）执行 spark-submit 命令。与 YARN 不同的是，这里的 master 参数指定为 K8s API Server 的地址，格式通常为 k8s://https://<k8s-api-server-host>:<port>。

  2. Driver Pod 创建请求：
    spark-submit 进程本身并不运行 Driver。它会解析用户的参数（如应用 JAR 包、主类、资源配置等），构造一个用于运行 Spark Driver 的 Pod 定义（Pod Spec），然后通过 K8s API 将这个创建 Pod 的请求发送给 K8s API Server。这个过程完成后，spark-submit 进程就可以退出了，实现了“一次提交，高枕无忧”。

  3. Driver Pod 调度与启动：
    K8s API Server 接收到请求后，将其持久化到 etcd 中。K8s Scheduler 检测到这个新的、未被调度的 Driver Pod，根据集群的资源状况、亲和性/反亲和性规则等，选择一个合适的工作节点（Node），并将 Pod 调度上去。目标节点上的 Kubelet 接收到指令，开始创建 Driver Pod，包括拉取指定的 Docker 镜像、挂载卷、设置环境变量等。

  4. Driver 内部初始化：
    Driver Pod 启动后，其内部的 Spark Driver 进程开始运行。它会初始化 SparkContext 和 KubernetesClusterSchedulerBackend。此时，Driver 已经身处 K8s 集群网络内部。

  5. Executor Pods 请求：
    SparkContext 初始化完成后，Driver 内的 KubernetesClusterSchedulerBackend 会开始向 K8s API Server 直接发起请求，要求创建指定数量的 Executor Pods。它会根据 --executor-cores, --executor-memory 等参数，为每个 Executor Pod 构造相应的资源请求（requests）和限制（limits）。

  6. Executor Pods 调度与启动：
    与 Driver Pod 的创建过程类似，K8s Scheduler 负责为这些 Executor Pods 寻找合适的节点并进行调度。Kubelet 在各自的节点上启动 Executor Pods。

  7. Executor 向 Driver 注册：
    每个 Executor Pod 启动后，其内部的 Executor 进程需要找到并连接到 Driver。这是如何实现的呢？在创建 Driver Pod 的同时，Spark 会自动创建一个 Headless Service，这个 Service 的 DNS 名称是固定的，并且会解析到 Driver Pod 的实际 IP 地址。Executor 启动时，通过环境变量或配置，它知道这个 Service 的地址，从而可以准确地找到 Driver 并完成注册。

  8. 任务执行与数据处理：
    一旦 Executor 注册成功，Driver 就开始向它们分发任务（Tasks）。Executor 执行任务，处理数据（例如从 HDFS、S3 或其他数据源读取数据），并在需要时进行 Shuffle 操作（Executor 之间通过 Pod IP直接通信）。

  9. 作业完成与资源清理：
    当所有任务完成，SparkContext.stop()被调用，Driver 进程正常退出。Driver Pod 的状态变为 Completed。K8s 会自动检测到 Driver 的终止，并根据其 restartPolicy（通常是 Never 或 OnFailure）决定是否保留 Pod。同时，Driver 在退出前会通过 K8s API 删除它所创建的所有 Executor Pods，释放计算资源。

Client 模式 vs. Cluster 模式

  • Cluster 模式 (生产推荐): 如上所述，Driver 运行在 K8s 集群内部的 Pod 中。优点是 Driver 具有高可用性（K8s 可配置重启），与 Executor 处于同一网络环境，通信效率高，并且提交客户端可以随时断开。
  • Client 模式: Driver 运行在 spark-submit 进程所在的机器上（集群外部）。它直接与 K8s API Server 通信来创建 Executor Pods。Executor Pods 启动后，需要反向连接到集群外部的 Driver。这种模式主要用于交互式开发和调试，因为它允许用户在本地 IDE 中直接运行和调试 Driver 代码。其缺点是 Driver 所在机器成为单点故障，且与 Executor 之间的网络延迟和带宽可能成为瓶颈。

三、关键技术深度剖析

要真正掌握 Spark on K8s，必须理解其背后的一些关键技术实现。

1. 资源管理与映射

Spark 的资源请求（--driver-memory, --executor-cores等）被精确地转换为 K8s Pod 的 spec.containers.resources 字段。
* spark.{driver/executor}.memory -> requests.memory 和 limits.memory
* spark.{driver/executor}.cores -> requests.cpu 和 limits.cpu
* spark.kubernetes.memoryOverheadFactor (或 spark.{driver/executor}.memoryOverhead) 用于计算 JVM 堆外内存，这部分会加到 Pod 的内存请求中，以避免 Pod 因超出内存限制而被 K8s OOMKilled。

正确配置这些参数对于作业的稳定性和资源利用率至关重要。

2. 网络模型

网络是 Spark on K8s 中最核心也最容易出问题的部分。
* Driver-Executor 通信：如前所述，通过为 Driver Pod 创建一个 Headless Service 来解决。Executor 使用 spark.driver.host（由系统自动设置为 Service 的 DNS 名称）来发现 Driver。
* Executor-Executor 通信：在需要数据 Shuffle 时，Executor 之间需要直接通信。在 K8s 中，每个 Pod 都有一个唯一的 IP 地址，并且默认情况下 Pod 之间可以直接通过此 IP 通信，这使得 Shuffle 操作可以高效进行。
* 外部访问：如果 Spark 作业需要暴露服务（如 Spark UI 或 Thrift Server），可以通过创建 K8s 的 Service（如 LoadBalancer 或 NodePort）或 Ingress 来实现。

3. 存储与数据访问

  • 应用依赖（JARs/Python files）：

    • 构建自定义 Docker 镜像 (最佳实践): 将所有依赖项，包括应用程序 JAR、Python 文件和第三方库，直接打包到 Spark 的 Docker 镜像中。这保证了环境的一致性和启动速度。
    • 远程依赖：可以通过 spark-submit 的 --jars 或 --py-files 参数指定位于 HDFS、S3、HTTP(s) 等远程位置的依赖文件。Driver 和 Executor Pods 在启动时会下载这些文件。
    • K8s Volume 挂载：可以使用 ConfigMap、Secret 或 PersistentVolumeClaim (PVC) 将配置文件或依赖挂载到 Pod 中。

  • 数据源访问：Spark Pods 就像集群中的任何其他应用一样，通过标准的 Spark Connector 访问 HDFS、S3、GCS 等数据存储。关键在于确保 Pod 拥有正确的网络访问权限和认证凭证（通常通过挂载 Secret 来安全地传递 Key/Token）。

  • Shuffle 数据存储：Shuffle 是 Spark 的性能关键。默认情况下，Shuffle 数据存储在 Executor Pod 的本地磁盘上（emptyDir 卷）。如果 Executor Pod 失败，其 Shuffle 数据会丢失，导致任务重算。对于需要更高稳定性的长作业，可以配置将 Shuffle 数据写入 PersistentVolume，但这会带来额外的网络 I/O 开销。

4. 动态资源分配

这是 Spark on K8s 的一大亮点。启用后 (spark.dynamicAllocation.enabled=true)，Spark 会根据工作负载自动调整 Executor 的数量。
* 工作原理：Driver 内部的 ExecutorPodsAllocator 会持续监控待处理任务队列的积压情况。当积压任务增多时，它会向 K8s API Server 请求创建新的 Executor Pods。反之，当 Executor 空闲一段时间后 (spark.dynamicAllocation.executorIdleTimeout)，ExecutorPodsAllocator 会向 API Server 发出删除该 Executor Pod 的指令。
* 优势：极大地提高了资源利用率，尤其是在负载波动较大的共享集群中。作业只在需要时才占用峰值资源，用完即还。

四、迈向生产：Spark Operator 与最佳实践

虽然 spark-submit 是入门的基础，但在生产环境中，为了实现声明式管理、自动化和更好的可观测性，强烈推荐使用 Spark Operator。

Spark Operator：声明式的 Spark 应用管理

Spark Operator 是一个遵循 Kubernetes Operator 模式的控制器。它引入了一个名为 SparkApplication 的自定义资源定义（CRD）。用户不再需要编写复杂的 spark-submit 命令，而是定义一个 YAML 文件来描述 Spark 作业的全部期望状态。

一个简化的 SparkApplication YAML 示例：
yaml
apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: SparkApplication
metadata:
name: spark-pi-example
namespace: spark-jobs
spec:
type: Scala
mode: cluster
image: "gcr.io/spark-operator/spark:v3.1.1"
mainClass: org.apache.spark.examples.SparkPi
mainApplicationFile: "local:///opt/spark/examples/jars/spark-examples_2.12-3.1.1.jar"
sparkVersion: "3.1.1"
restartPolicy:
type: OnFailure
onFailureRetries: 3
driver:
cores: 1
memory: "512m"
serviceAccount: spark
executor:
instances: 2
cores: 1
memory: "512m"

使用 Operator 的好处：
* 声明式 API：用 Git 管理 Spark 作业的 YAML 文件，完美融入 GitOps 流程。
* 生命周期管理：Operator 负责监控 SparkApplication 对象，并自动完成 spark-submit、状态跟踪、失败重试、垃圾回收等所有工作。
* 简化配置：将复杂的命令行参数转化为结构化的 YAML 字段，更易于理解和维护。
* 原生集成：可以更好地与 K8s 的事件、指标和日志系统集成。

生产环境最佳实践

  1. 构建和管理自定义镜像：为不同类型的作业或团队构建专用的、最小化的 Spark 镜像，预装所有依赖。使用镜像仓库（如 Harbor）进行版本管理。
  2. 精细化资源配置：为 Driver 和 Executor 设置合理的 CPU/Memory requests 和 limits。requests 保证了作业启动所需的最小资源，limits 防止单个作业耗尽节点资源。
  3. 使用节点亲和性/反亲和性：通过 nodeAffinity 将 Spark 作业调度到特定类型的节点（如高内存或带 GPU 的节点）。使用 podAntiAffinity 将 Executor Pods 分散到不同的节点或可用区，提高容错性。
  4. 配置日志和监控：配置 Spark 将日志输出到标准输出（stdout），以便被 K8s 的日志收集系统（如 EFK/ELK/Loki）捕获。使用 Prometheus JMX Exporter 或 Spark 自带的 Prometheus Sink 暴露指标，并通过 Grafana 进行可视化。
  5. 权限管理（RBAC）：为 Spark 作业创建专用的 ServiceAccount，并绑定仅包含必要权限的 Role 或 ClusterRole。最小权限原则是保障集群安全的基础。
  6. 善用动态分配：对于大多数批处理作业，开启动态资源分配以节省成本，并为其设置合理的最小/最大 Executor 数量。

五、结论与展望

Spark on Kubernetes 并非简单的技术叠加，而是一次深刻的架构变革。它将 Spark 强大的分布式计算能力与 Kubernetes 卓越的资源管理和应用编排能力完美融合，为现代数据平台带来了前所未有的统一性、弹性和运维效率。从底层的 Pod 调度、网络通信，到上层的动态资源分配和 Operator 模式，这套体系结构已经日趋成熟，并被越来越多的领先企业采纳为数据处理的首选方案。

未来，我们可以预见 Spark on K8s 将与 Serverless 理念进一步结合，与 Lakehouse 架构深度集成，并融入到更广泛的 AI/ML 工作流中。掌握其核心原理与架构，不仅是跟上技术潮流，更是为构建下一代智能数据平台打下坚实的基础。对于任何致力于数据领域的工程师来说，这都是一条通往未来的必经之路。

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部