阿里巴巴PouchContainer发布0.2.1版本，剑指企业级

近年来，随着以 Docker 等容器技术的持续走热，企业纷纷开始在内部进行尝试，尝试探索并建立一个广泛并通用的 PaaS 平台，整体提升内部应用开发和运维的水平，快速实现企业的数字化转型。阿里巴巴作为一家技术驱动的商业公司，早在 2011 年即开始实践容器技术，帮助集团完成应用容器化、提升 DevOps 能力、应用统一调度等目标。七年来，阿里巴巴在“如何高效可靠地为业务团队提供容器技术”方面，可谓历尽坎坷，也可谓凤凰涅槃。去年的云栖大会上，PouchContainer 第一次与行业见面，引发了不小的轰动。随后的开源建设，进一步帮助 PouchContainer 打磨自身技术，从而使其有能力如“水电煤”般普惠至行业千万家。

PouchContainer 的定位是“高效的企业级富容器技术”。容器技术虽然已经成为企业数据中心的标配技术，然而事实上其仍未到达在企业中迅速铺开的阶段。PouchContainer 可以通过提供高效可靠的容器技术，实现“企业存量应用的快速容器化”以及“提供安全隔离性强的环境”，从而解决企业痛点。

PouchContainer 的架构可以参见下图：

PouchContainer 自开源以来，即以开放的态度，与行业生态共建项目。开源至今，PouchContainer 吸引了容器生态多位开发者的开源参与, 开发者有来自科研机构，如浙江大学、华中科技大学以及上海交通大学，同时贡献中也有来自互联网公司的，如美团、滴滴、端点科技、谐云科技、才云等。目前 Pouch 的开源数据如下：

• 项目 GitHub 地址： https://github.com/alibaba/pouch；

• star 数超过 2200+；

• 开源贡献者有 41 位；

• 项目 commit 数达 1020；

• fork 数接近 400；

• maintainer 数量发展到 8 位；

一直以来，PouchContainer 将质量保障放在极其重要的位置，因此版本数的发布兼顾着“社区的体验”以及“质量的保障”。开源至今，项目共发布了 0.1.0，0.2.0 和 0.2.1 三个版本，其中 0.2.1 版本则实现了对多个企业级场景的支持，完全满足企业“快速存量应用容器化”以及“安全可靠强隔离”的场景要求。

开源将容器技术以及编排管理技术（如 Docker 与 Kubernetes 等），迅速在工业界宣传开，有初步形成事实标准的意味。然而，有过尝试与实践的企业，想必深有体会：开源容器技术在企业落地过程中，往往仅适用于企业增量业务，面对帮助企业存量业务如何拥抱新技术方面时，一直很难找到一座合理的桥梁。PouchContainer 作为从阿里巴巴走出来的开源容器技术，曾走过双 11 在线业务 100% 的容器化，覆盖中间件、蚂蚁金融、阿里云专有云等大量的业务场景，其中的企业级特性将是 Pouch 面世最大的价值。

传统容器技术“单进程”模式，对传统开发模型、运维都存在不小的挑战。

PouchContainer 0.2.1 版本中，“富容器”技术，则是天生设计来解决“开发运维侵入性”的问题。

“单进程”模式的容器技术，虽然轻松地解决了增量业务的交付问题，不过却交给企业信息化决策者一个现实的问题，“维持现状，苦撑存量业务？”，还是“侵入业务开发和运维，采纳新技术？” 相信大家不难看出，这里的技术并没有提供最优解，但凡对传统的开发运维存在侵入，技术的普及都会存在较大的阻力，因此企业架构在漫长的演进过程中，大部分的存量业务都没有变化，遑论老业务诞生新价值。

虚拟机虽然在容器技术的冲击下，略显疲态，不过该模式下应用的开发方式以及运维习惯，可以说为业务的生命周期管理做到了保驾护航。如果一款容器技术可以既有容器的优势、又兼容虚拟机时代的应用开发运维模式呢？PouchContainer 的富容器技术即解决此难题：

• init 进程：容器内提供完整的 init 守护进程，实现容器内部环境的管理（容器内多进程的管理、僵尸进程回收等），目前有三种 init 进程选项（/sbin/init, systemd 和 dumb-init）；

• prestart hook：init 进程协助下，完成容器应用启动前的钩子脚本，完成运维环境初始化、自定义预处理等管控需求。

容器技术没有权利定义业务开发运维模式，而 PouchContainer 的富容器技术，则为行业容器技术做了至关重要的补充。另外，富容器技术并不是 PouchContainer 的默认模式，“单进程”容器模式依然被友好支持，用户完全可以按需灵活选择模式。

因内核无法隔离，传统容器技术至今无法实现多租户。

隔离性是云计算技术必须正视的一个技术难题。隔离性强，意味着技术具备了企业级的初步条件；反之则几乎没有可能在业务线上铺开。哪怕是阿里巴巴这样的技术公司，实践容器技术伊始，安全问题都无法幸免。众所周知，行业中的容器方案大多基于 Linux 内核提供的 cgroup 和 namespace 来实现隔离，然后这样的轻量级方案存在弊端：

• 共享内核安全存疑：容器间，容器与宿主机之间，共享同一个内核，内核隐患牵一发而动全身；

• 资源隔离维度欠缺：cgroup 和 namespace 的隔离维度无法模拟虚拟机，如网络、磁盘、CPU 和内存的高级属性等；

• 内核参数配置困难：特殊场景下，有些依赖内核参数的容器需要配置内核参数，而共享内核导致容器修改内核影响整台机器。

介于此，PouchContainer 在设计之初就朝着兼容容器、结合 Hypervisor 的方向发展。实现方案方面，PouchContainer 第一个支持了 runV（当前 KataContainer 项目的前身）。达到的效果是：同一个容器引擎上，用户有能力同时部署“容器”和“虚拟机”，帮助企业级完成两种运维载体的统一化管理，将企业级信息化管理化繁为简。PouchContainer 支持两种计算载体的示意图如下：

两者统一化管理的命令行操作如下（其中 runtime 运行时标注为 runv 的表示虚拟机，而 runc 代表 Linux 容器）：

依然是隔离性问题，Linux 容器所依赖的 cgroup 和 namespace 技术，实际上并没有很好地做到容器的资源视角隔离。具体举例而言，就是给一个运行在 2GB 内核机器上的容器限制了 200MB 的内存，在容器内执行 free 命令，依然可以看到 2GB 内存。同样的资源维度，还有 CPU、blkio、uptime 等。

阿里巴巴由于业务复杂，应用栈种类多，在容器技术发展初期就遇到了“容器资源视角隔离弱”的难题。当时，大量的企业级 Java 应用在容器中运行的时候，经常遇到以下三类问题：

• Java 应用启动时用到的运行脚本，大部分通过查看主机内存来动态分配 JVM 的起始堆栈大小，因此容器模式下完全失效，毕竟容器分配到的实际内存要更小；

• Java 应用中众多中间件库包 library，通过查看主机内存来动态分配运行程序的堆栈大小，容器模式下同理出现异常；

• 为充分利用多核机器，应用可以判断机器 CPU 核数来动态创建线程数，容器模式下容器内进程 cpuset 的限制有可能小于宿主机，从而能导致容器应用的运行存在异常。

传统企业中存量应用很大部分是使用 Java 编写，或者会遇到上述情况。PouchContainer 在 0.1.0 版本即支持了 LXCFS，帮助容器实现查看的资源完全是精准的分配值。PouchContainer 通过 LXCFS 将宿主机上有关容器 cgroup 文件系统中的资源限制值，通过 FUSE 文件系统的方式生成虚拟文件，并挂在到对应的容器内部，完成真是资源信息的传递。PouchContainer 原生支持 LXCFS，仅需指定--enableLxcfs即可完成。如下图，不指定--enableLxcfs则容器free命令看到宿主机所有的 2GB 内存，若指定则看到容器总内存为受到限制的 200MB：

上一点提到 Linux 容器无法做到资源视角隔离，不过在文件系统视角隔离方面，它还做好视角隔离的。然而，这就是满足企业级需求了吗？很遗憾，答案是否定的，原因在于：Linux 容器无法帮助企业级容器应用做好数据卷磁盘隔离。举例而言，用户为应用创建一个容器，并绑定一个数据卷 volume，那么原则上容器的 rootfs 并没有受到磁盘的限额，用户应用完全有可能通过不断写文件，使得容器消耗完宿主机所有的存储空间；这样的情况同样适用于容器的数据卷 Volume。因此，不完善的容器数据卷隔离，是容器服务 SLA 保障的重大挑战。

刚发布的 0.2.1 版本中，PouchContainer 原生为容器 rootfs 以及数据卷 volume 实现了磁盘限额，实现方式为支持了 Linux 内核的特性 group quota 和 project quota。用户可以在启动 Pouch 守护进程时，配置 quota 驱动的类型，创建容器以及 Volume 时，均可以通过传递参数完成磁盘 quota 的设置。

高效的企业级富容器技术，是 PouchContainer 的定位。如今的 0.2.1 版本向社区、向企业传递了这样的信号：PouchContainer 发展的差异化定位，志在解决企业存量应用容器化缓慢的行业现状，为企业的数据化转型保驾护航，做好扎实的第一步。

未来，PouchContainer 的发展会秉持务实，拥抱创新。PouchContainer 不仅会在功能特性上继续贴近企业级的业务需求，在性能可靠性上为企业规避风险，同时在下一代创新容器方面做更多探索。更多内容，敬请期待。