阿里巴巴容器技术 Pouch 解析

Posted 2021-05-02 GoCN

大家早上好，很高兴今天能给大家介绍一下容器技术。其实昨天有很多的讲师已经说到容器，比如说饿了么的雪峰老师介绍他们那儿有 20% 业务已经用上了容器，饿了么对容器的倚重还是比较大的，洪教授也介绍到做容器方面的一些工作，七牛也为容器技术的探索做了很多工作。

那我先做一个现场调查，大家用过容器技术的举手。我发现还有一半人没有使用过容器技术，说明容器技术在市场化的路程当中还会有一个爆发点。

我还想问大家一个问题，有没有谁敢拍着胸脯说自己安装软件的时候从没有失败过？（看到很多人笑了）这说明一个问题，这可能并不能做到，但容器的镜像技术可以帮助大家实现。

我今天的议题是“解析阿里巴巴 Pouch 容器开源技术”。其实，阿里巴巴作为一家互联网公司有很多的业务，它的机房也很大，其实一家上了规模的公司谈到技术的时候，逃不出“规模”两个字。规模效应，比如容器技术，可以为一家公司节省很多方面的成本。如果大家原来用10台虚拟机100台虚拟机能够搞定的事情，现在需要3台物理机100个容器可以搞定，这样就节省了 7 台服务器，如果规模到了 1 万台服务器，容器技术可以节省上亿的成本。

今天我会从几个维度介绍Pouch技术，第一个是阿里集团的容器现状，然后是 pouch 的技术优势，还有pouch 的开源发展，相信这个方面很多人都有一个问题，pouch和docker有什么关系？后面会跟大家介绍到。

我们首先来看一下阿里巴巴集团容器的现状，在介绍之前大家肯定有一个疑问，为什么阿里云容器不直接用 docker？这里就涉及到开源技术怎么应用的问题。对于开源技术很多公司觉得价值很大，都会用，就像昨天雪峰老师介绍的一样，开源技术在企业落地的时候不仅是软件的事情，还有企业的技术团队怎么来做支撑。企业里面很多事情都是被逼的，很多业务需要对技术提出一些需求的时候，底层的技术就必须要迎合上层业务的需求。想想看，如果使用一个开源技术，我们能够做到百分百的快速响应吗？技术团队能够对业务部门说这个 feature 很好，但是下个月的 1.9 版本当中才有，那个时候我肯定会支持你吗？你觉得业务部门能够答应吗？肯定不能答应的。

很多公司在初期采用开源技术以后，往往会 fork 一份代码，事后再针对他的业务做一些支持或者说定制，如果情况好的话，那些改进、增强还能够 backport 到上流upstream社区，但事实很多是不能的，因为社区通常是通用化的技术积淀，而在企业里面的定制往往涉及到业务相关。

在这种情况下企业怎么办呢？往往他们自己有一套。阿里在 2011 年 Docker 没有诞生的时候就开始使用基于 LXC 的容器技术 ，使用在电商应用中。2015年初期的时候，这个容器技术里面没有包含镜像这个特性，这个时候把外界的镜像技术引入进来，形成现在的阿里容器。

现在容器技术使用到了什么规模呢？Pouch 技术覆盖阿里集团接近百来个 BU，在上个月双11的时候，接近2千亿的成交额依靠百万级的容器支持，在线业务 100% 容器化。昨天雪峰也介绍了为什么不把所有的业务都容器化，存储是一个比较大的原因；我们的情况是在线业务应用在演变过程当中，计算存储可以很好的做到适配容器，但是我们的离线业务没有真正完全做到容器化。

覆盖场景方面，在运行模式、编程语言、技术栈方面，都使用到了pouch，在这个方面，如果大家没有接触容器技术，比如说 docker，我这边有一个广告语，不管你用世界上最好的语言还是最差的语言，都可以用容器，所以尽管上容器这条船吧。这里包括蚂蚁，B2B，菜鸟、高德，阿里的专有云都用了我们的Pouch技术。

很多人问我 Pouch 是什么意思？育儿袋，它象征着对我们的应用 “贴身呵护“。它始于 2011年，是阿里内部容器技术产品，并于当年上线；2015年初开始吸收Docker镜像功能。容器结合阿里内核，大幅度提高隔离性。

接下来，介绍Pouch的演进之路。在绝大多数公司当中，业务还是肯定最为重要的环节之一。从业务的角度来讲，有应用开发，也有运维开发，应用开发过程当中，开发出来的应用，再推向部署，管理运维的时候，运维人员对底层支撑技术有一定的要求，阿里内部从运维视角出发，需要对一个应用的分装载体有一些要求，比如说独立的IP、能够ssh登陆，便于运维，出现问题能够第一时间解决问题，这是很必要的；有独立的文件系统，因为阿里这样的公司，内部有很多的业务，不同的业务部门，不同的 BU 部署在同一台机器上，能够做到初步的隔离，后面隔离要求越来越高，能够满足资源隔离，可见性和使用量。当前社区当中的容器技术会存在一定的弊端，比如我们看一个容器比如说 jvm，java 应用，会查看系统的总内存使用量来分配堆栈大小，在容器执行 free 命令，容器命名受到1G内核的限制，而我们却会看到正态宿主机16G的内存，这种情况会影响我们容器的运行。后面会介绍怎么解决这个问题。

如果要使用容器，使用 LXC，手工 hack 实现容器会有这样的一 些内容，你会发现，网桥管理其实已经非常方便了，通过系统调用可以创建虚拟网桥、网卡，我们可以去运行 sshd，独立的文件系统，可以通过 chroot 管理，资源隔离，使用量和可见性，通过 cgroup，Namespace，可以流量和网络的控制。时间到了2015年，那时候镜像技术让整个行业的软件交付有了统一的标准，阿里则引入Docker的镜像技术，逐渐形成了 Pouch。

Pouch 和 Docker 有哪些区别呢？

首先是隔离性。因为在云上，如果几个不同的租户在同一个机器上使用容器，如果他们现在使用行业中的一些容器技术，在隔离性方面肯定会受到影响。

另外一个方面是有 P2P 的镜像分发，阿里这样的公司，后面会介绍一下，其实数据量非常大的，一个应用打一个新的镜像要在很多节点分发的话量会非常大，如果单独通过一个 registry 下拉镜像，性能非常差，那么能不能通过 P2P 链式分发的方式来缓解镜像传输的能耗呢？

还有就是富容器技术。社区希望我们是 “one process，one container”，就是说我们容器当中只允许一个应用，这种情况对于传统的运维来说是一个灾难性的事件，因为里面缺少很多辅助运维的工具、脚本等以后，那势必会造成出了问题两眼摸黑，运维能力没有上去，对业务的支持会有很大的缺陷。在这个行业过渡期当中，阿里采用一种方案，让我们的容器继续延用传统运维方式，我们认为是一种富容器技术，这里面能够做的东西很多，比如会有个 init 进程、系统的 service、容器启动中的 pre-hook 等，这个是富容器的一些特性。

另外在规模化考验和内核兼容性方面也有一些优势。

介绍一下 Pouch 的生态架构。主要是阐述一下pouch在当前这个容器生态的定位，目前大家对于左边这一层知道的多一些，右边知道的少一些，左边大家听过最多就是 kubernetes。它和Docker的关系比较微妙，互相竞争，我们也会在 Pouch 当实现 CRI，在CRI里面保证我们的Pouch 在用户的数据中心当中，面对 kubernetes 的整个编排体系，做成 plugin。在 API 层面会延用 Docker，用户角度 API 是最主要的，所以我们会沿用Docker，这样也可以支持其他的编排系统。

图右边大家接触的少一些，因为这些属于系统底层，比如说 runtime 前面，大家可能听说的是 RunC，其实还有一些其他的 runtime，以虚拟机的形式启动起来，大家肯定能想到的优势是它的内核隔离性会做的很好，但是大家可以想象得到它的损耗、性能会下降、启动时间也会下降，这是一种折中的方案，毫无疑问它的损耗和启动时间会下降很多，会在秒级的时间，主要是为了提高它的安全性。阿里自己有一个Runlxc。下面还有一些隔离性的增强如 lxcfs，能够帮助容器提高其资源可见性方面的特性。其他还有一些 P2P 链式分发的开源项目，比如蜻蜓，大家可以关注一下。

看一下 Pouch 整个内部的一些架构，主要有两个层面，一个是CRI的实现，还有 Docker container API的实现，底层会延用层级的架构，最下层会对接 containerd，主要是在内核支持上面，中间层面主要还是各个维度 object 的 manager，请见下图。

丰富的隔离性。刚才讲的是 Pouch 的一些架构，我这边会讲架构之下的一些隔离性的优势。首先传统容器的隔离维度：namespace，cgroup；更优的容器可见性隔离：阿里 kernel、内核 Pouch、 lxcfs；额外隔离维度：磁盘、网络等 ：diskquota；基于 Hypervisor 的强容器隔离。见下图，主要还是在这个 container 上面，有一个 GuestOS 来实现内核层面的隔离，对多租户隔离要求高的场景非常有效。

我们还考虑到一点，整个行业可能花 5 到 8 年的时间适应了虚拟机，但是我们云的发展非常快，现在全都是容器的世界，整个行业在变现过程当中，其实过度期非常长的，这个时候如果有一样工具在体系当中既能够管控容器，又能够管控虚拟机，它价值会非常大，因为对于企业来讲，虽然底层的基础设施已经是异构的，但他们希望软件层面不是那么异构，从管控层面考虑，也是我们涉及的一个很重要原因。

资源可见性方面采用 lxcfs。其实这并不是大的问题，如果大家了解内核的话，在内核里面新增一套 cgroup，namespace 不就可以了。但是阿里的工程师和内核社区的人在交流讨论的时候会发现，这样的一种方式很难直接给我们的行业带来价值，因为这会涉及到很多方面关于内核的升级，pouch 方面的事情，尤其涉及到 cgroup2 这个版本的升级，现在的一个方案是通过 lxcfs 用户层的隔离手段来帮助容器技术解决这个问题。比如说 jav a应用容器化后相互影响、缺省堆栈大小取决于宿主机内存大小、缺省GC，JIT编译线程取决于宿主机CPU核数等。

刚才主要是介绍了 Pouch 在资源隔离方面做的一些改进，文档可以在 GitHub 上找到。

下面介绍 Pouch 和 P2P 镜像链式分发工具 “蜻蜓” 的结合，其实 P2P 技术诞生很长时间了，主要是帮助数据中心下载镜像的时候不要产生 类似于ddos 的请求，希望每个数据中心当中会有一个像 supernode 这样的节点，每个数据中心当中以 P2P 的方式分发内容。因为它不是 Pouch 的技术核心所以我简单介绍一下，如果大家感兴趣的话可以去 github 上看它的代码和使用文档，因为我相信一个容器技术推广的公司，肯定会遇到这样的问题，这些开源软件会给大家带来很大的方便。

这是我们使用的一个富容器技术，富容器技术和大家想象当中有一些不一样，可能也有些不同的思想，大家参考一下。众所周知，当前的容器技术，不会在容器内部回收僵尸进程，如果我写一个程序不断产生僵尸进程，你会发现那一台机器无法使用了。而富容器会在容器里面运行 init 进程，帮助用户解决类似的问题，当然还是其他的一些容器内部进程的管理能力。

容器内若没有运行系统服务，你会发现对其他东西的定制比较麻烦，如果有一种东西可以让用户非常方便的运行系统服务，给大家的运维会带来很大的方便，帮助用户体验和传统 VM 的没有什么区别。也体现了极强的应用适配性。如果企业中的业务跑的很平稳的情况下，一个技术人员要用容器，第一个考虑的问题是它对业务的侵入性有多大？如果一样容器技术体现极强的应用适配性，把代码拿过来的时候非常低成本的进入容器里面使用，这样的技术会比较不错。

富容器技术，阿里巴巴集团应用 100% 容器化的重要前提。

规模化考验。这里讲的技术比较少一些，给大家介绍一下混部的支持，昨天雪峰老师也介绍了，他昨天说我也不想这么做，我是被逼的，为什么被逼呢？其实阿里很多工程师，包括我们在场的很多工程师也是被逼的，被什么样的东西给逼的呢？因为阿里数据中心有很多的服务器，昨天雪峰来说也讲了 CPU 的超卖，为什么呢？为了控制成本，每台服务器都是有成本的，混部也是为成本考虑的，可以将离线业务和在线业务混跑在一起，灵活的调度，让数据中心CPU 的资源利用率提高到比较好的地步，比如原来数据中心的平均 cpu 的利用率可能是10%左右，如果可以提高到30%，诞生的经济效益非常大。

   另外一个方面，混部这种场景对于阿里巴巴双11其实效果非常明显的。大家可以想象一下，一个峰值过来以后，大家可以算一下后面的机器是多少？业务百倍上升了以后，机器能够百倍的上升吗？很难。如果把混部技术运用上的话，业务倍数增长，机器的增长数会比倍数小一个数量级，会带来非常大的经济效益。

内核兼容性方面。阿里仍存有相当规模的linux2.6.X内核机器、规模效应，放大现有老系统的资产价值、Pouch 支持内部所有的linux2.6.x的内核、部分支持来源制订系统调用的回避、部分支持来源内核补丁。

刚才主要是介绍了pouch的一些技术优势，后续细节可以再交流。

介绍的第三部分是 Pouch 的开源发展。开源出来还是蛮难的，一个技术为了支撑业务，内部有很多的耦合，内部有很多专门为某些业务开发的功能特性，这些东西不是通用的，我们不能把这些东西给开源出来，就算开源出来对行业也没有什么价值，相当于从新把内部的经验用开源的方式，从 0 到 1 给大家体现出来。双 11 的时候我们已经开源在 GitHub 上，预计在明年3月底发布第一个大版本。

这是 Pouch 项目开源链接：https://github.com/alibaba/pouch，希望大家多多支持。我们来看一下 Pouch，我们从双 11 到现在有一个月的时间，有 1700+ star 、有 30 多位贡献者，有一位协作机器人，它主要用来提高分布式开源项目的协作效率，大家可以看一下 Pouch 的文档，是非常丰富的。

我给大家介绍一下 pouchrobot，大家在协作写代码的时候，会遇到协作效率很低的问题，我在想这些东西能不能通过一个机器人来完成呢，我也接触过很多的机器人，有些机器人能力很强，后来就自己写了一个，比如说自动设置 labe 标签，提高管理的效率、冲突监测，相当于你一个 PR 合并进去以后，这个时候机器人帮你自动检测其他 PR、周报生成，一开始开源的时候，运营的人力会少很多，就自己写了这个功能，统计一下这一周发生的事情、文档生成，我要吐槽一下，现在工程师真的不愿意写文档，我们做了什么事情呢？写文档不愿意，没有关系，你的代码一定按照可以生成文档的方式来写，我发现程序员都是愿意的。我们 Pouch 有两个文档，一个 cli 文档，还有 api 文档，这个机器人会按照每天改动的东西基于 swagger 自动生产 api 文档，这样维护成本非常低。

如何参与 Pouch 呢。首先可以尝试使用 Pouch，也希望大家在组织当中使用 Pouch，并且布道宣传，我们的 Pouch 会以一种不一样的视角来建设容器生态，可以在使用过程当中贡献你的 bug，cli文档和api文档。

我的演讲结束，谢谢大家。

提问：这个容器只安装在物理机上面吧，而不是虚拟机上面？

孙宏亮：都可以，当容器技术刚刚诞生的时候，一开始不太敢在物理机上跑容器，因为担心隔离的问题，很多企业都是先是虚拟机，通过一层强隔离，在虚拟机里面跑容器，随着这两年容器技术慢慢跑开以后，在虚拟机里面运行容器的企业慢慢越来越多。

提问：我们现在不是搞运维的话很难接触到物理的机器，一般都是用云平台，如果是虚拟机跟容器还有一定的关系，真的有问题，采用高配置的虚拟机，高配置的虚拟机里面装容器，还是说多用几个低配的虚拟机，虚拟机里面不需要再放容器了？

孙宏亮：还是要从你的业务出发，还有从你的成本控制角度来考虑。从泛技术的角度来讲都可以，但是你决策的时候，你考虑的绝对不仅仅是技术的问题。比如说高配置机里面跑容器，是它的优势，在低配里面跑你的容器，是决策的问题。

提问：虚拟机会不会有安全方面的问题？

孙宏亮：会的。安全这个问题不可能完全的解决，用虚拟机也有安全的问题，也有一些权限的赋予。还有容器的隔离，这些都是东西在隔离内核的情况下考虑的，共享内核以后，尤其要注意我们的软资源怎么管理，现在内核也在引进，还有软资源的隔离。