360在离线混部 koordinator 和 hadoop-yarn 方案

公司内容器云平台使用的koordinator来调度和管理离线pod，大数据平台使用的hadoop yarn的方式来调度和运行离线作业。早期的使用方式是yarn以常驻pod的方式运行在k8s集群并通过koordinator的压制驱逐等手段来保证在线服务的稳定（每个node运行一个离线pod）。但这种运行方式有两个的弊端：

1、比如申请的离线pod规格为16c 32G，运行过程中koordinator将pod可使用资源压制到10c，resourceManager仍然以16c的容量来调度任务，这样势必造成任务间的资源争抢，导致任务运行时间增长。

2、koordinator的驱逐机制有两个条件，离线pod资源满意度（整机离线可用资源 / 离线pod-request资源 < 60%）与离线pod资源实际使用率(离线pod-use-cores / pod-limit-cores > 80%), 当两个条件同时满足时会对离线pod进行驱逐。 此时会有一个场景当离线pod在满负荷运行任务时，且此时任务已经运行了一个小时很快就运行完成了，此时koordinator对离线进行了压制，且压制的满意度小于60%，满足了如上两个条件触发了离线pod驱逐，已经运行一个小时的任务就会失败。虽然任务会调度到其他的pod运行，但任务完成时间有可能会超过用户的预期时间。

一、方案

针对如上两个痛点，最理想的方案如下：

1、能够实时上报yarn-pod的最大可用资源，这样resourceManager能够根据上报的资源量进行任务调度，避免调度的任务过多导致的资源争抢。

2、koordinator驱逐机制，不直接驱逐离线pod，而是驱逐离线pod中运行的任务，通过计算