大数据集群资源隔离：从逻辑隔离到物理隔离演进

大数据集群资源隔离的核心路径是：先用队列实现逻辑分组，再用 Node Labels 做节点级标签调度，最终通过 K8s 容器化达成物理级别的资源独占。三个阶段并非替代关系，而是逐步叠加——大多数生产集群同时运行着队列隔离和标签调度，部分业务已迁移到容器化环境。

为什么需要资源隔离

当多个业务团队共享同一个 Hadoop 或 Spark 集群时，一个典型的故障模式是：某团队提交的大规模离线批处理任务占满了集群全部资源，导致另一个团队的实时查询任务排队等待、延迟飙升。这种"吵闹邻居"问题在团队规模超过三个、作业类型涵盖批处理和交互式查询时尤为突出。

资源隔离要解决三个层次的问题：配额保障——每个团队获得约定的最小资源量；峰值限制——任何团队不能无限制占用集群资源；故障域隔离——一个业务的异常不会拖垮其他业务。

第一阶段：YARN 队列的逻辑隔离

YARN Capacity Scheduler 提供的层级队列是最基础的隔离手段。通过 capacity-scheduler.xml 中的 yarn.scheduler.capacity.root.queues 配置项，可以定义根队列的子队列结构。例如：

yarn.scheduler.capacity.root.queues=online,offline,default
yarn.scheduler.capacity.root.online.capacity=40
yarn.scheduler.capacity.root.offline.capacity=40
yarn.scheduler.capacity.root.default.capacity=20

这段配置为在线业务、离线批处理和默认队列分别分配了 40%、40%、20% 的集群容量。每个队列可以进一步设置 maximum-capacity（最大容量上限），防止空闲队列的资源被过度借用。

队列隔离通过 queue-mappings 机制将用户或用户组自动映射到指定队列，格式为 u:username:queue_name 或 g:groupname:queue_name。这确保了提交作业时不会误入其他团队的资源池。

队列隔离的局限在于它只在逻辑层面工作。 所有队列的作业仍然运行在同一组物理节点上，共享同一个 JVM 进程空间和文件系统 IO。一个队列中的 Shuffle 操作产生的网络流量会挤占另一个队列的带宽，而 YARN 本身无法对此进行精细控制。此外，Capacity Scheduler 对 CPU 和内存的限制是基于调度层面的逻辑值，不等同于操作系统层面的真实资源隔离。

第二阶段：Node Labels 实现节点级物理隔离

从 Hadoop 2.6 开始，Capacity Scheduler 引入了 Node Labels（节点标签）功能，允许将集群节点划分为不同的分区。每个节点最多分配一个标签（非重叠分区），队列可以通过 accessible-node-labels 属性指定可以使用哪些标签的节点。

典型配置方式：

<property>
  <name>yarn.scheduler.capacity.root.online.accessible-node-labels</name>
  <value>SSD</value>
</property>
<property>
  <name>yarn.scheduler.capacity.root.online.accessible-node-labels.SSD.capacity</name>
  <value>100</value>
</property>

这使得 online 队列的所有作业只能运行在标记为 SSD 的节点上，而 offline 队列则运行在普通磁盘节点上。这已经不再是纯粹的逻辑隔离——不同标签的节点在物理上是分开的，IO 和网络带宽不再共享。

Node Labels 的一个关键设计决策是标签排他性。Hadoop YARN 默认每个节点只能持有一个标签，这意味着节点要么属于 SSD 分区，要么属于普通磁盘分区，不能同时服务两种类型的工作负载。如果需要更细粒度的控制（例如同一个节点上既有 GPU 工作负载又有 CPU 工作负载），就需要借助 Kubernetes 的更灵活机制。

在线离线混部 是 Node Labels 最常见的应用场景。在线业务（如数据服务、API 查询）对延迟敏感但资源需求相对稳定，离线批处理（如 ETL、模型训练）对延迟容忍度高但资源需求波动大。通过标签调度将两类工作负载分配到不同节点组，同时在上层配置允许离线队列弹性借用在线队列空闲资源，可以在保障在线业务稳定性的同时提高整体集群利用率。

然而，Node Labels 的运维复杂度不容忽视。节点标签变更需要重启 ResourceManager 或执行动态刷新命令，标签分配出错可能导致整个分区的作业全部无法调度。此外，标签仅能标识节点的静态属性（如磁盘类型、是否有 GPU），无法动态感知节点的实际负载状态。

第三阶段：K8s 容器化资源隔离

当隔离需求从"同一集群内的队列分组"演进到"不同业务运行在完全独立的资源池中"时，Kubernetes 提供了更彻底的解决方案。

K8s 的资源隔离建立在三个机制之上：

Namespace + ResourceQuota： 为每个业务团队分配独立的 Namespace，通过 ResourceQuota 限制该命名空间下所有 Pod 的 CPU 和内存总量上限，通过 LimitRange 限制单个 Pod 的资源请求和上限范围。这在 API 层面实现了与 YARN 队列类似的配额管理，但作用域是集群级别的所有资源对象，而非仅限于某个调度器管理的计算作业。

cgroup 级别的硬隔离： 容器运行时通过 Linux cgroup 机制在操作系统层面真正限制每个容器的 CPU 使用时间和内存上限。当容器超出 memory limit 时会被 OOM Kill，超出 CPU limit 时会被限流。这与 YARN 仅在调度层面做逻辑约束有本质区别——YARN 无法阻止一个容器实际消耗超出配额的 CPU 时间。

节点亲和性与污点机制： K8s 的 nodeSelector、nodeAffinity 和 taint/toleration 机制可以实现比 YARN Node Labels 更灵活的节点级调度。一个节点可以同时具有多个标签（如 disk=ssd,gpu=a100,zone=cn-east），Pod 可以通过匹配表达式精确选择满足条件的节点子集。污点机制则可以确保特定节点只接受容忍了对应污点的 Pod，实现真正的资源独占。

演进路径的实施建议

从逻辑隔离到物理隔离并非一次性的架构迁移，而是一个渐进过程。以下是常见的演进步骤：

步骤一：梳理业务优先级和资源特征。 将集群上的作业按延迟敏感度分为三级——秒级响应的在线服务、分钟级容忍的交互式分析、小时级容忍的离线批处理。每类业务记录其 CPU、内存、磁盘 IO 的基线消耗和峰值消耗。

步骤二：建立队列层级。 在 YARN Capacity Scheduler 中配置 2-3 个顶层队列，按业务优先级分配 guaranteed capacity。设置 maximum-capacity 防止资源过度借用。通过 queue-mappings 将用户组绑定到对应队列。这一步通常可以在一天内完成，对现有作业零影响。

步骤三：引入 Node Labels 做节点分区。 在集群中选择一批节点打上标签，将高优先级的在线业务队列绑定到这些标签节点。这一步需要滚动重启 NodeManager 以注册标签，建议在业务低峰期执行。

步骤四：评估容器化迁移范围。 对于已经容器化的业务（如基于 Spark on K8s Operator 的作业），逐步迁移到 K8s Namespace 管理的资源池。对于尚未容器化的遗留作业，维持 YARN 管理不变。两种调度器可以共存于同一物理集群，通过不同的节点标签或污点策略划分资源边界。

常见失败模式

队列容量配置不合理。 所有子队列的 capacity 之和必须等于 100%，但实际业务需求可能经常变化。如果离线队列配置了 60% 的 capacity 但大部分时间只使用 20%，剩余 40% 的资源虽然可以被其他队列借用，但这种"借用"在 Capacity Scheduler 下是非保证的——一旦离线队列突发提交大量作业，借用方会被强制释放资源，导致作业失败。

Node Labels 变更导致调度中断。 在集群运行中修改节点标签需要执行 yarn rmadmin --replace-labels，如果新旧标签配置不一致，可能导致部分作业因找不到可用节点而挂起。

K8s Namespace 配置遗漏 LimitRange。 仅设置 ResourceQuota 不设置 LimitRange 时，没有设置 resources.requests 和 resources.limits 的 Pod 仍然可以被调度，导致实际资源消耗不可控。

混部场景下在线业务受影响。 将在线服务和批处理部署到同一物理机时，即使通过 cgroup 做了 CPU 和内存限制，批处理的大规模磁盘 IO 仍然可能影响在线服务的延迟。需要结合 IO cgroup（blkio controller）或物理网络隔离来解决。

关键决策点

选择隔离级别时，核心考量是隔离强度与资源利用率之间的权衡。纯逻辑隔离（队列）的资源利用率最高，因为所有节点可以被所有队列弹性使用，但隔离强度最低。完全物理隔离（独立集群）的隔离强度最高，但资源利用率最低，因为每个集群都需要预留冗余容量。Node Labels 和 K8s Namespace 提供了中间地带——在同一批物理节点上，通过调度策略实现接近物理隔离的效果，同时保持资源的弹性共享能力。