YARN 与 Kubernetes 大数据调度选型指南

在"Spark/Flink 作业跑在 YARN 还是 Kubernetes 上"这个问题上，最直接的答案是：如果你已经有一套稳定的 Hadoop 集群、作业以批处理为主、团队没有容器化经验，YARN 仍然是最低风险的选择；如果你在建云原生平台、需要弹性扩缩、GPU 调度或与微服务混部，Kubernetes 是方向，但要补上它在大数据场景的短板——gang scheduling 和队列公平——通常用 Volcano 或 YuniKorn 这类补充调度器。下面从调度机制差异展开，给出可执行的选型框架。

大数据调度的核心诉求

先明确大数据作业调度和普通微服务调度的区别：

• 队列与多租户：不同团队共用集群，需要容量保证、公平分配和隔离。
• 抢占与优先级：高优作业能拿回被低优作业占用的资源。
• All-or-Nothing：Spark 的 Executor、Flink 的 TaskManager 需要一批 Pod/容器同时就绪才能启动作业，部分就绪等于死锁。
• 弹性：作业高峰低谷明显，资源池能缩能放。
• 可观测性：队列水位、作业资源用量、失败原因要能查。

YARN 调度架构与队列/抢占机制

YARN 由 ResourceManager（RM）、NodeManager（NM）和每个作业的 ApplicationMaster（AM）组成：RM 维护全局资源，NM 管理单节点容器，AM 代表作业向 RM 申请资源。默认的 Capacity Scheduler 支持分层队列：每个队列有容量保证，空闲时可以借用其他队列的容量，高优先级需求可以配置抢占，由 yarn.resourcemanager.scheduler.monitor.enable 开启的 ProportionalCapacityPreemptionPolicy 周期性地把资源从超额队列回收。此外还有 Node Labels 支持按标签（如 GPU、大内存机型）调度，Spark 的动态资源分配配合 Shuffle Service 可以按需伸缩 Executor。从 Hadoop 3.1 开始 YARN 也支持用 Docker 运行容器，但这只是执行方式，调度模型本身不变。

这套机制是多年大数据生产沉淀下来的，优点是多租户语义完整、与 Spark/Flink/Hive/MapReduce 集成深、运维文档多；缺点是它只服务"数据作业"这一类负载，且与云原生生态（容器镜像、网络插件、监控体系）的耦合较弱。

Kubernetes 原生调度在大数据场景的局限

Kubernetes 的 kube-scheduler 是按 Pod 逐个调度的：每个 Pod 独立寻找满足资源条件的节点，它天然没有"一批 Pod 必须同时调度成功"的 gang scheduling 语义，也没有作业级队列、公平份额和容量保证。这带来几个现实问题：

• Spark 作业申请 N 个 Executor Pod，如果集群资源只够 N-1 个，作业会一直等待，而等待的 Pod 又占着资源，形成死锁。
• 多团队共用集群时，没有 YARN 那样的队列公平机制，抢占只能靠 PriorityClass 这种粗粒度手段，且可能直接杀掉正在跑的任务。
• 数据本地性需要靠节点亲和、污点等手动配置，不如 YARN 对 HDFS 本地性的原生感知。
• Spark 动态资源分配在 K8s 上需要额外部署 Shuffle Service，否则 Executor 缩容会导致 Shuffle 数据丢失。

因此，直接用原生 K8s 跑大数据作业，小规模没问题，规模上来后几乎必然要引入补充调度器。

Volcano / YuniKorn 补充调度器

• Volcano：CNCF 托管的批量调度项目，核心是 PodGroup（把一组 Pod 绑定成调度单元）实现 gang scheduling，支持队列、优先级、抢占与资源预留，并针对 Spark、MPI、PyTorch 等框架提供作业插件。它解决的是"K8s 上跑批处理和 AI 训练"的调度语义问题。
• YuniKorn：Apache 孵化项目，源自 Cloudera，目标是给 K8s 提供"YARN 式的队列调度"：分层队列、公平份额（fair share）、抢占、成本感知的 bin-packing，并提供 Spark 适配层，让从 YARN 迁移的团队沿用熟悉的队列模型。

两者可以并存：Volcano 管批量作业的 gang 语义，YuniKorn 管多租户队列的公平性；很多生产环境是"K8s 原生调度 + 其中一个补充调度器"的组合。

多租户、弹性与运维对比

• 多租户：YARN 的队列 + ACL + 用户限制成熟；K8s 用 Namespace + ResourceQuota + LimitRange + PriorityClass + PodDisruptionBudget 组合，隔离粒度更细但需要自己搭，且配额是 namespace 级的静态值，没有队列间的弹性借用。
• 弹性：YARN 本身不扩缩节点，要靠云厂商伸缩组或人工加节点；K8s 的 Cluster Autoscaler / Karpenter 可以按 Pod 需求自动扩缩节点池，这是云上成本优化的核心优势，也是很多人迁移的第一动力。
• 运维：YARN 的运维半径小（一个 Hadoop 集群），日志、监控与 Hadoop 生态一体；K8s 组件多、概念多，但换来的是统一的容器化交付、镜像版本化、Prometheus 监控和与微服务共用的基础设施。
• 混部：K8s 可以把数据作业和在线服务放进同一个资源池，YARN 做不到。

选型决策框架

按场景对号入座：

• 存量 Hadoop 集群 + 批处理为主 + 团队无 K8s 经验 → YARN，把精力花在队列规划和抢占配置上。
• 云原生战略 + 需要弹性 + 与在线服务混部 + GPU 训练 → Kubernetes + Volcano。
• 从 YARN 迁移到 K8s 但不想放弃队列模型 → Kubernetes + YuniKorn。
• 流批混合、已有 Flink 作业且想统一管理 → Kubernetes + Flink Kubernetes Operator，流作业用 native 模式。
• 追求最低运维成本、作业形态固定 → 维持 YARN，不折腾。
• 如果不想自建任何一套：云托管的 Spark/Flink 服务（如 EMR、Serverless 流计算）把调度与集群都封装掉了，适合团队规模小、作业形态标准化的场景，代价是调度细节不可见、成本模型按量计费，选型时要单独作为一个选项评估。

故障模式对比

两类平台各有典型的故障形态，生产环境出问题时的表现往往和文档描述差异很大，需要提前演练：

• YARN：RM 单点是经典风险，需要开启 RM HA（依赖 ZooKeeper 等）；NM 故障后该节点容器由 RM 重新调度，但本地缓存与中间数据会丢失；队列配置错误（容量总和、最大容量、用户限制）会导致作业长期等待，排查依赖 RM UI 的队列视图。
• Kubernetes：kube-scheduler 本身多副本高可用；节点故障时 Pod 会被重新调度，但有状态作业（依赖 PVC 或本地盘）恢复更慢；PriorityClass 抢占可能在任务跑一半时杀 Pod；集群资源碎片化会导致大作业长时间 Pending，需要结合补充调度器与节点池设计。

尤其要演练"资源紧张 + 高优作业抢占"这类组合场景：YARN 是队列级抢占（按策略回收超额队列资源），K8s 是 Pod 级驱逐（可能杀任意低优先级 Pod），两者对作业的影响面完全不同。

迁移路径与混合部署

迁移不要一步到位：先保持 YARN 跑存量作业，在 K8s 上开通新作业。Spark on K8s 迁移的检查清单包括：用 spark-submit --master k8s:// 或 Spark Operator 提交，确认 spark.shuffle.service.enabled 与 K8s Shuffle Service 部署，配置 PVC 或本地盘承载临时数据，验证动态资源分配在容器环境下的行为；Flink 则优先用 Flink Kubernetes Operator 以 Application 模式部署，天然贴合它的 job 生命周期。迁移顺序建议先无状态短作业、再有状态长作业，每个作业保留回滚路径（YARN 版本仍然可用），直到 K8s 侧稳定性与性能达标再逐步下线 YARN 队列。

混合期还要配套两件事：一是监控统一，把 YARN 与 K8s 的作业指标（队列利用率、Pod 调度延迟、任务失败率）汇总到同一套看板，否则无法对比迁移前后的真实收益；二是成本口径统一，K8s 按节点池计费与 YARN 按队列容量计费口径不同，建议按"单位作业的核时消耗"做对比，避免只看集群总账单做出错误判断。