![頭圖.png](https://ucc.alicdn.com/pic/developer-ecology/5274aa0e51324dfba409709d025ad7f5.png)

作者 | 易立、張維
來源 | [阿里巴巴雲原生公眾號](https://mp.weixin.qq.com/s/ytaShy5OZs7xr18iMPcWjQ)

> **導讀**：當前 Serverless 容器的行業趨勢如何？有哪些應用價值？如果 Kubernetes 天生長在雲上，它的架構應該如何設計？Serverless 容器需要哪些基礎設施？阿里雲容器服務產品負責人易立及阿里雲 Serverless Kubernetes 產品 TL 張維將分享他們對 Serverless 容器架構和背後的關鍵思考。

# 從 Serverless 容器到 Serverless Kubernetes

Serverless（無伺服器）容器是讓使用者無需購買和管理伺服器直接部署容器應用的產品、技術形態。

Serverless 容器可以極大提高容器應用部署的敏捷度和彈效能力，降低使用者計算成本；讓使用者聚焦業務應用而非底層基礎設施管理，極大地提高應用開發效率，降低運維成本。

![1.png](https://ucc.alicdn.com/pic/developer-ecology/aa5b444de46247e49724f6c4b94c6c18.png)

目前 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 環境中。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/a07b630ccdc446c3bd6d7677999e173d.png)

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

Gartner 報告中也談到 Serverless 容器業界標準未定，雲廠商有很多空間透過技術創新提供獨特的增值能力，其對雲廠商的建議是：

- 擴充套件 Serverless 容器應用場景和組合，遷移更多普通容器 workload 到 Serverless 容器服務。

- 推進 Serverless 容器的標準化，減輕使用者對雲廠商鎖定的擔憂。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/8948ba2a114c4a0c9a9004527ae21d77.png)

## 2. 典型場景與應用價值

自阿里雲 ASK/ECI 從 2018 年 5 月份正式公測以來，我們非常高興的看到 Serverless 容器的價值逐漸被使用者認可。典型應用場景包括：

### 1）線上業務彈性擴容

基於 ASK 支撐線上業務彈性擴容，在 30s 之內可以極速擴容 500 個應用例項，輕鬆應對預期和非預期突發流量。比如此次疫情時期多個線上教育平臺使用 ASK/ECI 超強彈效能力輕鬆面對業務高峰。

### 2）免運維 Serverless AI 平臺

基於 ASK 開發的智慧、免運維的 AI 應用平臺，可以讓開發者建立自己的演算法模型開發環境，而平臺則會按需彈性伸縮，極大減少了系統維護和容量規劃複雜性。

### 3）Serverless 大資料計算

基於 ASK 構建 Serverless 大資料計算平臺。透過 Serverless 化的 Spark, Presto 等資料計算應用，靈活滿足企業快速成長過程中不同業務部門的多種計算任務、高彈性、強隔離和免維護的需求。

![4.png](https://ucc.alicdn.com/pic/developer-ecology/62fc7b0e39f34340b88f64050d1e7348.png)

# 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，因為古代維京戰船以迅捷和便於操作而著稱。

![5.png](https://ucc.alicdn.com/pic/developer-ecology/23b8a6a5dc414d11a070e03cb81b628d.png)

### 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 包年包月
1. 更高的彈性效率：ECI 擴容速度要遠高於 ECS
1. 更大的彈性規模：與傳統 ECS 節點擴容不同，一個大規模容器應用動輒需要數萬核的彈性算力。
1. 持平的計算效能：ECI 計算效能需要和同規格 ECS 有一致的效能表現
1. 更低的遷移成本：與現有容器應用生態完美整合
1. 更低的使用成本：全自動化安全和運維能力

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 容器有很多獨立的挑戰。

![6.png](https://ucc.alicdn.com/pic/developer-ecology/75579c9dd95f4b439ad5e376d26c91d3.png)

根據 [Sysdig 2019 年容器的調研報告](https://sysdig.com/blog/sysdig-2019-container-usage-report/), 超過 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 容器技術重要的硬核能力。

Serverless Kubernetes：理想，現實與未來

相關文章