美团集群调度系统HULK技术演进
本文根据美团基础架构部/弹性策略团队负责人涂扬在2019 QCon（全球软件开发大会）上的演讲内容整理而成。本文涉及Kubernetes集群管理技术，美团相关的技术实践可参考此前发布的《美团点评Kubernetes集群管理实践》。html
1、背景
HULK是美团的容器集群管理平台。在HULK以前，美团的在线服务大部分部署都是在VM上，在此期间，咱们遇到了很大的挑战，主要包括如下两点：git
- 环境配置信息不一致：部分业务线下验证正常，但线上验证却不正常。
- 业务扩容流程长：从申请机器、资源审核到服务部署，须要5分钟才能完成。
由于美团不少业务都具备明显的高低峰特性，你们通常会根据最高峰的流量状况来部署机器资源，然而在业务低峰期的时候，每每用不了那么多的资源。在这种背景下，咱们但愿打造一个容器集群管理平台来解决上述的痛点问题，因而HULK项目就应运而生了。github
HULK平台包含容器以及弹性调度系统，容器能够统一运行环境、提高交付效率，而弹性调度能够提高业务的资源利用率。在漫威里有个叫HULK的英雄，在情绪激动的时候会变成“绿巨人”，情绪平稳后则恢复人身，这一点跟咱们容器的”弹性伸缩“特性比较相像，因此咱们的系统就取名为”HULK“。web
总的来说，美团HULK的演进能够分为1.0和2.0两个阶段，以下图所示：算法
在早期，HULK 1.0是基于OpenStack演进的一个集群调度系统版本。这个阶段工做的重点是将容器和美团的基础设施进行融合，好比打通CMDB系统、公司内部的服务治理平台、发布平台以及监控平台等等，并验证容器在生产环境的可行性。2018年，基础架构部将底层的OpenStack升级为容器编排标准Kubernetes，而后咱们把这个版本称之为HULK 2.0，新版本还针对在1.0运营过程当中遇到的一些问题，对系统专门进行了优化和打磨，主要包括如下几个方面：docker
- 进一步打磨了弹性策略和调度系统。
- 构建了一站式容器运营平台。
- 对基础系统软件进行增强，自研内核，提高安全隔离能力。
截止发稿时，美团生产环境超过1万个应用在使用容器，容器数过10万。数据库
2、HULK2.0集群调度系统整体架构图
上图中，最上层是集群调度系统对接的各个平台，包括服务治理、发布平台、测试部署平台、CMDB系统、监控平台等，咱们将这些系统打通，业务就能够无感知地从VM迁移到容器中。其中：安全
- 容器弹性：可让接入的业务按需使用容器实例。
- 服务画像：负责应用运行状况的搜集和统计，如CPU/IO使用、服务高峰期、上下游等信息，为弹性伸缩、调度系统提供支持。
- 容器编排和镜像管理：负责对实例进行调度与应用实例构建。
最底层的HULK Agent是咱们在每一个Node上的代理程序。此前，在美团技术团队官方博客上，咱们也分享过底层的镜像管理和容器运行时相关内容，参见《美团容器技术研发实践》一文。而本文将重点阐述容器编排（调度系统）和容器弹性（弹性伸缩平台），以及团队遇到的一些问题以及对应的解决方案，但愿对你们能有所启发。架构
3、调度系统痛点、解法
3.1 业务扩缩容异常
痛点：集群运维人员排查成本较高。并发
为了解决这个问题，咱们能够先看一下调度系统的简化版架构，以下图所示：
能够看到，一次扩缩容请求基本上会经历如下这些流程：
a. 用户或者上层系统发起扩缩容请求。
b. 扩缩容组件从策略配置中心获取对应服务的配置信息。
c. 将对应的配置信息提交到美团自研的一个API服务（扩展的K8s组件），而后K8s各Master组件就按照原生的工做流程开始Work。
d. 当某个实例调度到具体的Node上的时候，开始经过IP分配服务获取对应的Hostname和IP。
e. Container-init是一号进程，在容器内部拉起各个Agent，而后启动应用程序。针对已经标准化接入的应用，会自动进行服务注册，从而承载流量。
而这些模块是由美团内部的不一样同窗分别进行维护，每次遇到问题时，就须要多个同窗分别核对日志信息。可想而知，这种排查问题的方式的成本会有多高。
解法：相似于分布式调用链中的traceId，每次扩缩容会生成一个TaskId，咱们在关键链路上进行打点的同时带上TaskId，并按照约定的格式统一接入到美团点评日志中心，而后在可视化平台HULK Portal进行展现。
落地效果：
- 问题排查提效：以前排查相似问题，多人累计耗时平均须要半个小时。目前，1个管理员经过可视化的界面便可达到分钟级定位到问题。
- 系统瓶颈可视化：全链路上每一个时段的平均耗时信息一览无遗。
3.2 业务定制化需求
痛点：每次业务的特殊配置均可能变动核心链路代码，致使总体系统的灵活性不够。
具体业务场景以下：
- 业务但愿可以去设置一些系统参数，好比开启swap，设置memlock、ulimit等。
- 环境变量配置，好比应用名、ZooKeeper地址等。
解法：建设一体化的调度策略配置中心，经过调度策略配置中心，可定制化调度规则。
- 实例基本配置，好比业务想给机器加Set化、泳道标识。
- 实例的扩展配置：如部分业务，好比某些服务想将实例部署在包含特定硬件的宿主机，会对核心业务有N+1的容灾需求，而且还须要将实例部署在不一样的IDC上。
- 相同配置的应用能够建立一个组，将应用和组进行关联。
在策略配置中心，咱们会将这些策略进行Manifest组装，而后转换成Kubernetes可识别的YAML文件。
落地效果：实现了平台自动化配置，运维人员获得解放。
3.3 调度策略优化
接下来，介绍一下Kubernetes调度器Scheduler的默认行为：它启动以后，会一直监听ApiServer，经过ApiServer去查看未Bind的Pod列表，而后根据特定的算法和策略选出一个合适的Node，并进行Bind操做。具体的调度策略分为两个阶段：Predicates预选阶段和Priorities打分阶段。
Predicates 预选阶段（一堆的预选条件）：PodFitsResources检查是否有足够的资源（好比CPU、内存）来知足一个Pod的运行需求，若是不知足，就直接过滤掉这个Node。
Priorities 打分阶段（一堆的优先级函数）：
- LeastRequested：CPU和内存具备相同的权重，资源空闲比越高的节点得分越高。
- BalancedResourcesAllocation：CPU和内存使用率越接近的节点得分越高。
将以上优先级函数算出来的值加权平均算出来一个得分（0-10），分数越高，节点越优。
痛点一：当集群达到3000台规模的时候，一次Pod调度耗时5s左右（K8s 1.6版本）。若是在预选阶段，当前Node不符合过滤条件，依然会判断后续的过滤条件是否符合。假设有上万台Node节点，这种判断逻辑便会浪费较多时间，形成调度器的性能降低。
解法：当前Node中，若是遇到一个预选条件不知足（比较像是短路径原则），就将这个Node过滤掉，大大减小了计算量，调度性能也获得大幅提高。
成效：生产环境验证，提高了40%的性能。这个方案目前已经成为社区1.10版本默认的调度策略，技术细节能够参考GitHub上的PR。
痛点二：资源利用率最大化和服务SLA保障之间的权衡。
解法：咱们基于服务的行为数据构建了服务画像系统，下图是咱们针对某个应用进行服务画像后的树图展示。
调度前：能够将有调用关系的Pod设置亲和性，竞争相同资源的Pod设置反亲和性，相同宿主机上最多包含N个核心应用。
调度后：通过上述规则调度后，在宿主机上若是依然出现了资源竞争，优先保障高优先级应用的SLA。
3.4 重编排问题
痛点：
（1）容器重启/迁移场景：
- 容器和系统盘的信息丢失。
- 容器的IP变动。
（2）驱逐场景：Kubelet会自动杀死一些违例容器，但有多是很是核心的业务。
解法：
（1）容器重启/迁移场景：
- 新增Reuse策略，保留原生重启策略（Rebuild）。
- 定制化CNI插件，基于Pod标识申请和复用IP。
（2）关闭原生的驱逐策略，经过外部组件来作决策。
4、弹性伸缩平台痛点、解法
弹性伸缩平台总体架构图以下：
注：Raptor是美团点评内部的大监控平台，整合了CAT、Falcon等监控产品。
在弹性伸缩平台演进的过程当中，咱们主要遇到了如下5个问题。
4.1 多策略决策不一致
如上图所示，一个业务配置了2条监控策略和1条周期策略：
- 监控策略：当某个指标（好比QPS、CPU）超过阈值上限后开始扩容，低于阈值下限后开始缩容。
- 周期策略：在某个固定的时间开始扩容，另一个固定的时间开始缩容。
早期的设计是各条策略独自决策，扩容顺序有多是：缩5台、缩2台、扩10台，也有多是：扩10台、缩5台、缩2台，就可能形成一些无效的扩缩行为。
解法：增长了一个聚合层（或者把它称之为策略协商层），提供一些聚合策略：默认策略（多扩少缩）和权重策略（权重高的来决策扩缩行为），减小了大量的无效扩缩现象。
4.2 扩缩不幂等
如上图所示，聚合层发起具体扩缩容的时候，因以前采用的是增量扩容方式，在一些场景下会出现频繁扩缩现象。好比，原先12台，这个时候弹性伸缩平台告诉调度系统要扩容8台，在返回TaskId的过程当中超时或保存TaskId失败了，这个时候弹性伸缩平台会继续发起扩容8台的操做，最后致使服务下有28台实例（不幂等）。
解法：采用按目标扩容方式，直接告诉对端，但愿能扩容到20台，避免了短期内的频繁扩缩容现象。
4.3 线上代码多版本
如上图所示，一个业务线上有30台机器，存在3个版本（A、B、C）。以前咱们弹性扩容的作法是采用业务构建的最新镜像进行扩容，但在实际生产环境运行过程当中却遇到问题。好比一些业务构建的最新镜像是用来作小流量测试的，自己的稳定性没有保障，高峰期扩容的时候会提高这个版本在线上机器中的比例，低峰期的时候又把以前稳定版本给缩容了，通过一段时间的频繁扩缩以后，最后线上遗留的实例可能都存在问题。
解法：基于约定优于配置原则，咱们采用业务的稳定镜像（采用灰度发布流程将线上全部实例均覆盖过一遍的镜像，会自动标记为稳定镜像）进行扩容，这样就比较好地解决了这个问题。
4.4 资源保障问题
如上图所示，存量中有2个服务，一个须要扩容20台，一个须要扩容15台，这个时候若是新接入一个服务，同一时间须要扩容30台，可是资源池只剩余50台实例了。这个时候就意味着，谁先扩容谁就能够得到资源保障，后发起的请求就没法得到资源保障。
解法：
（1）存量资源水位检测：当存量资源的使用水位超过阈值的时候，好比达到80%的时候会有报警，告诉咱们须要作资源补充操做。
（2）增量服务弹性资源预估：若是这个服务经过预判算法评估，接入以后可能会致使存量服务的扩容得不到保障，则拒绝或者补充资源后，再让这个业务接入。
4.5 端到端时效问题
如图所示，咱们的分钟级监控时延（好比1:00:00~1:01:00的监控数据，大概须要到1:01:10后可将采集到的全部数据聚合完成）是70s+，调度链路时延是30s+，总体须要上100s+，在生产环境的业务每每会比较关注扩容时延。
解法：监控系统这块已经建设秒级监控功能。基于这些作法都属于后验性扩容，存在必定的延迟性，目前咱们也在探索基于历史行为数据进行服务预测，在监控指标达到扩容阈值前的1~2分钟进行提早扩容。
5、经验总结
技术侧：
- 开源产品“本土化”： 原生的Kubernetes须要和内部已有的基础设施，如服务树、发布系统、服务治理平台、监控系统等作融合，才能更容易在公司内进行落地。
- 调度决策：增量的调度均使用新策略来进行规范化，存量的可采用重调度器进行治理。
- 弹性伸缩：公有云在弹性伸缩这块是没有SLA保障的，可是作内部私有云，就须要作好扩容成功率、端到端时延这两块的SLA保障。
业务侧：
- 业务迁移：建设了全自动化迁移平台，帮助业务从VM自动迁移到容器，极大地下降了因迁移而带来的人力投入。
- 业务成本：使用HULK可较好地提高业务运维效率（HULK具有资源利用率更高、弹性扩容、一键扩容等特色），下降了业务成本。
做者简介
涂扬，美团点评技术专家，现任基础架构部弹性策略团队负责人。
团队信息
美团点评基础架构团队诚招高级、资深技术专家，Base北京、上海。咱们致力于建设美团点评全公司统一的高并发高性能分布式基础架构平台，涵盖数据库、分布式监控、服务治理、高性能通讯、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同窗加入呦。