简介：以后 Serverless 容器的行业趋势如何？有哪些利用价值？如果 Kubernetes 天成长在云上，它的架构应该如何设计？Serverless 容器须要哪些基础设施？阿里云容器服务产品负责人易立及阿里云 Serverless Kubernetes 产品 TL 张维将分享他们对 Serverless 容器架构和背地的要害思考。

从 Serverless 容器到 Serverless Kubernetes

Serverless（无服务器）容器是让用户无需购买和治理服务器间接部署容器利用的产品、技术状态。

Serverless 容器能够极大进步容器利用部署的麻利度和弹性能力，升高用户计算成本；让用户聚焦业务利用而非底层基础设施治理，极大地提高利用开发效率，升高运维老本。

目前 Kubernetes 曾经成为业界容器编排零碎的事实标准，基于 Kubernetes 的云原生利用生态（Helm, Istio, Knative, Kubeflow, Spark on K8s 等）更是让 Kubernetes 成为云操作系统。一方面通过 Serverless 形式根本性解决 K8s 本身的治理复杂性，让用户无需受困于 K8s 集群容量布局、平安保护、故障诊断；一方面进一步开释了云计算的能力，将平安、可用性、可伸缩性等需要由基础设施实现，这样能够造成差异化竞争力。

1. 行业趋势

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 环境中。

图源

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

• 扩大 Serverless 容器利用场景和组合，迁徙更多一般容器 workload 到 Serverless 容器服务。
• 推动 Serverless 容器的标准化，加重用户对云厂商锁定的担心。

2. 典型场景与利用价值

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

1）在线业务弹性扩容

基于 ASK 撑持在线业务弹性扩容，在 30s 之内能够极速扩容 500 个利用实例，轻松应答预期和非预期突发流量。比方此次疫情期间多个在线教育平台应用 ASK/ECI 超强弹性能力轻松面对业务顶峰。

2）免运维 Serverless AI 平台

基于 ASK 开发的智能、免运维的 AI 利用平台，能够让开发者创立本人的算法模型开发环境，而平台则会按需弹性伸缩，极大缩小了系统维护和容量布局复杂性。

3）Serverless 大数据计算

基于 ASK 构建 Serverless 大数据计算平台。通过 Serverless 化的 Spark, Presto 等数据计算利用，灵便满足企业疾速成长过程中不同业务部门的多种计算工作、高弹性、强隔离和免保护的需要。

Serverless 容器架构思考

不同于规范 K8s，Serverless K8s 与 IaaS 基础设施深度整合，其模式更利于私有云厂商通过技术创新，晋升规模、效率和能力。在架构层面咱们将 Serverless 容器分成容器编排和计算资源池两层，上面咱们将对这两层进行深度分析，分享咱们对 Serverless 容器架构和背地的要害思考。

1. Kubernetes 的胜利秘诀

Kubernetes 在容器编排的胜利不止得益于 Google 的光环和 CNCF（云原生计算基金会）的致力运作。背地是其在 Google Borg 大规模分布式资源调度和自动化运维畛域的积淀和升华。
其中几个技术要点：

1）申明式 API

因为 Kubernetes 采纳了申明式的 API。开发者能够关注于利用本身，而非零碎执行细节。比方 Deployment, StatefulSet, Job 等不同资源类型，提供了对不同类型工作负载的形象。对 Kubernetes 实现而言，基于申明式 API 的“level-triggered”实现比“edge-triggered”形式能够提供更加强壮的分布式系统实现。

2）可扩展性架构

所有 K8s 组件都是基于统一的、凋谢的 API 实现、交互。三方开发者也可通过 CRD（Custom Resource Definition）/Operator 等办法提供畛域相干的扩大实现，极大晋升了 K8s 的能力。

3）可移植性

K8s 通过一系列形象如 Loadbalance Service, Ingress, CNI, CSI，帮忙业务利用能够屏蔽底层基础设施的实现差别，灵便迁徙。

2. Serverless Kubernetes 的设计准则

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

• 用户能够间接应用 Kubernetes 的申明式 API，兼容 Kubernetes 的利用定义，Deployment, StatefulSet, Job, Service 等无需批改。
• 全兼容 Kubernetes 的扩大机制，这个很重要，这样能力让 Serverless Kubernetes 反对更多的工作负载。此外 Serverless K8s 本身的组件也是严格遵守 K8s 的状态迫近的管制模式。
• Kubernetes 的能力尽可能充分利用云的能力来实现，比方资源的调度、负载平衡、服务发现等。根本性简化容器平台的设计，晋升规模，升高用户运维复杂性。同时这些实现应该是对用户通明的，保障可移植性，让用户现有利用能够平滑部署在 Serverless K8s 之上，也应该容许用户利用混合部署在传统容器和 Serverless 容器之上。

3. 从 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，因为现代维京战船以迅捷和便于操作而著称。

1）Scheduler

传统 K8s scheduler 的次要性能是从一批节点中抉择一个适合的 node 来调度 Pod，满足资源、亲和性等多种束缚。因为在 Serverless K8s 场景中没有 node 的概念，资源只受限于底层弹性计算库存，咱们只须要保留一些根本的 AZ 亲和性等概念反对即可。这样 scheduler 的工作被极大简化，执行效率极大晋升。此外咱们定制扩大了 scheduler，能够对 Serverless workload 进行更多的编排优化，能够在保障利用可用性的前提下充沛升高了计算成本。

2）可伸缩性

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 也应用了一些翻新的办法限度变更流传的范畴，这些畛域咱们将继续优化。

3）基于云的控制器实现

咱们基于阿里云的云服务实现了 kube-proxy、CoreDNS、Ingress Controller 的行为，升高零碎复杂性，比方：

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

4）面向工作负载的深度优化

将来充分发挥 Serverless 容器的能力，咱们须要针对工作负载的个性进行深度优化。

• Knative：Knative 是 Kubernetes 生态下一种 Serverless 利用框架，其中 serving 模块反对依据流量主动扩缩容和缩容到 0 的能力。基于 Serverless K8s 能力，阿里云 Knative 能够提供一些新的差异化性能，比方反对主动缩容到最低老本 ECI 实例规格，这样能够在保障冷启动工夫的 SLA 并无效升高计算成本。此外通过 SLB/ALB 实现了 Ingress Gateway，无效地升高了零碎复杂性并降低成本。
• 在 Spark 等大规模计算工作场景下，也通过一些垂直优化伎俩进步大批量工作的创立效率。这些能力曾经在江苏跨域的用户场景中失去验证。

Serverless 容器基础设施

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

1. 更低的计算成本：弹性老本要低于 ECS，long run 利用老本要靠近 ECS 包年包月
2. 更高的弹性效率：ECI 扩容速度要远高于 ECS
3. 更大的弹性规模：与传统 ECS 节点扩容不同，一个大规模容器利用动辄须要数万核的弹性算力。
4. 持平的计算性能：ECI 计算效力须要和同规格 ECS 有统一的性能体现
5. 更低的迁徙老本：与现有容器利用生态完满集成
6. 更低的应用老本：全自动化平安和运维能力

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 容器技术重要的硬核能力。

作者：易立、张维
原文链接
本文为阿里云原创内容，未经容许不得转载