美团点评容器平台HULK的调度系统

由于将资源层信息作为共享数据提供给上层所有应用,Omega为了解决数据一致性,会对所有应用调度的提交冲突做解决,本质上是为每个节点维护了一个状态关系数据库.从这个角度看,Omega也存在一些缺点：

1. 共享调度时冲突发生的频率,直接影响了整体调度器的性能.
2. 由于没有集中的调度模块,难以对所有资源分组(Namespace)或用户的资源使用量做精确限制.
3. 上层调度器数量仍然不能很多,并行分发完整的集群状态的开销较大.

Borg与Kubernetes

Borg据说现在已经逐渐演进吸收了Omega的很多设计思想,包括共享状态调度模式,然而Kubernetes默认调度plugin的做法仍然是串行处理队列中的调度任务,这也符合Kubernetes追求的简洁优雅.

HULK调度解决方案

对于调度器设计难题,我们认为针对不同的场景,指标的侧重点不同.

比如对于分布式系统的CAP,大多数互联网场景下都会保证AP而舍弃C(只保证最终一致性),因为在互联网分布式集群规模大、网络故障频发的场景下,要保证服务高可用只能牺牲强一致；而对于金融等涉及钱财的领域,则一般保证CA、舍弃P,即使遇到网络故障时只读不写,也必须保证强一致性.

同理对于调度器资源层设计,在互联网高并发、弹性伸缩频发的场景下,可以牺牲部分资源利用率从而提高并发调度能力.

HULK调度系统模型如下：

HULK调度模型

如图,HULK调度系统分为调度请求队列、调度计算模块、调度资源池这三个模块.工作流程如下：

1. 上层HULK弹性伸缩系统,将调度任务ID写入调度请求队列中.
2. HULK调度系统消费调度请求队列,取出的调度任务ID将由调度计算池执行调度计算,决策出备选的部署位置,并向调度资源池申请资源.
3. 调度资源池维护管理宿主机集群资源,全部资源会提供给所有调度任务共享(与Omega类似),资源池中每个宿主机都有一个对应的Actor来负责管理.

调度计算模块(资源调度算法)

HULK调度系统的调度计算方式与诸多业界调度系统类似,通过过滤+打分的方式筛选出“最优部署位置”：

HULK调度任务

• 宿主机(Host)：调度资源池中共享的宿主机集群,支持pool级别硬隔离,如在线服务与数据库/缓存的实例部署在不同的物理机集群中；支持资源软隔离,如在线服务离线任务混布部署,通过cgroups等机制隔离和设置权重.
• 过滤(Filter)：预选(Predicates)的概念,通过超售、打散限制策略,排除掉一部分不合需求的宿主机.
• 打分(Rank)：优选(Priorities)的概念,通过在线离线混布、不同资源类型混布、宿主机负载均衡等策略和对应权重,最终计算出一个rank值,根据rank值排序最终得出最优部署位置.

超售

不管是在传统虚拟机时代还是容器时代,超售始终是一个让人又爱又恨的机制.

超售在一定程度上提高了集群的资源利用率,因为机器在申请之时往往提高对真实资源消耗的预估,也就是在服务运行中,绝大多数情况用不到申请的所有资源.然而正因为超售,常常会带来各种因资源争用引发的服务异常,严重的情况下会导致宿主机上所有实例的不可用.

HULK容器调度同样采用了超售机制,我们和IaaS层对资源进行了分类,可压缩资源(如CPU、I/O等)使用超售机制,而不可压缩资源(如Memory、Disk)只允许在一些测试环境超售.

相比于是否开启超售,超售系数才是更为棘手的难题,它直接关系到资源利用率和服务稳定性.我们采用了超售上限+动态系数的机制,从IaaS层设置的超售上限固定了资源超售的上限比例,超过上限的实例创建将会失败,而HULK调度系统会根据具体场景决定超售系数：

1. 参考宿主机实时监控,如Load负载、内存使用、带宽占用等指标.
2. 不同的实例类型(在线、离线)调度时超售系数不同.

业务实例打散

随着物理集群规模的扩大,宿主机故障频次也会响应提高.如果一个在线服务的所有实例都部署在同一个宿主机上,很可能出现宿主机宕机后服务整体不可用,这是我们不能接受的.

（编辑：网站开发网_马鞍山站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!