前言

随着 Serverless 概念的进一步普及，越来越多的企业用户开始将业务迁移到 Serverless 平台。通过 Serverless，用户可以聚焦业务实现。无需关注运维与基础设施，按需使用资源和付费 ，其中用户最大的收益体现在两个方面：

• "零"运维成本，将底层基础设施的运维工作交由平台提供方（云厂商）去完成；
  
• “零”资源浪费，无需常备资源，仅在需要运行业务的时候启动实例，在处理完逻辑之后释放资源，按使用量付费，降低云资源的使用成本。
  

Serverless 给云用户带来巨大收益的同时，也给云厂商带来了极大的挑战。首先云厂商需要提供稳定、强大的基础设施，帮用户维护好海量的实例；其次，按量付费，资源按需启动运行则要求云厂商提供足够强大的弹性能力，能够在短时间内为用户启动足够多的实例，让用户可以在业务高峰到来的时候迅速准备好服务予以应对，这样用户才会放心地将核心业务托管在 Serverless 产品上。

在今年的云栖大会上，阿里云的 Serverless 产品大放异彩，函数计算产品宣布支持 2 万函数实例 /min 的并发交付能力，而 ECI（弹性容器实例）的技术专家陈晓宇更是进行了现场演示，在 6 秒钟的时间内拉起了 3000 个弹性容器实例，向客户展示了阿里云强大的 Severless 弹性能力。

在演示过程中，晓宇介绍了 ECI 在管控调度上的优化方案，同时也介绍了支撑 ECI 的底层方案--袋鼠系统。本文将详细展开介绍袋鼠系统在阿里云强大基础设施上所做的优化，揭秘支持阿里云云原生 Serverless 快速弹性背后的底层技术。

云原生容器运行时

对于云厂商来说，Serverless 型产品需要有一个合适的运行时，提供以下基础的能力：

• 云原生生态兼容：Severless 是云原生的典型业务，对于云原生生态（k8s 体系）有很强的依赖，因此需要运行时能够无缝地与云原生生态无缝对接
• 具备强隔离能力：云厂商会服务众多不同的客户，因此一般单一物理机上需要运行多个不同客户的实例，特别是在 Serverless 场景下，实例的规格普遍偏小，物理机上服务的客户数量会更多。因此需要由运行时实现实例之间的绝对隔离，保障不同租户之间的数据安全和稳定性。
  

基于以上的诉求，kata containers 进入了我们的视线。kata containers 架构引入了沙箱容器的概念，通过硬件虚拟化技术和独立内核，提供了与 VM 同等级的多租隔离，另外通过 kata-shim-v2 接口，直接对接 contained 和 k8s，减少了重复构建、部署容器组件的开销，也能够较好地与开源的 k8s 生态（监控、metric、安全等）组件进行对接。

早在 2019 年，阿里云就基于 kata containers 架构进行 Serverless 服务的探索，将其用到了生产中去，即阿里云袋鼠沙箱容器 1.0 架构。在生产实践过程中，我们也发现了原生 kata containers 的一些不足：

• 首先是启动速度：由于硬件虚拟化和分离内核的存在，相比于普通容器，kata 容器需要额外增加虚拟化环境的建立时间、guest 内核启动时间、guest OS 内系统组件启动时间等，这些时间累加起来会极大的影响容器的扩容速度。虽然袋鼠沙箱 1.0 做了很多针对性的优化，将容器实例整体拉起时间（从containerd发起创建容器到 pause 容器 running）时间优化到了 800ms，但是相比普通容器还是有比较大的差距。
  
• 其次是资源开销：在 kata 容器默认推荐配置中，会预留 2G 的内存资源给 guest 内的管控资源或 guest kernel 使用。在实际应用过程中，即便袋鼠沙箱进行了大量的优化，最终整体的 guest 内开销还有 200M左 右，host 上也有接近 100M 左右的内存开销。
  
• 最后是稳定性：这是一个表征不明显但是影响极大的问题。相比于普通容器，kata containers 引入了更多的组件，包含 kata-shim，hypervisor、guest kernel、kata-agent 等等，众多组件极容易出现衔接异常引发的问题，主要体现在实例的创建、销毁等过程中。对此 kata-shim-v2 在一定程度上缓解了这个问题，但是在线上还是遇到过一些由于 shim-v2 和 hypervisor 之间的通信或者状态同步导致的稳定性问题。
  

以上的问题在 Serverless 场景下会被放大，比如文章开头的时候提到的极速并发能力，就需要运行时能够快速的启动实例，进而能够在短时间内尽量多地将容器准备好投入服务，而 800ms 的启动时间使得单机的并发能力受到了极大的限制；而 Severless 有大量的极小规格实例，像 ECI 就推出了 512M 内存的规格，在函数计算场景更是有 128M 的实例，如果运行时本身就有 200M 的开销，对于客户来说成本是不可接受的。同时，Serverless 实例的普遍运行时间很短，每日新增的实例创建是海量的，如果在创建、销毁过程中会出现大量问题的话，那是不具备稳定生产条件的。

基于以上遇到的问题，阿里云的袋鼠团队与蚂蚁的可信原生技术团队以 kata containers 为基础框架，推出了阿里云袋鼠沙箱容器 2.0：

• 用基于硬件虚拟化的轻量级沙箱替换传统的 vm，同时使用精简设备模型，并优化裁剪配置  Alibaba Cloud Linux kenrel，将整体软件栈各个组件打薄；
  
• 创新性地将 shim-v2 组件和沙箱管理单元融合到一个进程中，推出了全新的容器引擎 runD，将 shim 以及沙箱管理的通信从 gRPC 换成了 function call 以及 IPC；
  
• 打通基于 ebpf 的管控通道，实现shim对于沙箱内运行时的 upcall 机制；
  
• 使用阿里云全新推出的 LifSeaOS（ContainerOS）作为 guestOS；
  
• 采用 rust 语言全新开发，并集成kata rust agent，实现沙箱管控链路的rust改造。

架构优化带来的收益也是明显的。

通过管控链路的缩短以及组件的精简，并辅以对沙箱内存分配流程、host cgroup 管理流程和 IO 链路的优化，runD 实例的端到端启动时间（从 containerd 下发创建指令到 pause 容器拉起）缩短到了 300ms，并发能力达到了 200/s。进入 2021 年，袋鼠沙箱容器更是引入了沙箱实例复制技术，在实验室环境下将单实例端到端启动缩短到了 110ms，并发能力提升到了惊人的 360/s。在生产环境下，即便包含业务管控耗时，ECI 的实例启动时间也在1秒左右，单机并发达到了 50/s，支撑起了集群 3000/6s，5000/15s 的极速并发能力。

除了启动时间的收益，资源开销也有了显著的缩小，当前袋鼠沙箱容器内的资源 overhead 已经减少到 30M 左右，在产品上通过少量的资源“补偿”，即可实现用户的“零”overhead，所买即所得；同时 runD 在 host 上的资源开销缩减到了 2M 左右，实现了在单一物理机上的 2000 实例的高密服务能力。

除了性能、开销指标上的收益，新架构的使用也获得了组件能力的升级。首先 runD 实现了针对沙箱容器的全链路热升级能力，为产品的稳定性提供了兜底保障；同时使能了实例内资源热插、热拔的能力，可以实现针对单一实例的无损 VPA 能力。

袋鼠沙箱容器目前已经在阿里云上服务了数十款 Serverless 云产品，每日承接了上百万实例的创建、销毁流量，为用户提供了稳定、高效的运行时服务。而 runD 引擎也即将开源，我们期望通过社区化的运作，让更多的云原生场景能够通过开源的技术获得收益，敬请大家期待。

​

云原生底层系统

以上着重介绍了阿里云袋鼠沙箱容器 2.0 运行时，但是 Serverless 产品是整体的优秀表现，单靠一个运行时是不够的，需要有一套完整的系统方案进行支撑，袋鼠团队正是在致力于在打造这样一套包含运行时、单机存储、单机网络方案的阿里云云原生底层系统。

袋鼠沙箱容器运行在阿里云神龙平台上，享受神龙平台强大的 I 层能力。同时我们与 Alibaba Cloud Linux 的内核团队针对云原生 Serverless 场景进行了 Linux 内核深层次的优化，利用沙箱内 guest->runD->host kernel->神龙平台全栈优化，充分发挥阿里云强大的软、硬件基础设施结合能力带来的红利。

在针对 Serverless 业务进行特征分析和画像的过程中，我们详细刻画了 Serverless 带给云基础设施的压力。统计数据发现，绝大部分实例的运行时长都很短，以分钟甚至毫秒级为单位。再结合上文提到的大量 Serverless 用户会在云上使用小规格或者极小规格实例，以及瞬间并发的使用特征，如果给每一个 Severless 实例都分配一个传统的 VPC 网卡或者云盘，那么频繁的实例创建、销毁会对整体的网络、存储后端带来一系列严重的串扰。因此袋鼠团队构建了一套单机系统，能够覆盖单一物理机节点上的网络、存储，叠加于阿里云的基础网络和存储之上，以单机为粒度吸收 Serverless 带来的实例频繁创建、销毁的压力。​

网络

针对 Severless 大量用户使用网络仅需要进行单向访问的特点（即容器不需要对外提供访问端口或者服务，仅需要访问 VPC 内的云服务或者 ECS），袋鼠团队设计研发了 ANSM（Alibaba Network Service Mesh）方案，将单物理机上 ENI 的创建频率直接降低为零。

基于 ANSM 网络方案，实例的网络建立时间由秒级下降到了 200ms，并且单售卖节点上的实例数量、服务用户的数量摆脱了 ENI 数量的限制，可以在一台物理机上调度任意用户的任意数量的 POD，在生产上最大 POD 数量可达 2000 以上。

存储

在存储上，袋鼠提供了基于 Devicemapper 的存储分割方案，利用该方案，一台售卖节点仅需要创建一次高规格的 ESSD 云盘，然后便可以利用 Devicemapper 的能力进行切割对外提供服务，这个方案将不同实例存储的建立时间由秒级优化到了毫秒级，同时使用块设备的形态提供给不同的用户，保障了用户之间数据的安全性。

镜像

在生产实践中，我们发现拉取容器镜像、解压容器镜像耗时很长，占据了实例整体端到端启动的大部分时间，因此 ECI 提供了 image cache 镜像缓存方案，将用户镜像缓存在快照之中，直接将这这部分时间清零。同时我们也在探索是否有可以让用户无感进行镜像拉取加速的方式，我们将关注点放到了 2016 年 Tyler Harter 在 FAST 会议上发表的题为《 Slacker: Fast Distribution with Lazy Docker Containers 》的演讲，在其演讲中阐述了他们的一个观测结果：容器启动阶段仅需要使用镜像中不到 7% 的数据。因此我们提出一种设想，是否可以有一种按需加载的镜像拉取手段，仅将必要的数据拉取到本地，减少不必要的数据传输，在提升实例启动性能的基础上，同步减少并发场景下对于镜像仓库的传输带宽的压力。

在 2021 年，阿里云袋鼠沙箱容器正式将 Nydus 方案用在了 Serverless 产品之上。Nydus 是一种新型容器镜像格式，基于 Nydus 镜像加速方案，可以实现：

​

• 容器镜像按需加载
• Chunk 级别的镜像数据去重
• 去除镜像分层，减少不同镜像层之间的重复数据
  

使用 Nydus 镜像加速方案之后，ECI 拉取 423M 大小的镜像（解压后 1.1G）时间由 20s 下降到了 0.8s，极大提升了实例启动性能。当前 Nydus 已经在 CNCF 开源，并且正在与社区一起推进下一代镜像格式，更多 Nydus 细节查看：https://github.com/dragonflyoss/image-service

小结

随着云服务厂商服务边界的逐步上移，Serverless 服务正在通过给用户提供更好的弹性、性能和成本能力帮助客户快捷的完成业务的部署、运维和扩缩容，而袋鼠作为阿里云 Serverless 运行时产品的软件系统底座，也在不断地探索以更快的启动时间、更高的并发能力和更强的运行时性能构建更强的 Servless 产品，为用户带来更多的价值。在此欢迎有识之士加入我们，一起构建硬核的云原生底层系统。

联系邮箱：shaokang.hwd@alibaba-inc.com

加入龙蜥社群

加入微信群：添加社区助理-龙蜥社区小龙（微信：openanolis_assis），备注【龙蜥】拉你入群；加入钉钉群：扫描下方钉钉群二维码。欢迎开发者/用户加入龙蜥社区（OpenAnolis）交流，共同推进龙蜥社区的发展，一起打造一个活跃的、健康的开源操作系统生态！

关于龙蜥社区

龙蜥社区(OpenAnolis)是由企事业单位、高等院校、科研单位、非营利性组织、个人等按照自愿、平等、开源、协作的基础上组成的非盈利性开源社区。龙蜥社区成立于 2020 年 9 月，旨在构建一个开源、中立、开放的Linux上游发行版社区及创新平台。

短期目标是开发龙蜥操作系统(Anolis OS)作为 CentOS 替代版，重新构建一个兼容国际 Linux 主流厂商发行版。中长期目标是探索打造一个面向未来的操作系统，建立统一的开源操作系统生态，孵化创新开源项目，繁荣开源生态。

龙蜥OS 8.4已发布，支持 x86_64 、ARM64、LoongArch 架构，完善适配 Intel、飞腾、海光、兆芯、鲲鹏、龙芯等芯片，并提供全栈国密支持。

欢迎下载：https://openanolis.cn/download

加入我们，一起打造面向未来的开源操作系统！

https://openanolis.cn