Linux中國

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

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

對這篇文章感覺如何?

太棒了
0
不錯
0
愛死了
0
不太好
0
感覺很糟
0
雨落清風。心向陽

    You may also like

    Leave a reply

    您的電子郵箱地址不會被公開。 必填項已用 * 標註

    此站點使用Akismet來減少垃圾評論。了解我們如何處理您的評論數據

    More in:Linux中國