美团容器平台架构及容器技术实践

背景

美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”，它的这个特性和容器的“弹性伸缩”很像，所以我们给这个平台起名为HULK。貌似有一些公司的容器平台也叫这个名字，纯属巧合。

2016年，美团开始使用容器，当时美团已经具备一定的规模，在使用容器之前就已经存在的各种系统，包括CMDB、服务治理、监控告警、发布平台等等。我们在探索容器技术时，很难放弃原有的资产。所以容器化的第一步，就是打通容器的生命周期和这些平台的交互，例如容器的申请/创建、删除/释放、发布、迁移等等。然后我们又验证了容器的可行性，证实容器可以作为线上核心业务的运行环境。

2018年，经过两年的运营和实践探索，我们对容器平台进行了一次升级，这就是容器集群管理平台HULK 2.0。

美团当前的容器使用状况是：线上业务已经超过3000多个服务，容器实例数超过30000个，很多大并发、低延时要求的核心链路服务，已经稳定地运行在HULK之上。本文主要介绍我们在容器技术上的一些实践，属于基础系统优化和打磨。

美团容器平台的基本架构

首先介绍一下美团容器平台的基础架构，相信各家的容器平台架构大体都差不多。

首先，容器平台对外对接服务治理、发布平台、CMDB、监控告警等等系统。通过和这些系统打通，容器实现了和虚拟机基本一致的使用体验。研发人员在使用容器时可以和使用VM一样，不需要改变原来的使用习惯。

此外，容器提供弹性扩容能力，能根据一定的弹性策略动态增加和减少服务的容器节点数，从而动态地调整服务处理能力。这里还有个特殊的模块——“服务画像”，它的主要功能是通过对服务容器实例运行指标的搜集和统计，更好的完成调度容器、优化资源分配。比如可以根据某服务的容器实例的CPU、内存、IO等使用情况，来分辨这个服务属于计算密集型还是IO密集型服务，在调度时尽量把互补的容器放在一起。

再比如，我们可以知道某个服务的每个容器实例在运行时会有大概500个进程，我们就会在创建容器时，给该容器加上一个合理的进程数限制（比如最大1000个进程），从而避免容器在出现问题时，占用过多的系统资源。如果这个服务的容器在运行时，突然申请创建20000个进程，我们有理由相信是业务容器遇到了Bug，通过之前的资源约束对容器进行限制，并发出告警，通知业务及时进行处理。

往下一层是“容器编排”和“镜像管理”。容器编排解决容器动态实例的问题，包括容器何时被创建、创建到哪个位置、何时被删除等等。镜像管理解决容器静态实例的问题，包括容器镜像应该如何构建、如何分发、分发的位置等等。

最下层是我们的容器运行时，美团使用主流的Linux+Docker容器方案，HULK Agent是我们在服务器上的管理代理程序。

把前面的“容器运行时”具体展开，可以看到这张架构图，按照从下到上的顺序介绍：

美团主要使用了CentOS系列的开源组件，因为我们认为Red Hat有很强的开源技术实力，比起直接使用开源社区的版本，我们希望Red Hat的开源版本能够帮助解决大部分的系统问题。我们也发现，即使部署了CentOS的开源组件，仍然有可能会碰到社区和Red Hat没有解决的问题。从某种程度上也说明，国内大型互联公司在技术应用的场景、规模、复杂度层面已经达到了世界领先的水平，所以才会先于社区、先于Red Hat的客户遇到这些问题。

容器遇到的一些问题

在容器技术本身，我们主要遇到了4个问题：隔离、稳定性、性能和推广。

容器的实现

容器本质上是把系统中为同一个业务目标服务的相关进程合成一组，放在一个叫做namespace的空间中，同一个namespace中的进程能够互相通信，同时看不见其他namespace中的进程。每个namespace可以拥有自己独立的主机名、进程ID系统、IPC、网络、文件系统、用户等等资源，在某种程度上，实现了一个简单的虚拟：让一个主机上可以同时运行多个互不感知的系统。

此外，为了限制namespace对物理资源的使用，对进程能使用的CPU、内存等资源需要做一定的限制，这就是Cgroup技术，Cgroup是Control group的意思。比如我们常说的4c4g的容器，实际上是限制这个容器namespace中所用的进程，最多能够使用4核的计算资源和4GB的内存。

简而言之，Linux内核提供namespace完成隔离，Cgroup完成资源限制。namespace+Cgroup构成了容器的底层技术（rootfs是容器文件系统层技术）。

美团的解法、改进和优化

隔离

之前一直和虚拟机打交道，但直到用上容器，才发现在容器里面看到的CPU、Memory的信息都是服务器主机的信息，而不是容器自身的配置信息，直到现在，社区版的容器还是这样。比如一个4c4g的容器，在容器内部可以看到有40颗CPU、196GB内存的资源，这些资源其实是容器所在宿主机的信息。这给人的感觉，就像是容器的“自我膨胀”，觉得自己能力很强，但实际上并没有，而且还会带来很多问题。

上图是一个内存信息隔离的例子。获取系统内存信息时，社区Linux无论在主机上还是在容器中，内核都是统一返回主机的内存信息，如果容器内的应用，按照它发现的宿主机内存来进行配置的话，实际资源是远远不够的，导致的结果就是：系统很快会发生OOM异常。

我们做的隔离工作，是在容器中获取内存信息时，内核根据容器的Cgroup信息返回容器的内存信息（类似LXCFS的工作）。

CPU信息隔离的实现和内存的类似，不再赘述，这里举一个CPU数目影响应用性能例子。

大家都知道，JVM GC（垃圾对象回收）对Java程序执行性能有一定的影响。默认的JVM使用公式“ParallelGCThreads = (ncpus <= 8) ? ncpus : 3 + ((ncpus * 5) / 8)” 来计算做并行GC的线程数，其中ncpus是JVM发现的系统CPU个数。一旦容器中JVM发现了宿主机的CPU个数（通常比容器实际CPU限制多很多），这就会导致JVM启动过多的GC线程，直接的结果就导致GC性能下降。Java服务的感受就是延时增加，TP监控曲线突刺增加，吞吐量下降。针对这个问题有各种解法：

 ●  我们在新平台上通过对内核的改进，实现了容器中能获取正确CPU资源数，做到了对业务、镜像和编程语言都透明（类似问题也可能影响OpenMP、Node.js等应用的性能）。

有一段时间，我们的容器是使用root权限进行运行，实现的方法是在docker run的时候加入‘privileged=true’参数。这种粗放的使用方式，使容器能够看到所在服务器上所有容器的磁盘，导致了安全问题和性能问题。安全问题很好理解，为什么会导致性能问题呢？可以试想一下，每个容器都做一次磁盘状态扫描的场景。当然，权限过大的问题还体现在可以随意进行mount操作，可以随意的修改NTP时间等等。

在新版本中，我们去掉了容器的root权限，发现有一些副作用，比如导致一些系统调用失败。我们默认给容器额外增加了sys_ptrace和sys_admin两个权限，让容器可以运行GDB和更改主机名。如果有特例容器需要更多的权限，可以在我们的平台上按服务粒度进行配置。

Linux有两种IO：Direct IO和Buffered IO。Direct IO直接写磁盘，Duffered IO会先写到缓存再写磁盘，大部分场景下都是Buffered IO。

我们使用的Linux内核3.X，社区版本中所有容器Buffer IO共享一个内核缓存，并且缓存不隔离，没有速率限制，导致高IO容器很容易影响同主机上的其他容器。Buffer IO缓存隔离和限速在Linux 4.X里通过Cgroup V2实现，有了明显的改进，我们还借鉴了Cgroup V2的思想，在我们的Linux 3.10内核实现了相同的功能：每个容器根据自己的内存配置有对应比例的IO Cache，Cache的数据写到磁盘的速率受容器Cgroup IO配置的限制。

Docker本身支持较多对容器的Cgroup资源限制，但是K8s调用Docker时可以传递的参数较少，为了降低容器间的互相影响，我们基于服务画像的资源分配，对不同服务的容器设定不同的资源限制。除了常见的CPU、内存外，还有IO的限制、ulimit限制、PID限制等等，所以我们扩展了K8s来完成这些工作。

业务在使用容器的过程中产生core dump文件是常见的事。比如C/C++程序内存访问越界，或者系统OOM时，系统选择占用内存多的进程杀死，默认都会生成一个core dump文件。

社区容器系统默认的core dump文件会生成在宿主机上。由于一些core dump文件比较大，比如JVM的core dump通常是几个GB，或者有些存在Bug的程序，其频发的core dump，很容易快速写满宿主机的存储，并且会导致高磁盘IO，也会影响到其他容器。还有一个问题是：业务容器的使用者没有权限访问宿主机，从而拿不到dump文件进行下一步的分析。

为此，我们对core dump的流程进行了修改，让dump文件写到容器自身的文件系统中，并且使用容器自己的Cgroup IO吞吐限制。

稳定性

我们在实践中发现，影响系统稳定性的主要是Linux Kernel和Docker。虽然它们本身是很可靠的系统软件，但是在大规模、高强度的场景中，还是会存在一些Bug。这也从侧面说明，我们国内互联网公司在应用规模和应用复杂度层面也属于全球领先。

在内核方面，美团发现了Kernel 4.x Buffer IO限制的实现问题，得到了社区的确认和修复。我们还跟进了一系列CentOS的Ext4补丁，解决了一段时间内进程频繁卡死的问题。

我们碰到了两个比较关键的Red Hat版Docker稳定性问题：

面对系统内核、Docker、K8S这些开源社区的系统软件，存在一种观点是：我们不需要自己分析问题，只需要拿社区的最新更新就行了。但是我们并不认同，我们认为技术团队自身的能力很重要，主要是如下原因：

性能

容器平台性能，主要包括两个方面性能：

 ●  容器操作（创建、删除等等）的性能。

上图是我们CPU分配的一个例子，我们采用的主流服务器是两路24核服务器，包含两个Node，每个12核，算上超线程共48颗逻辑CPU。属于典型的NUMA（非一致访存）架构：系统中每个Node有自己的内存，Node内的CPU访问自己的内存的速度，比访问另一个Node内存的速度快很多（差一倍左右）。

过去我们曾经遇到过网络中断集中到CPU0上的问题，在大流量下可能导致网络延时增加甚至丢包。为保证网络处理能力，我们从Node0上划出了8颗逻辑CPU用来专门处理网络中断和宿主机系统上的任务，例如镜像解压这类高CPU的工作，这8颗逻辑CPU不运行任何容器的Workload。

在容器调度方面，我们的容器CPU分配尽量不跨Node，实践证明跨Node访问内存对应用性能的影响比较大。在一些计算密集型的场景下，容器分配在Node内部会提升30%以上的吞吐量。当然，按Node的分配方案也存在一定的弊端：会导致CPU的碎片增加，为了更高效地利用CPU资源，在实际系统中，我们会根据服务画像的信息，分配一些对CPU不敏感的服务容器跨Node使用CPU资源。

上图是一个真实的服务在CPU分配优化前后，响应延时的TP指标线对比。可以看到TP999线下降了一个数量级，并且所有的指标都更加平稳。

性能优化：文件系统

针对文件系统的性能优化，第一步是选型，根据统计到的应用读写特征，我们选择了Ext4文件系统（超过85%的文件读写是对小于1M文件的操作）。

Ext4文件系统有三种日志模式：

我们选择了Writeback模式（默认是oderded），它在几种挂载模式中速度最快，缺点是：发生故障时数据不好恢复。我们大部分容器处于无状态，故障时在别的机器上再拉起一台即可。因此我们在性能和稳定性中，选择了性能。容器内部给应用提供可选的基于内存的文件系统tmpfs，可以提升有大量临时文件读写的服务性能。

如上图所示，在美团内部创建一个虚拟机至少经历三步，平均时间超过300秒。使用镜像创建容器平均时间23秒。容器的灵活、快速得到了显著的体现。

容器扩容23秒的平均时间包含了各个部分的优化，如扩容链路优化、镜像分发优化、初始化和业务拉起优化等等。接下来，本文主要介绍一下我们做的镜像分发和解压相关的优化。

上图是美团容器镜像管理的总体架构，其特点如下：

镜像分发是影响容器扩容时长的一个重要环节。

从上图可以看出，随着分发服务器数目的增加，原有分发时间也快速增加，而P2P镜像分发时间基本上保持稳定。

Docker的镜像拉取是一个并行下载，串行解压的过程，为了提升解压的速度，我们美团也做了一些优化工作。

对于单个层的解压，我们使用并行解压算法替换Docker默认的串行解压算法，实现上是使用pgzip替换gzip。

Docker的镜像具有分层结构，对镜像层的合并是一个“解压一层合并一层，再解压一层，再合并一层”的串行操作。实际上只有合并是需要串行的，解压可以并行起来。我们把多层的解压改成并行，解压出的数据先放在临时存储空间，最后根据层之间的依赖进行串行合并。前面的改动（并行解压所有的层到临时空间）导致磁盘IO的次数增加了近一倍，也会导致解压过程不够快。

于是，我们使用基于内存的Ramdisk来存储解压出来的临时文件，减轻了额外文件写带来的开销。做了上面这些工作以后，我们又发现，容器的分层也会影响下载加解压的时间。上图是我们简单测试的结果：无论对于怎么分层的镜像并行解压，都能大幅提升解压时间，对于层数多的镜像提升更加明显。

推广

推广容器的第一步是能说出容器的优势，我们认为容器有如下优势：

这三个特性的组合，可以给业务带来更大的灵活度和更低的计算成本。

因为容器平台本身是一个技术产品，它的客户是各个业务的RD团队，因此我们需要考虑下面一些因素：

总结

Docker容器加Kubernetes编排是当前容器云的主流实践之一，美团容器集群管理平台HULK也采用了这样的方案。本文主要分享了美团在容器技术上做的一些探索和实践。内容主要涵盖美团容器云在Linux Kernel、Docker和Kubernetes层面做的一些优化工作，以及美团内部推动容器化进程的一些思考，欢迎大家跟我们交流、探讨。