鏡像對(duì)容器部署的挑戰(zhàn)

在容器的生產(chǎn)實(shí)踐中，偏小的容器鏡像能夠很快地部署啟動(dòng)。當(dāng)應(yīng)用的鏡像達(dá)到幾個(gè) GB 以上的時(shí)候，在節(jié)點(diǎn)上下載鏡像通常會(huì)消耗大量的時(shí)間。Dragonfly 通過引入 P2P 網(wǎng)絡(luò)有效提升了容器鏡像大規(guī)模分發(fā)的效率。然而，用戶還是必須等待鏡像數(shù)據(jù)完整下載到本地，然后才能創(chuàng)建自己的容器。我們希望進(jìn)一步縮減鏡像下載的時(shí)間，讓用戶能夠更快地部署容器應(yīng)用。同時(shí)，如何更好地保護(hù)用戶數(shù)據(jù)，也是容器行業(yè)近年來的重要關(guān)注點(diǎn)。

為此，我們?yōu)?Dragonfly 項(xiàng)目引入了一個(gè)容器鏡像加速服務(wù) Nydus。Nydus 能夠極大縮短鏡像下載時(shí)間，并提供端到端的鏡像數(shù)據(jù)一致性校驗(yàn)，從而讓用戶能夠更安全快捷地管理容器應(yīng)用。Nydus 由阿里云和螞蟻集團(tuán)的工程師合作開發(fā)，并大規(guī)模部署在內(nèi)部的生產(chǎn)環(huán)境中。作為云原生生態(tài)的一部分， Nydus 在生產(chǎn)環(huán)境的優(yōu)秀表現(xiàn)，讓我們有信心現(xiàn)在將項(xiàng)目開源，讓更多的容器用戶能夠體驗(yàn)到容器快速啟動(dòng)和安全加載方面的能力。

容器鏡像加速服務(wù) Nydus 地址：https://github.com/dragonflyoss/image-service

Nydus: Dragonfly 的容器鏡像服務(wù)

Nydus 項(xiàng)目?jī)?yōu)化了現(xiàn)有的 OCI 鏡像標(biāo)準(zhǔn)格式，并以此設(shè)計(jì)了一個(gè)用戶態(tài)的文件系統(tǒng)。通過這些優(yōu)化，Nydus 能夠提供這些特性：

容器鏡像按需下載，用戶不再需要下載完整鏡像就能啟動(dòng)容器
塊級(jí)別的鏡像數(shù)據(jù)去重，最大限度為用戶節(jié)省存儲(chǔ)資源
鏡像只有最終可用的數(shù)據(jù)，不需要保存和下載過期數(shù)據(jù)
端到端的數(shù)據(jù)一致性校驗(yàn)，為用戶提供更好的數(shù)據(jù)保護(hù)
兼容 OCI 分發(fā)標(biāo)準(zhǔn)和 artifacts 標(biāo)準(zhǔn)，開箱即可用
支持不同的鏡像存儲(chǔ)后端，鏡像數(shù)據(jù)不只可以存放在鏡像倉庫，還可以放到 NAS 或者類似 S3 的對(duì)象存儲(chǔ)上
與 Dragonfly 的良好集成

架構(gòu)上， Nydus 主要包含一個(gè)新的鏡像格式，和一個(gè)負(fù)責(zé)解析容器鏡像的 FUSE 用戶態(tài)文件系統(tǒng)進(jìn)程。

Nydus 能夠解析 FUSE 或者 virtiofs 協(xié)議來支持傳統(tǒng)的 runc 容器或者 Kata 容器。容器倉庫、OSS 對(duì)象存儲(chǔ)、NAS 以及 Dragonfly 的超級(jí)節(jié)點(diǎn)和 peer 節(jié)點(diǎn)都可以作為 Nydus 的鏡像數(shù)據(jù)源。同時(shí)，Nydus 還可以配置一個(gè)本地緩存，從而避免每次啟動(dòng)都從遠(yuǎn)端數(shù)據(jù)源拉取數(shù)據(jù)。

鏡像格式方面， Nydus 把一個(gè)容器鏡像分成元數(shù)據(jù)和數(shù)據(jù)兩層。其中元數(shù)據(jù)層是一棵自校驗(yàn)的哈希樹，每個(gè)文件和目錄都是哈希樹中的一個(gè)附帶哈希值的節(jié)點(diǎn)。一個(gè)文件節(jié)點(diǎn)的哈希值由文件的數(shù)據(jù)確定，一個(gè)目錄節(jié)點(diǎn)的哈希值則由該目錄下所有文件和目錄的哈希值確定。每個(gè)文件的數(shù)據(jù)被按照固定大小切片并保存到數(shù)據(jù)層中，數(shù)據(jù)切片可以在不同文件以及不同鏡像中的不同文件共享。

Nydus 能為用戶帶來什么？

用戶如果部署了 Nydus 鏡像服務(wù)，最直觀的一個(gè)感受就是，容器啟動(dòng)變快了，從以前的明顯時(shí)間消耗，變成了幾乎瞬間就能啟動(dòng)起來。在我們的測(cè)試中， Nydus 能夠把常見鏡像的啟動(dòng)時(shí)間，從數(shù)分鐘縮短到數(shù)秒鐘。

另外一個(gè)不那么明顯但也很重要的改進(jìn)，是 Nydus 能夠?yàn)橛脩籼峁┤萜鬟\(yùn)行時(shí)數(shù)據(jù)一致性校驗(yàn)。在傳統(tǒng)的鏡像中，鏡像數(shù)據(jù)會(huì)先被解壓到本地文件系統(tǒng)，再由容器應(yīng)用去訪問使用。解壓前，鏡像數(shù)據(jù)是完整校驗(yàn)的。但是解壓之后，鏡像數(shù)據(jù)不再能夠被校驗(yàn)。這帶來的一個(gè)問題就是，如果解壓后的鏡像數(shù)據(jù)被無意或惡意地修改，用戶是無法感知的。而 Nydus 鏡像不會(huì)被解壓到本地，同時(shí)可以對(duì)每一次數(shù)據(jù)訪問進(jìn)行校驗(yàn)，如果數(shù)據(jù)被篡改，則可以從遠(yuǎn)端數(shù)據(jù)源重新拉取。

未來規(guī)劃

前面我們介紹了 Nydus 的架構(gòu)和優(yōu)點(diǎn)。在過去的一年里，我們和內(nèi)部的產(chǎn)品團(tuán)隊(duì)一起致力于讓 Nydus 項(xiàng)目更穩(wěn)定、安全和易用。在把 Nydus 項(xiàng)目開源之后，我們將會(huì)更關(guān)注廣泛的云原生容器生態(tài)。我們的愿景是，當(dāng)用戶在集群中部署 Dragonfly 和 Nydus 服務(wù)的時(shí)候，無論鏡像大小，用戶都能夠方便快捷地運(yùn)行他們的容器應(yīng)用，同時(shí)不需要為容器鏡像的數(shù)據(jù)安全性擔(dān)憂。

OCI 社區(qū)容器鏡像標(biāo)準(zhǔn)

我們已經(jīng)在內(nèi)部生產(chǎn)環(huán)境中大規(guī)模部署 Nydus，而我們堅(jiān)信對(duì) OCI 鏡像標(biāo)準(zhǔn)的改進(jìn)需要廣泛的社區(qū)合作。為此，我們積極地參與了 OCI 社區(qū)關(guān)于下一代鏡像標(biāo)準(zhǔn)的討論，并發(fā)現(xiàn) Nydus 能夠廣泛地符合 OCI 社區(qū)對(duì)下一代鏡像格式的要求。所以我們提議把 Nydus 作為 OCI 社區(qū)下一代鏡像格式的示例實(shí)現(xiàn)，并期待和更多的云原生行業(yè)領(lǐng)導(dǎo)者們一起推進(jìn)下一代鏡像標(biāo)準(zhǔn)的制定和實(shí)現(xiàn)。

FAQ

Q1：現(xiàn)有的 OCI 鏡像標(biāo)準(zhǔn)有什么問題？
A1：SUSE 的 Aleksa Sarai 寫過一個(gè) blog (The Road to OCIv2 Images: What's Wrong with Tar?)，詳細(xì)描述了現(xiàn)有 OCI 鏡像標(biāo)準(zhǔn)的一系列問題，簡(jiǎn)單總結(jié)就是 OCI 鏡像標(biāo)準(zhǔn)使用的 tar 格式太古老，并不適合作為容器鏡像格式。

Q2：Nydus 和 CRFS 有什么區(qū)別？
A2：CRFS 是 GO build team 設(shè)計(jì)的一個(gè)鏡像格式。二者在主要設(shè)計(jì)思想上非常相似。細(xì)節(jié)上， Nydus 支持塊級(jí)別的數(shù)據(jù)去重和端到端的數(shù)據(jù)一致性校驗(yàn)，可以說是在 CRFS 的 stargz 格式上的進(jìn)一步改進(jìn)。

Q3：Nydus 和 Azure 的 Teleport 有什么區(qū)別？
A3：Azure Teleport 更像是現(xiàn)有 OCI 鏡像標(biāo)準(zhǔn)在基于 SMB 文件共享協(xié)議的 snapshotter 上的一個(gè)部署實(shí)現(xiàn)，能夠支持容器鏡像數(shù)據(jù)按需下載，但保留了所有目前 OCI 鏡像 tar 格式的缺陷。相對(duì)的，Nydus 拋棄了過時(shí)的 tar 格式，并使用 merkle tree 格式來提供更多的高級(jí)特性。

Q4：如果運(yùn)行基于 Nydus 的容器的時(shí)候網(wǎng)絡(luò)斷了怎么辦？
A4：使用現(xiàn)有 OCI 鏡像的時(shí)候，如果在容器鏡像還沒有完整下載的時(shí)候網(wǎng)絡(luò)斷了，容器會(huì)一開始就無法啟動(dòng)。Nydus 很大程度上改變了容器啟動(dòng)的流程，用戶不需要再等待鏡像數(shù)據(jù)完整下載就能啟動(dòng)容器。而容器運(yùn)行時(shí)如果網(wǎng)絡(luò)斷了，將無法訪問沒有下載到本地的鏡像數(shù)據(jù)。Nydus 支持在容器啟動(dòng)后在后臺(tái)下載容器鏡像數(shù)據(jù)，所以當(dāng)容器鏡像數(shù)據(jù)完整下載到本地后，基于 Nydus 的容器也不會(huì)受到網(wǎng)絡(luò)中斷的影響。

附錄：OClv2 鏡像標(biāo)準(zhǔn)

從 2020 年 6 月開始，OCI 社區(qū)花了一個(gè)多月時(shí)間密集討論了當(dāng)前 OCI 鏡像標(biāo)準(zhǔn)的缺陷，以及 OCIv2 鏡像格式需要滿足哪些要求。OCIv2 在這里只是一個(gè)宣傳命名，實(shí)際上 OCIv2 是當(dāng)前 OCI 鏡像標(biāo)準(zhǔn)的改進(jìn)，而不會(huì)是一個(gè)全新的鏡像標(biāo)準(zhǔn)。

這次鏡像格式大討論從一個(gè)郵件和一份共享文檔開始，并促成了多次在線的 OCI 社區(qū)討論會(huì)議。最后的結(jié)論也很鼓舞人心，OCIv2 鏡像格式需要滿足下列要求：

更少的重復(fù)數(shù)據(jù)
可重建的鏡像格式
明確的更少的文件系統(tǒng)元數(shù)據(jù)
可以 mount 的文件系統(tǒng)格式
鏡像內(nèi)容列表
鏡像數(shù)據(jù)按需加載
可擴(kuò)展性
可校驗(yàn)和/或可修復(fù)
更少的上傳數(shù)據(jù)
可以工作在不可信存儲(chǔ)上

在共享文檔中可以找到每一個(gè)要求的詳細(xì)描述。我們?nèi)虆⑴c了整個(gè) OCIv2 鏡像格式要求的討論，并發(fā)現(xiàn) Nydus 很好地滿足了全部的這些要求。這進(jìn)一步促使我們開源 Nydus 項(xiàng)目來為社區(qū)討論提供一個(gè)工作的代碼基礎(chǔ)。

共享文檔鏈接：https://hackmd.io/@cyphar/ociv2-brainstorm

“阿里巴巴云原生關(guān)注微服務(wù)、Serverless、容器、Service Mesh 等技術(shù)領(lǐng)域、聚焦云原生流行技術(shù)趨勢(shì)、云原生大規(guī)模的落地實(shí)踐，做最懂云原生開發(fā)者的公眾號(hào)。”

總結(jié)

以上是生活随笔為你收集整理的让容器应用管理更快更安全，Dragonfly 发布 Nydus 容器镜像加速服务的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。