Serverless Kubernetes - 理想，現實與未來

作者：賢維（阿裡雲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環境中。

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

在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！是我們前進的方向。