當(dāng)前 Serverless 容器的行業(yè)趨勢(shì)如何?有哪些應(yīng)用價(jià)值?如果 Kubernetes 天生長(zhǎng)在云上，它的架構(gòu)應(yīng)該如何設(shè)計(jì)?Serverless 容器需要哪些基礎(chǔ)設(shè)施?阿里云容器服務(wù)產(chǎn)品負(fù)責(zé)人易立及阿里云 Serverless Kubernetes 產(chǎn)品 TL 張維將分享他們對(duì) Serverless 容器架構(gòu)和背后的關(guān)鍵思考。

從 Serverless 容器到 Serverless Kubernetes

Serverless(無服務(wù)器)容器是讓用戶無需購(gòu)買和管理服務(wù)器直接部署容器應(yīng)用的產(chǎn)品、技術(shù)形態(tài)。Serverless 容器可以極大提高容器應(yīng)用部署的敏捷度和彈性能力，降低用戶計(jì)算成本;讓用戶聚焦業(yè)務(wù)應(yīng)用而非底層基礎(chǔ)設(shè)施管理，極大地提高應(yīng)用開發(fā)效率，降低運(yùn)維成本。

??

目前 Kubernetes 已經(jīng)成為業(yè)界容器編排系統(tǒng)的事實(shí)標(biāo)準(zhǔn)，基于 Kubernetes 的云原生應(yīng)用生態(tài)(Helm, Istio, Knative, Kubeflow, Spark on K8s 等)更是讓 Kubernetes 成為云操作系統(tǒng)。一方面通過 Serverless 方式根本性解決 K8s 自身的管理復(fù)雜性，讓用戶無需受困于 K8s 集群容量規(guī)劃、安全維護(hù)、故障診斷;一方面進(jìn)一步釋放了云計(jì)算的能力，將安全、可用性、可伸縮性等需求由基礎(chǔ)設(shè)施實(shí)現(xiàn)，這樣可以形成差異化競(jìng)爭(zhēng)力。

行業(yè)趨勢(shì)

Gartner 預(yù)測(cè)到 2023 年，70% AI 任務(wù)會(huì)通過容器、Serverless 等計(jì)算模型構(gòu)建。在 AWS 的調(diào)研中，在 2019 年 40% 的 ECS(AWS 彈性容器服務(wù))新用戶采用 ECS on Fargate 的 Serverless Container 形態(tài)。

Serverless 容器是現(xiàn)有 Container as a Service 的進(jìn)化方向之一，可以和 fPaaS/FaaS (Function as a Service) 形成良好的互補(bǔ)。FaaS 提供了事件驅(qū)動(dòng)的編程方式，用戶只需實(shí)現(xiàn)函數(shù)的處理邏輯，比如當(dāng)接收到用戶上傳的一個(gè)視頻時(shí)，對(duì)視頻進(jìn)行轉(zhuǎn)碼和加水印。FaaS 方式開發(fā)效率很高，也可以將彈性發(fā)揮到極致，但需要用戶改變現(xiàn)有的開發(fā)模式來進(jìn)行適配。而 Serverless Container 應(yīng)用的載體是容器鏡像，靈活性很好，配合調(diào)度系統(tǒng)可以支持各種類型應(yīng)用，比如無狀態(tài)應(yīng)用、有狀態(tài)應(yīng)用、計(jì)算任務(wù)類應(yīng)用等等。用戶大量現(xiàn)有的應(yīng)用無需修改即可部署在 Serverless Container 環(huán)境中。

??

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

Gartner 報(bào)告中也談到 Serverless 容器業(yè)界標(biāo)準(zhǔn)未定，云廠商有很多空間通過技術(shù)創(chuàng)新提供獨(dú)特的增值能力，其對(duì)云廠商的建議是：

• 擴(kuò)展 Serverless 容器應(yīng)用場(chǎng)景和組合，遷移更多普通容器 workload 到 Serverless 容器服務(wù)。
• 推進(jìn) Serverless 容器的標(biāo)準(zhǔn)化，減輕用戶對(duì)云廠商鎖定的擔(dān)憂。

??

典型場(chǎng)景與應(yīng)用價(jià)值

自阿里云 ASK/ECI 從 2018 年 5 月份正式公測(cè)以來，我們非常高興的看到 Serverless 容器的價(jià)值逐漸被用戶認(rèn)可。典型應(yīng)用場(chǎng)景包括：

在線業(yè)務(wù)彈性擴(kuò)容

基于 ASK 支撐在線業(yè)務(wù)彈性擴(kuò)容，在 30s 之內(nèi)可以極速擴(kuò)容 500 個(gè)應(yīng)用實(shí)例，輕松應(yīng)對(duì)預(yù)期和非預(yù)期突發(fā)流量。比如此次疫情時(shí)期多個(gè)在線教育平臺(tái)使用 ASK/ECI 超強(qiáng)彈性能力輕松面對(duì)業(yè)務(wù)高峰。

免運(yùn)維 Serverless AI 平臺(tái)

基于 ASK 開發(fā)的智能、免運(yùn)維的 AI 應(yīng)用平臺(tái)，可以讓開發(fā)者創(chuàng)建自己的算法模型開發(fā)環(huán)境，而平臺(tái)則會(huì)按需彈性伸縮，極大減少了系統(tǒng)維護(hù)和容量規(guī)劃復(fù)雜性。

Serverless 大數(shù)據(jù)計(jì)算

基于 ASK 構(gòu)建 Serverless 大數(shù)據(jù)計(jì)算平臺(tái)。通過 Serverless 化的 Spark, Presto 等數(shù)據(jù)計(jì)算應(yīng)用，靈活滿足企業(yè)快速成長(zhǎng)過程中不同業(yè)務(wù)部門的多種計(jì)算任務(wù)、高彈性、強(qiáng)隔離和免維護(hù)的需求。

??

Serverless 容器架構(gòu)思考

不同于標(biāo)準(zhǔn) K8s，Serverless K8s 與 IaaS 基礎(chǔ)設(shè)施深度整合，其模式更利于公有云廠商通過技術(shù)創(chuàng)新，提升規(guī)模、效率和能力。在架構(gòu)層面我們將 Serverless 容器分成容器編排和計(jì)算資源池兩層，下面我們將對(duì)這兩層進(jìn)行深度剖析，分享我們對(duì) Serverless 容器架構(gòu)和背后的關(guān)鍵思考。

Kubernetes 的成功秘訣

Kubernetes 在容器編排的成功不止得益于 Google 的光環(huán)和 CNCF(云原生計(jì)算基金會(huì))的努力運(yùn)作。背后是其在 Google Borg 大規(guī)模分布式資源調(diào)度和自動(dòng)化運(yùn)維領(lǐng)域的沉淀和升華。

其中幾個(gè)技術(shù)要點(diǎn)：

聲明式 API

由于 Kubernetes 采用了聲明式的 API。開發(fā)者可以關(guān)注于應(yīng)用自身，而非系統(tǒng)執(zhí)行細(xì)節(jié)。比如 Deployment, StatefulSet, Job 等不同資源類型，提供了對(duì)不同類型工作負(fù)載的抽象。對(duì) Kubernetes 實(shí)現(xiàn)而言，基于聲明式 API 的 “l(fā)evel-triggered” 實(shí)現(xiàn)比 “edge-triggered” 方式可以提供更加健壯的分布式系統(tǒng)實(shí)現(xiàn)。

可擴(kuò)展性架構(gòu)

所有 K8s 組件都是基于一致的、開放的 API 實(shí)現(xiàn)、交互。三方開發(fā)者也可通過 CRD(Custom Resource Definition)/Operator 等方法提供領(lǐng)域相關(guān)的擴(kuò)展實(shí)現(xiàn)，極大提升了 K8s 的能力。

可移植性

K8s 通過一系列抽象如 Loadbalance Service, Ingress, CNI, CSI，幫助業(yè)務(wù)應(yīng)用可以屏蔽底層基礎(chǔ)設(shè)施的實(shí)現(xiàn)差異，靈活遷移。

Serverless Kubernetes 的設(shè)計(jì)原則

Serverless Kubernetes 必須要能兼容 Kubernetes 生態(tài)，提供 K8s 的核心價(jià)值，此外要能和云的能力深度整合。

• 用戶可以直接使用 Kubernetes 的聲明式 API，兼容 Kubernetes 的應(yīng)用定義，Deployment, StatefulSet, Job, Service 等無需修改
• 全兼容 Kubernetes 的擴(kuò)展機(jī)制，這個(gè)很重要，這樣才能讓 Serverless Kubernetes 支持更多的工作負(fù)載。此外 Serverless K8s 自身的組件也是嚴(yán)格遵守 K8s 的狀態(tài)逼近的控制模式。
• Kubernetes 的能力盡可能充分利用云的能力來實(shí)現(xiàn)，比如資源的調(diào)度、負(fù)載均衡、服務(wù)發(fā)現(xiàn)等。根本性簡(jiǎn)化容器平臺(tái)的設(shè)計(jì)，提升規(guī)模，降低用戶運(yùn)維復(fù)雜性。同時(shí)這些實(shí)現(xiàn)應(yīng)該是對(duì)用戶透明的，保障可移植性，讓用戶現(xiàn)有應(yīng)用可以平滑部署在 Serverless K8s 之上，也應(yīng)該允許用戶應(yīng)用混合部署在傳統(tǒng)容器和 Serverless 容器之上。

從 Node Centric 到 Nodeless

傳統(tǒng)的 Kubernetes 采用以節(jié)點(diǎn)為中心的架構(gòu)設(shè)計(jì)：節(jié)點(diǎn)是 Pod 的運(yùn)行載體，Kubernetes 調(diào)度器在工作節(jié)點(diǎn)池中選擇合適的 node 來運(yùn)行 Pod，并利用 Kubelet 完成對(duì) Pod 進(jìn)行生命周期管理和自動(dòng)化運(yùn)維;當(dāng)節(jié)點(diǎn)池資源不夠時(shí)，需要對(duì)節(jié)點(diǎn)池進(jìn)行擴(kuò)容，再對(duì)容器化應(yīng)用進(jìn)行擴(kuò)容。

對(duì)于 Serverless Kubernetes 而言，最重要的一個(gè)概念是將容器的運(yùn)行時(shí)和具體的節(jié)點(diǎn)運(yùn)行環(huán)境解耦。只有如此，用戶無需關(guān)注 node 運(yùn)維和安全，降低運(yùn)維成本;而且極大簡(jiǎn)化了容器彈性實(shí)現(xiàn)，無需按照容量規(guī)劃，按需創(chuàng)建容器應(yīng)用 Pod 即可;此外 Serverless 容器運(yùn)行時(shí)可以被整個(gè)云彈性計(jì)算基礎(chǔ)設(shè)施所支撐，保障整體彈性的成本和規(guī)模。

在 2017 年底，我們啟動(dòng) Serverless Kubernetes 項(xiàng)目的時(shí)候，我們一直在思考，如果 Kubernetes 天生長(zhǎng)在云上，它的架構(gòu)應(yīng)該如何設(shè)計(jì)。我們?cè)诂F(xiàn)有 Kubernetes 的設(shè)計(jì)實(shí)現(xiàn)上，進(jìn)行了擴(kuò)展和優(yōu)化。構(gòu)建了 Cloud Scale 的 Nodeless K8s 架構(gòu)——內(nèi)部代號(hào)為 Viking，因?yàn)楣糯S京戰(zhàn)船以迅捷和便于操作而著稱。

??

Scheduler

傳統(tǒng) K8s scheduler 的主要功能是從一批節(jié)點(diǎn)中選擇一個(gè)合適的 node 來調(diào)度 Pod，滿足資源、親和性等多種約束。由于在 Serverless K8s 場(chǎng)景中沒有 node 的概念，資源只受限于底層彈性計(jì)算庫(kù)存，我們只需要保留一些基本的 AZ 親和性等概念支持即可。這樣 scheduler 的工作被極大簡(jiǎn)化，執(zhí)行效率極大提升。此外我們定制擴(kuò)展了 scheduler，可以對(duì) Serverless workload 進(jìn)行更多的編排優(yōu)化，可以在保證應(yīng)用可用性的前提下充分降低了計(jì)算成本。

可伸縮性

K8s 的可伸縮性受到眾多因素的影響，其中一個(gè)就是節(jié)點(diǎn)數(shù)量。為了保障 Kubernetes 兼容性，AWS EKS on Fargate 采用 Pod 和 Node 1:1 模型(一個(gè)虛擬節(jié)點(diǎn)運(yùn)行一個(gè) Pod)，這樣將嚴(yán)重限制了集群的可擴(kuò)展性，目前單集群最多支持 1000 個(gè) Pod。我們認(rèn)為，這樣的選擇無法滿足大規(guī)模應(yīng)用場(chǎng)景的需求。在 ASK 中我們?cè)诒３至?Kubernetes 兼容性的同時(shí)，解決了集群規(guī)模受限于 Node 影響，單集群可以輕松支持 10K Pod。此外傳統(tǒng) K8s 集群中還有很多因素會(huì)影響集群的可伸縮性，比如部署在節(jié)點(diǎn)上的 kube-proxy，在支持 clusterIP 時(shí)，任何單個(gè) endpoint 變更時(shí)就會(huì)引起全集群的變更風(fēng)暴。在這些地方 Serverless K8s 也使用了一些創(chuàng)新的方法限制變更傳播的范圍，這些領(lǐng)域我們將持續(xù)優(yōu)化。

基于云的控制器實(shí)現(xiàn)

我們基于阿里云的云服務(wù)實(shí)現(xiàn)了 kube-proxy、CoreDNS、Ingress Controller 的行為，降低系統(tǒng)復(fù)雜性，比如：

• 利用阿里云的 DNS 服務(wù) PrivateZone，為 ECI 實(shí)例動(dòng)態(tài)配置 DNS 地址解析，支持了 headless service
• 通過 SLB 提供了提供負(fù)載均衡能力
• 通過 SLB/ALB 提供的 7 層路由來實(shí)現(xiàn) Ingress 的路由規(guī)則

面向工作負(fù)載的深度優(yōu)化

未來充分發(fā)揮 Serverless 容器的能力，我們需要針對(duì)工作負(fù)載的特性進(jìn)行深度優(yōu)化。

• Knative：Knative 是 Kubernetes 生態(tài)下一種 Serverless 應(yīng)用框架，其中 serving 模塊支持根據(jù)流量自動(dòng)擴(kuò)縮容和縮容到 0 的能力?；?Serverless K8s 能力，阿里云 Knative 可以提供一些新的差異化功能，比如支持自動(dòng)縮容到最低成本 ECI 實(shí)例規(guī)格，這樣可以在保障冷啟動(dòng)時(shí)間的 SLA 并有效降低計(jì)算成本。此外通過 SLB/ALB 實(shí)現(xiàn)了 Ingress Gateway，有效地降低了系統(tǒng)復(fù)雜性并降低成本。
• 在 Spark 等大規(guī)模計(jì)算任務(wù)場(chǎng)景下，也通過一些垂直優(yōu)化手段提高大批量任務(wù)的創(chuàng)建效率。這些能力已經(jīng)在江蘇跨域的用戶場(chǎng)景中得到驗(yàn)證。

Serverless 容器基礎(chǔ)設(shè)施

對(duì)于 Serverless 容器而言，我們梳理的用戶重點(diǎn)訴求是：

1. 更低的計(jì)算成本：彈性成本要低于 ECS，long run 應(yīng)用成本要接近 ECS 包年包月
2. 更高的彈性效率：ECI 擴(kuò)容速度要遠(yuǎn)高于 ECS
3. 更大的彈性規(guī)模：與傳統(tǒng) ECS 節(jié)點(diǎn)擴(kuò)容不同，一個(gè)大規(guī)模容器應(yīng)用動(dòng)輒需要數(shù)萬核的彈性算力。
4. 持平的計(jì)算性能：ECI 計(jì)算效能需要和同規(guī)格 ECS 有一致的性能表現(xiàn)
5. 更低的遷移成本：與現(xiàn)有容器應(yīng)用生態(tài)完美集成
6. 更低的使用成本：全自動(dòng)化安全和運(yùn)維能力

ECI 的關(guān)鍵技術(shù)選擇如下：

基于輕量化 Micro VM 的安全容器運(yùn)行時(shí)

對(duì)于云產(chǎn)品而言，首先的考慮就是安全性。為此，ECI 選擇基于袋鼠云原生容器引擎和輕量化 Micro VM 來實(shí)現(xiàn)安全、隔離的容器運(yùn)行時(shí)。除了運(yùn)行時(shí)的資源隔離之外，不同用戶之間的網(wǎng)絡(luò)、存儲(chǔ)、quota、彈性 SLO 等一系列能力也基于阿里云基礎(chǔ)設(shè)施，實(shí)現(xiàn)了嚴(yán)格的多租隔離。

在性能方面，除了袋鼠容器引擎在 OS/容器方面的高度優(yōu)化之外，ECI 在容器執(zhí)行上優(yōu)化集成了現(xiàn)有阿里云基礎(chǔ)設(shè)施能力，比如支持 ENI 網(wǎng)卡直通、存儲(chǔ)直接掛載。這些能力保障 ECI 中應(yīng)用執(zhí)行效率等于甚至略優(yōu)于現(xiàn)有 ECS 運(yùn)行環(huán)境。

基于 Pod 的基本調(diào)度單位和標(biāo)準(zhǔn)、開放的 API 接口

與 Azure ACI, AWS Fargate on ECS 不同，在 ECI 設(shè)計(jì)初期就確定了基于 Pod 作為 Serverless 容器的基本調(diào)度和運(yùn)行單位，這樣可以更加簡(jiǎn)單地結(jié)合上層 Kubernetes 編排系統(tǒng)。

ECI 提供提供了 Pod 的生命周期管理能力，包括 Create/Delete/Describe/Logs/Exec/Metrics 等。ECI Pod 與 K8s Pod 能力一致，不同之處在于其沙箱基于 Micro VM 而非 CGroup/Namespace。這樣使得 ECI Pod 可以比較完美地支持各種 K8s 應(yīng)用，包括 Istio 這樣以 sidecar 方式動(dòng)態(tài)注入的技術(shù)。

此外標(biāo)準(zhǔn)化的 API 屏蔽了底層資源池的具體實(shí)現(xiàn)，可以同時(shí)可以容納底層不同形態(tài)、不同架構(gòu)、不同的資源池和生產(chǎn)調(diào)度實(shí)現(xiàn)。ECI 底層架構(gòu)做了多次優(yōu)化、迭代，比如袋鼠安全沙箱的創(chuàng)建可以通過神龍架構(gòu)的 MOC 卡進(jìn)行 offload，但是這些對(duì)上層應(yīng)用和集群編排是無感的。

此外 API 需要擁有足夠的通用性支持在多個(gè)場(chǎng)景中使用，讓用戶在 ASK/ACK、自建 K8s 和混合云場(chǎng)景中都可以充分利用 Serverless 容器的優(yōu)勢(shì)和價(jià)值。這個(gè)也是阿里云 ECI 和友商一個(gè)重要的不同。

ECI 與 ECS 并池架構(gòu)

通過并池我們有能力充分整合阿里云彈性計(jì)算資源池的算力，包括多種模式(按量，spot，RI，Saving Plan 等)，多種機(jī)型供應(yīng)(GPU/vGPU, 新 CPU 架構(gòu)上線)，多樣化的存儲(chǔ)能力(ESSD，本地盤)等，讓 ECI 在功能、成本和規(guī)模上更有優(yōu)勢(shì)，滿足用戶對(duì)計(jì)算成本和彈性規(guī)模的強(qiáng)訴求。

Serverless 容器的挑戰(zhàn)

Serverless 容器資源創(chuàng)建過程首先是一個(gè)計(jì)算資源的創(chuàng)建裝配過程，是計(jì)算、存儲(chǔ)、網(wǎng)絡(luò)多個(gè)基礎(chǔ) IaaS 資源的協(xié)同裝配過程。然而與 ECS 不同，Serverless 容器有很多獨(dú)立的挑戰(zhàn)。

??

根據(jù) Sysdig 2019 年容器的調(diào)研報(bào)告(https://sysdig.com/blog/sysdig-2019-container-usage-report/), 超過 50% 的容器生命周期小于 5 分鐘。Serverless 容器需要具備秒級(jí)的啟動(dòng)速度才能滿足用戶對(duì) Serverless 容器的啟動(dòng)訴求。Serverless 容器自身的啟動(dòng)速度主要受如下因素影響：

底層虛擬化資源的創(chuàng)建和組裝

通過端到端管控鏈路的優(yōu)化 ECI 可以將資源準(zhǔn)備時(shí)間優(yōu)化到亞秒級(jí)。

Micro VM 操作系統(tǒng)啟動(dòng)時(shí)間

袋鼠容器引擎針對(duì)容器場(chǎng)景對(duì)操作系統(tǒng)進(jìn)行了大量剪裁和優(yōu)化，極大減少了 OS 啟動(dòng)時(shí)間。

鏡像下載時(shí)間

從 Docker 鏡像倉(cāng)庫(kù)下載鏡像并在本地解壓縮是一個(gè)非常耗時(shí)的操作。下載時(shí)間取決于鏡像大小，通常在 30 秒到數(shù)分鐘不等。在傳統(tǒng) Kubernetes 中， worker 節(jié)點(diǎn)會(huì)在本地緩存已下載過的鏡像，這樣下次啟動(dòng)不會(huì)重復(fù)下載和解壓。為了實(shí)現(xiàn)極致彈性成本效率，ECI 和 ECS 采用并池的策略，計(jì)算存儲(chǔ)分離的架構(gòu)，這也意味著我們不可能通過傳統(tǒng)方式利用本地盤來做容器鏡像的緩存。

為此我們實(shí)現(xiàn)了一個(gè)創(chuàng)新的方案：可以將容器鏡像制作成一個(gè)數(shù)據(jù)盤快照。當(dāng) ECI 啟動(dòng)時(shí)，如果鏡像快照存在，可以直接基于快照創(chuàng)建一個(gè)只讀數(shù)據(jù)盤，并隨著實(shí)例啟動(dòng)自動(dòng)掛載，容器應(yīng)用直接利用掛載數(shù)據(jù)盤作為 rootfs 進(jìn)行啟動(dòng)?；诒P古 2.0 架構(gòu)和阿里云 ESSD 云盤的極致 I/O 性能，我們可以將鏡像加載的時(shí)間縮小到 1 秒以內(nèi)。

這個(gè)領(lǐng)域還有很大發(fā)展空間，下一步會(huì)進(jìn)一步和多個(gè)團(tuán)隊(duì)共同優(yōu)化 Serverless 容器的啟動(dòng)效率。

此外， Serverless 容器的調(diào)度相比 ECS 更關(guān)注資源彈性供給的確定性。Serverless 容器強(qiáng)調(diào)按需使用，而 ECS 更多是提前購(gòu)買預(yù)留。在大規(guī)模容器創(chuàng)建場(chǎng)景下，單用戶單 AZ 彈性 SLO 保障是一個(gè)很大的挑戰(zhàn)。在電商大促、跨年活動(dòng)和最近的突發(fā)疫情保障的一系列用戶支持中，用戶對(duì)于云平臺(tái)是否能夠提供彈性資源供給確定性 SLO 是極度重視的。此外，結(jié)合 Serverless K8s，上層調(diào)度器和 ECI 彈性供給策略配合，我們可以給用戶更多對(duì)彈性資源供給的控制能力，平衡彈性的成本，規(guī)模和持有時(shí)間等不同需求維度。

Serverless 容器的并發(fā)創(chuàng)建效率也至關(guān)重要。在高彈性場(chǎng)景，用戶要求 30s 內(nèi)啟動(dòng) 500 Pod 副本來支持突發(fā)流量，類似 Spark/Presto 等計(jì)算業(yè)務(wù)對(duì)并發(fā)啟動(dòng)的訴求更大。

為了有效減低計(jì)算成本，Serverless 容器應(yīng)該提升部署密度。由于采用 MicroVM 技術(shù)，每個(gè) ECI 實(shí)例擁有獨(dú)立的 OS 內(nèi)核。此外為了兼容 K8s 語義，還有一些輔助進(jìn)程運(yùn)行在 ECI 內(nèi)部。目前每個(gè) ECI 進(jìn)程會(huì)有 100M 左右的額外開銷。類似 EKS on Fargate，每個(gè) Pod 也有近 256M 左右的系統(tǒng)開銷。這部分會(huì)降低 Serverless 的部署密度。我們需要將共性的開銷下沉到基礎(chǔ)設(shè)施之上，甚至通過 MOC 軟硬一體的方式來進(jìn)行卸載。