從 Serverless 容器到 Serverless Kubernetes
Serverless（無服務器）容器是讓用戶無需購買和管理服務器直接部署容器應用的產品、技術形態。Serverless 容器可以極大提高容器應用部署的敏捷度和彈性能力，降低用戶計算成本；讓用戶聚焦業務應用而非底層基礎設施管理，極大地提高應用開發效率，降低運維成本。
目前 Kubernetes 已經成為業界容器編排系統的事實標準，基於 Kubernetes 的雲原生應用生態（Helm, Istio, Knative, Kubeflow, Spark on K8s 等）更是讓 Kubernetes 成為雲操作系統。一方面通過 Serverless 方式根本性解決 K8s 自身的管理複雜性，讓用戶無需受困於 K8s 集群容量規劃、安全維護、故障診斷；一方面進一步釋放了雲計算的能力，將安全、可用性、可伸縮性等需求由基礎設施實現，這樣可以形成差異化競爭力。
行業趨勢
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 容器的標準化，減輕用戶對雲廠商鎖定的擔憂。
典型場景與應用價值
自阿里雲 ASK/ECI 從 2018 年 5 月份正式公測以來，我們非常高興的看到 Serverless 容器的價值逐漸被用戶認可。典型應用場景包括：
在線業務彈性擴容
基於 ASK 支撐在線業務彈性擴容，在 30s 之內可以極速擴容 500 個應用實例，輕鬆應對預期和非預期突發流量。比如此次疫情時期多個在線教育平臺使用 ASK/ECI 超強彈性能力輕鬆面對業務高峰。
免運維 Serverless AI 平臺
基於 ASK 開發的智能、免運維的 AI 應用平臺，可以讓開發者創建自己的算法模型開發環境，而平臺則會按需彈性伸縮，極大減少了系統維護和容量規劃複雜性。
Serverless 大數據計算
基於 ASK 構建 Serverless 大數據計算平臺。通過 Serverless 化的 Spark, Presto 等數據計算應用，靈活滿足企業快速成長過程中不同業務部門的多種計算任務、高彈性、強隔離和免維護的需求。
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 年容器的調研報告（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 技術公開課
Serverless 具體產品形態如何？如何在生產中使用？在落地過程中有哪些深坑？10 位阿里巴巴 Serverless 領域技術專家共同打造最適合開發者入門的 Serverless 公開課，3 個階段 ，10 個課時，讓你輕鬆上手，即學即用。
識別下方二維碼，或點擊“閱讀原文”免費學習：
