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 方興未艾。
云原生技術正成為釋放云價值的最短路徑,未來,阿里巴巴將會持續在云原生上進行投入,而阿里的云原生技術不僅會在內部大規模普及,也通過阿里云服務全社會。
