來源 | [阿里巴巴雲原生公眾號](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247496662&idx=1&sn=cb2947676b10cc400a835c35f5a349f2&chksm=fae6f819cd91710fc7b4750c4e0439e3d2b93c642295b71b23d9d21c606f765f0e40d3ded12b&token=1544202383&lang=zh_CN#rd)

作者 | 志敏、智清

2020 年 雙11，阿里核心系統實現了全面雲原生化，扛住了史上最大流量洪峰，向業界傳達出了“雲原生正在大規模落地”的訊號。這裡包含著諸多阿里 "雲原生的第一次”，其中非常關鍵的一點是 80% 核心業務部署在阿里雲容器 ACK 上，可在 1 小時內擴充套件超百萬容器。

可以說，以 Kubernetes 為代表的容器技術正成為雲端計算新介面。容器提供了應用分發和交付標準，將應用與底層執行環境進行解耦。Kubernetes 作為資源排程和編排的標準，遮蔽底層架構差異性，幫助應用平滑執行在不同基礎設施上。CNCF Kubernetes 的一致性認證，進一步確保不同雲廠商 Kubernetes 實現的相容性，這也讓更多的企業願意採用容器技術來構建雲時代的應用基礎設施。

# 雲原生容器新介面的崛起

![1.png](https://ucc.alicdn.com/pic/developer-ecology/f1cde54336d948e28d0834c7141707cb.png)

作為容器編排的事實標準，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](http://mp.weixin.qq.com/s?__biz=MzUzNzYxNjAzMg==&mid=2247491144&idx=1&sn=3044da766ccb7cee8b624286cf7d9ffd&chksm=fae51587cd929c91099f9076f381dfc6d1c60681f4784209e0eb27989329c96e1cc1e35d188d&scene=21#wechat_redirect)，推動“雲邊一體化”概念落地，透過對原生 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 建設的雲原生愛好者，共同打造了這個更完善、普適的雲原生應用負載引擎。

# 雲原生作業系統的進化

如今，在雲原生應用架構介面層，阿里集團的技術體系正在全面切向雲原生技術、雲產品。

![2.png](https://ucc.alicdn.com/pic/developer-ecology/43189e7afc6c4492aa02fb448797fa8b.png)

阿里云為客戶提供的雲原生作業系統， 首先基礎設施層是強大的 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 架構。

![3.png](https://ucc.alicdn.com/pic/developer-ecology/fd0fba588a1c4285af0e73c9363efa6f.png)

**阿里雲容器服務連續兩年國內唯一進入 Gartner《公有云容器服務競爭格局》報告；在 Forrester 首個企業級公共雲容器平臺報告中，阿里雲容器服務位列 Strong Performer, 中國第一**。

# 展望

雲端計算的未來是雲原生，容器新介面是進化中的關鍵一小步。向下，容器新介面帶來的高密度、高頻度的能力要求會進一步催熟雲端計算的端到端最佳化；向上，基於容器新介面的 Serverless、新一代的中介軟體、新一代的應用 PaaS 方興未艾。

雲原生技術正成為釋放雲價值的最短路徑，未來，阿里巴巴將會持續在雲原生上進行投入，而阿里的雲原生技術不僅會在內部大規模普及，也透過阿里雲服務全社會。

以 Kubernetes 為代表的容器技術，已成為雲端計算的新介面

相關文章