containerd 1.0 探索之旅

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

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

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

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

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

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

作者：Michael Crosby 譯者：qhwdw 校對：wxy

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

本文轉載來自 Linux 中國: https://github.com/Linux-CN/archive