歡迎光臨
每天分享高質量文章

containerd 1.0 探索之旅 | Linux 中國

containerd 被用於 Docker、Kubernetes CRI、以及一些其它的專案,在這些平臺中事實上都使用了 containerd,而許多人並不知道 containerd 存在於這些平臺之中,這篇文章就是為這些人所寫的。
— Michael Crosby


編譯自 | https://blog.docker.com/2017/12/containerd-ga-features-2/ 
 作者 | Michael Crosby
 譯者 | qhwdw

我們在過去的文章中討論了一些 containerd 的不同特性,它是如何設計的,以及隨著時間推移已經修複的一些問題。containerd 被用於 Docker、Kubernetes CRI、以及一些其它的專案,在這些平臺中事實上都使用了 containerd,而許多人並不知道 containerd 存在於這些平臺之中,這篇文章就是為這些人所寫的。我將來會寫更多的關於 containerd 的設計以及特性集方面的文章,但是現在,讓我們從它的基礎知識開始。

我認為容器生態系統有時候可能很複雜。尤其是我們所使用的術語。它是什麼?一個運行時,還是別的?一個運行時 … containerd(它的發音是 “container-dee”)正如它的名字,它是一個容器守護行程,而不是一些人忽悠我的“收集containnerd”。它最初是作為 OCI 運行時(就像 runc 一樣)的集成點而構建的,在過去的六個月中它增加了許多特性,使其達到了像 Docker 這樣的現代容器平臺以及像 Kubernetes 這樣的編排平臺的需求。

那麼,你使用 containerd 能去做些什麼呢?你可以擁有推送或拉取功能以及鏡像管理。可以擁有容器生命周期 API 去創建、運行、以及管理容器和它們的任務。一個完整的專門用於快照管理的 API,以及一個其所依賴的開放治理的專案。如果你需要去構建一個容器平臺,基本上你不需要去處理任何底層操作系統細節方面的事情。我認為關於 containerd 中最重要的部分是,它有一個版本化的並且有 bug 修複和安全補丁的穩定 API。

由於在內核中沒有一個 Linux 容器這樣的東西,因此容器是多種內核特性捆綁在一起而成的,當你構建一個大型平臺或者分佈式系統時,你需要在你的管理代碼和系統呼叫之間構建一個抽象層,然後將這些特性捆綁粘接在一起去運行一個容器。而這個抽象層就是 containerd 的所在之處。它為穩定型別的平臺層提供了一個客戶端,這樣平臺可以構建在頂部而無需進入到內核級。因此,可以讓使用容器、任務、和快照型別的工作相比通過管理呼叫去 clone() 或者 mount() 要友好的多。與靈活性相平衡,直接與運行時或者宿主機交互,這些物件避免了常規的高級抽象所帶來的性能犧牲。結果是簡單的任務很容易完成,而困難的任務也變得更有可能完成。

containerd

containerd 被設計用於 Docker 和 Kubernetes、以及想去抽象出系統呼叫或者在 Linux、Windows、Solaris 以及其它的操作系統上特定的功能去運行容器的其它容器系統。考慮到這些用戶的想法,我們希望確保 containerd 只擁有它們所需要的東西,而沒有它們不希望的東西。事實上這是不太可能的,但是至少我們想去嘗試一下。雖然網絡不在 containerd 的範圍之內,它並不能做成讓高級系統可以完全控制的東西。原因是,當你構建一個分佈式系統時,網絡是非常中心的地方。現在,對於 SDN 和服務發現,相比於在 Linux 上抽象出 netlink 呼叫,網絡是更特殊的平臺。大多數新的網絡都是基於路由的,並且每次一個新的容器被創建或者刪除時,都會請求更新路由表。服務發現、DNS 等等都需要及時被通知到這些改變。如果在 containerd 中添加對網絡的管理,為了能夠支持不同的網絡接口、鉤子、以及集成點,將會在 containerd 中增加很大的一塊代碼。而我們的選擇是,在 containerd 中做一個健壯的事件系統,以便於多個消費者可以去訂閱它們所關心的事件。我們也公開發佈了一個 任務 API[1],它可以讓用戶去創建一個運行任務,也可以在一個容器的網絡命名空間中添加一個接口,以及在一個容器的生命周期中的任何時候,無需複雜的鉤子來啟用容器的行程。

在過去的幾個月中另一個添加到 containerd 中的領域是完整的儲存,以及支持 OCI 和 Docker 鏡像格式的分佈式系統。有了一個跨 containerd API 的完整的目錄地址儲存系統,它不僅適用於鏡像,也適用於元資料、檢查點、以及附加到容器的任何資料。

我們也花時間去 重新考慮如何使用 “圖驅動” 工作[2]。這些是疊加的或者允許鏡像分層的塊級檔案系統,可以使你執行的構建更加高效。當我們添加對 devicemapper 的支持時,圖驅動graphdrivers最初是由 Solomon 和我寫的。Docker 在那個時候僅支持 AUFS,因此我們在疊加檔案系統之後,對圖驅動進行了建模。但是,做一個像 devicemapper/lvm 這樣的塊級檔案系統,就如同一個堆疊檔案系統一樣,從長遠來看是非常困難的。這些接口必須基於時間的推移進行擴展,以支持我們最初認為並不需要的那些不同的特性。對於 containerd,我們使用了一個不同的方法,像快照一樣做一個堆疊檔案系統而不是相反。這樣做起來更容易,因為堆疊檔案系統比起像 BTRFS、ZFS 以及 devicemapper 這樣的快照檔案系統提供了更好的靈活性。因為這些檔案系統沒有嚴格的父/子關係。這有助於我們去構建出 快照的一個小型接口[3],同時還能滿足 構建者[4] 的要求,還能減少了需要的代碼數量,從長遠來看這樣更易於維護。

你可以在 Stephen Day 2017/12/7 在 KubeCon SIG Node 上的演講[5]找到更多關於 containerd 的架構方面的詳細資料。

除了在 1.0 代碼庫中的技術和設計上的更改之外,我們也將 containerd 管理樣式從長期 BDFL 樣式轉換為技術委員會[6],為社區提供一個獨立的可信任的第三方資源。


via: https://blog.docker.com/2017/12/containerd-ga-features-2/

作者:Michael Crosby[8] 譯者:qhwdw 校對:wxy

本文由 LCTT 原創編譯,Linux中國 榮譽推出

LCTT 譯者

qhwdw ? ? ? ? ?
共計翻譯:73 篇
貢獻時間:112 天


推薦文章

< 左右滑動查看相關文章 >

點擊圖片、輸入文章 ID 或識別二維碼直達

赞(0)

分享創造快樂