阿里雲容器如何實現 1000Pod-min 一鍵啓動

嘉賓 | 王凌志

整理 | 李慧文

隨着雲原生和容器編排技術的發展，阿里雲容器服務 Kubernetes 版受到越來越多用戶的青睞，但同時也存在非常多的問題，例如彈性、安全、穩定、運維等。面對這些問題，阿里雲是如何思考的呢？在 QCon 全球軟件開發大會（2021）北京站上，阿里雲高級技術專家王志凌分享了阿里雲在 Serverless 容器場景下的探索和實踐。我們整理了他的演講，以期幫你更好地使用容器服務。（下文以王志凌老師第一人稱敘述）

1 容器用戶的痛點與挑戰

雲上的容器企業用戶可分爲四類：共振型、毛刺型、混部型、平穩型， 如下圖所示：

**共振型各業務間存在關聯，流量增長後各業務對資源的訴求同時增長，需要極致的彈性能力，**如微博熱點話題、電商大促、泛互聯網行業流量高峯等。

**毛刺型需短時間內創建海量資源，運行後釋放所創資源，需極致的庫存和彈性能力，**常見於離線型業務，如大數據計算任務、Job 任務、AI 仿真任務等。

**混部型擁有多個業務，不同業務不同時間段對算力要求不同，優先級不同，存在多部門業務資源爭搶問題 ，**如白天爲在線服務高峯期，晚上爲離線 Job 型業務高峯。此外，多家企業部署在同一個 Kubernetes 上還存在容器逃逸的數據安全和攻擊應對問題。

平穩型業務此處暫不贅述。

綜上所述，雲上容器用戶的痛點我們整體上可以歸納爲五類：**彈性能力不足；成本和資源無法平衡；安全性不足；容災、穩定性能力不足；性能或異構管理複雜度過高。**這些痛點阿里雲是如何解決的呢？

2 阿里雲 Serverless 容器實例技術內幕

如下圖右側所示：容器實例的資源形態（以阿里云爲例）即爲一個 Elastic Container Instance 中包含一個 Pod，Pod 中包含多個容器。

容器實例在和 Kubernetes 結合時，可實現完整的資源供給，在普通 Kubernetes 中，可實現 Node 資源的彈性擴充。

下圖爲兩個容器實例的例子：

左圖爲容器實例單實例模擬實驗。一條命令即可起一個單容器實例。如圖中爲 eci run 5 兆帶寬的 nginx，一條命令後便起了一個擁有 5 兆公網帶寬可使用 eci 進入的 nginx 實例。其操作和傳統 Docker 大同小異。

右圖爲容器實例本地集成的例子。如圖所示，在筆記本上安裝 mini Kubernetes，同時安裝 Virtual Node 將資源調度指定到 Virtual Node 上，即可一鍵創建出數萬覈資源。

阿里雲容器實例的整體架構

阿里雲容器本身定義在 PaaS 層上，但是容器實例定義在 IaaS 層上，和雲服務器 ECS 同基礎設施層。

這是由於容器均處於單租戶模式下，而容器實例處於多租戶模式下。多租戶模式意味着需準備計算資源、存儲資源、網絡資源等等，所以容器實例專注的不是容器交付本身，而是以容器所需的基礎設施資源交付爲重點。

阿里雲容器實例複用了阿里基礎設施的計算、網絡、存儲相關架構。具體來說，計算採用神龍物理機，網絡採用洛神 2.0，存儲採用盤古。

**阿里雲打通了 IaaS 層全棧的日誌採集和監控報警。**其中日誌採集採用了兩類特徵學習：一類通過提取故障特徵實現了故障預測及硬件故障預警等，若發現預警可將服務器或容器熱遷移到其他物理機上；另一類特徵針對用戶業務，下文會詳述。

此外，阿里云爲用戶預留了內部運維或故障遷移的熱遷移時間。

Serverless 容器的架構演進

2018 年，阿里雲容器實例最初爲 on ECS 架構，開容器實例時需開大量 ECS 、建 ECS 資源池。演進後，ECI 和 ECS 均混部在物理機上，共享物理集羣和庫存。

業界容器實例安全沙箱實現很多，常見的在物理機上安裝 Kubernetes 後 runv 即可實現，**但在多租戶模式下，業界的 runv 模式均只考慮了資源隔離性，未考慮數據安全性。**阿里雲採用自研的安全沙箱 “袋鼠”，結合重構了 Containerd 中 image 和 volume 相關的實現，最終保證了用戶數據界限在其安全沙箱內部。

通過混部容器實例，可複用服務器庫存，解決產品庫存供給能力的問題，也便於進行全局的資源管理、使用統一基礎設施存儲與網絡、複用 VM 資源強隔離機制、複用 VM 穩定性運維能力進行故障預測恢復和 Pod 級別熱遷移，另外也提供了支持 Pod 級別 SLA 能力。

異構與 Pod 級別 SLA

開發常常抱怨運維提供的資源能力不足，本質上是缺乏 SLA 保證。Node 購買時可保證其 SLA，但是開多個 Pod 後就難以保證了。爲此阿里雲在並池基礎上實現了 Pod 級別的 SLA 保證。

阿里內部的達摩院語音、自動駕駛、釘釘視頻，均嚴格按照 SLA 機制使用 Pod，**即定義相應的規格，開發向運維提資源需求時必須使用約定的規格數據。**該規格對服務器來說代表 CPU 主頻、PPS、網卡隊列等，對雲盤來說代表 bps、iops。

SLA 下沉到 Pod 級別, 還可實現大規模的異構資源管理。大型公司業務種類繁多，包括 GPU 模式、計算密集型、網絡密集型等，但在一個集羣中指定不同 SLA 規格 Node 的異構資源管理相當複雜，若每種異構架均構建一個獨立集羣，運維必將苦不堪言。實現了 Pod 級別 SLA 後，運維完全不需要關心集羣級別異構特性，業務可在一個集羣中自主指定所需異構模型。

1000Pod/min 啓動實現：軟硬全棧優化

阿里雲的 Sandbox 包含負責輕量化管理的 Agent、自定 Container 和輕量級、虛擬化的安全沙箱三部分。

彈性效率依賴於控制面。在控制面上，阿里雲實現了預熱、資源複用、網絡存儲預熱、鏡像緩存、全鏈路輕量化、用戶特徵提取等。

資源複用即前文提及的通過以用戶業務爲特徵的學習機制篩選某些用戶行爲，如頻繁創建釋放大量資源等，針對性實現資源層面的複用。

Serverless 下用戶無法提前在 Node 節點上預熱鏡像。但多數用戶的鏡像和存儲均在雲上，同時無論是何處創建容器都需拉鏡像，因此阿里雲**打通了基礎設施存儲跟容器鏡像 cache 能力。用戶不必拉鏡像即可直接使用鏡像，**通過鏡像 cache、nydus 按需讀取和 P2P 模式三種方式，實現一秒 start 超大鏡像。

安全容器架構

在安全方面，阿里雲採用的自研安全沙箱體系如下圖所示：

**該體系運行時分爲三種模式：runc、rund、rune。**runc 運行在單租戶模式下；rund 完全隔離類似開源的 runv；rune 爲安全 runtime。

阿里雲在引擎層通過加速、高併發，輕量化提高了資源供給效率，實現了單安全沙箱啓動 200 ms 左右。

具體來說，在網絡上採用了 eBPF，提高自身網絡性能的同時爲用戶提供 Mesh 透明攔截或監控的能力；在存儲上一方面打通本地臨時存儲和塊存儲，避免中間協議轉換，另一方面採用 copy-on-write 機制，防止同機器的容器、容器鏡像重複拷貝。

在安全上，第一，通過加密形態的全鏈路通道（包括物理機打入的流量）解決了安全通道問題；第二，基於 TPM（Trust platform model）實現了硬盤數據加密，第三，通過英特爾 SGX 衍生出的 Inclavare Containers 模式保證了容器內存數據的安全。該模式軟硬一體，如下圖所示：

3 阿里雲容器實例經典使用場景

Serverless Kubernetes 架構實踐  

Serverless 容器實例最常見的模式爲全 Serverless 形態，可自定義虛擬節點或虛擬集羣，適用於一個虛擬集羣即爲一個可用區，或定製某個虛擬集羣爲特殊規格資源等的情況。

已廣泛使用 Kubernetes 購買了多臺服務器的公司，可採用自有 Kubernetes+ECI 的模式，日常時在現有物理節點上啓動 longrun 類型的任務，極致利用已有 CPU，高峯期時使用虛擬節點擴容。

該方案以標準 Provider 模式交付，用戶不存在平臺成本，無論在自己的 IDC 或任何雲上均可遷移；創建的 Pod 全局打散，可消除單 Pod 宕機後的影響；一個虛擬節點可代表數幾百萬核甚至上千萬核的資源，無需擴容即可保證高峯期容量。

此外，若用虛擬機形態或裸金屬形態做 Node，需先購買服務器或裸金屬（圖中紅色）才能開 Pod（圖中藍色），在 Serverless 形態可只開 Pod，經濟效益顯著。

實踐一：釘釘 100 萬覈資源實踐

疫情時期，由於學生上課和在家辦公，釘釘的資源被極致利用。第一波疫情時，釘釘用服務器擴容物理 Node，拉通衆多團隊，花費了 48 小時才擴了 100 萬覈資源。

這讓釘釘意識到資源供給效率的重要性。因此去年釘釘從傳統服務器形態演進到完全 Serverless Kubernetes 形態。演進後，壓測到 100 萬核只需 30 分鐘，且這 30 分鐘還包括了業務初始化時間。

此處關鍵在於，在服務器形態時需先擴充物理節點（部分需要特殊的初始化），擴完後再創 Pod。

實踐二：成本與資源平衡

下圖爲某司極致按需使用 GPU 的時序圖：

圖中第一步爲非推理任務，第二步爲推理任務，第三步又爲非推理任務。此時，多數用戶會選擇直接創建 GPU，如此便浪費了第一步第三步的資源。阿里雲支持用戶在 runtime 時動態 attach GPU，跑完其業務後再釋放 GPU。

多數用戶在做藍綠髮布時，可能需準備 2 倍機器專門用作發佈。在 Serverless 下，如已有 1 萬覈資源，可再用 Serverless Pod 創建 1 萬覈資源。發佈時將服務切到 Serverless 上運行，運行正常後再部署到 Node 上，隨後釋放 Serverless 資源即可。如此可節省大量成本。

4 未來預測

根據現狀，可預測雲原生和 Serverless 未來熱點如下：

  1. Serverless 持續火爆發展；

  2. 混合雲實現標準化；

  3. 彈性按需付費；

  4. 實現 Pod 級別 SLA。

嘉賓介紹：

王凌志
10 年基礎設施研發經驗，2015 年加入阿里雲彈性計算團隊，致力於基礎設施相關研發，2018 年參與並主導了新一代 Serverless 基礎設施產品 ECI 研發工作。目前產品專注於爲使用容器企業用戶提供免運維、高彈性，以容器爲粒度的安全基礎設施，助力企業以更高的效率、更敏捷的資源供給思維輕鬆應對在線業務波峯低谷。

外部鏈接：

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/8pI6hba63jjdecHyVwYasw

猜你喜歡