作者：賢維（阿里雲Serverless Kubernetes產品TL），易立（阿里雲容器服務產品線負責人）
從Serverless容器到Serverless Kubernetes
Serverless（無服務器）容器是讓用戶無需購買和管理服務器直接部署容器應用的產品、技術形態。Serverless容器可以極大提高容器應用部署的敏捷度和彈性能力，降低用戶計算成本；讓用戶聚焦業務應用而非底層基礎設施管理，極大地提高應用開發效率，降低運維成本。
目前Kubernetes已經成為業界容器編排系統的事實標準，基於Kubernetes的雲原生應用生態（Helm, Istio, Knative, Kubeflow, Spark on k8s等）更是讓Kubernetes成為雲操作系統。Serverless Kubernetes得到了雲廠商的高度關注。一方面通過Serverless方式根本性解決K8s自身的管理複雜性，讓用戶無需受困於K8s集群容量規劃、安全維護、故障診斷；一方面進一步釋放了雲計算的能力，將安全、可用性、可伸縮性等需求由基礎設施實現，這樣可以形成差異化競爭力。
阿里雲在2018年5月推出 ECI（Elastic Container Instance彈性容器實例），ASK (Alibaba Cloud Serverless Kubernetes)等產品，並在2019年2月正式商業化.
行業趨勢
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在 2020年 Public Cloud Container Service Market評估報告中把Serverless容器作為雲廠商容器服務平臺的主要差異化之一，其中將產品能力劃分為Serverless 容器實例和Serverless Kubernetes兩類。這與阿里雲ECI/ASK的產品定位高度一致。如下圖。
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等數據計算應用，靈活滿足企業中不同業務部門快速成長過程中對多種計算計算任務，高彈性，強隔離、免維護的業務需求。
細分在阿里雲Kubernetes服務中使用Serverless容器的場景，我們同時支持在K8s集群中使用ECI的方案ACK on ECI，和針對Serverless Kubernetes的極致優化的產品ASK。二者可以實現互補，覆蓋滿足不同客戶的的訴求。
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年容器的調研報告, 超過 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容器技術重要的硬核能力。
我們將聯合阿里雲多個團隊共同建設阿里云云原生IaaS基礎設施， 一方面進一步優化現有Serverless容器產品形態，給客戶一個更低成本、更好的使用體驗，更佳的兼容性的Serverless K8s產品。一方面基於Serverles容器，未來也可以幫助上層應用有更多發展和創新空間。Cloud Native First! Serverless First！是我們前進的方向。