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

原文地址:https://note.youdao.com/share/?id=08d7c57b04dda159c53155b00cbbe5cb&type=note#/

容器的实现

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

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

美团的解法、改进和优化

隔离

之前一直和虚拟机打交道,但直到用上容器,才发现在容器里面看到的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监控曲线突刺增加,吞吐量下降。针对这个问题有各种解法:

  • 显式的传递JVM启动参数“-XX:ParallelGCThreads”告诉JVM应该启动几个并行GC线程。它的缺点是需要业务感知,为不同配置的容器传不同的JVM参数。
  • 在容器内使用Hack过的glibc,使JVM(通过sysconf系统调用)能正确获取容器的CPU资源数。我们在一段时间内使用的就是这种方法。其优点是业务不需要感知,并且能自动适配不同配置的容器。缺点是必须使用改过的glibc,有一定的升级维护成本,如果使用的镜像是原生的glibc,问题也仍然存在。
  • 我们在新平台上通过对内核的改进,实现了容器中能获取正确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服务重启以后,Docker exec无法进入容器,这个问题比较复杂。在解决之前我们用nsenter来代替Docker exec并积极反馈给Red Hat。后来Red Hat在今年初的一个更新解决了这个问题。https://access.redhat.com/errata/RHBA-2017:1620
  • 是在特定条件下Docker Daemon会Panic,导致容器无法删除。经过我们自己Debug,并对比最新的代码,发现问题已经在Docker upstream中得到解决,反馈给Red Hat也很快得到了解决。https://github.com/projectatomic/containerd/issues/2

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

  • 美团的应用规模大、场景复杂,很多问题也许很多企业都没有遇到过,不能被动的等别人来解答。
  • 对于一些实际的业务问题或者需求(例如容器内正确返回CPU数目),社区也许觉得不重要,或者不是正确的理念,可能就不会解决。
  • 社区很多时候只在Upstream解决问题,而Upstream通常不稳定,即使有Backport到我们正在使用的版本,排期也很难进行保障。
  • 社区会发布很多补丁,通常描述都比较晦涩难懂,如果没有对问题的深刻理解,很难把遇到的实际问题和一系列补丁联系起来。
  • 对于一些复杂问题,社区的解决方案不一定适用于我们自身的实际场景,我们需要自身有能力进行判断和取舍。

美团在解决开源系统问题时,一般会经历五个阶段:自己深挖、研发解决、关注社区、和社区交互,最后贡献给社区。

性能

容器平台性能,主要包括两个方面性能:

  • 业务服务运行在容器上的性能。
  • 容器操作(创建、删除等等)的性能。

上图是我们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文件系统有三种日志模式:

  • Journal:写数据前等待Metadata和数据的日志落盘。
  • Ordered:只记录Metadata的日志,写Metadata日志前确保数据已经落盘。
  • Writeback:仅记录Metadata日志,不保证数据比Metadata先落盘。

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

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

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

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

  • 存在多个Site。
  • 支持跨Site的镜像同步,根据镜像的标签确定是否需要跨Site同步。
  • 每个Site有镜像备份。
  • 每个Site内部有实现镜像分发的P2P网络。

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

  • 跨Site同步:保证服务器总能从就近的镜像仓库拉取到扩容用的镜像,减少拉取时间,降低跨Site带宽消耗。
  • 基础镜像预分发:美团的基础镜像是构建业务镜像的公共镜像,通常有几百兆的大小。业务镜像层是业务的应用代码,通常比基础镜像小很多。在容器扩容的时候如果基础镜像已经在本地,只需要拉取业务镜像的部分,可以明显地加快扩容速度。为达到这样的效果,我们会把基础镜像事先分发到所有的服务器上。
  • P2P镜像分发:基础镜像预分发在有些场景会导致上千个服务器同时从镜像仓库拉取镜像,对镜像仓库服务和带宽带来很大的压力。因此我们开发了镜像P2P分发的功能,服务器不仅能从镜像仓库中拉取镜像,还能从其他服务器上获取镜像的分片。

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

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

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

Docker的镜像具有分层结构,对镜像层的合并是一个“解压一层合并一层,再解压一层,再合并一层”的串行操作。实际上只有合并是需要串行的,解压可以并行起来。我们把多层的解压改成并行,解压出的数据先放在临时存储空间,最后根据层之间的依赖进行串行合并。前面的改动(并行解压所有的层到临时空间)导致磁盘IO的次数增加了近一倍,也会导致解压过程不够快。于是,我们使用基于内存的Ramdisk来存储解压出来的临时文件,减轻了额外文件写带来的开销。做了上面这些工作以后,我们又发现,容器的分层也会影响下载加解压的时间。上图是我们简单测试的结果:无论对于怎么分层的镜像并行解压,都能大幅提升解压时间,对于层数多的镜像提升更加明显。

推广

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

  • 轻量级:容器小、快,能够实现秒级启动。
  • 应用分发:容器使用镜像分发,开发测试容器和部署容器配置完全一致。
  • 弹性:可以根据CPU、内存等资源使用或者QPS、延时等业务指标快速扩容容器,提升服务能力。

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

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

  • 产品优势:推广容器平台从某种程度上讲,自身是一个ToB的业务,首先要有好的产品,它相对于以前的解决方案(虚拟机)存在很多优势。
  • 和已有系统打通:这个产品要能和客户现有的系统很好的进行集成,而不是让客户推翻所有的系统重新再来。
  • 原生应用的开发平台、工具:这个产品要易于使用,要有配合工作的工具链。
  • 虚拟机到容器的平滑迁移:最好能提供从原有方案到新产品的迁移方案,并且容易实施。
  • 与应用RD紧密配合:要提供良好的客户支持,(即使有些问题不是这个产品导致的也要积极帮忙解决)。
  • 资源倾斜:从战略层面支持颠覆性新技术:资源上向容器平台倾斜,没有足够的理由,尽量不给配置虚拟机资源。

原文地址:https://note.youdao.com/share/?id=08d7c57b04dda159c53155b00cbbe5cb&type=note#/

原文发布于微信公众号 - 云计算与大数据(heidcloud)

原文发表时间:2018-11-15

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏安恒信息

漏洞预警 | FFmpeg组件处理播放列表文件可能导致信息泄露

FFmpeg是一个免费的可以执行音讯和视讯多种格式的录影、转档、串流功能的软件,广泛的应用于各大视频网站上。 FFmpeg处理HLS播放列表文件的方式存在安全漏...

30170
来自专栏IT大咖说

揭秘携程内部海量CRN项目解决方案

摘要 随着公司内部CRN项目的日益增多,越来越多的业务部门开始意识到,是否可以将CRN的项目直接运行在浏览器上,以免去他们在H5和SEO上的额外开发。甚至有的W...

44750
来自专栏CSDN技术头条

Docker将会在Windows和MAC平台本地化

对Linux用户来说,Docker一直是一个本地化的应用程序,但是对于Windows和MAC来说并不是。好消息是,Docker马上将要发布两个新的测试版本:Do...

26570
来自专栏从零开始的linux

初识docker

docker使用go语言开发,基于apache2.0协议 容器虚拟化 ? 传统虚拟化 ? Docker的优势 启动非常快,秒级实现 资源利用率很高,一台机器可以...

39050
来自专栏SDNLAB

新型云基础设施项目Airship 介绍

AT&T正在与SK电信(SKT),Intel和OpenStack基金会合作推出一个名为Airship的新型云开放基础设施项目。Airship的宣传语是“声明式地...

25120
来自专栏FreeBuf

如何打造一款可靠的WAF(Web应用防火墙)

之前写了一篇《WAF防御能力评测及工具》,是站在安全运维人员选型WAF产品的角度来考虑的(优先从测试角度考虑是前职业病,毕竟当过3年游戏测试?!)。本篇文章从W...

40450
来自专栏北京马哥教育

Linux 容器 vs 虚拟机 —— 谁更胜一筹

自从Linux上的容器变得流行以来,了解Linux容器和虚拟机之间的区别变得更加棘手。本文将向您提供详细信息,以了解Linux容器和虚拟机之间的差异。 Linu...

31340
来自专栏技术翻译

考虑将Docker引入您的数据科学工作流程

作为数据科学家的一个重要问题是正确配置数据科学环境。有时这意味着安装了很多软件包,等待软件包编译,处理模糊的错误,设置一切正常工作......大多数时候,这是一...

10800
来自专栏大魏分享(微信公众号:david-share)

原生KVM虚拟化方案"管理平台"配置步骤(RHV-M Appliance)

浅谈2016年的虚拟化市场 本文正式开始之前,先阐述一个观点,即RHV/RHEV是基于KVM原生的虚拟化解决方案, 为什么这么说呢? 首先,KVM严格意义上讲不...

49740
来自专栏祝威廉

其实连Docker公司都把Docker用错啦

好吧,我承认我标题党了。但是这篇内容应该让你从一个新的角度理解Docker的本质是什么。

8620

扫码关注云+社区

领取腾讯云代金券