关于容器: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 云平台期间，咱们面临的次要问题包含以下几个方面：

1. 架构简单，运维和保护比拟艰难：OpenStack 的整个架构中计算资源的治理模块是十分宏大和简单，问题排查和可靠性始终是很大的问题。
2. 环境不统一问题突出：环境不统一问题是容器镜像呈现之前业界的通用问题，不利于业务的疾速上线和稳定性。
3. 虚拟化自身资源占用多：虚拟化自身大略占用 10% 的宿主机资源耗费，在集群规模足够大的时候，这是一块十分大的资源节约。
4. 资源交付和回收周期长，不易灵便调配：一方面是整个虚拟机创立流程简短；另一方面各种初始化和配置资源筹备耗时长且容易出错，所以就导致整个机器资源从申请到交付周期长，疾速的资源调配是个难题。
5. 高下峰显著，资源节约重大：随着挪动互联网的高速倒退，公司业务呈现高下峰的工夫越来越多，为了保障服务稳固不得不依照最高的资源需要来筹备资源，这就导致低峰时资源闲暇重大，进而造成节约。

2.1 容器化的过程和阻碍

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

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

1. 稳定性差：因为复用了 OpenStack 的底层资源管理能力，整个扩容过程包含两层的资源调度，且数据同步流程简单，机房的隔离性也比拟差，经常出现一个机房呈现问题，其余机房的扩缩容也受到影响。
2. 能力欠缺：因为波及的零碎多，并且是跨部门合作，故障节点的迁徙和恢复能力不易实现，资源类型也比拟繁多，整个故障排查和沟通效率低下。
3. 扩展性差：Hulk1.0 的管制层面对底层资源的治理能力受限，无奈依据场景和需要疾速扩大。
4. 性能：业务对于扩缩容和弹性资源的交付速度需要进一步提高，且容器技术的弱隔离性导致业务的服务受到的烦扰增多，负面反馈减少。

上述的问题通过一段时间的优化和改善，始终不能彻底解决。在这种状况下，咱们不得不从新思考整个容器平台的架构合理性，而此时 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 策略。流程如下：

1. kubelet 在 SyncPod 时，重启策略如果是 Reuse 则会获取对应 Pod 已退出状态的 App 容器，如果存在则拉起最新的 App 容器（可能有多个），如果不存在则间接新建。
2. 更新 App 容器映射的 pauseID 为新的 pause 容器 ID，这样就建设了 Pod 下新的 pause 容器和原先 App 容器的映射。
3. 从新拉起 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 其余稳定性优化

1. 在调度层面，咱们为调度器减少了负载感知和基于服务画像利用特色的打散和优选策略。
2. 在故障容器发现和解决上，基于特色库落地的告警自愈组件，可能秒级发现 - 剖析 - 解决告警。
3. 对于一些有非凡资源需要，例如高 IO、高内存等利用采纳专区隔离，防止对其余利用造成影响。

2.2.4 平台型业务容器化

置信做过 ToB 业务的同学应该都理解，任何产品都存在大客户计划，那么对于美团这样的公司，外部也会存在这种状况。平台型业务的容器化有个特点是：实例数多，以千或万计，所以资源老本就比拟高；业务位置比拟高，个别都是十分外围的业务，对性能和稳定性要求很高。所以，如果想要通过“一招鲜”的形式解决此类业务的问题，就有些不切实际。

这里，咱们以 MySQL 平台为例，数据库业务对于稳定性、性能和可靠性要求十分高，业务本人又次要以物理机为主，所以老本压力十分大。针对数据库的容器化，咱们次要是从宿主机端的资源分配定制和优化为切入口。

1. 针对 CPU 资源分配，采纳独占 CPU 汇合的形式，防止 Pod 之间产生争抢。
2. 通过容许自定义 SWAP 大小来应答短暂的高流量，并敞开 Numa Node 和 PageCache 来晋升稳定性。
3. 在磁盘调配中采纳 Pod 独占磁盘进行 IOPS 的隔离，以及通过预调配和格式化磁盘来晋升扩容的速度，晋升资源交付效率。
4. 调度反对独有的打散策略和缩容确认，躲避缩容危险。

最终，咱们将数据库的交付效率晋升了 60 倍，并且在大多数状况下性能比之前的物理机器还要好。

2.2.5 业务资源优先级保障

对于一个企业而言，基于老本思考，资源始终会处于有余的状态，那么如何保障资源的供应和调配就显得十分重要。

1. 业务估算配额确定资源供应，通过专区来做专有资源专用。
2. 建设弹性资源池和买通私有云来应答突发资源需要。
3. 依照业务和利用类型的优先级保障资源应用，确保外围业务先拿到资源。
4. 多个 Kubenretes 集群和多机房来做容灾，应答集群或机房的故障。

2.2.6 云原生架构的落地

在迁徙到 Kubernetes 之后，咱们进一步实现了云原生架构的落地。

为了解决云原生利用治理的阻碍，咱们设计实现了美团特色的云原生利用治理引擎——KubeNative，将利用的配置和信息管理对平台透明化，业务平台只须要创立原生的 Pod 资源即可，不须要关注利用的信息同步和治理细节，并反对各 PaaS 平台本人来扩大管制层面的能力，运行本人的 Operator。

下图就是目前咱们整个的云原生利用治理架构，已反对 Hulk 容器平台、Serverless 以及 TiDB 等平台的落地。

2.3 基础设施迁徙后的收益

1. 实现全公司业务 98% 的容器化，显著晋升了资源管理的效率和业务稳定性。
2. Kubernetes 稳定性 99.99% 以上。
3. Kubernetes 成为美团外部集群治理平台的规范。

三、经营大规模 Kubernetes 集群的挑战和应答策略

在整个基础设施迁徙过程中，除了解决历史遗留问题和零碎建设，随着 Kubernetes 集群规模和数量快速增长，咱们遇到的新的挑战是：如何稳固、高效地经营大规模 Kubernetes 集群。咱们在这几年的 Kubernetes 经营中，也逐步摸索出了一套验证可行的经营教训。

3.1 外围组件优化与降级

咱们最后应用的 Kubernetes 是 1.6 版本，性能和稳定性是比拟差的，当咱们达到 1K 节点的时候就逐步呈现问题，达到 5K 节点时根本集群不可用。例如，调度性能十分差，集群吞吐量也比拟低，偶然还产生“雪崩”的状况，扩缩容链路耗时也在变长。

针对外围组件的剖析和优化，这里从 kube-apiserver、kube-scheduler、etcd 以及容器等四个方面来概括下。

1. 针对 kube-apiserver，为了缩小重启过程长时间地产生 429 申请重试，咱们实现了多级的流量管制，将不可用窗口从 15min 升高为 1min，并通过缩小和防止内部零碎的 List 操作升高集群负载，通过外部的 VIP 来做节点的负载平衡，保障管制节点的稳定性。
2. 在 kube-scheduler 层，咱们加强了调度的感知策略，调度成果相比之前更稳固；对调度性能的优化提出的预选中断和部分最优策略也已合并到社区，并成为通用的策略。
3. 针对 etcd 的经营，通过拆分出独立的 Event 集群升高主库的压力，并且基于高配的 SSD 物理机器部署能够达到日常 5 倍的高流量拜访。
4. 在容器层面，容器复用晋升了容器的故障容忍能力，并通过精细化的 CPU 调配晋升利用稳定性；通过容器的磁盘预挂载晋升 Node 的故障复原速度。

另外，社区版本的迭代是十分快的，高版本在稳定性和个性反对上更好，不可避免咱们须要进行版本的降级，但如何确保降级胜利是一个很大的挑战，尤其是咱们在没有足够的 Buffer 资源进行资源腾挪状况下。

集群降级，业界通用的计划是间接基于原有集群降级，计划存在以下几点问题：

1. 降级版本有限度，不能跨大版本升级：只能一点点从低版本升级到高版本，耗时费劲，而且成功率低。
2. 管制立体降级危险不可控：尤其是有 API 变更的时候，会笼罩之前的数据，甚至是不可回滚的。
3. 用户有感知，容器须要新建，老本和影响较高：这个是比拟痛的点，无可避免会产生容器新建。

为此，咱们深入研究了 Kubernetes 对容器层面的管制形式，设计实现了一种可能平滑将容器数据从低版本集群迁徙到高版本集群的计划，将集群降级细化为 Node 粒度的一一宿主机上容器的原地热降级，随时能够暂停和回滚。新计划次要是通过内部工具将 Node 和 Pod 数据从低版本集群迁徙到高版本集群，并解决 Pod 对象和容器的兼容性问题。外围思路是两点：通过低版本兼容高版本的 API，通过刷新容器的 Hash 保障 Pod 下的容器不会被新；通过工具实现 Pod 和 Node 资源数据从低版本集群迁徙到高版本集群。

该计划亮点次要包含以下 4 个方面：

1. 大规模生产环境的集群降级不再是难题。
2. 解决了现有技术计划危险不可控的问题，危险降到了宿主机级别，降级更为平安。
3. 通用性强，可做到任意版本的降级，且计划生命周期长。
4. 优雅地解决了降级过程中容器新建问题，真正做到了原地热降级。

3.2 平台化与经营效率

大规模的集群经营是十分有挑战的事件，满足业务的疾速倒退和用户需要也是对团队极大的考验，咱们须要从不同纬度的思考集群的经营和研发能力。

在 Kubernetes 与 etcd 集群的整个经营和运维能力建设上，咱们关注的指标是平安经营、高效运维、标准化治理以及节约老本。所以针对 Kubernetes 与 etcd 集群，咱们曾经实现了平台化的治理经营，笼罩了个性扩大、性能与稳定性、日常运维、故障复原、数据经营以及平安管控等 6 个方面。

对于一个非公有云业务的 Kubernetes 团队，人力还是十分无限的，除了集群的日常经营还有研发工作，所以咱们对于经营效率的晋升十分关注。咱们将日常运维逐渐的积淀转换，构建了一套美团外部的 Kubernetes 集群治理平台。

1. 将集群的治理标准化、可视化，防止了黑白屏的运维操作。
2. 通过告警自愈和主动巡检将问题解决收敛掉，所以尽管咱们有大几十个集群，但咱们的运维效率还是比拟高的，值班同学很少须要关注。
3. 全副的运维操作流程化，不仅晋升了运维效率，人为操作导致的故障的概率也减小了。
4. 通过经营数据的剖析进一步做了资源的精细化调度和故障预测，进一步提前发现危险，晋升了经营的品质。

3.3 危险管制和可靠性保障

规模大、笼罩业务广，任何的集群故障都会间接影响到服务的稳定性甚至用户的体验，在经验了屡次运维故障和平安压力下，咱们造成了一套可复制的危险管制和可靠性保障策略。

在整个危险管控链路中，咱们分为指标、告警、工具、机制 & 措施和人员 5 个层面：

1. 指标数据采集，从节点、集群、组件以及资源层面采集外围指标作为数据源。
2. 危险推送，笼罩外围指标的多级、多维度的告警机制。
3. 在工具反对上，通过被动、被动以及流程化等缩小误操作危险。
4. 机制保障上，买通测试、灰度验证、公布确认以及演练等升高疏忽大意的状况。
5. 人是危险的基本，这块咱们始终也在致力建设和轮值，确保问题的响应。

在可靠性验证和经营方面，咱们笃信须要把功夫用在评审，通过集群巡检来评估集群的衰弱状况，并推送报表；定期的宕机演练保障实在故障可能疾速复原，并将日常问题补全到全链路测试中，造成闭环。

四、总结与将来瞻望

4.1 教训心得

1. Kubernetes 的落地齐全兼容社区的 Kubernetes API；只会做插件化的扩大，并尽量不改管制层面的原有行为。
2. 对社区的一些个性，舍短取长，并且有预期的降级，不自觉降级和跟进社区版本，尽量放弃每年度的一个外围稳固版本。
3. 落地以用户痛点为突破口，业务是比拟理论的，为什么须要进行迁徙？业务会怕麻烦、不配合，所以推动要找到业务痛点，从帮忙业务的角度登程，成果就会不一样。
4. 外部的集群治理经营的价值展示也是很重要的一环，让用户看到价值，业务看到潜在的收益，他们会被动来找你。

在容器时代，不能只看 Ku1. bernetes 自身，对于企业内的基础设施，“向上”和“向下”的交融和兼容问题也很要害。“向上”是面向业务场景为用户提供对接，因为容器并不能间接服务于业务，它还波及到如何部署利用、服务治理、调度等诸多层面。“向下”，即容器与基础设施相结合的问题，这里更多的是兼容资源类型、更弱小的隔离性、更高的资源应用效率等都是关键问题。

4.2 将来瞻望

1. 对立调度：VM 会大量长期存在一段时间，但如果同时保护两套基础设施产品成本是十分高的，所以咱们也在落地 Kubernetes 来对立治理 VM 和容器。
2. VPA：摸索通过 VPA 来进一步晋升整个资源的应用效率。
3. 云原生利用治理：以后，咱们已将云原生利用治理在生产环境落地，将来咱们会进一步扩充云原生利用的覆盖面，一直晋升研发效率。
4. 云原生架构落地：推动各个中间件、存储系统、大数据以及搜寻业务单干落地各个领域的云原生零碎。

作者介绍

国梁，美团点评技术专家，现负责美团点评 Kubernetes 集群的整体经营和保护以及云原生技术落地反对。

招聘信息

美团点评基础架构团队诚招高级、资深技术专家，Base 北京、上海。咱们致力于建设美团全公司对立的高并发高性能分布式基础架构平台，涵盖数据库、分布式监控、服务治理、高性能通信、消息中间件、根底存储、容器化、集群调度、Kubernetes、云原生等基础架构次要的技术畛域。欢送有趣味的同学投送简历到 tech@meituan.com（邮件主题注明：基础架构）

浏览更多技术文章，请扫码关注微信公众号 - 美团技术团队！