Kubernetes如何改变美团的云基础设施？

本文根据美团基础架构部王国梁在KubeCon 2020云原生开源峰会Cloud Native + Open Source Virtual Summit China 2020上的演讲内容整理而成。

一、背景与现状

Kubernetes是让容器应用进入大规模工业生产环境的开源系统，也是集群调度领域的事实标准，目前已被业界广泛接受并得到了大规模的应用。Kubernetes已经成为美团云基础设施的管理引擎，它带来的不仅仅是高效的资源管理，同时也大幅降低了成本，而且为美团云原生架构的推进打下了坚实的基础，支持了Serverless、云原生分布式数据库等一些平台完成容器化和云原生化的建设。

从2013年开始，美团就以虚拟化技术为核心构建了云基础设施平台;2016年，开始探索容器技术并在内部进行落地，在原有OpenStack的资源管理能力之上构建了Hulk1.0容器平台;2018年，美团开始打造以Kubernetes技术为基础的Hulk2.0平台;2019年年底，我们基本完成了美团云基础设施的容器化改造;2020年，我们坚信Kubernetes才是未来的云基础设施标准，又开始探索云原生架构落地和演进。

当前，我们构建了以Kubernetes、Docker等技术为代表的云基础设施，支持整个美团的服务和应用管理，容器化率达到98%以上，目前已有数十个大小Kubernetes集群，数万的管理节点以及几十万的Pod。不过出于容灾考虑，我们最大单集群设置为5K个节点。

下图是当前我们基于Kubrnetes引擎的调度系统架构，构建了以Kubernetes为核心的统一的资源管理系统，服务于各个PaaS平台和业务。除了直接支持Hulk容器化之外，也直接支持了Serverless、Blade等平台，实现了PaaS平台的容器化和云原生化。

二、OpenStack到Kubernetes转变的障碍和收益

对于一个技术栈比较成熟的公司而言，整个基础设施的转变并不是一帆风顺的，在OpenStack云平台时期，我们面临的主要问题包括以下几个方面：

架构复杂，运维和维护比较困难：OpenStack的整个架构中计算资源的管理模块是非常庞大和复杂，问题排查和可靠性一直是很大的问题。 环境不一致问题突出：环境不一致问题是容器镜像出现之前业界的通用问题，不利于业务的快速上线和稳定性。 虚拟化本身资源占用多：虚拟化本身大概占用10%的宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。 资源交付和回收周期长，不易灵活调配：一方面是整个虚拟机创建流程冗长;另一方面各种初始化和配置资源准备耗时长且容易出错，所以就导致整个机器资源从申请到交付周期长，快速的资源调配是个难题。 高低峰明显，资源浪费严重：随着移动互联网的高速发展，公司业务出现高低峰的时间越来越多，为了保障服务稳定不得不按照最高的资源需求来准备资源，这就导致低峰时资源空闲严重，进而造成浪费。

2.1 容器化的过程和障碍

为了解决虚拟机存在的问题，美团开始探索更加轻量级的容器技术的落地，也就是Hulk1.0项目。不过基于当时的资源环境和架构，Hulk1.0是以原有的OpenStack为基础资源管理层实现的容器平台，OpenStack提供底层的宿主机的资源管理能力，解决了业务对弹性资源的需求，并且整个资源交付周期从分钟级别降低到了秒级。

但是，随着Hulk1.0的推广和落地，也暴露出一些新的问题：

稳定性差：因为复用了OpenStack的底层资源管理能力，整个扩容过程包括两层的资源调度，且数据同步流程复杂，机房的隔离性也比较差，经常出现一个机房出现问题，其他机房的扩缩容也受到影响。 能力欠缺：由于涉及的系统多，并且是跨部门协作，故障节点的迁移和恢复能力不易实现，资源类型也比较单一，整个故障排查和沟通效率低下。 扩展性差：Hulk1.0的控制层面对底层资源的管理能力受限，无法根据场景和需求快速扩展。 性能：业务对于扩缩容和弹性资源的交付速度需求进一步提高，且容器技术的弱隔离性导致业务的服务受到的干扰增多，负面反馈增加。

上述的问题经过一段时间的优化和改善，始终不能彻底解决。在这种情况下，我们不得不重新思考整个容器平台的架构合理性，而此时Kubernetes已逐步被业界认可和应用，它清晰的架构和先进的设计思路让我们看到了希望。所以我们基于Kubernetes构建了新的容器平台，在新的平台中Hulk完全基于原生的Kubernetes API，通过Hulk API来对接内部的发布部署系统，这样两层API将整个架构解耦开来，领域明确，应用管理和资源管理可以独立迭代，Kubernetes强大的编排和资源管理能力凸显。

容器化的核心思路是让Kubernetes做好资源层面的管理，而通过上层的控制层解决对美团应用管理系统和运维系统的依赖问题，保持Kubernetes的原生兼容性，减少后续的维护成本，并完成了快速收敛资源管理的需求。同时，也减少了用户基于新平台的资源申请的学习成本，这点非常重要，也是后续我们能快速大规模迁移基础设施资源的“基础”。

2.2 容器化过程的挑战和应对策略

2.2.1 复杂灵活、动态和可配置的调度策略

美团产品众多，业务线和应用特点五花八门，所以相应的，我们对于资源类型和调度策略的需求也是非常多。例如，有些业务需要特定的资源类型(SSD、高内存、高IO等等)，有些业务需要特定的打散策略(例如机房、服务依赖等)，所以如何很好地应对这些多样化的需求，就是一个很大的问题。

为了解决这些问题，我们为扩容链路增加了策略引擎，业务可以对自己的应用APPKEY自定义录入策略需求，同时基于大数据分析的服务画像，也会根据业务特点和公司的应用管理策略为业务策略推荐，最终这些策略会保存到策略中心。在扩容过程中，我们会自动为应用的实例打上对应的需求标签，并最终在Kubenretes中生效，完成预期的资源交付。

2.2.2 精细化的资源调度和运营

精细化的资源调度和运营，之所以做精细化运营主要是出于两点考虑：业务的资源需求场景复杂，以及资源不足的情况较多。

（编辑：应用网_阳江站长网）

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