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”）正如它的名字，它是一個容器守護行程，而不是一些人忽悠我的“收集contain迷nerd”。它最初是作為 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] 的要求，還能減少了需要的程式碼數量，從長遠來看這樣更易於維護。