作者 |陳博
來源 |
阿裡巴巴雲原生公衆号近日阿裡巴巴開源了其
雲原生容器鏡像加速技術，它推出的 overlaybd 鏡像格式，相比于傳統的分層 tar 封包件格式，實作了基于網絡的按需讀取，進而使得容器可以快速啟動。
該技術方案原本是阿裡雲内部 DADI 項目的一部分， DADI 是 Data Accelerator for Disaggregated Infrastructure 的縮寫，旨在為計算存儲分離架構提供各種可能的資料通路加速技術。鏡像加速是 DADI 架構在容器及雲原生領域的一次突破性嘗試，該技術自 2019 年投産以來，已線上上部署了大量機器，累計啟動容器次數超過 10 億，支援了阿裡巴巴集團及阿裡雲的多個業務線，極大提高了應用的釋出和擴容效率。2020 年，團隊在國際頂級會議發表了論文"DADI: Block-Level Image Service for Agile and Elastic Application Deployment. USENIX ATC'20"[1]，并随後啟動了開源項目，計劃将技術該貢獻給社群，通過建立标準并打造生态，吸引更多的開發者投入到容器及雲原生性能優化這個領域上來。
背景簡介
随着 Kubernetes 和雲原生的大爆發，容器在企業内部的大規模應用已經越來越廣泛。部署啟動快是容器的核心優勢之一，這個啟動快是指本地鏡像執行個體化的時間非常短，即“熱啟動”時間短。然而對于“冷啟動”，即在本地無鏡像的情況下，需要先從 Registry 下載下傳鏡像才能建立容器。業務的鏡像經過長期維護和更新，無論是鏡像層數還是整體大小都會達到一個較大的量級，比如可能達到數百 MB 或者幾個 GB。是以生産環境中，容器的冷啟動往往耗時數分鐘，并且随規模擴大會導緻 Registry 因叢集内網絡擁堵而無法快速地下載下傳鏡像。
例如，在之前某年的雙十一活動中，阿裡内部一個應用因為容量不足觸發緊急擴容，但因并發量過大，整體擴容耗時較長，這期間對部分使用者的使用體驗造成了影響。而到了 2019 年，随着 DADI 的部署上線，新鏡像格式的容器在“鏡像拉取+容器啟動”上耗費的總時間比普通容器縮短了 5 倍，且 p99 長尾時間更是比後者快了 17 倍。
如何處理存儲在遠端的鏡像資料，這是解決容器冷啟動慢這個問題的核心點。曆史上業界對這一問題做出的嘗試有：使用塊存儲或者NAS儲存容器鏡像，實作按需讀取；使用基于網絡的分發技術（如 p2p），将鏡像從多個源頭下載下傳、或者提前預熱到主機上，避免出現網絡單點瓶頸。近年來，針對新鏡像格式的讨論也逐漸被提上議題，根據 Harter 等人的
研究表明，拉取鏡像占用了容器啟動時間的 76%，而隻有 6.4% 的時間用來讀取資料。是以，支援 On-demand Read 技術的鏡像，已經成為預設的潮流風向。Google 提出的
stargz格式，其全稱是 Seekable tar.gz，顧名思義，可以有選擇地從存檔中搜尋并提取特定的檔案，無需掃描或者解壓整個鏡像。stargz 旨在提高鏡像拉取的性能，其延遲拉取技術（lazy-pull）不會拉取整個鏡像檔案，實作了按需讀取。為了進一步提高運作時效率，stargz 又推出了一個 containerd 的 snapshotter 插件，在存儲層面對 I/O 做了進一步優化。
在容器的生命周期中，鏡像就緒後需要挂載（mount），而分層鏡像挂載的核心技術便是 overlayfs，它以一種堆疊的形式将下層的多個 layer 檔案合并，并向上暴露出一個統一的隻讀檔案系統。類比上文提到的塊存儲和 NAS，一般可以通過快照的形式進行分層堆疊，而跟 stargz 綁定的 CRFS，也可以看做是 overlayfs 的另一種實作。
新鏡像格式
DADI 沒有直接使用 overlayfs，或者說，它隻是借鑒了 overlayfs 和早期聯合檔案系統（union filesystem）的思想，但提出了一種全新的基于塊裝置的分層堆疊技術，稱之為 overlaybd，它為容器鏡像提供了一系列基于塊的合并資料視圖。overlaybd 的實作十分簡單，是以很多之前想做而不能做的事都可以成為現實；而實作一個完全 POSIX 相容的檔案系統接口則充滿挑戰，并可能存在 bug，這點從各個主流檔案系統的發展曆史上就可以看出。
除了簡單以外，overlaybd 對比 overlayfs 的其他優點有：
- 避免多層鏡像導緻的性能下降，如 overlayfs 模式下大檔案的更新會觸發跨層引用複制，系統必須先将檔案複制到可寫層；或者建立硬連結速度很慢等問題。
- 可以友善地采集 block 級别的 I/O 模式，進行錄制以及重放，進而預取資料，進一步加速啟動。
- 使用者的檔案系統和主控端 OS 可以靈活選擇，如支援 Windows NTFS。
- 可以使用有效的編解碼器進行線上解壓縮。
- 可以下沉到雲中的分布式存儲（如 EBS）中，鏡像系統盤可以跟資料盤使用同一套存儲方案。
- overlaybd 具有天然的可寫層支援（RW），隻讀挂載甚至可以成為曆史。
overlaybd 原理
為了了解 overlaybd 的原理，首先需要了解容器鏡像的分層機制。容器鏡像由多個增量 layer 檔案組成，在使用時進行疊加，這樣在鏡像分發時隻需要對 layer 檔案進行分發。每一層實質上都是與上一層的差異（包括檔案的添加，修改或删除）的壓縮包。容器引擎可以通過其 storage driver，按照約定的方式将差異疊加起來，然後以 Read-Only 的模式挂載到指定目錄，該目錄即稱為 lower_dir；而以 Read/Write 模式挂載的可寫層，挂載目錄則一般稱為 upper_dir。
請注意，overlaybd 本身沒有檔案的概念，它隻是将鏡像抽象為虛拟塊裝置，并在其上裝載正常的檔案系統。當使用者應用讀取資料時，該讀取請求首先由正常的檔案系統處理，将請求轉換為虛拟塊裝置的一次或多次讀取。這些讀取請求會被轉發到使用者态的接收程式，即 overlaybd 的運作時載體，最後轉換為對一個或多個 layer 的随機讀取。
與傳統鏡像一樣，overlaybd 在内部仍然保留着 layer 分層的結構，但每層的内容都是檔案系統變更差異對應的一系列 data block。overlaybd 向上提供了一個合并視圖，對 layer 的疊加規則很簡單，即對于任意一個 data block，總是使用最後的變更，在 layer 中未發生變更的塊均視為全零塊；向下又提供了将一系列 data block 導出成一個 layer 檔案的功能，該檔案高密度非稀疏、且可索引。是以，對塊裝置某個連續 LBA 範圍進行讀操作，可能包含了原本屬于多層的小塊資料段，我們将這些小塊資料段稱為 segment。從 segment 的屬性中找到層号，便能夠繼續映射到對這層的 layer 檔案的讀取上來。傳統的容器鏡像可以将它的 layer 檔案儲存在 Registry 或者對象存儲上，那麼 overlaybd 鏡像自然也可以。
為了更好的相容性，overlaybd 在 layer 檔案的最外層，包裝了一層 tar 檔案的頭和尾，這樣僞裝成一個 tar 檔案。由于 tar 内部僅一個檔案，不影響按需讀取。目前無論是 docker、containerd 或者 buildkit，對鏡像的下載下傳或上傳預設都有 untar 和 tar 的流程，不侵入代碼是無法逾越的，是以增加 tar 僞裝有利于相容性和流程的統一，例如在鏡像轉換、建構、或者全量下載下傳使用時，都無需修改代碼，隻需提供插件即可。
整體架構
DADI 整體架構如圖，以下分别介紹各個元件：
1. containerd snapshotter
containerd 自 1.4 版起，開始初步支援一些啟動遠端鏡像的功能，并且 K8s 已經明确将放棄 Docker 作為運作時的支援。是以 DADI 開源版本選擇優先支援 containerd 生态，之後再支援 Docker。
snapshotter 的核心功能是實作抽象的服務接口，用于容器 rootfs 的挂載和解除安裝等操作。它的設計替代了在 Docker 早期版本稱之為 graphdriver 的子產品，使得存儲驅動更加簡化，同時相容了塊裝置快照與 overlayfs。
DADI 提供的 overlaybd-snapshotter 一方面能讓容器引擎支援新的 overlaybd 格式的鏡像，即将虛拟塊裝置挂載到對應的目錄，另一方面也相容傳統 OCI tar 格式鏡像，讓使用者繼續以 overlayfs 運作普通容器。
2. iSCSI target
iSCSI 是一種被廣泛支援的遠端塊裝置協定，穩定成熟性能高，遇到故障可恢複。overlaybd 子產品作為 iSCSI 協定的後端存儲，即使程式意外 crash，重新拉起即可恢複。而基于檔案系統的鏡像加速方案，例如 stargz，則無法恢複。
iSCSI target 是 overlaybd 的運作時載體。在本項目中，我們實作了兩種 target 子產品：第一種是基于開源項目
tgt，由于其擁有 backing store 機制，可以将代碼編譯成動态連結庫以便運作時加載；第二種是基于 Linux 核心的
LIO SCSI target（又稱為 TCMU），整個 target 運作在核心态，可以比較友善地輸出虛拟塊裝置。
3. ZFile
ZFile 是我們提供的一種支援線上解壓的資料壓縮格式。它将源檔案按固定大小的 block size 切分，各資料塊進行單獨壓縮，同時維護一個 jump table，記錄了各資料塊在 ZFile 中的實體偏移位置。如需從 ZFile 中讀資料，隻要查找索引找到對應位置，并僅解壓縮相關的 data block 即可。
ZFile 支援各種有效的壓縮算法，包括 lz4，zstd 等，它解壓速度極快，開銷低，可以有效節省存儲空間和資料傳輸量。實驗資料表明，按需解壓遠端的 ZFile 資料，性能高于加載非壓縮資料，這是因為傳輸節省的時間，大于解壓的額外開銷。
overlaybd 支援将 layer 檔案導出成 ZFile 格式。
4. cache
正如上文所說，layer 檔案儲存在 Registry 上，容器對塊裝置的讀 I/O 會映射到對 Registry 的請求上（這裡利用到了 Registry 對 HTTP Partial Content 的支援）。但是由于 cache 機制的存在，這種情形不會一直存在。cache 會在容器啟動後的一段時間後自動開始下載下傳 layer 檔案，并持久化到本地檔案系統。如果 cache 命中，則讀 I/O 就不會再發給 Registry，而是讀本地。
行業領先
3 月 25 日，權威咨詢機構 Forrester 釋出 2021 年第一季度 FaaS 平台（Function-As-A-Service Platforms）評估報告，阿裡雲憑借産品能力全球第一的優勢脫穎而出，在八個評測次元中拿到最高分，成為比肩亞馬遜 AWS 的全球 FaaS 上司者。這也是
首次有國内科技公司進入 FaaS 上司者象限。
衆所周知，容器是 FaaS 平台的承載基礎，而容器啟動速度更是決定了整個平台的性能與響應延遲。DADI 助力阿裡雲函數計算産品，
大幅度縮短容器啟動時間 50%~80%，帶來了全新的 Serverless 使用體驗。
總結展望
阿裡巴巴開源的 DADI 容器加速項目以及其推出的 overlaybd 鏡像格式，有助于應對新時代下容器對快速啟動的需求。項目組未來将協同社群一起，加快對接主流工具鍊，積極參與新鏡像格式标準制定，目标是讓 overlaybd 成為 OCI 遠端鏡像格式的标準之一。
歡迎大家參與開源項目，一起貢獻力量！
後續工作
1. Artfacts Manifest
OCI Image 的 v1 Manifest 格式描述能力有限，無法滿足遠端鏡像需求。目前 v2 的讨論沒有實質進展，推翻 v1 也不現實。但是，可以借助 OCI Artfacts Manifest 使用 Additional Descriptor 來描述原始資料，相容性上有所保證，使用者更容易接受。Artfacts 也是 OCI/CNCF 在推廣的項目，DADI 未來計劃擁抱 Artfacts 并實作 PoC。
2. 開放對多種檔案系統的支援
DADI 本身支援使用者根據需要選擇合适的檔案系統來建構鏡像，但是目前尚未開放相應的接口，預設使用了 ext4 檔案系統。我們未來将完善相關接口并放開此功能，由使用者根據自身需要，決定使用什麼檔案系統。
3. Buildkit 工具鍊
目前使用者可以通過 buildkit 外挂 snapshotter 來建構鏡像，未來将進一步完善，形成完整工具鍊。
4. 資料領取
在容器啟動後對 I/O 模式進行記錄，後續啟動同一鏡像時便可以重放該記錄，對資料進行預取，避免臨時請求 Registry，這樣容器的冷啟動時間将繼續縮短一半以上。理論上所有無狀态或幂等容器都可以進行錄制和重放。