在容器技术加持的云原生形成趋势的今天，PouchContainer 容器技术支持的业务方也不再只有集团电商业务和在线业务了，我们通过标准化的演进，把所有定制功能做了插件化，适配了不同场景的需要。
限时福利：张磊、李响等人撰写的 《CNCF X 阿里巴巴云原生技术公开课》 限时 0 元领取中。
作者 | 杨育兵（沈陵） 阿里巴巴高级技术专家
我们从 2016 年开始在集团推广全面的镜像化容器化，今年是集团全面镜像化容器化后的第 4 个 双 11，PouchContainer 容器技术已经成为集团所有在线应用运行的运行时底座和运维载体，每年 双 11 都有超过百万的 PouchContainer 容器同时在线，提供电商和所有相关的在线应用平稳运行的载体，保障大促购物体验的顺滑。我们通过 PouchContainer 容器运行时这一层标准构建了应用开发和基础设施团队的标准界面，每年应用都有新的需求、新的变化，同时基础设施也有上云/混部/神龙/存储计算分离/网络变革这些升级，两边平行演进，互不干扰。技术设施和 PouchContainer 自身都做了很大的架构演进，这些很多的架构和技术演进对应用开发者都是无感知的。
2015 年之前，我们用的运行时是 LXC，PouchContainer 为了在镜像化后能够平滑接管原来的 T4 容器，在 LXC 中支持新的镜像组装方式，并支持交互式的 exec 和内置的网络模式。随着云原生的进程，我们在用户无感知的情况下对运行时做了 containerd+runc 的支持，用标准化的方式加内部功能插件，实现了内部功能特性的支持和被各种标准化运维系统无缝集成的目标。无论是 LXC 还是 runc 都是让所有容器共享 Linux 内核，利用 cgroup 和 namespace 来做隔离，对于强安全场景和强隔离场景是不适用的。为了容器这种开发和运维友好的交付形式能给更多场景带来收益，我们很早就开始探索这方面的技术，和集团 os 创新团队以及蚂蚁 os 虚拟化团队合作共建了 kata 安全容器和 gvisor 安全容器技术，在容器生态嫁接，磁盘、网络和系统调用性能优化等方面都做了很多的优化。在兼容性要求高的场景我们优先推广 kata 安全容器，已经支持了 SAE 和 ACK 安全容器场景。在语言和运维习惯确定的场景，我们也在 618 大促时上线了一些合适的电商使用了 gvisor 的运行时隔离技术，稳定性和性能都得到了验证。为了一部分专有云场景的实施，我们今年还首次支持了 Windows 容器运行时，在容器依赖相关的部署、运维方面做了一些探索，帮助敏捷版专有云拿下了一些客户。除了安全性和隔离性，我们的运行时演进还保证了标准性，今年最新版本的 PouchContainer 把 diskquota、lxcfs、dragonfly、DADI 这些特性都做成了可插拔的插件，不需要这些功能的场景可以完全不受这些功能代码的影响。甚至我们还对一些场景做了 containerd 发行版，支持纯粹的标准 CRI 接口和丰富的运行时。
镜像化以后必然会引入镜像分发的效率方面的困难，一个是速度另一个是稳定性，让发布扩容流程不增加太多时间的情况下，还要保证中心节点不被压垮。PouchContainer 在一开始就支持了使用 Dragonfly 来做 P2P 的镜像分发，就是为了应对这种问题，这是我们的第一代镜像分发方案。在研发域我们也对镜像分层的最佳实践做了推广，这样能最大程度的保证基础环境不变时每次下载的镜像层最小。镜像加速要解决的问题有：build 效率、push 效率、pull 效率、解压效率以及组装效率。第一代镜像加速方案，结合 Dockerfile 的最佳实践解决了 build 效率和 pull 效率和中心压力。第一代镜像分发的缺点是无论用户启动过程中用了多少镜像数据，在启动容器之前就需要把所有的镜像文件都拉到本地，在很多场景下都是浪费的，特别影响的是扩容场景。所以第二代的镜像加速方案，我们调研了阿里云的盘古，盘古的打快照、mount、再打快照这种使用方式完美匹配打镜像和分发的流程；能做到秒级镜像 pull，因为 pull 镜像时只需要鉴权，下载镜像 manifest，然后 mount 盘古，也能做到镜像内容按需读取。
