大数据平台多租户资源隔离：YARN 与 K8s 方案对比

大数据平台的多租户资源隔离问题，本质上是在共享集群中保证不同团队或业务线之间互不干扰。YARN Capacity Scheduler 和 Kubernetes Namespace+ResourceQuota 是两种主流方案，它们的设计哲学、适用场景和演进路径截然不同。本文对比这两种方案的核心机制，给出选型决策框架，并提出从 YARN 渐进式演进到 K8s 的实际路径。

YARN Capacity Scheduler 的隔离机制

Capacity Scheduler 是 Hadoop 生态中最成熟的多租户资源管理方案。它通过 Queue（队列）实现逻辑隔离，每个队列配置固定的资源容量配额。

核心配置要素：

Queue 的容量通过 yarn.scheduler.capacity.<queue-path>.capacity 配置，表示该队列占集群总资源的百分比。所有队列的 capacity 之和必须等于 100。通过 maximum-capacity 限制队列的最大可用资源，防止空闲队列的资源被其他队列无限抢占。

以一个典型的三层队列为例。根队列下有两个子队列：production 和 staging。production 分配 70% 的容量，staging 分配 30%。production 下再细分为 data_team（50%）和 algo_team（50%）。这样 data_team 实际可用的集群资源是 70% * 50% = 35%。

资源抢占机制：

Capacity Scheduler 支持三种抢占策略：none（不抢占）、master（仅从同级队列抢占）、user（支持用户级抢占）。生产环境建议使用 master 策略，允许在高优先级队列资源不足时从低优先级队列抢占，但不支持队列内部的用户级抢占，避免队列内矛盾。

YARN 的优势：

成熟稳定，经过大规模生产验证。与 Hadoop 生态组件（Hive、Spark、Flink、MapReduce）深度集成，资源调度透明。支持 Dominant Resource Fairness（DRF）算法，在多维度资源（CPU、内存、GPU）之间做公平分配。配置粒度可以到队列级别、用户级别、应用级别三层。

YARN 的局限：

隔离粒度粗。YARN 的隔离主要是资源配额层面的，无法做到容器级别的网络隔离和存储隔离。不同队列的容器可以访问相同的 HDFS 路径和网络端口。运维复杂度高。Queue 的配置分散在 capacity-scheduler.xml 和各组件的配置文件中，多租户策略的变更需要重启 YARN 和相关服务。弹性不足。maximum-capacity 的限制是硬性的，即使集群空闲，空闲资源也无法被其他队列利用（除非开启 enable-user-limit-virtual-node 等实验性特性）。

对于已经建立 Hadoop 技术栈的团队，EasyMR 提供了多团队集群管理能力，内置 YARN 队列的可视化配置和资源监控，降低了多租户管理的运维门槛。

Kubernetes Namespace + ResourceQuota 的隔离机制

Kubernetes 原生的多租户隔离通过 Namespace 实现逻辑隔离，配合 ResourceQuota 和 LimitRange 实现资源限制。

Namespace 隔离：

每个租户分配独立的 Namespace，所有资源（Pod、Service、ConfigMap、Secret）都在 Namespace 内创建和管理。不同 Namespace 之间的资源默认不可见，需要显式的 RBAC 授权才能跨 Namespace 访问。

ResourceQuota 配置：

ResourceQuota 限制 Namespace 内的资源总量。典型的配置包括 CPU 请求量上限（requests.cpu）、内存请求量上限（requests.memory）、Pod 数量上限（pods）、服务数量上限（services）等。当资源配额耗尽时，新 Pod 创建请求会被拒绝。

LimitRange 配置：

LimitRange 控制单个 Pod 或容器的资源上下限。配合 ResourceQuota 使用，可以防止单个 Pod 独占 Namespace 的所有配额。典型的配置是设置容器的 CPU requests 为 100m 到 1000m，memory requests 为 128Mi 到 4Gi。

K8s 的优势：

隔离粒度细。除了 CPU 和内存，还可以通过 NetworkPolicy 实现网络隔离，通过 PVC 和 StorageClass 实现存储隔离。生态丰富。Helm Chart、Operator、CI/CD 流水线等工具链成熟，租户管理可以高度自动化。弹性好。ResourceQuota 配合 Cluster Autoscaler 可以实现集群级别的自动扩缩容，空闲资源不会被浪费。

K8s 的局限：

大数据组件的 K8s 原生支持参差不齐。Spark on K8s 已经比较成熟，Flink on K8s 也有稳定的 Operator 支持，但 Hive、Presto 等组件的 K8s 部署和管理仍然比较复杂。网络策略配置不当会导致性能问题。NetworkPolicy 的实现依赖底层 CNI 插件（如 Calico、Cilium），配置过于严格可能影响组件间的正常通信。学习曲线陡峭。YARN 的运维团队需要额外掌握 Kubernetes 的概念和工具链。

选型决策框架

选择 YARN 的场景：团队的技术栈以 Hadoop 生态为主，Spark、Hive、Flink 是主要计算引擎。对隔离的要求主要是资源配额层面，不需要网络和存储级别的隔离。运维团队对 YARN 运维经验丰富，不愿承担 K8s 的迁移成本。

选择 K8s 的场景：团队已经在使用或计划迁移到 K8s。计算引擎多样化，包括在线服务和离线批处理。需要细粒度的网络和存储隔离。追求更灵活的资源弹性。

混合架构：很多团队处于过渡期，需要同时支持 YARN 和 K8s 两种资源管理方式。这种情况下，可以用统一的资源管理层（如 YCOS 等平台）来屏蔽底层差异，提供一致的多团队集群管理界面。关键是在资源视图层面实现统一，让上层用户不感知底层调度器的差异。

渐进式演进路径

完全从 YARN 迁移到 K8s 是高风险操作，建议分四个阶段渐进式推进。

第一阶段：评估与试点。选择一个新上线的、非核心的计算任务，以 K8s 方式部署。验证网络策略、资源配额、存储挂载等基础能力。这个阶段通常需要 1 到 2 个月。

第二阶段：Spark on K8s 替换。将 YARN 上的 Spark 任务逐步迁移到 K8s。Spark 原生支持 K8s 调度，迁移成本相对较低。优先迁移批处理任务，再迁移交互式查询任务。保留 YARN 集群用于 Hive 和 Flink。

第三阶段：Flink on K8s 替换。Flink on K8s 需要部署 Flink Kubernetes Operator，配置 JobManager 和 TaskManager 的资源模板。这个阶段要重点验证 Checkpoint 和 Savepoint 的可靠性，以及与外部系统（Kafka、数据库）的网络连通性。

第四阶段：下线 YARN。当所有计算任务都迁移到 K8s 后，逐步缩减 YARN 集群规模，最终下线。这个阶段要确保有完善的回滚方案，一旦 K8s 集群出现稳定性问题，可以快速恢复到 YARN。

每个阶段之间设置至少一个月的稳定期，确认上一阶段无问题后再推进下一阶段。在迁移过程中，保持两个集群并行运行，通过统一的管理平台进行资源分配和监控，避免出现管理盲区。