利为汇网站建设,国际摄影网站,聊城手机网站建设解决方案,河北省保定市雄县本文根据美团基础架构部/弹性策略团队负责人涂扬在2019 QCon#xff08;全球软件开发大会#xff09;上的演讲内容整理而成。本文涉及Kubernetes集群管理技术#xff0c;美团相关的技术实践可参考此前发布的《美团点评Kubernetes集群管理实践》。 一、背景 HULK是美团的容器… 本文根据美团基础架构部/弹性策略团队负责人涂扬在2019 QCon全球软件开发大会上的演讲内容整理而成。本文涉及Kubernetes集群管理技术美团相关的技术实践可参考此前发布的《美团点评Kubernetes集群管理实践》。 一、背景 HULK是美团的容器集群管理平台。在HULK之前美团的在线服务大部分部署都是在VM上在此期间我们遇到了很大的挑战主要包括以下两点 环境配置信息不一致部分业务线下验证正常但线上验证却不正常。业务扩容流程长从申请机器、资源审核到服务部署需要5分钟才能完成。因为美团很多业务都具有明显的高低峰特性大家一般会根据最高峰的流量情况来部署机器资源然而在业务低峰期的时候往往用不了那么多的资源。在这种背景下我们希望打造一个容器集群管理平台来解决上述的痛点问题于是HULK项目就应运而生了。 HULK平台包含容器以及弹性调度系统容器可以统一运行环境、提升交付效率而弹性调度可以提升业务的资源利用率。在漫威里有个叫HULK的英雄在情绪激动的时候会变成“绿巨人”情绪平稳后则恢复人身这一点跟我们容器的”弹性伸缩“特性比较相像所以我们的系统就取名为”HULK“。 总的来讲美团HULK的演进可以分为1.0和2.0两个阶段如下图所示 在早期HULK 1.0是基于OpenStack演进的一个集群调度系统版本。这个阶段工作的重点是将容器和美团的基础设施进行融合比如打通CMDB系统、公司内部的服务治理平台、发布平台以及监控平台等等并验证容器在生产环境的可行性。2018年基础架构部将底层的OpenStack升级为容器编排标准Kubernetes然后我们把这个版本称之为HULK 2.0新版本还针对在1.0运营过程中遇到的一些问题对系统专门进行了优化和打磨主要包括以下几个方面 进一步打磨了弹性策略和调度系统。构建了一站式容器运营平台。对基础系统软件进行加强自研内核提升安全隔离能力。截止发稿时美团生产环境超过1万个应用在使用容器容器数过10万。 二、HULK2.0集群调度系统总体架构图 上图中最上层是集群调度系统对接的各个平台包括服务治理、发布平台、测试部署平台、CMDB系统、监控平台等我们将这些系统打通业务就可以无感知地从VM迁移到容器中。其中 容器弹性可以让接入的业务按需使用容器实例。服务画像负责应用运行情况的搜集和统计如CPU/IO使用、服务高峰期、上下游等信息为弹性伸缩、调度系统提供支持。容器编排和镜像管理负责对实例进行调度与应用实例构建。最底层的HULK Agent是我们在每个Node上的代理程序。此前在美团技术团队官方博客上我们也分享过底层的镜像管理和容器运行时相关内容参见《美团容器技术研发实践》一文。而本文将重点阐述容器编排调度系统和容器弹性弹性伸缩平台以及团队遇到的一些问题以及对应的解决方案希望对大家能有所启发。 三、调度系统痛点、解法 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化、泳道标识。实例的扩展配置如部分业务比如某些服务想将实例部署在包含特定硬件的宿主机会对核心业务有N1的容灾需求并且还需要将实例部署在不同的IDC上。相同配置的应用可以创建一个组将应用和组进行关联。在策略配置中心我们会将这些策略进行Manifest组装然后转换成Kubernetes可识别的YAML文件。 落地效果实现了平台自动化配置运维人员得到解放。 3.3 调度策略优化 接下来介绍一下Kubernetes调度器Scheduler的默认行为它启动之后会一直监听ApiServer通过ApiServer去查看未Bind的Pod列表然后根据特定的算法和策略选出一个合适的Node并进行Bind操作。具体的调度策略分为两个阶段Predicates预选阶段和Priorities打分阶段。 Predicates 预选阶段一堆的预选条件PodFitsResources检查是否有足够的资源比如CPU、内存来满足一个Pod的运行需求如果不满足就直接过滤掉这个Node。 Priorities 打分阶段一堆的优先级函数 LeastRequestedCPU和内存具有相同的权重资源空闲比越高的节点得分越高。BalancedResourcesAllocationCPU和内存使用率越接近的节点得分越高。将以上优先级函数算出来的值加权平均算出来一个得分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关闭原生的驱逐策略通过外部组件来做决策。 四、弹性伸缩平台痛点、解法 弹性伸缩平台整体架构图如下 注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分钟进行提前扩容。 五、经验总结 技术侧 开源产品“本土化” 原生的Kubernetes需要和内部已有的基础设施如服务树、发布系统、服务治理平台、监控系统等做融合才能更容易在公司内进行落地。调度决策增量的调度均使用新策略来进行规范化存量的可采用重调度器进行治理。弹性伸缩公有云在弹性伸缩这块是没有SLA保障的但是做内部私有云就需要做好扩容成功率、端到端时延这两块的SLA保障。业务侧 业务迁移建设了全自动化迁移平台帮助业务从VM自动迁移到容器极大地降低了因迁移而带来的人力投入。业务成本使用HULK可较好地提升业务运维效率HULK具备资源利用率更高、弹性扩容、一键扩容等特点降低了业务成本。作者简介 涂扬美团点评技术专家现任基础架构部弹性策略团队负责人。 招聘信息 美团点评基础架构团队诚招高级、资深技术专家Base北京、上海。我们致力于建设美团点评全公司统一的高并发高性能分布式基础架构平台涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、基础存储、容器化、集群调度等基础架构主要的技术领域。欢迎有兴趣的同学投送简历到 techmeituan.com邮件标题注明基础架构部弹性策略团队
