螞蟻安全科技 Nydus 與 Dragonfly 鏡像加速實踐

編者按:本文詳細介紹螞蟻安全科技使用龍蜥社區技術進行鏡像加速的實踐過程,可以讓您瞭解如何基於龍蜥社區推出的容器鏡像,Nydus 與 Dragonfly 鏡像加速技術和 LifseaOS 爲容器的啓動加速。文章轉自金融級分佈式架構,以下爲全文:

01 背景簡介

ZOLOZ是龍蜥社區理事單位螞蟻集團旗下的全球安全風控平臺,通過業內領先的生物識別、大數據分析和人工智能技術,爲用戶和機構提供安全又便捷的安全風控解決方案。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 端的壓力。

DragonflyDragonfly 是⼀款基於 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 倉庫:https://hub.docker.com/r/openanolis/anolisos/tags

3.1.2 Dockerfile 優化

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

Dockerfile 最佳實踐原則:https://docs.docker.com/develop/develop-images/dockerfile_best-practices/

3.1.3 並行構建和構建緩存

螞蟻構建中心採用 Nydus 社區優化版的 BuildKit ,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 提案:https://hackmd.io/@cyphar/ociv2-brainstorm

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 的這篇論文中就提到,一般鏡像只有 6% 的內容會被實際用到。按需加載的目的是讓容器運行時有選擇地從 Blob 中的鏡像層(layer)下載和提取文件,但 OCIDocker 鏡像規範將所有的鏡像層打包成一個 tar 或 tar.gz 存檔,這樣即使你要提取單個文件也要掃描整個 Blob。如果鏡像使用 gzip 進行壓縮,就更沒有辦法提取特定文件了。

(圖/Nydus 鏡像格式)

RAFS 鏡像格式是 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 項目

元數據和 Chunk 的索引加在一起,就組成了上圖中的 Meta 層,它是所有鏡像層堆疊後容器能看到的整個 Filesystem 結構,包含目錄樹結構,文件元數據,Chunk 信息(塊的大小和偏移量,以及每個文件的元數據(名稱、文件類型、所有者等))。有了 Meta 之後,就可以在不掃描整個存檔文件的情況下提取需要的文件。另外,Meta 層包含了 Hash 樹以及 Chunk 數據塊的 Hash,以此來保證我們可以在運行時對整顆文件樹校驗,以及針對某個 Chunk 數據塊做校驗,並且可以對整個 Meta 層簽名,以保證運行時數據被篡改後依然能夠被檢查出來。

(圖/Nydus 按需加載)

Nydus 默認使用用戶態文件系統實現 FUSE 來做按需加載,用戶態的 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 ,另外想了解更多 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 方案,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 https://dragonflyoss.github.io/helm-charts/
$ 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 http://127.0.0.1:8002 to use your scheduler"
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:
  https://d7y.io/docs/getting-started/quick-start/kubernetes/

更多詳情參考:https://d7y.io/zh/docs/setup/integration/nydus

4.3 Nydus 安裝

$ curl -fsSL -o config-nydus.yaml https://raw.githubusercontent.com/dragonflyoss/Dragonfly2/main/test/testdata/charts/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

更多詳情參考:

https://github.com/dragonflyoss/helm-charts/blob/main/INSTALL.md

同時,AnolisOS 8 系統中已經集成了 Nydus 相關的包以及工具,您可以在使用 AnolisOS 8 的時候快速使用 Nydus 能力,詳情參考:https://openanolis.cn/sig/cloud-native/doc/624244092113272868?lang=zh

4.4 ContainerOS 使用

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

05 注意事項

ContainerOS 目前僅支持 Kubernetes 1.24.6 及以上版本,需要在創建 ACK 集羣,或升級 ACK 集羣的 K8s 版本爲 1.24.6 及以上版本方可使用。ContainerOS 預置了影響 Node Ready 和 Pod Ready 的必備的組件,如 Flannel、Terway 等網絡插件。原本節點啓動後需要拉取並啓動這些組件的容器鏡像,節點纔會處於就緒狀態,預置之後便無需從網絡上拉取。但是,爲了防止集羣的組件版本與預置的組件版本不一致的情況,請參考注意事項

06 參考資料

文/螞蟻集團 ZOLOZ 團隊

原文鏈接

本文爲阿里雲原創內容,未經允許不得轉載。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章