知道嗎？容器鏡像也可以延遲拉取！

在容器的整個(gè)生命周期中，拉取鏡像是最耗時(shí)的步驟之一。Harter 等人的研究^[1]表明：

拉取鏡像占用了容器啟動(dòng)時(shí)間的 76%，只有 6.4% 的時(shí)間用來讀取數(shù)據(jù)。

這個(gè)問題一直困擾著各類工作負(fù)載，包括 serverless 函數(shù)的冷啟動(dòng)時(shí)間，鏡像構(gòu)建過程中基礎(chǔ)鏡像的拉取等。雖然有各種折中的解決方案，但這些方案都有缺陷：

• 緩存鏡像 : 冷啟動(dòng)時(shí)仍然有性能損失。
• 減小鏡像體積 : 無法避免某些場景需要用到大體積的鏡像，比如機(jī)器學(xué)習(xí)。

現(xiàn)在有一個(gè)更通用的解決方案，該方案完全兼容 OCI 標(biāo)準(zhǔn)，目前看來是比較理想的方案。

1. Containerd Stargz Snapshotter

Containerd 為了解決這個(gè)問題啟動(dòng)了一個(gè)非核心子項(xiàng)目 **Stargz Snapshotter**^[2]，旨在提高鏡像拉取的性能。該項(xiàng)目作為 Containerd 的一個(gè)插件，利用 Google 的 stargz 鏡像格式^[3]來延遲拉取鏡像。這里的延遲拉取指的是 Containerd 在拉取時(shí)不會(huì)拉取整個(gè)鏡像文件，而是按需獲取必要的文件。

下圖是基于 HelloBench^[4] 的容器啟動(dòng)過程基準(zhǔn)測試結(jié)果，跑在 Github Actions 提供的機(jī)器上，鏡像倉庫直接使用 Docker Hub^[5]：

• legacy 表示使用 Containerd 默認(rèn)的 snapshotter（overlayfs）來拉取鏡像且不進(jìn)行優(yōu)化時(shí)的啟動(dòng)性能，這種情況下 Containerd 會(huì)拉取整個(gè)鏡像內(nèi)容，所以拉取時(shí)間會(huì)很長。
• 而對于 stargz 格式的鏡像，Containerd 可以在鏡像還沒有完全拉取到本地之前就啟動(dòng)容器，然后按需獲取需要的文件，所以拉取的時(shí)間更短。但讀取文件時(shí)需要從遠(yuǎn)程倉庫下載文件內(nèi)容，所以 run 的性能要低于傳統(tǒng)的拉取方式。
• 如果使用進(jìn)一步優(yōu)化的鏡像格式 estargz，可以在拉取時(shí)間短的基礎(chǔ)上提高 run 的性能。

Stargz snapshotter 的特點(diǎn)：

兼容 OCI 標(biāo)準(zhǔn)

Stargz snapshotter 可以從符合 OCI^[6]/Docker^[7] 鏡像倉庫標(biāo)準(zhǔn)的鏡像倉庫中延遲拉取 stargz 鏡像，拉取到的 stargz 鏡像也符合 OCI^[8]/Docker^[9] 鏡像規(guī)范，所以任何容器運(yùn)行時(shí)都可以運(yùn)行。

支持私有鏡像倉庫

Stargz snapshotter 支持基于文件 ~/.docker/config.json 的認(rèn)證，也支持基于 Kubernetes Secret 的認(rèn)證。

支持 Kubernetes

它也可以作為 Containerd 的 CRI 插件^[10]，所以 Kubernetes 也可以使用。

2. 使用指南

要想在 Kubernetes 中使用 stargz snapshotter，需要在每個(gè)節(jié)點(diǎn)上運(yùn)行一個(gè)守護(hù)進(jìn)程，然后將其配置為 Containerd 的插件。同時(shí)需要確保 Containerd 的 commit 版本不低于 d8506bf^[11]。所需的 Containerd 配置文件（/etc/containerd/config.toml）內(nèi)容如下：

version = 2

# Plug stargz snapshotter into containerd
# Containerd recognizes stargz snapshotter through specified socket address.
# The specified address below is the default which stargz snapshotter listen to.
[proxy_plugins]
  [proxy_plugins.stargz]
    type = "snapshot"
    address = "/run/containerd-stargz-grpc/containerd-stargz-grpc.sock"

# Use stargz snapshotter through CRI
[plugins."io.containerd.grpc.v1.cri".containerd]
  snapshotter = "stargz"

然后就可以創(chuàng)建 stargz 格式的 Pod 了，例如：

apiVersion:?v1
kind:?Pod
metadata:
??name:?nodejs
spec:
??containers:
??-?name:?nodejs-stargz
????image:?stargz/node:13.13.0-esgz
????command:?["node"]
????args:
????-?-e
????-?var?http?=?require('http');
??????http.createServer(function(req,?res)?{
????????res.writeHead(200);
????????res.end('Hello?World!\n');
??????}).listen(80);
????ports:
????-?containerPort:?80

該 Pod 使用了可以從 Docker Hub 中延遲拉取的鏡像 stargz/node:13.13.0-esgz 來取代官方的鏡像 library/node:13.13.0。

3. 實(shí)現(xiàn)原理

Stargz snapshotter 是由多種技術(shù)組合而成的，本節(jié)只介紹其中三種技術(shù)：

stargz 壓縮格式

延遲拉取的目的是讓容器運(yùn)行時(shí)有選擇地從 blob 中的鏡像層（layer）下載和提取文件，但 OCI^[12]/Docker^[13] 鏡像規(guī)范將所有的鏡像層打包成一個(gè) tar 或 tar.gz 存檔，這樣即使你要提取單個(gè)文件也要掃描整個(gè) blob。如果鏡像使用 gzip 進(jìn)行壓縮，就更沒有辦法提取特定文件了。

Stargz^[14] 是谷歌提出的存檔壓縮格式，是 Seekable tar.gz 的縮寫，顧名思義，可以有選擇地從存檔中搜尋并提取特定的文件，無需掃描整個(gè)鏡像 blob。關(guān)于 Stargz 鏡像格式的更多細(xì)節(jié)，請參考 CRFS 項(xiàng)目^[15]。通過結(jié)合 OCI^[16]/Docker^[17] 鏡像倉庫規(guī)范支持的 HTTP Range Request，容器運(yùn)行時(shí)可以有選擇地從鏡像倉庫中獲取文件。

在 stargz 存檔中，每個(gè) tar 條目都被壓縮成 gzip 格式，stargz 是所有 gzip 的組合，仍然是有效的 gzip，所以任何容器運(yùn)行時(shí)都可以像對待傳統(tǒng)的 tar.gz 鏡像層一樣對待 stargz 鏡像層。對于大文件來說，會(huì)被分成多個(gè) gzip，只包含元數(shù)據(jù)的條目（如符號(hào)鏈接）與相鄰的條目會(huì)壓縮到同一個(gè) gzip 中。

在 gzip 之后還包含一個(gè)名為 TOC 的索引文件條目，這是一個(gè) JSON 文件（stargz.index.json），記錄了 stargz 存檔中每個(gè)文件內(nèi)容對應(yīng)的塊的大小和偏移量，以及每個(gè)文件的元數(shù)據(jù)（名稱、文件類型、所有者等）。有了 TOC 之后，就可以在不掃描整個(gè)存檔文件的情況下提取需要的文件。

stargz 優(yōu)化版

Stargz 雖然提高了拉取性能，但在運(yùn)行階段按需讀取文件時(shí)仍然存在性能缺陷。為了解決這個(gè)問題，stargz snapshotter 做了進(jìn)一步的優(yōu)化。

一般情況下，每個(gè)容器鏡像都是用來運(yùn)行特定的服務(wù)，這些信息在構(gòu)建時(shí)就已經(jīng)定義好了，例如在 Dockerfile 中定義的 entrypoint、環(huán)境變量等等。我們可以根據(jù)這些信息來預(yù)測容器運(yùn)行時(shí)可能需要訪問的文件，在運(yùn)行之前預(yù)取這些文件，從而提高緩存命中率。

stargz snapshotter 項(xiàng)目中的 ctr-remote images optimize 命令提供了對讀取最有可能在運(yùn)行時(shí)訪問的文件性能的優(yōu)化，將這些文件放到相鄰的鏡像層中。具體的做法是在一個(gè)沙箱環(huán)境中運(yùn)行指定的工作負(fù)載，并對所有文件進(jìn)行剖析，篩選出最有可能被訪問的文件，然后按照預(yù)測的訪問順序?qū)ζ溥M(jìn)行排序，并在最后放置一個(gè)標(biāo)志性文件作為結(jié)束。在運(yùn)行容器之前，stargz snapshotter 會(huì)通過單個(gè) HTTP Range Request 預(yù)取和預(yù)緩存這個(gè)范圍的文件，提高緩存命中率，從而減輕運(yùn)行時(shí)的開銷。

遠(yuǎn)程 snapshotter 插件

Containerd 的架構(gòu)是可插拔的，所有的功能是按照定義的 API 以插件的形式實(shí)現(xiàn)的。用戶可以將其與自定義插件集成來擴(kuò)展 Containerd 的功能。例如，AWS Firecracker^[18] 就擴(kuò)展了 Containerd 來支持 microVMs。

Snapshotter 就是 Containerd 的其中一個(gè)插件，它被用來存儲(chǔ)拉取到本地的鏡像層。在拉取鏡像的過程中，Containerd 會(huì)提取其中的鏡像層，并將它們疊加在一起，存儲(chǔ)為為一個(gè)快照（snapshot）。當(dāng) Containerd 啟動(dòng)容器時(shí)，會(huì)向 snapshotter 查詢快照，并將其作為容器的 rootfs。

Containerd 也支持遠(yuǎn)程的 snapshotter，它是 snapshotter 的一個(gè)變體，能夠直接掛載遠(yuǎn)程的鏡像層作為快照（snapshot），無需拉取整個(gè)鏡像層。Stargz snapshotter 也實(shí)現(xiàn)了遠(yuǎn)程 snapshotter。

參考鏈接

• Startup Containers in Lightning Speed with Lazy Image Distribution on Containerd^[19]
• Stargz Snapshotter^[20]

參考資料