共计 4694 个字符，预计需要花费 12 分钟才能阅读完成。
导语 | 传统 HADOOP 生态系统应用 YARN 治理 / 调度计算资源，该零碎⼀般具备显著的资源使⽤周期。实时计算集群资源耗费次要在⽩天，而数据报表型业务则安顿在离线计算集群中。离在线业务离开部署的首要问题就是资源使用率低，耗费老本⾼。随着业务的增⻓和突发的报表计算需要，为了解决为离线集群预留资源，腾讯云 EMR 团队和容器团队联合推出 Hadoop Yarn on Kubernetes Pod，以提⾼容器资源使用率，升高资源老本，将闲时容器集群 CPU 使⽤率晋升数倍之多。本文次要介绍 HADOOP 资源调度器 YARN 在容器环境中的优化与实际。
一、Hadoop Yarn on Kubernetes Pod 混合部署模式
Hadoop Yarn on Kubernetes Pod 计划提供弹性扩缩容和离在线混合部署两项性能。弹性扩缩容次要聚焦于如何利⽤云原生资源，疾速扩容资源以补充算力。离在线混合部署模式的目标是为了充沛应用在线集群的闲暇资源，尽可能减少为离线集群预留闲暇资源的频次。
EMR 弹性扩缩容模块（yarn-autoscaler）提供按负载和按工夫弹性伸缩两种扩缩容形式。对于按负载伸缩，用户能够对不同指标设置阈值来触发扩缩容，比方设置 Yarn 队列中 availablevcore、pending vcore、available mem、pending mem。亦能够应用工夫扩缩规定，按天、按周、按月等规定指定触发。
当弹性规定被触发后，离在线部署模块获取以后在线 TKE 集群中能够提供的闲置算力的规格及数量，调用 Kubernetes api 创立对应数量的资源，ex-scheduler 扩大调度器确保 Pod 被创立在残余资源更多的节点上，该 POD 负责启动 YARN 的服务。
通过该计划，Yarn 的 NodeManager 服务能够疾速部署到 POD 节点中。但也 Yarn 原生调度没有思考异构资源，由此引发了两个问题：
1. AM 的 POD 被驱赶，导致 APP 失败
在 node 节点的资源紧缺的条件下，kubelet 为了保障 node 节点的稳定性，回触发被动驱赶 pod 的机制。如果该节点存在 AM 服务，则整个 Application 就要被视为失败，ResourceManager 此时会重新分配 AM。对于计算量很大的工作，Application 重跑的代价不可接受。
2. Yarn 原生非独占分区资源共享局限性
Yarn 的标签分区个性⽀持独占分区（Exclusive），非独占分区（Non-exclusive）。
- 独占分区（Exclusive）：例如指定独占分区 x，Yarn 的 container 只会调配到该 x 分区。
- 非独占分区（Non-exclusive）：例如非独占分区 x，x 分区的资源能够共享给 default 分区。
只有当指定分区 default 时，default 上运⾏的 Application 能够使⽤分区 x 的资源。
然而在理论使⽤场景中，⽤户要给各个业务部门调配各自的独占分区资源，同时会划分出供各部门应用的 default 分区。default 分区资源会比拟短缺，业务部门心愿可能应用本人的独占分区和同时充分利用 default 分区资源，独占分区资源和 default 分区都不够用的时候，才会触发弹性扩容，往属于本人的独占分区中扩容资源。
二、对 Yarn 革新带来的挑战
对上述 feature 的开发，除了需要技术本⾝的难度。还须要思考到尽可能升高用户存量集群稳定性的影响，缩小用户业务侧革新老本。
- 集群稳定性：Hadoop Yarn 作为大数据系统中的根底调度组件，如果改变过多，引发的故障几率就会增大。同时引入的 feature, 必然须要降级存量集群的 Haoop Yarn。降级操作要做到对存量业务集群无感知，不能影响到当天的业务。
- 业务侧应用老本：引入的新 feature 也必须合乎原⽣ yarn 的应用习惯，不便业务侧用户了解，同时升高业务侧对代码的革新。
1. AM 自主抉择存储介质
目前 Yarn 的社区没有思考云上异构资源混合部署的特点。在线 TKE 集群中，当资源缓和时会对容器进行驱赶。为了防止 Appliction 从新计算，浪费资源的景象，必须提供 AM 能够指定是否调配到 POD 类型资源。
自主抉择存储介质中，应用配置化标识，由 NodeManager 通过 RPC 上报是否将资源提供给 AM 应用，ResourceManager 通过上报信息决定将 Application 的 AM 调配到稳固资源介质中。由 NodeManager 通过配置化上报信息的益处是不言而喻的：
- 去集中化：缩小 ResourceManager 解决逻辑。否则，扩容资源时，还需将资源信息通过 RPC/ 配置流入到 ResourceManager 中。如无必要，勿增实体，对 ResourceManager 的革新应该轻量化。
- 集群稳定性：存量业务集群对 Yarn 降级后，须要重启 NodeManager, 只须要重启 ResourceManager。Yare 的高可用个性可保障降级过程对业务无影响。无需重启 NodeManager 的起因是，NM 默认将本机资源视为可调配。
- 简略易用：用户能够通过配置⾃由决定工作资源领有调配 AM 的权力，不单单局限 POD 容器资源。
2. 多标签动态分配资源
Yarn 的原生标签设计中，提交工作时的标签表达式中只能含有单个标签。如果为了提⾼利用率，同时应用多个分区资源，就必须将非 default 分区设置为 Non-exclusive 个性。标签表达式必须解决如下三个问题：
- 资源隔离：分区 A 设置 Non-exclusive 后，资源被其余分区上的 APP 占用后，无奈及时替换给分区 A 的 App。
- 自在共享资源：只有 default 分区才有资格申请 Non-exclusive 分区资源。
- 动静抉择分区资源：多分区资源共享时，无奈依据分区残余资源大小抉择可用区，影响工作执行效率。
腾讯云 EMR 团队通过反对扩大表达式语法，减少对逻辑运算符表达式的反对，使 App 能够申请多个分区资源。同时开发资源统计模块动静统计分区可用资源，为 App 调配最合适的分区。
三、实操演练
测试环境：指定 172.17.48.28/172.17.48.17 的 NodeManager 为 default 分区，172.17.48.29/172.17.48.26 的 NodeManager 为 x 分区。
队列设置：
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>
<configuration>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>a,b</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.accessible-node-labels.x.capacity</nam e>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.accessible-node-labels.y.capacity</nam e>
<value>100</value>
</property>
<!-- configuration of queue-a -->
<property>
<name>yarn.scheduler.capacity.root.a.accessible-node-labels</name>
<value>x</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.a.accessible-node-labels.x.capacity</n ame>
<value>100</value>
</property>
<!-- configuration of queue-b -->
<property>
<name>yarn.scheduler.capacity.root.b.accessible-node-labels</name>
<value>y</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.b.accessible-node-labels.y.capacity</n ame>
<value>100</value>
</property>
</configuration>1. 规定 AM 只能调配在 172.17.48.28
对另外三个节点的 NodeManager 节点配置如下配置项:
yarn.nodemanager.am-alloc-disabled = true配置后，提交的 Application 的 AM 只能在 172.17.48.28 节点启动。
2. 应用组合标签
通过 mapreduce.job.node-label-expression 指定标签表达式，x|| 示意同时应用 x /default 分区。
hadoop jar /usr/local/service/hadoop/share/hadoop/mapreduce/hadoop-mapredu ce-examples-3.1.2.jar pi -D mapreduce.job.queuename="a" -D mapreduce.job. node-label-expression="x||" 10 10应用该命令提交后，察看到 Application 的 container 被调配在 x /default 分区。
四、Hadoop Yarn on Kubernetes Pod 最佳实际
该客户大数据利用和存储跑在 Yarn 治理的大数据集群，在生产环境中，面临诸多问题，次要体现在大数据的算力有余和在线业务波谷时资源的节约。如离线计算在算力有余时，数据准时性无奈失去保障，尤其是当遇到随机紧急大数据查问工作，没有可用的计算资源，只能停掉已有的计算工作，或者等已有工作实现，⽆论哪种⽅式，总体工作执行的效率都会大打折扣。
基于 Hadoop Yarn on Kubernetes Pod 计划，将离线工作主动扩容至云上集群，与 TKE 在线业务集群混合部署，充分利用云上波谷时段的闲置资源，进步离线业务的算力，并利用云上资源疾速的弹性扩容能力，及时补充离线计算的算力。
通过 Hadoop Yarn on Kubernetes Pod ⽅案对客户的在线 TKE 集群资源应用进下优化后，集群闲时 CPU 使用率能进步 500%。
五、总结
本文提出了基于 YARN 针对云原生容器化的优化与实际，在混合部署云原生环境中，极大地提高了工作运行的稳定性，高效性，无效进步了集群资源利用率，节约硬件老本。在将来，咱们会探讨更多大数据云原生场景，为企业客户带来更多的理论效益。
作者简介
张翮，腾讯云高级工程师，目前次要负责腾讯云大数据产品弹性 MapReduce 的管控相干模块，和重要组件 Hive 的技术研发。向 Apache Hive，Apache Calcite 开源我的项目奉献过代码，毕业于电子科技大学。