Serverless Kubernetes：理想，現實與將來

 

做者 | 易立、張維 

導讀：當前 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 容器技術重要的硬核能力。

課程推薦

爲了更多開發者可以享受到 Serverless 帶來的紅利，這一次，咱們集結了 10+ 位阿里巴巴 Serverless 領域技術專家，打造出最適合開發者入門的 Serverless 公開課，讓你即學即用，輕鬆擁抱雲計算的新範式——Serverless。