螞蟻安全科技 Nydus 與 Dragonfly 映象加速實踐 | 龍蜥技術

編者按：本文詳細介紹螞蟻安全科技使用龍蜥社群技術進行映象加速的實踐過程，可以讓您瞭解如何基於龍蜥社群推出的容器映象，Nydus 與 Dragonfly 映象加速技術和 LifseaOS 為容器的啟動加速。文章轉自金融級分散式架構，以下為全文。

文/螞蟻集團 ZOLOZ 團隊

01 背景簡介

ZOLOZ[1]是龍蜥社群理事單位螞蟻集團旗下的全球安全風控平臺，透過業內領先的生物識別、大資料分析和人工智慧技術，為使用者和機構提供安全又便捷的安全風控解決方案。ZOLOZ 已為中國、印尼、馬來西亞、菲律賓等 14 個國家和地區的 70 餘家合作伙伴提供數字化轉型過程中的安全風控技術支援。目前，已經覆蓋金融、保險、證券、信貸、電信、公眾服務等領域，累計服務使用者超 12 億。

隨著 Kubernetes 和雲原生的大爆發，ZOLOZ 應用開始在公有云上進行大規模容器化部署。ZOLOZ 業務的映象經過長期維護和更新，無論是映象層數還是整體大小都達到了一個較大的量級（數百 MB 或者幾個 GB）。特別是 ZOLOZ AI 演算法推理應用的基礎映象大小要遠大於一般應用映象（Docker Hub 上 PyTorch/PyTorch：1.13.1-CUDA 11.6-cuDNN 8-Runtime 有 4.92GB，同比 CentOS：latest 只有約 234MB），對於容器冷啟動，即在本地無映象的情況下，需要先從 Registry 下載映象才能建立容器，在生產環境中，容器的冷啟動往往耗時數分鐘，並且隨規模擴大會導致 Registry 因叢集內網路擁堵而無法快速地下載映象，如此龐大的映象給應用的更新和擴容等操作都帶來了不少挑戰。在公有云上容器化持續推進的當下，ZOLOZ 應用主要遇到了三大挑戰：

1. 演算法映象大，推送到雲上映象倉庫耗時長，開發過程中，在使用測試環境進行測試時，往往希望快速迭代，快速驗證，但是每次改完一個分支釋出驗證都要經過幾十分鐘，開發效率十分低下。

2. 拉取演算法映象耗時長，在叢集擴容大量機器拉取映象檔案會容易導致叢集網路卡被打滿，影響業務正常執行。

3. 叢集機器拉起時間長，難以滿足流量突增時，彈性自動擴縮容。

雖然也嘗試過各種折中的解決方案，但這些方案都有缺陷，我們現在結合螞蟻、阿里雲、位元組跳動等多個技術團隊打造了一套更通用的公有云上解決方案，該方案改造成本低，效能好，其中大部分技術都在龍蜥社群中發起、發展、開源，目前看來是比較理想的方案。

02 術語及定義

OCI：Open Container Initiative，開放容器計劃是一個 Linux 基金會專案，由 Docker 在 2015 年 6 月啟動，旨在為作業系統級虛擬化（最重要的是 Linux 容器）設計開放標準。

OCI Manifest：遵循 OCI Image Spec 的製品。

BuildKit：是 Docker 公司出品的一款更高效、Docekrfile 無關、更契合雲原生應用的新一代 Docker 構建工具。

映象：本文中的映象指 OCI Manifest，也包括 Helm Chart 等其他 OCI Manifest。

映象倉庫：遵循 OCI Distribution Spec 實現的製品倉庫。

ECS：是一種由 CPU、記憶體、雲盤組成的資源集合，每一種資源都會邏輯對應到資料中心的計算硬體實體。

ACR：阿里雲映象倉庫服務。

ACK：阿里雲容器服務 Kubernetes 版提供高效能可伸縮的容器應用管理能力，支援企業級容器化應用的全生命週期管理。

ACI：ACI 全稱 Ant Continuous Integration（AntCI），是螞蟻集團研發效能旗下一款以流水線（Pipeline）為核心的 CI/CD 效能產品。使用智慧自動化構建、測試和部署，提供了以程式碼流為輸入的輕量級持續交付解決方案，提高團隊研發的工作效率。

Private Zone：基於專有網路 VPC（Virtual Private Cloud）環境的私有 DNS 服務。該服務允許在自定義的一個或多個 VPC 中將私有域名對映到 IP 地址。

P2P：點對點技術，當 P2P 網路中某一個 Peer 從 Server 下載資料的時候，下載完資料後也能當作服務端供其他 Peer 下載。當大量節點同時下載的時候，能保證後續下載的資料，可以不用從 Server 端下載。從而減輕 Server 端的壓力。

Dragonfly： Dragonfly 是⼀款基於 P2P 技術的檔案分發和映象加速系統，並且是雲原生架構中映象加速領域的標準解決方案以及最 佳實踐。現在為雲原生計算機基金會（CNCF）託管作為孵化級專案。

Nydus：Nydus 映象加速框架是 Dragonfly 的子專案，它提供了容器映象按需載入的能力，在生產環境支撐了每日百萬級別的加速映象容器建立，在啟動效能，映象空間最佳化，端到端資料一致性，核心態支援等方面相比 OCIv1 有巨大優勢。 Nydus 也是龍蜥社群雲原生 SIG 創始專案之一。

LifseaOS： 龍蜥社群的開源專案，是面向容器場景的輕量、快速、安全、映象原子管理的容器最佳化作業系統。相比傳統作業系統軟體包數量減少 60%，映象大小減少 70%，OS 首 次啟動從傳統 OS 的 1min 以上下降到了 2s 左右。支援映象只讀和 OSTree 技術，將 OS 映象版本化管理，更新作業系統上的軟體包、或者固化的配置時，以整個映象為粒度進行更新。

03 方案設計

3.1 解決映象大的問題

3.1.1 精簡基礎映象大小

基礎 OS 從 CentOS 7 改為龍蜥社群釋出的官方 OS 映象 Anolis OS 8，精簡運維工具的安裝，只預設安裝一些必須的工具列表（基礎運維工具、執行時通用依賴、日誌清理、安全基線等元件），並簡化安全加固的配置，基礎映象從 1.63GB 減少到 300MB。

Anolis OS 倉庫：

3.1.2 Dockerfile 最佳化

透過 Dockerfile 編寫約束、映象檢測等手段減少不必要的構建資源和時間。

Dockerfile 最 佳實踐原則：

https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

3.1.3 並行構建和構建快取

螞蟻構建中心採用 Nydus 社群最佳化版的 BuildKit [2]，BuildKit 支援 layer 級別快取，準確引用先前的產出物並進行快取匹配，使用方法與普通映象並無區別，對於 Multistage 型別 Dockerfile，BuildKit 可以實現不同 stage 之間的並行執行。

3.2 推送到雲上映象倉庫耗時長

3.2.1 使用 Nydus 映象進行塊級別資料去重

傳統 OCI 映象，不同映象之間可以共享的最小單位是映象中的層，在 deduplication 上的效率是非常低的，層內部存在重複的資料，層與層之間可能存在大量重複的資料，即使有微小的差別，也會被作為不同的層。根據 OCI Image Spec 對刪除檔案和 Hard Link 的設計，一個映象內部可能存在已經被上層刪除的檔案仍然存在於下層中，幷包含在映象中。另外 OCI Image 使用了 tar+gzip 格式來表達映象中的層，而 tar 格式並不區分 tar archive entries ordering，這帶來一個問題即如果使用者在不同機器上 build 去同一個映象，最終可能會因為使用了不同的檔案系統而得到不同的映象，但若干不同映象的實質內容是完全相同的情況，導致上傳下載資料量飆增。

OCIv1 存在的問題與 OCIv2 提案：

Nydus 映象檔案以檔案 Chunk 為粒度分割，扁平化後設資料層（移除中間層），每一個 Chunk 在映象中只會儲存一次，可指定 Base Image , 用作其他 Nydus Image 的 Chunk dictionary，基於 Chunk level deduplication 提供了在不同映象之間低成本的 data 去重能力，大大降低了映象的上傳和下載資料量。

（圖/Nydus 映象塊共享）

如上圖 Nydus 映象 1 和映象 2 存在相同的資料塊 B2、C、E1、F，映象 2 新增 E2、G1、H1、H2，如果映象倉庫已經存在映象 1，那麼映象 2 可以基於映象 1 進行映象構建，僅需要將 E2、G1、H1、H2 構建在一層，在上傳的時候僅需要將這一層上傳到映象倉庫，達到僅檔案差異上傳、拉取的效果，縮短研發週期。

3.2.2 直接構建雲上 Nydus 映象

目前在大多數加速映象的落地場景中，加速映象的生產都是基於映象轉換的。目前落地的 Nydus 轉換方案主要為以下三種：

i. 映象倉庫轉換

普通映象構建完成並 push 到映象倉庫後，觸發映象倉庫的轉換動作，完成映象轉換。這種方案的缺點在於，構建和轉換往往在不同機器上進行。映象構建並 push 後，還需要 pull 到轉換機並將產出 push 到映象倉庫，需要增加一次完整的映象流轉過程，延遲較高，而且還佔用映象倉庫的網路資源。在加速映象轉換完成前，應用釋出並無法享受加速效果，仍需要完整 pull 映象。

ii. 雙版本構建

在普通映象構建完成後，在構建機本地直接轉換。為提高效率，可以在每層構建完成後即開始對該層進行轉換，加速映象生成延遲可以大幅降低。這個方案，無需等待普通映象上傳即可開始轉換，而且在本地轉換，相比較方案 1，可以省掉的轉換機映象傳輸的開銷。如果基礎映象對應的加速映象不存在，則將其轉換出來；如果存在，pull 可以忽略不計，但是無可避免的是 push 總是需要雙份。

iii. 直接構建

上述兩種基於轉換的方案，與直接構建 Nydus 加速映象相比，都有明顯的生產延遲。一是基於 OCI 的映象構建速度明顯慢於 Nydus 映象構建；二是轉換是事後行為，都存在或多或少的滯後；三是都存在額外的資料傳輸。而直接構建，流程少，速度快，又節約資源：

可以看出，加速映象構建，步驟明顯減少，資料傳輸量明顯減少，構建完成後即可直接享受加速映象的能力，應用釋出速度可以大幅提升。

3.3 映象啟動慢

3.3.1 Nydus 映象按需載入

在容器啟動時，容器內業務 IO 請求哪些檔案的資料，再從遠端 Registry 拉取這些資料，這樣避免映象大量資料拉取阻塞容器的啟動，映象的資料的實際使用率是很低的，比如 Cern 的這篇論文 [3]中就提到，一般映象只有 6% 的內容會被實際用到。按需載入的目的是讓容器執行時有選擇地從 Blob 中的映象層（layer）下載和提取檔案，但 OCI [4]/ Docker [5]映象規範將所有的映象層打包成一個 tar 或 tar.gz 存檔，這樣即使你要提取單個檔案也要掃描整個 Blob。如果映象使用 gzip 進行壓縮，就更沒有辦法提取特定檔案了。

（圖/Nydus 映象格式）

RAFS 映象格式 [6] 是 Nydus 提出的存檔壓縮格式。其中將容器映象檔案系統的資料（Blobs）和後設資料（Bootstrap）分離，讓原來的映象層只儲存檔案的資料部分。並且把檔案以 Chunk 為粒度分割，每層 Blob 儲存對應的 Chunk 資料；因為採用了 Chunk 粒度，這細化了去重粒度，Chunk 級去重讓層與層之間，映象與映象之間共享資料更容易，也更容易實現按需載入。原來的映象層只儲存檔案的資料部分（也就是圖中的 Blob 層）。Blob 層儲存的是檔案資料的切塊（Chunk），例如將一個 10MB 的檔案，切割成 10 個 1MB 的塊，於是就可以將 Chunk 的 Offset 記錄在一個索引中，容器在請求檔案的部分資料時，透過結合 OCI/Docker 映象倉庫規範支援的 HTTP Range Request，容器執行時可以有選擇地從映象倉庫中獲取檔案，如此一來節省不必要的網路開銷。關於 Nydus 映象格式的更多細節，請參考 Nydus Image Service 專案[7]。

後設資料和 Chunk 的索引加在一起，就組成了上圖中的 Meta 層，它是所有映象層堆疊後容器能看到的整個 Filesystem 結構，包含目錄樹結構，檔案後設資料，Chunk 資訊（塊的大小和偏移量，以及每個檔案的後設資料（名稱、檔案型別、所有者等））。有了 Meta 之後，就可以在不掃描整個存檔檔案的情況下提取需要的檔案。另外，Meta 層包含了 Hash 樹以及 Chunk 資料塊的 Hash，以此來保證我們可以在執行時對整顆檔案樹校驗，以及針對某個 Chunk 資料塊做校驗，並且可以對整個 Meta 層簽名，以保證執行時資料被篡改後依然能夠被檢查出來。

（圖/Nydus 按需載入）

Nydus 預設使用使用者態檔案系統實現 FUSE [8] 來做按需載入，使用者態的 Nydus Daemon 程式將 Nydus 映象掛載點作為容器 RootFS 目錄，當容器產生 read(fd,count) 之類的檔案系統 IO 時，核心態 FUSE 驅動將該請求加入處理佇列，使用者態 Nydus Daemon 透過 FUSE Device 讀取並處理該請求，從遠端 Registry 拉取 Count 對應數量的 Chunk 資料塊後，最終透過核心態 FUSE 回覆給容器。Nydus 還實現了一層本地 Cache，已經從遠端拉取的 Chunk 會解壓縮後快取在本地，Cache 可以做到以層為單位在映象之間共享，也可以做到 Chunk 級別的共享。

（圖/從 Pod 建立到容器啟動）

利用 Nydus 做映象加速後，不同應用的啟動時間都有了質的飛躍，能夠在非常短的時間內拉起應用，滿足雲上快速伸縮的要求。

3.3.2 只讀檔案系統 EROFS

當容器映象中存在大量檔案時，頻繁的檔案操作會產生大量的 FUSE 請求，造成核心態/使用者態上下文的頻繁切換，造成效能瓶頸； 龍蜥社群設計並實現了相容核心原生 EROFS 檔案系統的 Nydus RAFS（Registry Acceleration File System） v6 格式，相比於此前的格式，它具備塊資料對齊，後設資料更加精簡，高可擴充套件性與高效能等優勢。在映象資料全部下載到本地的情況下，FUSE 使用者態方案會導致訪問檔案的程式頻繁陷出到使用者態，並涉及核心態/使用者態之間的記憶體複製，更進一步支援了 EROFS over FS-Cache 方案（Linux 5.19-rc1），當使用者態 Nydusd 從遠端下載 Chunk 後會直接寫入 FS-Cache 快取，之後容器訪問時，能夠直接透過核心態 FS-Cache 讀取資料，而無需陷出到使用者態，在容器映象的場景下實現幾乎無損的效能和穩定性，其按需載入階段表現類似 FUSE 使用者態實現，按需載入結束後與原生檔案系統的效能相近，優於 FUSE 使用者態實現。

（圖/不同檔案系統方案按需載入階段對比）

目前 Nydus 在構建，執行，核心態（Linux 5.19-rc1）均已支援了該方案，龍蜥社群的 Anolis OS 7、Anolis OS 8 核心也都支援了 RAFS v6，詳細用法可以參見 Nydus EROFS FS-Cache user guide [9]，另外想了解更多 Nydus 核心態實現細節，可以參見 Nydus 映象加速之核心演進之路。

（圖/Nydus 核心實現細節）

3.3.3 Dragonfly P2P 加速映象下載

不論是映象倉庫服務本身還是背後的儲存，最終肯定是有頻寬和 QPS 限制的。如果單純依賴服務端提供的頻寬和 QPS，很容易就無法滿足需求。因此需要引入 P2P，減輕服務端壓力，進而滿足大規模併發拉取映象的需求。在大規模拉映象的場景下，在使用 Dragonfly&Nydus 場景對比 OCIv1 場景能夠節省 90% 以上的容器啟動時間。

（圖/Dragonfly P2P 映象加速拉取）

使用 Nydus 之後啟動時間更短是因為映象 Lazyload 的特性，只需要拉取很小的一部分後設資料 Pod 就能啟動。在大規模場景下，使用 Dragonfly 回源拉取映象的數量很少。OCIv1 的場景所有的映象拉取都要回源，因此使用 Dragonfly 回源峰值和回源流量相比 OCIv1 的場景少很多。並且使用 Dragonfly 後隨著併發數提高，回源峰值和流量不會顯著提高。

（圖/1G 大小的隨機檔案測試）

3.4 叢集伸縮時間長

3.4.1 ACR 映象倉庫全球同步

為了滿足客戶優質的體驗以及資料合規需求，需要就近接入，因此 ZOLOZ 在全球多個站點進行雲上部署。藉助 ACR 映象倉庫進行跨境同步加速，全球多地域間同步，提高容器映象分發效率。上傳和下載映象都在本區域機房內進行，特別是在一些網路不太好的國家內，也能夠像本地機房一樣進行部署，真正做到應用的一鍵部署到全球各地。

3.4.2 採用 ContainerOS 極速啟動

藉助雲原生滿足客戶急速增長資源擴容，利用彈性降低成本，在雲上需要極速伸縮虛擬機器，並將其加入到叢集內部。阿里雲 ACK 基於 龍蜥的 LifseaOS，構建了全託管節點池的容器最佳化 OS 映象 ContainerS。ContainerOS 透過簡化 OS 啟動流程，預置叢集管控必備元件的容器映象以減少節點啟動過程中因映象拉取而帶來的耗時，極大地提高了 OS 啟動速度，降低了 ACK 鏈路中的節點擴容時間。ContainerOS 從如下幾個方面進行了最佳化：

• ContainerOS 透過簡化 OS 啟動流程，有效降低 OS 啟動時間。ContainerOS 的定位是跑在雲上虛擬機器的作業系統，不會涉及到太多的硬體驅動，因此 ContainerOS 將必要的核心驅動模組修改為 built-in 模式。此外，ContainerOS 去除了 initramfs，且 udev 規則也被大大簡化，此時 OS 啟動速度得到了大幅提升。以 ecs.g7.large 規格的 ECS 例項為例，LifseaOS 的首 次啟動時間保持在 2s 左右，而 Alinux3 則需要 1min 以上。

• ContainerOS 透過預置叢集管控必備元件的容器映象以減少節點啟動過程中因映象拉取而帶來的耗時。ECS 節點啟動完成後需要拉取部分元件的容器映象，這些元件負責在 ACK 場景下執行一些基礎性的工作。例如 Terway 元件負責網路，節點必須在 Terway 元件的容器就緒的情況下才能轉換為就緒狀態。因此，既然網路拉取的長尾效應會帶來極大的耗時，那麼可以透過預置的方式提前將此元件提前安裝在 OS 內部，此時可直接從本地目錄獲取，避免網路拉取映象耗時。

• ContainerOS 也會透過結合 ACK 管控鏈路最佳化，提高節點彈性效能。

最終，統計了從空的 ACK 節點池擴容的端到端的 P90 耗時，從下發擴容請求開始計時，到 90% 的節點處於就緒狀態結束計時，並對比了 CentOS、Alinux2 Optimized-OS [10] 方案，ContainerOS 效能優勢明顯，具體資料如下圖所示。

（圖/ecs.c6.xlarge 併發啟動資料）

3.5 整體鏈路

（圖/ZOLOZ 公有云應用部署整體方案）

• 透過精簡基礎映象以及遵循 Dockerfile 規約，對映象大小進行精簡。

• 利用螞蟻託管的 BuildKit 對映象進行 Multistage 並行構建，在重複構建時採用快取加快映象構建。直接構建 Nydus 加速映象時透過映象之間重複分析進行去重，僅上傳映象之間差異的塊到遠端映象倉庫。

• 透過 ACR 全球加速同步的能力，將映象分發到全球不同的映象倉庫中，進行就近拉取。

• 透過 Dragonfly P2P 網路對 Nydus 映象塊進行按需加速拉取。

• 節點上使用 ContainerOS 作業系統，提高 OS 啟動速度以及映象啟動速度。

（圖/容器研發流程）

（圖/以 3G 映象為例）

*排程時間：該時間是指從阿里雲建立一臺 ECS，到節點加入到 K8s 叢集並 Ready 的時間，得益於 ContainerOS 的最佳化，該耗時降低非常明顯。

透過對研發全流程各個環節進行極 致的最佳化，可以發現最佳化後，研發效率和線上穩定性都得到了質的提升，目前整套方案已經在阿里雲和 AWS 都完成了部署，線上穩定執行 3 個月，未來將在雲廠商提供標準的部署環境，滿足更多型別的業務場景。

04 使用指南

4.1 映象構建

程式碼資產都在螞蟻域內，利用螞蟻映象構建中心託管的 BuildKit 叢集，透過自定義的 ACI 元件進行構建 Nydus 映象。

映象構建:
  stage: 映象構建
  id: build-image
  component: nydus-image-build
  inputs:
    imageName: ${{parameters.imageName}} #構建的映象 name
    imageTag: ${{vcs.commitSha}} # 構建的映象 tag，這裡的 ${{vcs.commitSha}} 是 ACI 內建引數
    dockerfile: Dockerfile # dockerfile檔案位置（預設相對程式碼根目錄）
    chunkDictImage: ${{parameters.chunkDictImage}}
    timeoutInSec: 1200

可以指定 Chunk Dict Image 按 Chunk 去重粒度，如果構建的映象和 Chunk Dict Image。Image Name 可以直接指定阿里雲 ACR 倉庫，構建的 Nydus 映象直接推送到雲上，減少映象中轉耗時。

4.2 Dragonfly 安裝

$ helm repo add dragonfly 
$ helm install --wait --timeout 10m --dependency-update --create-namespace --namespace dragonfly-system dragonfly dragonfly/dragonfly --set dfdaemon.config.download.prefetch=true,seedPeer.config.download.prefetch=true
NAME: dragonfly
LAST DEPLOYED: Fri Apr  7 10:35:12 2023
NAMESPACE: dragonfly-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
1. Get the scheduler address by running these commands:
  export SCHEDULER_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l "app=dragonfly,release=dragonfly,component=scheduler" -o jsonpath={.items[0].metadata.name})
  export SCHEDULER_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $SCHEDULER_POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  kubectl --namespace dragonfly-system port-forward $SCHEDULER_POD_NAME 8002:$SCHEDULER_CONTAINER_PORT
  echo "Visit 
2. Get the dfdaemon port by running these commands:
  export DFDAEMON_POD_NAME=$(kubectl get pods --namespace dragonfly-system -l "app=dragonfly,release=dragonfly,component=dfdaemon" -o jsonpath={.items[0].metadata.name})
  export DFDAEMON_CONTAINER_PORT=$(kubectl get pod --namespace dragonfly-system $DFDAEMON_POD_NAME -o jsonpath="{.spec.containers[0].ports[0].containerPort}")
  You can use $DFDAEMON_CONTAINER_PORT as a proxy port in Node.
3. Configure runtime to use dragonfly:
  

更多詳情參考：

4.3 Nydus 安裝

$ curl -fsSL -o config-nydus.yaml 
$ helm install --wait --timeout 10m --dependency-update --create-namespace --namespace nydus-snapshotter nydus-snapshotter dragonfly/nydus-snapshotter -f config-nydus.yaml
NAME: nydus-snapshotter
LAST DEPLOYED: Fri Apr  7 10:40:50 2023
NAMESPACE: nydus-snapshotter
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
Thank you for installing nydus-snapshotter.
Your release is named nydus-snapshotter.
To learn more about the release, try:
  $ helm status nydus-snapshotter
  $ helm get all nydus-snapshotter

更多詳情參考：

同時，AnolisOS 8 系統中已經整合了 Nydus 相關的包以及工具，您可以在使用 AnolisOS 8 的時候快速使用 Nydus 能力，詳情參考：

4.4 ContainerOS 使用

ContainerOS 基於龍蜥社群的 LifseaOS 專案開發，針對 ACK 叢集節點池的彈性擴容場景，實現了極速擴容的特性。一方面，LifseaOS 透過簡化 OS 本身的啟動流程提高了 OS 啟動速度。它裁剪掉了大量雲上場景無需的硬體驅動，必要的核心驅動模組修改為 built-in 模式，去除了 initramfs，udev 規則也被大大簡化，OS 首 次啟動時間從傳統 OS 的 1min 以上下降到了 2s 左右。另一方面，ContainerOS 結合 ACK 場景進行了定製最佳化。它透過預置叢集管控必備元件的容器映象以減少節點啟動過程中因映象拉取而帶來的耗時，並結合 ACK 管控鏈路最佳化（例如調節關鍵邏輯的檢測頻率、調整高負載下系統瓶頸中的限流值等），極大地提高了節點擴容速度。在阿里雲控制檯上為 ACK 叢集建立託管節點池 [11] 時，在配置選單中可以 選擇 ECS 例項的作業系統，下拉選擇 ContainerOS 即可，OS 映象名字中的 1.24.6 對應的是叢集的 K8s 版本。另外，如果您需要高效能的節點池彈性擴容能力，為了實現最 佳的節點擴容效能，更多資訊請參見使用 ContainerOS 實現節點極速擴容 [12]。

05 注意事項

ContainerOS 目前僅支援 Kubernetes 1.24.6 及以上版本，需要在建立 ACK 叢集，或升級 ACK 叢集的 K8s 版本[13]為 1.24.6 及以上版本方可使用。ContainerOS 預置了影響 Node Ready 和 Pod Ready 的必備的元件，如 Flannel、Terway 等網路外掛。原本節點啟動後需要拉取並啟動這些元件的容器映象，節點才會處於就緒狀態，預置之後便無需從網路上拉取。但是，為了防止叢集的元件版本與預置的元件版本不一致的情況，請參考注意事項[14]。

06 參考資料

—— 完 ——

為給大家提供更好的內容和服務，龍蜥社群誠摯地邀請大家參與問卷調研，請掃描下方二維碼填寫，我們將篩選出優質反饋，送出龍蜥周邊！