ACP雲原生容器工程師 - ASK概述與產品介紹

基本概念

Serverless基本概念

對於傳統雲服務來說，我們需要購買的基礎設施是服務器節點ECS，然後在ECS上自行部署應用或者部署其餘付費應用，但是我們爲了更好地適應應用的使用情況，有時並不需要ECS支持，這樣可以更輕量地部署應用，成本也會更低。這就是阿里雲無服務Kubernetes(ASK)的基本概念。

• 特點：

  • 用戶無需購買和管理服務器

  • 直接部署容器應用

  • 提高容器應用部署的敏捷度和彈性能力

  • 降低用戶計算成本

  • 讓用戶聚焦業務應用

• 優勢：

  • 敏捷部署、安全隔離、生態鏈接、高移植性

  • 無需節點容量規劃

  • 無需OS和系統軟件維護

  • 零基礎設施運維

  • “無限”容量、秒級擴容、基於容器擴容

  • 更高的資源利用率、更低計算成本

 

發展趨勢

• 兩種技術趨勢的整合

  • 雲平臺託管的後臺服務BaaS

  • 無狀態計算模型：函數服務FaaS

• Gartner

  • 到2023年，70% AI任務會通過容器、Serverless等計算模型構建

• AWS

  • 在2019年 40%的ECS新客戶採用Serverless Container

• 採納Serverless技術的行業廣泛

  • 外包經濟、金融業、服務業

• Serverless是雲計算必經的一場革命，會越來越流行

 

架構思考

• Serverless場景的容器不是部署在傳統的ECS上，而是部署在ECI上。然而ECS和ECI並不衝突，可以混合使用

• 不同於標準K8s，Serverless K8s與IaaS基礎設施深度融合，其產品模式更利於公有云廠商通過技術創新，提升規模、效率和能力

• Serverless也分成容器編排和計算資源池兩層。

• Serverless的幾個技術要點：聲明式API、可擴展性架構、可移植性

 

架構設計

• Serverless並不是一個單獨的技術，必須兼容Kuubernetes生態，提供K8s的核心價值，此外要能和雲的能力深度整合。

• 用戶可以直接使用Kubernetes的聲明式API，Deployment、StatefulSet、Job、Service等無需修改

• 全兼容Kuberenetes的擴展機制，這樣才能讓Serverless Kubernetes支持更多的工作負載，此外Serverless K8s自身的組件也是嚴格遵守K8s的狀態逼近的控制模式

• Kubernetes的能力盡可能充分利用雲的能力來實現，比如資源的調度、負載均衡、服務發現等。根本性簡化容器平臺的設計，提升規模，降低用戶運維複雜性

• 這些實現應該對用戶透明，保證可移植性，讓用戶現有應用可以平滑部署在Serverless K8s之上，也應該允許用戶應用混合部署在傳統容器和Serverless容器之上

 

Nodeless

• 對於傳統的Kubernetes來說，採用以節點爲中心的架構設計：

  • 節點是Pod的運行載體，Kubernetes調度器在工作節點池中選擇合適的node來運行pod，並利用kubelet完成對pod進行生命週期管理和自動化運維

  • 當節電池資源不夠時，需要對節點池進行擴容，再對容器化應用進行擴容

• 對於Serverless Kubernetes來說

  • 沒有節點這個概念

  • 容器化應用是一等公民

  • 極大簡化容器彈性實現，無需按照容量規劃，按需創建容器應用pod即可

  • Serverless容器運行時可以被整個暈彈性計算基礎設施所支撐，保障整體彈性的成本和規模

 

現有產品的架構

初始架構-Viking

優化方向

1. 可伸縮性 - ECI

2. 基於雲的控制器實現 - PrivateZone、SLB、SLB/ALB

3. 面向負載的深度優化 - Knative、垂直優化

 

ASK產品介紹

• 是阿里雲推出的無服務器Kubernetes容器服務

• 無需購買節點即可直接部署容器應用，無需對集羣進行節點維護和容量規劃，並且餓根據應用配置的CPU和內存資源量進行按需付費（非包年包月，因爲沒有製程規格的節點）

• 提供完善的Kubernetes兼容能力，同時降低了Kubernetes使用門檻，更專注於應用本身，而不是基礎設施

• ASK集羣中的Pod給予阿里雲彈性容器實例ECI運行在安全隔離的容器運行環境中

• 每個Pod容器實例底層通過輕量級虛擬化安全沙箱技術完全搶格力，容器實例間互不影響。

 

核心優勢

1. 簡單易用：無門檻，秒級部署容器應用

2. 秒級伸縮：無需擔心集羣容量規劃

3. 安全隔離：通敵底層沙箱進行強安全隔離

4. 降低成本：按需計費，無資源閒置費用

5. 原生兼容：支持原生k8s應用和生態，service、helm、ingress等

6. 服務集成：支持與其他雲組件(數據庫、vpc中現有應用直接交匯)

 

無節點管理(nodeless)

• 更多專注於應用的開發，而不是基礎設施的維護。更多關注pod/service/ingress/job等應用編排語義上，更少對底層node進行關注。

• 無需管理節點也可以顯著降低集羣的運維管理成本，比如node的安全管理、監控/日誌管理、基礎系統軟件的升級和維護

• 在ASK集羣中，我們使用虛擬節點virtual-kubelet代替ECS節點，此virtual-kubelet節點的容量可以認爲是“無限大”，用戶無需爲集羣的容量擔憂，無需預先做容量規劃

 

Serverless kubernetes vs Classic Kubernetes

 

無Master管理與極簡的K8s

• 與ACK託管版一樣，ASK的Master等資源(apiserver, ccm, kcm等)被容器服務平臺託管，用戶無需管理這些核心組件的升級和運維，也不需要成本

• ASK對Kubernetes進行大量簡化，包括默認託管很多addon，用戶無需在管理一些基礎的addon，也不需要對此付費

• 依賴阿里元原生的網絡和存儲等能力，以及獨特的託管架構設計，ASK提供了極簡但功能完備的Kubernetes基礎運行環境

簡化彈性伸縮

• 因爲無需管理節點和容量規劃，當集羣需要擴容時也就不需要考慮節點層面的擴容，只需要關注pod的擴容，這對於擴容的速度和效率都是極大的提升

• ASK/ECI的方式被刻意用來快速應對業務流量高峯

• 當前ASK/ECI支持30s完全啓動500個pod，單個pod啓動可以達到10s以內

 

更低的成本

• 除去ASK集羣本身的低成本創建外，pod的按需使用也讓很多場景下資源利用率達到最優。對於很多Jobs或者數據計算場景而言，用戶並不需要長期維護一個固定的資源池，這時ASK/ECI可以很好地支持這些訴求

• 若pod一天運行少於16小時，使用ASK更加經濟實惠；若超過16小時，使用ACK更加經濟實惠。

 

ECI: 快速交付容器資源的彈性計算服務

• ECI是阿里雲基於ECS IaaS資源池提供的穩定、高效、高彈性容器實例服務

• ECI讓容器成爲了公有云的一等公民，用戶無需購買和管理ECS就可以直接部署容器應用，這種假話的容器實例產品形態和ASK形成了一個完美地組合

• 用戶可以直接使用ECI Open API創建容器資源實例，但在容器場景中用戶普遍需要一個編排系統，來負責容器的調度、高可用編排等能力，而ASK正式這樣的Kubernetes編排層。

• 對於ASK而言

  • ECI讓ASK容器服務免去了搭建後臺計算資源池的必要，更不用爲底層計算資源池的容量而擔憂

  • 基於ECI就意味着基於整個阿里雲IaaS規模化資源池，天然擁有了庫存和彈性優勢

  • 另外ECI和ECS複用資源池意味着 我們可以最大化釋放規模化紅利，給用戶提供更低成本的計算服務

 

容器生態支持

• ASK比較適合的場景：

  • CI/CD

  • 數據計算

  • AI

  • ServiceMesh

  • 測試

• ASK集羣不支持Helm v2，近期ACK/ASK會發布Helm v3的支持，之後用戶可以非常方便地在ASK集羣中部署Charts

 

小結

• ASK基本概念

• ASK產品介紹

• ASK優勢

• ASK架構介紹與思考