Kubernetes如何改变美团的云基础设施？
发布时间：2025-09-16 点击：10
本文根据美团基础架构部王国梁在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%%u4ee5上，目前已有数十个大小kubernetes集群，数万的管理节点以及几十万的pod。不过出于容灾考虑，我们最大单集群设置为5k个节点。
下图是当前我们基于kubrnetes引擎的调度系统架构，构建了以kubernetes为核心的统一的资源管理系统，服务于各个paas平台和业务。除了直接支持hulk容器化之外，也直接支持了serverless、blade等平台，实现了paas平台的容器化和云原生化。
二、openstack到kubernetes转变的障碍和收益
对于一个技术栈比较成熟的公司而言，整个基础设施的转变并不是一帆风顺的，在openstack云平台时期，我们面临的主要问题包括以下几个方面：
架构复杂，运维和维护比较困难：openstack的整个架构中计算资源的管理模块是非常庞大和复杂，问题排查和可靠性一直是很大的问题。 环境不一致问题突出：环境不一致问题是容器镜像出现之前业界的通用问题，不利于业务的快速上线和稳定性。 虚拟化本身资源占用多：虚拟化本身大概占用10%%u7684宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。 资源交付和回收周期长，不易灵活调配：一方面是整个虚拟机创建流程冗长;另一方面各种初始化和配置资源准备耗时长且容易出错，所以就导致整个机器资源从申请到交付周期长，快速的资源调配是个难题。 高低峰明显，资源浪费严重：随着移动互联网的高速发展，公司业务出现高低峰的时间越来越多，为了保障服务稳定不得不按照最高的资源需求来准备资源，这就导致低峰时资源空闲严重，进而造成浪费。
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 精细化的资源调度和运营
精细化的资源调度和运营，之所以做精细化运营主要是出于两点考虑：业务的资源需求场景复杂，以及资源不足的情况较多。
我们依托私有云和公有云资源，部署多个kubenretes集群，这些集群有些是承载通用业务，有些是为特定应用专有的集群，在集群维度对云端资源进行调配，包括机房的划分、机型的区分等。在集群之下，我们又根据不同的业务需要，建设不同业务类型的专区，以便做到资源池的隔离来应对业务的需要。更细的维度，我们针对应用层面的资源需求、容灾需求以及稳定性等做集群层的资源调度，最后基于底层不同硬件以及软件，实现cpu、mem和磁盘等更细粒度的资源隔离和调度。
2.2.3 应用稳定性的提升和治理
不管是vm，还是最初的容器平台，在应用稳定性方面一直都存在问题。为此，我们需要在保障应用的sla上做出更多的努力。
2.2.3.1 容器复用
在生产环境中，宿主机的发生重启是一种非常常见的场景，可能是主动重启也可能是被动，但用户角度来看，宿主机重启意味着用户的一些系统数据就可能丢失，代价还是比较高的。我们需要避免容器的迁移或重建，直接重启恢复。但我们都知道，在kubernetes中，对于pod中的容器的重启策略有以下几种：always、onfailure和never，宿主机重启后容器会重新被创建。
为了解决这个问题，我们为容器的重启策略类型增加了reuse策略。流程如下：
kubelet在syncpod时，重启策略如果是reuse则会获取对应pod已退出状态的app容器，如果存在则拉起最新的app容器(可能有多个)，如果不存在则直接新建。 更新app容器映射的pauseid为新的pause容器id，这样就建立了pod下新的pause容器和原先app容器的映射。 重新拉起app容器即可完成pod状态同步，最终即使宿主机重启或内核升级，容器数据也不会丢失。
2.2.3.2 numa感知与绑定
用户的另一个痛点与容器性能和稳定性相关。我们不断收到业务反馈，同样配置的容器性能存在不小的差异，主要表现为部分容器请求延迟很高，经过我们测试和深入分析发现：这些容器存在跨numa node访问cpu，在我们将容器的cpu使用限制在同一个numa node后问题消失。所以，对于一些延迟敏感型的业务，我们要保证应用性能表现的一致性和稳定性，需要做到在调度侧感知numa node的使用情况。
为了解决这个问题，我们在node层采集了numa node的分配情况，在调度器层增加了对numa node的感知和调度，并保证资源使用的均衡性。对于一些强制需要绑定node的敏感型应用，如果找不到合适的node则扩容失败;对于一些不需要绑定numa node的应用，则可以选择尽量满足的策略。
2.2.3.3 其他稳定性优化
在调度层面，我们为调度器增加了负载感知和基于服务画像应用特征的打散和优选策略。
在故障容器发现和处理上，基于特征库落地的告警自愈组件，能够秒级发现-分析-处理告警。
对于一些有特殊资源需求，例如高io、高内存等应用采用专区隔离，避免对其他应用造成影响。
2.2.4 平台型业务容器化
相信做过tob业务的同学应该都了解，任何产品都存在大客户方案，那么对于美团这样的公司，内部也会存在这种情况。平台型业务的容器化有个特点是：实例数多，以千或万计，所以资源成本就比较高;业务地位比较高，一般都是非常核心
阿里云购买服务器云盘后脱机
租用阿里云服务器怎样维护
云服务器价格实惠
服务器集群的应用优势
linux中添加用户的命令是什么
租用高防服务器对网站到底有多重要？
重庆服务器托管市场低价云服务器
共享型虚拟主机是什么意思
一、背景与现状
kubernetes是让容器应用进入大规模工业生产环境的开源系统，也是集群调度领域的事实标准，目前已被业界广泛接受并得到了大规模的应用。kubernetes已经成为美团云基础设施的管理引擎，它带来的不仅仅是高效的资源管理，同时也大幅降低了成本，而且为美团云原生架构的推进打下了坚实的基础，支持了serverless、云原生分布式数据库等一些平台完成容器化和云原生化的建设。
从2013年开始，美团就以虚拟化技术为核心构建了云基础设施平台;2016年，开始探索容器技术并在内部进行落地，在原有openstack的资源管理能力之上构建了hulk1.0容器平台;2018年，美团开始打造以kubernetes技术为基础的hulk2.0平台;2019年年底，我们基本完成了美团云基础设施的容器化改造;2020年，我们坚信kubernetes才是未来的云基础设施标准，又开始探索云原生架构落地和演进。
当前，我们构建了以kubernetes、docker等技术为代表的云基础设施，支持整个美团的服务和应用管理，容器化率达到98%%u4ee5上，目前已有数十个大小kubernetes集群，数万的管理节点以及几十万的pod。不过出于容灾考虑，我们最大单集群设置为5k个节点。
下图是当前我们基于kubrnetes引擎的调度系统架构，构建了以kubernetes为核心的统一的资源管理系统，服务于各个paas平台和业务。除了直接支持hulk容器化之外，也直接支持了serverless、blade等平台，实现了paas平台的容器化和云原生化。
二、openstack到kubernetes转变的障碍和收益
对于一个技术栈比较成熟的公司而言，整个基础设施的转变并不是一帆风顺的，在openstack云平台时期，我们面临的主要问题包括以下几个方面：
架构复杂，运维和维护比较困难：openstack的整个架构中计算资源的管理模块是非常庞大和复杂，问题排查和可靠性一直是很大的问题。 环境不一致问题突出：环境不一致问题是容器镜像出现之前业界的通用问题，不利于业务的快速上线和稳定性。 虚拟化本身资源占用多：虚拟化本身大概占用10%%u7684宿主机资源消耗，在集群规模足够大的时候，这是一块非常大的资源浪费。 资源交付和回收周期长，不易灵活调配：一方面是整个虚拟机创建流程冗长;另一方面各种初始化和配置资源准备耗时长且容易出错，所以就导致整个机器资源从申请到交付周期长，快速的资源调配是个难题。 高低峰明显，资源浪费严重：随着移动互联网的高速发展，公司业务出现高低峰的时间越来越多，为了保障服务稳定不得不按照最高的资源需求来准备资源，这就导致低峰时资源空闲严重，进而造成浪费。
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 精细化的资源调度和运营
精细化的资源调度和运营，之所以做精细化运营主要是出于两点考虑：业务的资源需求场景复杂，以及资源不足的情况较多。
我们依托私有云和公有云资源，部署多个kubenretes集群，这些集群有些是承载通用业务，有些是为特定应用专有的集群，在集群维度对云端资源进行调配，包括机房的划分、机型的区分等。在集群之下，我们又根据不同的业务需要，建设不同业务类型的专区，以便做到资源池的隔离来应对业务的需要。更细的维度，我们针对应用层面的资源需求、容灾需求以及稳定性等做集群层的资源调度，最后基于底层不同硬件以及软件，实现cpu、mem和磁盘等更细粒度的资源隔离和调度。
2.2.3 应用稳定性的提升和治理
不管是vm，还是最初的容器平台，在应用稳定性方面一直都存在问题。为此，我们需要在保障应用的sla上做出更多的努力。
2.2.3.1 容器复用
在生产环境中，宿主机的发生重启是一种非常常见的场景，可能是主动重启也可能是被动，但用户角度来看，宿主机重启意味着用户的一些系统数据就可能丢失，代价还是比较高的。我们需要避免容器的迁移或重建，直接重启恢复。但我们都知道，在kubernetes中，对于pod中的容器的重启策略有以下几种：always、onfailure和never，宿主机重启后容器会重新被创建。
为了解决这个问题，我们为容器的重启策略类型增加了reuse策略。流程如下：
kubelet在syncpod时，重启策略如果是reuse则会获取对应pod已退出状态的app容器，如果存在则拉起最新的app容器(可能有多个)，如果不存在则直接新建。 更新app容器映射的pauseid为新的pause容器id，这样就建立了pod下新的pause容器和原先app容器的映射。 重新拉起app容器即可完成pod状态同步，最终即使宿主机重启或内核升级，容器数据也不会丢失。
2.2.3.2 numa感知与绑定
用户的另一个痛点与容器性能和稳定性相关。我们不断收到业务反馈，同样配置的容器性能存在不小的差异，主要表现为部分容器请求延迟很高，经过我们测试和深入分析发现：这些容器存在跨numa node访问cpu，在我们将容器的cpu使用限制在同一个numa node后问题消失。所以，对于一些延迟敏感型的业务，我们要保证应用性能表现的一致性和稳定性，需要做到在调度侧感知numa node的使用情况。
为了解决这个问题，我们在node层采集了numa node的分配情况，在调度器层增加了对numa node的感知和调度，并保证资源使用的均衡性。对于一些强制需要绑定node的敏感型应用，如果找不到合适的node则扩容失败;对于一些不需要绑定numa node的应用，则可以选择尽量满足的策略。
2.2.3.3 其他稳定性优化
在调度层面，我们为调度器增加了负载感知和基于服务画像应用特征的打散和优选策略。
在故障容器发现和处理上，基于特征库落地的告警自愈组件，能够秒级发现-分析-处理告警。
对于一些有特殊资源需求，例如高io、高内存等应用采用专区隔离，避免对其他应用造成影响。
2.2.4 平台型业务容器化
相信做过tob业务的同学应该都了解，任何产品都存在大客户方案，那么对于美团这样的公司，内部也会存在这种情况。平台型业务的容器化有个特点是：实例数多，以千或万计，所以资源成本就比较高;业务地位比较高，一般都是非常核心
阿里云购买服务器云盘后脱机
租用阿里云服务器怎样维护
云服务器价格实惠
服务器集群的应用优势
linux中添加用户的命令是什么
租用高防服务器对网站到底有多重要？
重庆服务器托管市场低价云服务器
共享型虚拟主机是什么意思
上一篇：如何利用阿里云服务器挂机
下一篇：域名竞拍和一口价哪种好