作者：贤维（阿里云Serverless Kubernetes产品TL），易立（阿里云容器服务产品线负责人）

从Serverless容器到Serverless Kubernetes

Serverless（无服务器）容器是让用户无需购买和管理服务器直接部署容器应用的产品、技术形态。Serverless容器可以极大提高容器应用部署的敏捷度和弹性能力，降低用户计算成本；让用户聚焦业务应用而非底层基础设施管理，极大地提高应用开发效率，降低运维成本。

目前Kubernetes已经成为业界容器编排系统的事实标准，基于Kubernetes的云原生应用生态（Helm, Istio, Knative, Kubeflow, Spark on k8s等）更是让Kubernetes成为云操作系统。Serverless Kubernetes得到了云厂商的高度关注。一方面通过Serverless方式根本性解决K8s自身的管理复杂性，让用户无需受困于K8s集群容量规划、安全维护、故障诊断；一方面进一步释放了云计算的能力，将安全、可用性、可伸缩性等需求由基础设施实现，这样可以形成差异化竞争力。

阿里云在2018年5月推出 ECI（Elastic Container Instance弹性容器实例），ASK (Alibaba Cloud Serverless Kubernetes)等产品，并在2019年2月正式商业化.

行业趋势

Gartner预测到2023年，70% AI任务会通过容器、Serverless等计算模型构建。在AWS的调研中，在2019年 40%的ECS（AWS弹性容器服务）新客户采用ECS on Fargate的Serverless Container形态。

Serverless容器是现有Container as a Service的进化方向之一，可以和fPaaS/FaaS(Function as a Service)形成良好的互补。FaaS提供了事件驱动的编程方式，用户只需实现函数的处理逻辑，比如当接收用户上传一个视频时，对视频进行转码和加水印。FaaS方式开发效率很高，也可以将弹性发挥到极致，但需要用户改变现有的开发模式来进行适配。而Serverless Container 应用的载体是容器镜像，灵活性很好，配合调度系统可以支持各种类型应用，比如无状态应用、有状态应用、计算任务类应用等等。用户大量现有的应用无需修改即可部署在Serverless Container环境中。

原图：https://blogs.gartner.com/tony-iams/containers-serverless-computing-pave-way-cloud-native-infrastructure/

在Gartner在 2020年 Public Cloud Container Service Market评估报告中把Serverless容器作为云厂商容器服务平台的主要差异化之一，其中将产品能力划分为Serverless 容器实例和Serverless Kubernetes两类。这与阿里云ECI/ASK的产品定位高度一致。如下图。

Gartner报告中也谈到 Serverless容器业界标准未定，云厂商有很多空间通过技术创新提供独特的增值能力，其对云厂商的建议是：

• 扩展Serverless容器应用场景和产品组合，迁移更多普通容器workload到serverless容器服务。
• 推进Serverless容器的标准化，减轻用户对云厂商锁定的担忧。
  

典型场景与客户价值

自阿里云ASK/ECI从2018年5月份正式公测以来，我们非常高兴的看到Serverless容器的价值逐渐被客户认可。典型客户场景包括：

• 在线业务弹性扩容：基于ASK支撑在线业务弹性扩容，在30s之内可以极速扩容500个应用实例，轻松应对预期和非预期突发流量。比如此次疫情时期多个在线教育客户使用ASK/ECI超强弹性能力轻松面对业务高峰。
• 免运维Serverless AI平台：基于ASK开发的智能、免运维的AI应用平台，可以让开发者创建自己的算法模型开发环境，而平台则会按需弹性伸缩，极大减少了系统维护和容量规划复杂性。
• Serverless大数据计算：基于ASK构建Serverless大数据计算平台。通过Serverless化的Spark, Presto等数据计算应用，灵活满足企业中不同业务部门快速成长过程中对多种计算计算任务，高弹性，强隔离、免维护的业务需求。

细分在阿里云Kubernetes服务中使用Serverless容器的场景，我们同时支持在K8s集群中使用ECI的方案ACK on ECI，和针对Serverless Kubernetes的极致优化的产品ASK。二者可以实现互补，覆盖满足不同客户的的诉求。

Serverless容器架构思考

不同于标准K8s，Serverless K8s与IaaS基础设施深度整合，其产品模式更利于公有云厂商通过技术创新，提升规模、效率和能力。在架构层面我们将Serverless容器分成容器编排和计算资源池两层，下面我们将对这两层进行深度剖析，分享我们对Serverless容器架构和产品背后的关键思考。

Kubernetes 的成功秘诀

Kubernetes在容器编排的成功不止得益于Google的光环和CNCF（云原生计算基金会）的努力运作。背后是其在Google Borg大规模分布式资源调度和自动化运维领域的沉淀和升华。

其中几个技术要点：

声明式API：由于Kubernetes采用了声明式的API。开发者可以关注于应用自身，而非系统执行细节。比如Deployment, StatefulSet, Job等不同资源类型，提供了对不同类型工作负载的抽象。对Kubernetes实现而言，基于声明式API的 “level-triggered” 实现比 “edge-triggered” 方式可以提供更加健壮的分布式系统实现。

可扩展性架构：所有K8s组件都是基于一致的、开放的API实现、交互。三方开发者也可通过CRD（Custom Resource Definition）/Operator等方法提供领域相关的扩展实现，极大提升了K8s的能力。

可移植性：K8s通过一系列抽象如Loadbalance Service, Ingress, CNI, CSI，帮助业务应用可以屏蔽底层基础设施的实现差异，灵活迁移。

Serverless Kubernetes的设计原则

Serverless Kubernetes 必须要能兼容Kubernetes生态，提供K8s的核心价值，此外要能和云的能力深度整合。

用户可以直接使用Kubernetes的声明式API，兼容Kubernetes的应用定义，Deployment, StatefulSet, Job, Service等无需修改。

全兼容Kubernetes的扩展机制，这个很重要，这样才能让Serverless Kubernetes支持更多的工作负载。此外Serverless K8s自身的组件也是严格遵守K8s的状态逼近的控制模式。

Kubernetes的能力尽可能充分利用云的能力来实现，比如资源的调度、负载均衡、服务发现等。根本性简化容器平台的设计，提升规模，降低用户运维复杂性。同时这些实现应该是对用户透明的，保障可移植性，让用户现有应用可以平滑部署在Serverless K8s之上，也应该允许用户应用混合部署在传统容器和Serverless容器之上。

从 Node Centric 到 Nodeless

传统的Kubernetes采用以节点为中心的架构设计：节点是pod的运行载体，Kubernetes调度器在工作节点池中选择合适的node来运行pod，并利用Kubelet完成对Pod进行生命周期管理和自动化运维；当节点池资源不够时，需要对节点池进行扩容，再对容器化应用进行扩容。

对于Serverless Kubernetes而言，最重要的一个概念是将容器的运行时和具体的节点运行环境解耦。只有如此，用户无需关注node运维和安全，降低运维成本；而且极大简化了容器弹性实现，无需按照容量规划，按需创建容器应用Pod即可；此外Serverless容器运行时可以被整个云弹性计算基础设施所支撑，保障整体弹性的成本和规模。

在2017年底，我们启动Serverless Kubernetes项目的时候，我们一直在思考，如果Kubernetes天生长在云上，它的架构应该如何设计。我们在现有Kubernetes的设计实现上，进行了扩展和优化。构建了Cloud Scale的Nodeless K8s架构 - 内部的产品代号为Viking，因为古代维京战船以迅捷和便于操作而著称。

• Scheduler：传统K8s scheduler的主要功能是从一批节点中选择一个合适的node来调度pod，满足资源、亲和性等多种约束。由于在Serverless K8s场景中没有node的概念，资源只受限于底层弹性计算库存，我们只需要保留一些基本的AZ亲和性等概念支持即可。这样scheduler的工作被极大简化，执行效率极大提升。此外我们定制扩展了scheduler，可以对serverless workload进行更多的编排优化，可以在保证应用可用性的前提下充分降低了计算成本。
• 可伸缩性：K8s的可伸缩性收到众多因素的影响，其中一个就是节点数量。为了保障Kubernetes兼容性，AWS EKS on Fargate采用Pod和Node 1:1模型（一个虚拟节点运行一个Pod），这样将严重限制了集群的可扩展性，目前单集群最多支持1000个pod。我们认为，这样的选择无法满足大规模应用场景的需求。在ASK中我们在保持了Kubernetes兼容性的同时，解决了集群规模受限于Node影响，单集群可以轻松支持10K Pod。此外传统K8s集群中还有很多因素会影响集群的可伸缩性，比如部署在节点上的 kube-proxy，在支持clusterIP时，任何单个endpoint变更时就会引起全集群的变更风暴。在这些地方Serverless K8s也使用了一些创新的方法限制变更传播的范围，这些领域我们将持续优化。

• 基于云的控制器实现：我们基于阿里云的云服务实现了kube-proxy、CoreDNS、Ingress Controller的行为，降低系统复杂性，比如：

  • 利用阿里云的DNS服务PrivateZone，为ECI实例动态配置DNS地址解析，支持了headless service
  • 通过SLB提供了提供负载均衡能力
  • 通过SLB/ALB提供的7层路由来实现Ingress的路由规则

• 面向工作负载的深度优化：未来充分发挥Serverless容器的能力，我们需要针对工作负载的特性进行深度优化。

  • Knative：Knative是Kubernetes生态下一种serverless应用框架，其中serving模块支持根据流量自动扩缩容和缩容到0的能力。基于Serverless k8s能力，阿里云Knative可以提供一些新的差异化功能，比如支持自动缩容到最低成本ECI实例规格，这样可以在保障冷启动时间的SLA并有效降低计算成本。此外通过SLB/ALB实现了Ingress Gateway，有效地降低了系统复杂性并降低成本。
  • 在Spark等大规模计算任务场景下，也通过一些垂直优化手段提高大批量任务的创建效率。这些能力已经在江苏跨域的客户场景中得到验证。

Serverless容器基础设施

对于Serverless容器而言，我们梳理的客户重点诉求是：

• 更低的计算成本：弹性成本要低于ECS，long run应用成本要接近ECS包年包月
• 更高的弹性效率：ECI扩容速度要远高于ECS
• 更大的弹性规模：与传统ECS节点扩容不同，一个大规模容器应用动辄需要数万核的弹性算力。
• 持平的计算性能：ECI计算效能需要和同规格ECS有一致的性能表现
• 更低的迁移成本：与现有容器应用生态完美集成
• 更低的使用成本：全自动化安全和运维能力

ECI的关键技术选择如下：

基于轻量化Micro VM的安全容器运行时

对于云产品而言，首先的考虑就是安全性。为此，ECI选择基于袋鼠云原生容器引擎和轻量化Micro VM来实现安全、隔离的容器运行时。除了运行时的资源隔离之外，不同客户之间的网络、存储、quota、弹性SLO等一系列能力也基于阿里云基础设施，实现了严格的多租隔离。

在性能方面，除了袋鼠容器引擎在OS/容器方面的高度优化之外，ECI在容器执行上优化集成了现有阿里云基础设施能力，比如支持ENI网卡直通、存储直接挂载。这些能力保障ECI中应用执行效率等于甚至略优于现有ECS运行环境。

基于 Pod 的基本调度单位和标准、开放的API接口

与Azure ACI, AWS Fargate on ECS不同，在ECI设计初期就确定了基于Pod作为Serverless容器的基本调度和运行单位，这样可以更加简单地结合上层Kubernetes编排系统。

ECI提供提供了 Pod的生命周期管理能力，包括 Create／Delete／Describe／Logs／Exec／Metrics等。ECI Pod与K8s Pod能力一致，不同之处在于其沙箱基于Micro VM而非CGroup/Namespace。这样使得ECI Pod 可以比较完美地支持各种K8s应用，包括Istio这样以sidecar方式动态注入的技术。

此外标准化的API屏蔽了底层资源池的具体实现，可以同时可以容纳底层不同形态、不同架构、不同的资源池和生产调度实现。ECI底层架构做了多次优化、迭代，比如袋鼠安全沙箱的创建可以通过神龙架构的MOC卡进行offload，但是这些对上层应用和集群编排是无感的。

此外API需要拥有足够的通用性支持在多个场景中使用，让用户在ASK/ACK、自建k8s和混合云场景中都可以充分利用Serverless容器的优势和价值。这个也是阿里云ECI和友商一个重要的不同。

ECI与ECS并池架构

通过并池我们有能力充分整合阿里云弹性计算资源池的算力，包括多种售卖模式（按量，spot，RI，Saving Plan等），多种机型供应（GPU/vGPU, 新CPU架构上线），多样化的存储能力（ESSD，本地盘）等，让ECI在产品功能，成本和规模上更有优势，满足客户对计算成本和弹性规模的强诉求。

Serverless容器的挑战

Serverless容器资源创建过程首先是一个计算资源的创建装配过程，是计算、存储、网络多个基础IaaS资源的协同装配过程。然而与ECS不同，Serverless容器有很多独立的挑战

根据Sysdig 2019年容器的调研报告, 超过 50% 的容器生命周期小于 5 分钟。Serverless容器需要具备秒级的启动速度才能满足用户对Serverless容器的启动诉求。Serverless 容器自身的启动速度主要受如下因素影响：

• 底层虚拟化资源的创建和组装：通过端到端管控链路的优化ECI可以将资源准备时间优化到亚秒级。
• Micro VM操作系统启动时间：袋鼠容器引擎针对容器场景对操作系统进行了大量剪裁和优化，极大减少了OS启动时间
• 镜像下载时间：从Docker镜像仓库下载镜像并在本地解压缩是一个非常耗时的操作。下载时间取决于镜像大小，通常在30秒到数分钟不等。在传统Kubernetes中， worker节点会在本地缓存已下载过的镜像，这样下次启动不会重复下载和解压。为了实现极致弹性成本效率，ECI和ECS采用并池的策略，计算存储分离的架构，这也意味着我们不可能通过传统方式利用本地盘来做容器镜像的缓存。为此我们实现了一个创新的方案：可以将容器镜像制作成一个数据盘快照。当ECI启动时，如果镜像快照存在，可以直接基于快照创建一个只读数据盘，并随着实例启动自动挂载，容器应用直接利用挂载数据盘作为rootfs进行启动。基于盘古2.0架构和阿里云ESSD云盘的极致I/O性能，我们可以将镜像加载的时间缩小到1秒以内。

这个领域还有很大发展空间，下一步会进一步和多个团队共同优化Serverless容器的启动效率。

此外， Serverless容器的调度相比ECS更关注资源弹性供给的确定性。Serverless容器强调按需使用，而ECS更多是提前购买预留。在大规模容器创建场景下，单用户单AZ弹性SLO保障是一个很大的挑战。在电商大促、跨年活动和最近的突发疫情保障的一系列客户支持中，客户对于云平台是否能够提供弹性资源供给确定性SLO是极度重视的。此外，结合Serverless K8s，上层调度器和ECI弹性供给策略配合，我们可以给客户更多对弹性资源供给的控制能力，平衡弹性的成本，规模和持有时间等不同需求维度。

Serverless容器的并发创建效率也至关重要。在高弹性场景，客户要求30s内启动500 pod副本来支持突发流量，类似Spark/Presto等计算业务对并发启动的诉求更大。

为了有效减低计算成本，Serverless容器应该提升部署密度。由于采用MicroVM技术，每个ECI实例拥有独立的OS内核。此外为了兼容K8s语义，还有一些辅助进程运行在ECI内部。目前每个ECI进程会有100M左右的额外开销。类似EKS on Fargate，每个Pod也有近256M左右的系统开销。这部分会降低Serverless的部署密度。我们需要将共性的开销下沉到基础设施之上，甚至通过MOC软硬一体的方式来进行卸载。

未来展望

在预期范围内各大云厂商将会持续投入Serverless容器方向来加大容器服务平台的差异化。上面已经提到成本、兼容性、创建效率和弹性供给保障是serverless容器技术重要的硬核能力。

我们将联合阿里云多个团队共同建设阿里云云原生IaaS基础设施， 一方面进一步优化现有Serverless容器产品形态，给客户一个更低成本、更好的使用体验，更佳的兼容性的Serverless K8s产品。一方面基于Serverles容器，未来也可以帮助上层应用有更多发展和创新空间。Cloud Native First! Serverless First！是我们前进的方向。