引領雲原生髮展 阿里雲首創雲原生容器界面方法論
2020年 雙11,阿里核心系統實現了全面雲原生化,扛住了史上最大流量洪峰,向業界傳達出了“雲原生正在大規模落地”的信號。這裡包含着諸多阿里 "雲原生的第一次”,其中非常關鍵的一點是80% 核心業務部署在阿里雲容器 ACK 上,可在1小時內擴展超百萬容器。
可以說,以 Kubernetes 爲代表的容器技術正成爲雲計算新界面。容器提供了應用分發和交付標準,將應用與底層運行環境進行解耦。Kubernetes 作爲資源調度和編排的標準,屏蔽底層架構差異性,幫助應用平滑運行在不同基礎設施上。CNCF Kubernetes 的一致性認證,進一步確保不同雲廠商 Kubernetes 實現的兼容性,這也讓更多的企業願意採用容器技術來構建雲時代的應用基礎設施。
雲原生容器新界面的崛起
作爲容器編排的事實標準,Kubernetes 支持 IaaS 層不同類型的計算、存儲、網絡等能力,不論是 CPU、GPU、FPGA 還是專業的 ASIC 芯片,都可以統一調度、高效使用異構算力的資源,同時完美支撐各種開源框架、語言和各類型應用。伴隨着 Kubernetes 成爲新操作系統的事實,以雲原生容器爲主的技術,已經成爲雲計算的新界面。
1. 雲原生容器界面特徵
雲原生容器界面具有以下三個典型特徵:
向下封裝基礎設施,屏蔽底層架構的差異性。
1)向下封裝基礎設施,屏蔽底層差異性
統一技能棧降低人力成本:Kubernetes 可以在 IDC、雲端、邊緣等不同場景進行統一部署和交付,通過雲原生提倡的 DevOps 文化和工具集的使用有效提升技術迭代速度,因此整體上可以降低人力成本。
統一技術棧提升資源利用率:多種計算負載在 Kubernetes 集羣統一調度,可以有效提升資源利用率。Gartner 預測“未來3年,70% 的 AI 任務運行在容器和 Serverless 上” ,而 AI 模型訓練和大數據計算類工作負載更加需要 Kubernetes 提供更低的調度延遲、更大的併發調度吞吐和更高的異構資源利用率。
加速數據服務的雲原生化:由於計算存儲分離具備巨大的靈活性和成本優勢,數據服務的雲原生化也逐漸成爲趨勢。容器和 Serverless 的彈性可以簡化對計算任務的容量規劃。結合分佈式緩存加速(比如 Alluxio 或阿里雲 Jindofs)和調度優化,也可以大大提升數據計算類和 AI 任務的計算效率。
安全能力進一步加強:隨着數字經濟的發展,企業的數據資產成爲新“石油”,大量數據需要在雲端進行交換、處理。如何保障數據的安全、隱私、可信成爲了企業上雲的最大挑戰。我們需要用技術手段,建立數字化信任基礎,保護數據,幫助企業創建可信任的商業合作關係,促進業務增長。比如基於 Intel SGX 等加密計算技術,阿里云爲雲上客戶提供了可信的執行環境。不過,可信應用開發和使用門檻都很高,需要用戶對現有應用進行重構,處理大量的底層技術細節,讓這項技術落地非常困難。
2)拓展雲計算新邊界,雲邊端一體化管理
隨着邊緣計算的場景和需求不斷增加,“雲邊協同”、“邊緣雲原生”正在逐漸成爲新的技術焦點。Kubernetes 具有強大的容器編排、資源調度能力,可以滿足邊緣/IoT 場景中,對低功耗、異構資源適配、雲邊網絡協同等方面的獨特需求。爲了推動雲原生和邊緣計算交叉領域的協同發展,阿里巴巴於2020年5月正式對外開源邊緣計算雲原生項目 OpenYurt,推動“雲邊一體化”概念落地,通過對原生 Kubernetes 進行擴展的方式完成對邊緣計算場景需求的支持,其主要特性有:
“零”侵入的邊緣雲原生方案:提供完整的 Kubernetes 兼容性,支持所有原生工作負載和擴展技術(Operator/CNI/CSI 等);可以輕鬆實現原生 Kubernetes 集羣一鍵轉化爲 OpenYurt 集羣。
節點自治:具備雲邊弱網或斷網環境下的邊緣節點自治、自愈能力,保障業務連續性。
針對海量邊緣節點的應用交付,可提供高效、安全、可控的應用發佈和管理方式。
2019年 KubeCon 上阿里雲發佈邊緣容器服務 ACK@Edge,OpenYurt 正是其核心框架。短短一年,ACK@Edge 已經應用於音視頻直播、雲遊戲、工業互聯網、交通物流、城市大腦等場景中,並服務於盒馬、優酷、阿里視頻雲和衆多互聯網、新零售企業。同時,作爲 ACK@Edge 的開源版本 OpenYurt,已經成爲 CNCF 的沙箱項目,推動 Kubernetes 上游社區兼顧邊緣計算的需求,歡迎各位開發者一起共建,迎接萬物智聯的新時代。
3)向上支撐多種工作負載和分佈式架構
企業在 IT 轉型的大潮中對數字化和智能化的訴求越來越強烈,最突出的需求是如何能快速、精準地從海量業務數據中挖掘出新的商業機會和模式創新,才能更好應對多變、不確定性的業務挑戰。
Kubernetes 可以向上支持衆多開源主流框架構建微服務、數據庫、消息中間件、大數據、AI、區塊鏈等各種類型應用。從無狀態應用、到企業核心應用、再到數字智能應用,企業和開發者都可以基於 Kubernetes 順利地自動部署、擴展和管理容器化應用。
2. 阿里巴巴如何理解雲原生容器界面
阿里巴巴將雲原生看作未來重要的技術趨勢,爲了更快加速、更好協同,制定了清晰的經濟體雲原生技術路線,舉集團之力統籌推動雲原生。
在雲原生容器界面的指引下,阿里巴巴集團以基礎設施、運維及其周邊系統作爲切入點,掀起全面雲原生化的浪潮,陸續將系統改造爲適配雲原生架構的新方案,推動集團內部使用的技術框架、工具等被雲可接受的標準產品或雲產品替代;進一步轉變運維思路和工作方式,兼容適配新的運維模式。例如:DevOps 需要改變傳統虛擬機時代的運維思想,容器運行時的組件要改爲支持 Kubernetes Pod 下的新模式,容器內日誌、監控等各類運維組件都需要變化、運維模式也隨之變化。
在計算、網絡、存儲方面,用戶通過 Kubernetes 的統一管理,可以充分利用阿里雲的 IaaS 能力,讓每個業務擁有自己獨立的彈性網卡和雲盤,對網絡和存儲性能有着高低不同需求的業務,也有能力部署在同一臺宿主機上,並保證互相不被幹擾的隔離性。傳統非雲物理機機型決定業務部署類型,會導致的彈性不足問題,也得到了很好的解決。因此,用戶在提升資源利用率、降低成本的同時,也極大提升了業務的穩定性。
在節點資源層,用戶可充分利用 Kubernetes 的底座擴展能力,讓節點管理實現雲原生化;在架構層面,通過節點生命週期控制器、自愈控制器和組件升級控制器等,可實現節點自愈、流轉、交付、環境組件變更的節點生命週期的完全閉環,讓容器層完全屏蔽底層節點感知,完全改變了節點的運維管理模式。基於強大的雲原生節點管理模式,阿里巴巴內部將集團之前相對割裂的節點資源整合爲一體,真正實現了資源池從點形成面,將內核、環境組件、機型規格等進行統一標準整合,資源池的大一統並結合統一調度形成巨大的彈性能力,這也是雲原生節點管理中的『書同文,車同軌,度同制,行同倫,地同域』,讓節點資源從諸侯格局變成了大一統的雲原生資源池。
新興的生態和業務,基於 ACK(阿里雲容器服務)提供的雲原生土壤,如 Service Mesh、Serverless、Faas 等,也非常快速地在集團內落地,並得到蓬勃發展。
在應用 PaaS 層,雲原生的應用交付模式走向了更爲徹底的容器化,充分利用了 Kubernetes 的自動化調度能力,基於 OAM Trait 的標準定義來構建集團內統一的 PaaS 運維能力,基於 GitOps 研發模式讓基礎設施和雲資源代碼化、可編程。
阿里集團向雲原生容器界面的演進
爲了支撐阿里集團龐大而複雜的業務,十年之間,衆多技術工程師走出了一條深深淺淺的容器之旅。
那麼,在阿里集團內部,容器界面是如何演進的呢?
在過去十年,阿里集團內的容器技術,經歷了從自研 LXC(Linux Container)容器 T4,到富容器,再到 Kubernetes 雲原生輕量級容器的演進歷程。每一次轉變升級,都是基於不同時期的業務背景,所做出的技術迭代和自我革新。
第一階段:基於 LXC 的容器 T4嘗試
受困於虛擬機 KVM 的巨大開銷,以及 KVM 編排管理的複雜度,阿里集團在2011年時發起對 LXC 和 Linux Kernel 的定製,在內部上線了基於 LXC 的 T4容器。但相比後面出現的 Docker, T4容器在技術上存在一些不足,比如沒有實現鏡像提取和應用描述。T4誕生後的多年,阿里持續嘗試在 T4之上構建複雜的基線定義,但屢屢遭遇問題。
第二階段:引入容器鏡像機制的 AliDocker,實現大規模分發
2015年,阿里引入 Docker 的鏡像機制,將 Docker 和 T4的功能取長補短互相整合,即:讓 T4具備 Docker 鏡像能力,同時又讓 Docker 具備了 T4對內部運維體系的友好性,並在此基礎上形成內部產品 AliDocker。
過程中,阿里引入 P2P 鏡像分發機制,隨着電商核心應用逐步全面升級到 AliDocker,通過宿主機的環境隔離性和移植性,屏蔽了底層環境差異,爲雲化/統一調度/混部/存儲計算分離等後續基礎架構變革打下了基礎,鏡像機制的優勢得以體現。其中,孵化的 P2P 鏡像分發是2018年10月加入 CNCF 的 Dragonfly。
第三階段:完全自主產權的容器 Pouch,阿里內部全面容器化
隨着容器技術的規模化鋪開,AliDocker 化的優勢得以體現,阿里完全自主產權的 Pouch 得以展開並逐漸替代 AliDocker。同時,阿里集團100% Pouch 化也一直在快速推進,2016年 雙11前,已經實現了全網的容器化。
Pouch 寓意是一個神奇的育兒袋,爲裡面的應用提供貼心的服務。因爲 Pouch 統一了集團在線應用的運行時,應用開發人員就無需關注底層基礎設施的變化。接下來的數年,底層基礎設施發生了雲化、混部、網絡 VPC 化、存儲無盤化、內核升級、調度系統升級等各種技術演進,但 Pouch 容器運行時使絕大部分底層變化對應用無感知,屏蔽了對上層應用的影響。Pouch 自身也把運行時從 LXC 切換到了 runC,並將其核心技術反哺給開源社區,同時集團也逐步將過去的存量 AliDocker 實例無縫切換爲開源的 Pouch 實現。
過程中富容器模式的存在,一方面讓用戶和應用能夠無縫平滑地切換到容器化,另一方面應用依賴的各種運維、監控、日誌收集等運維繫統,基於富容器模式也得以跟隨容器化平滑遷移。
但富容器也有着較多缺點。由於富容器中可以存在多個進程,並且允許應用開發和運維人員登錄到容器中,這違反了容器的“單一功能”原則,也不利於不可變基礎設施的技術演進。例如:Serverless 演進過程中,調度插入的代理進程實際上是與應用無關的,一個容器中有太多的功能也不利於容器的健康檢查和彈性。
容器化是雲原生的必經之路。阿里集團正是通過這種方式,快速走完了容器化這一步,極大加速了雲原生的進一步演進。全面容器化後,雲原生的大勢已經不可阻擋,越來越多新的理念和應用架構在容器生態中成長起來,基於容器和鏡像的應用打包、分發、編排、運維的優勢被越多的人看到、接受和擁抱,各種運維繫統開始適配雲原生架構。
第四階段:調度系統兼收幷蓄及 ACK 的演進
隨着以 Kubernetes 爲代表的容器技術成爲雲計算的新界面,阿里自研的 Sigma 也在持續探索 Kubernetes 的落地實踐,並藉助集團全面上雲的契機,最終實現了從 Sigma 管控到 ACK 的全面遷移。
2018年,集團調度系統開始了從內部定製的 Sigma 到 ACK 的逐步演進,容器輕量化成爲一個重要的演進目標。雲原生浪潮下,集團內部的運維生態也隨之快速演進。輕量化容器的解決思路是用 Kubernetes 的 Pod 來拆分容器,剝離出獨立的運維容器,並將衆多與應用無關的運維進程逐個轉移至運維容器。
Sigma 誕生之初致力於將阿里集團衆多割裂的在線資源池整合統一,在此基礎上,不斷探索新的資源混跑形態,包括在離線混部、離在線混部、Job 調度、CPUShare、VPA 等衆多技術。通過提升阿里集團數據中心整體資源利用率,帶來巨大的成本節約效益。基於全託管免運維 Sigma Master、公共大資源池、應用額度服務,提供 Serverless 的資源交付和最佳的用戶體驗。Sigma 調度也加速了 T4到 Pouch 的全面容器化進程,通過應用研發自定義的 Dockerfile 標準化容器,以及透明化基礎設施的 Sigma 調度引擎,業務研發已無需關心底層運維,工作重心得以聚焦於業務本身。
從 Sigma 到 ACK 的升級,是希望 ACK 領先的雲產品能力得以賦能阿里集團,使得 Sigma 可以加速享受雲計算的能力,包括異構資源的統一管理、面向全球化的安全合規等。但實際上,遷移 ACK 的過程並非一帆風順:
首先,圍繞着核心管控鏈路,阿里原有的規模和複雜場景能力、原有的龐大存量容器如何遷移到新的平臺,以及容器界面如何兼容並影響現有的龐大生態體系升級,實際上都會成爲演進中的包袱和劣勢。實現在高速飛行中換引擎並解決存量遷移問題的難度,這在業界都有共鳴。
其次,性能、多集羣運維、安全防禦、穩定性等衆多問題,都是全面遷移 ACK 的挑戰。圍繞着性能,阿里基於原生 Kubernetes 做了非常多的優化並回饋給社區,如 Cache Index、Watch Bookmark 等,並建設了一整套 Kubernetes 規模化設施,包括安全防禦組件、OpenKruise、多集羣組件發佈等能力等。
圍繞 “經濟體調度 = ACK + 經濟體擴展” 的總體思路,阿里集團內部遷移至 ACK 過程中的積累又能沉澱給雲,豐富產品能力,幫助客戶形成雲上的競爭力。至此,阿里集團內部、阿里雲、開源社區形成了非常好的技術合力,自研、商用、開源,三位一體融合互補。
自研、商用、開源,三位一體融合互補
技術和業務是相輔相成的,業務爲技術提供場景促進技術進步;技術的進步反過來帶動業務更好的發展。複雜而豐富的場景,提供了一個天然肥沃的土壤,進一步推動阿里技術的發展。阿里集團的技術一直持續保持先進。在過去,業內一直非常領先的中間件、容器、調度等各類技術,阿里都率先應用於業務,並將能力沉澱到雲產品再輸送給客戶,助力企業加速數字化轉型,產生了廣泛的引領者影響力。
但在新雲原生時代,如何在雲原生標準下持續保持這份影響力,我們看到了更多挑戰。上述的阿里容器界面演進簡史記錄了一線阿里工程師們如何應對這些挑戰。更抽象地講,這些得益於阿里巴巴雲原生技術體系自研、商用、開源三位一體的戰略決策。
1. 阿里雲側的挑戰
阿里雲過去面對的用戶大部分是普適性用戶,而阿里集團內部場景的訴求是需要解決大規模、超高性能等問題,阿里雲產品能否很好地兼顧和支撐是非常大的挑戰。進一步考慮,如果我們能很好地抽象出大衆用戶的訴求,阿里集團對阿里雲來說又是一個非常好的“試煉場”。
2. 集團內部的挑戰
船小好調頭,而船大就沒那麼靈活了。過去業界獨有的阿里集團內部龐大規模場景,現在反而是邁向雲原生的包袱。問題的根本在於如何讓阿里集團的技術能夠快速融合和貢獻雲原生標準,而不是形成技術孤島。
3. 開源側的挑戰和機遇
開源側的挑戰和機遇:阿里雲在雲原生開源項目貢獻中有着持續投入,推出了 OpenKruise、聯合微軟推出 OAM、KubeVela 等開源項目,這些都源於阿里巴巴在雲原生領域的沉澱, 並且通過開源社區用戶的反饋,完善在阿里雲原生落地的解決方案。以 OpenKruise 爲例, 該項目是阿里巴巴打造的一個基於 Kubernetes 的、面向大規模應用場景的通用擴展引擎,它的開源使每一位 Kubernetes 開發者和阿里雲上的用戶都能便捷地使用阿里巴巴內部雲原生應用統一的部署發佈能力。當社區用戶或外部企業遇到了 Kubernetes 原生 workload 不滿足的困境時,企業內部不需要重複造一套相似的“輪子”,而是可以選擇使用 OpenKruise 的成熟能力。而且,阿里集團內部使用的 OpenKruise 和開源社區版本中有95% 以上的代碼是完全一樣的。我們希望和每一位參與 OpenKruise 建設的雲原生愛好者,共同打造了這個更完善、普適的雲原生應用負載引擎。
雲原生操作系統的進化
如今,在雲原生應用架構界面層,阿里集團的技術體系正在全面切向雲原生技術、雲產品。
阿里云爲客戶提供的雲原生操作系統, 首先基礎設施層是強大的 IaaS 資源,基於第三代神龍架構的計算資源可以更彈性的擴展,以更加優化的成本提供更高的性能;雲原生的分佈式文件系統,爲容器持久化數據而生;雲原生網絡加速應用交付能力,提供應用型負載均衡與容器網絡基礎設施。
其次在容器編排層,阿里雲容器服務自2015年上線來,伴隨數千家企業客戶,共同實踐過各行各業大量生產級場景。越來越多的客戶以雲原生的方式架構其大部分甚至全量應用,隨着業務深入發展,爲了滿足大中型企業對可靠性、安全性的強烈需求,阿里雲推出新品可供賠付 SLA 的容器服務企業版 ACK Pro,並同樣支撐了阿里集團內部的衆多產品的落地。
容器服務 ACK Pro 版,針對金融、大型互聯網、政企客戶的需求,支持更大規模集羣,更高性能和更加全面的安全防護。
首先,基於神龍架構,軟硬一體化優化設計,提供卓越性能:
無損 Terway 容器網絡,簡化數據鏈路,相比路由網絡延遲下降30%。
支持全球首款持久性內存實例,相比 NVMe,I/O 密集應用 TPS 提升100%。
其次,提供對異構算力和工作負載優化的高效調度:
智能 CPU 調度優化,在保障 SLA 和密度的前提下,Web 應用 QPS 提升30%。
支持 GPU 算力共享, AI 模型預測成本節省50% 以上。
最後,爲企業提供全面安全防護:
支持阿里雲安全沙箱容器,滿足企業客戶對應用的安全、隔離需求,性能相比開源提升30%。
國內首批通過可信雲容器安全先進性認證,支持運行時風險秒級阻斷。
同時,阿里雲全託管託管服務網格 ASM 正式商用化,這是業內首個全託管 Istio 兼容服務網格 ASM。
ASM 可以實現多種異構應用服務統一治理,提供了對雲上虛擬機,容器,彈性容器實例,和 IDC 應用等異構服務的統一管理,提供全鏈路可觀測性和端到端安全防護。幫助您加速企業應用的現代化改造,輕鬆構建混合雲 IT 架構。
阿里雲容器服務連續兩年國內唯一進入 Gartner《公有云容器服務競爭格局》報告;在 Forrester 首個企業級公共雲容器平臺報告中,阿里雲容器服務位列 Strong Performer, 中國第一。
展望
雲計算的未來是雲原生,容器新界面是進化中的關鍵一小步。向下,容器新界面帶來的高密度、高頻度的能力要求會進一步催熟雲計算的端到端優化;向上,基於容器新界面的 Serverless、新一代的中間件、新一代的應用 PaaS 方興未艾。
雲原生技術正成爲釋放雲價值的最短路徑,未來,阿里巴巴將會持續在雲原生上進行投入,而阿里的雲原生技術不僅會在內部大規模普及,也通過阿里雲服務全社會。