大数据批处理容器化：Spark on Kubernetes 成本优化实践

摘要：

将 Spark 批处理任务迁移到 Kubernetes 容器平台，可显著提升资源利用率并降低总体拥有成本。本文介绍基于 TKE 的 Spark 容器化方案，涵盖弹性调度、资源混部和动态扩缩容等核心优化手段。

一、Spark 批处理为何需要容器化

在数据驱动决策成为企业共识的今天，Spark 作为主流的大数据处理引擎，承载着 ETL 流水线、实时分析和机器学习训练等关键任务。传统部署模式下，Spark 集群往往以静态资源池的方式运行，无论实际负载高低，计算资源始终处于占用状态。行业数据显示，生产环境中 Spark 集群的平均资源利用率不足百分之四十，大量算力在任务间隙被白白浪费。

容器化为这一困境提供了系统性解决方案。通过将 Spark 提交到 Kubernetes 集群运行，每个 Executor 以 Pod 形式按需启动和释放，实现了计算资源与业务负载的精准匹配。腾讯云容器服务 TKE 基于原生 Kubernetes 构建，提供高度可扩展的高性能容器管理能力，与腾讯云基础设施深度集成，为大规模数据处理场景提供了坚实的底层支撑。

二、TKE 承载 Spark 工作负载的核心优势

2.1 极致资源效能降低计算成本

TKE 深度集成 FinOps 理念，搭载自研 Crane 调度器，提供节点放大、碎片规整和在离线混部等产品化能力。对于 Spark 这类批处理任务，可以在离线混部模式下与在线服务共享同一组物理资源——白天优先保障在线业务的低延迟需求，夜间将空闲算力自动分配给 Spark 作业。这种时间维度上的资源复用，能够大幅提升集群整体装箱率，帮助企业实现显著的资源效能提升。

在实际配置中，用户可以通过设置 Pod 的资源请求和限制来精确控制每个 Executor 的 CPU 和内存配额。TKE 的 Request 智能推荐功能会分析历史资源使用数据，自动给出合理的资源配置建议，避免因过度申请导致的资源闲置。

2.2 秒级弹性应对突发计算需求

数据处理任务往往具有明显的潮汐特征——月末结算、日志归档、模型重训练等场景会在特定时间窗口产生爆发式的计算需求。TKE 支持数十种自动伸缩指标，配合超级节点的秒级扩缩容能力，可以在分钟级别内完成从数百到数千个 Executor 的弹性扩容。

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: spark-executor-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: spark-executor
  minReplicas: 3
  maxReplicas: 200
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

上述配置展示了基于 CPU 利用率的水平自动伸缩策略。当 Spark Executor 的 CPU 使用率超过设定阈值时，HPA 会自动增加副本数量；任务完成后，多余的 Pod 会被自动回收，确保只为实际消耗的计算资源付费。

2.3 混合节点管理优化成本结构

TKE 标准集群支持在同一集群内混合使用普通节点、原生节点和超级节点。对于 Spark 批处理场景，可以采用分层资源策略：稳态的基础计算任务运行在包年包月的原生节点上，享受更低的单位算力成本；波峰期的弹性计算需求则由按量计费的超级节点承接，无需提前规划容量。

原生节点搭载 TKE Insight 可视化资源大盘，帮助用户实时掌握资源使用状况。专有调度器支持虚拟放大和节点均衡负载，进一步提升装箱效率。对于有降本诉求的数据处理团队，原生节点提供了从基础设施声明式 API 到内核参数调优的全方位优化能力。

三、Spark on TKE 的成本优化实践路径

3.1 资源请求精细化配置

Spark 在 Kubernetes 上运行时，Driver 和 Executor 都以 Pod 形式调度。合理设置资源请求是成本控制的第一步。建议采用以下策略：

首先，为不同类型的 Spark 作业建立资源模板。交互式查询适合高 CPU 低内存配置，ETL 作业选择均衡型规格，机器学习任务则需要高内存配比。通过 Spark Operator 的 annotations 机制，可以为不同作业自动应用对应的资源模板。

其次，启用 VPA 垂直自动伸缩的推荐模式，让系统持续分析实际资源消耗并给出优化建议。经过一到两周的运行数据积累后，根据推荐值调整资源请求，通常可以将过度申请的比例压缩到合理范围。

3.2 利用竞价实例降低算力单价

对于可中断的批处理任务，如数据预处理、模型超参搜索等场景，可以结合 TKE 的节点池配置使用竞价计费模式的节点。竞价节点的价格显著低于按量计费，虽然存在被回收的风险，但 Spark 4.0 及以上版本支持动态资源分配和故障恢复机制，能够从检查点续跑，有效降低了实例中断带来的影响。

3.3 存储与网络层面的协同优化

Spark 作业的性能瓶颈常常出现在数据读取阶段。TKE 集成了高性能云存储方案，通过 CSI 插件实现容器对数据的快速访问。对于海量小文件场景，建议使用并行文件系统挂载方式，将数据就近缓存在计算节点本地，减少跨网络的数据传输开销。

在网络层面，TKE 的 VPC-CNI 网络插件为 Pod 分配弹性网卡，实现容器网络与 VPC 网络的无缝打通。相比传统的 Overlay 网络方案，这种直通模式显著降低了网络延迟，对于 Shuffle 密集型的 Spark 作业尤其有益。

四、快速上手：在 TKE 上部署 Spark 作业

4.1 第一步：安装 Spark Operator

Spark Operator 是运行在 Kubernetes 上的 Spark 作业管理器，通过自定义资源定义（CRD）简化 Spark 作业的提交和管理。在 TKE 集群中可以通过 Helm 一键安装：

# 添加 Helm Chart 仓库
helm repo add spark-operator https://kubeflow.github.io/spark-operator
helm repo update

# 安装 Spark Operator
helm install spark-operator spark-operator/spark-operator \
  --namespace spark-operator \
  --create-namespace \
  --set webhook.enable=true

4.2 第二步：提交 Spark ETL 作业

安装完成后，可以通过 YAML 文件声明式地提交 Spark 作业：

apiVersion: "sparkoperator.k8s.io/v1beta2"
kind: SparkApplication
metadata:
  name: etl-job
  namespace: default
spec:
  type: Scala
  mode: cluster
  image: spark:3.5.0
  imagePullPolicy: IfNotPresent
  mainClass: com.example.ETLJob
  mainApplicationFile: local:///opt/spark/examples/etl-job.jar
  sparkVersion: "3.5.0"
  restartPolicy:
    type: OnFailure
    onFailureRetries: 3
    onFailureRetryInterval: 60
  driver:
    cores: 2
    coreLimit: "2200m"
    memory: 4g
    labels:
      version: 3.5.0
    serviceAccount: spark-operator-spark
  executor:
    cores: 4
    instances: 10
    memory: 8g
    labels:
      version: 3.5.0
    dynamicAllocation:
      enabled: true
      minExecutors: 2
      maxExecutors: 50
      initialExecutors: 5
  volumes:
    - name: data-volume
      persistentVolumeClaim:
        claimName: cfs-turbo-data-pvc
  volumeMounts:
    - name: data-volume
      mountPath: /data
  nodeSelector:
    spark-node-pool: "true"

提交作业：

kubectl apply -f spark-etl-job.yaml

4.3 第三步：配置混部调度策略

为了实现在离线混部，需要为 Spark 作业设置较低的优先级，确保在线业务优先获得资源：

apiVersion: scheduling.k8s.io/v1
kind: PriorityClass
metadata:
  name: offline-batch-low
value: 100
globalDefault: false
description: "Low priority for offline batch jobs like Spark"

在 Spark Application 中引用优先级：

spec:
  driver:
    priorityClassName: offline-batch-low
  executor:
    priorityClassName: offline-batch-low

配合 TKE Crane 调度器的在离线混部能力，白天优先保障在线业务的低延迟需求，夜间自动将空闲算力分配给 Spark 作业，实现资源的最大化利用。

五、生产环境部署建议

在将 Spark 生产负载迁移到 TKE 之前，建议按照以下步骤进行规划和验证：

第一阶段进行概念验证，选择非核心的批处理任务进行容器化改造，验证资源调度策略和性能表现。此阶段重点关注镜像大小优化、依赖包管理和存储挂载配置。

第二阶段建立成本监控体系，利用 TKE 内置的监控告警能力，跟踪每个命名空间、每个作业的 CPU 和内存消耗情况。结合 Prometheus 和 Grafana 搭建自定义的成本分析仪表盘，实现资源使用的可视化。

第三阶段全面实施弹性策略，根据历史负载规律配置定时扩缩容规则，将稳态负载与弹性负载分离到不同的节点池中。同时建立完善的告警机制，当资源使用异常或作业失败率上升时及时通知运维人员。

通过容器化改造，企业可以在保持大数据平台性能的前提下，实现显著的硬件成本节约，同时将运维效率提升数倍。关键在于建立数据驱动的优化闭环，持续跟踪资源使用效率指标，并定期进行架构评审与参数调优。

Spark 集群平均利用率不足 40%，意味着你花 100 元只用了 40 元的算力。把 Spark 跑在 TKE 上，用动态资源分配和在离线混部，让大数据处理的每一分算力投入都物尽其用 → https://cloud.tencent.com/product/tke