題圖攝於北京前門
注：微信公衆號不按照時間排序，請關注“亨利筆記”，並加星標以置頂，以免錯過更新。
上個月 Kubernetes 1.20 beta 版的發佈記錄（release note）裏面聲明瞭 kubelet 的 dockershim 模塊已經過時了（deprecated），最快將在 1.23 版本中移除，即大約是一年之後。
這本來是個很普通的消息，沒想到上週突然冒出了一批搶眼球的文章，說什麼 Kubernetes 終於“甩掉”了 Docker ，一時間這條消息被炒得沸沸揚揚。不明就裏的用戶被嚇得戰戰兢兢，不知所措。
這個 dockershim 其實是 Kubernetes 早期生長的一顆乳牙而已，現在“恆牙”已經長結實了，乳牙自然脫落就好。所以說，移去 dockershim 只是項目發展的必然結果，對用戶影響微乎其微，不必多慮。
下面是一個簡單的示意圖，根據筆者在《Harbor權威指南》一書中的插圖略微修改而來。Kubernetes 的 kubelet 可以支持多種符合 CRI 規範的運行時（runtime），例如 containerd 和 CRI-O。
而用戶熟悉的 Docker（圖中的 dockerd）不符合 CRI 規範，因此當年 kubelet 內置了一個模塊 dockershim，用來對 Docker 進行 CRI 接口的適配。經過幾年的發展，CRI 的運行時已經很成熟了，用戶在 Kubernetes 中可以直接使用 containerd或者 CRI-O ，無需再通過 dockershim – dockerd – containerd 繞一圈（圖中紅色箭頭），既費時又費力的。由此可見，dockershim 就是那顆已完成歷史使命的乳牙而已，無足輕重了。
至於說 Kubernetes 徹底 “甩掉”了 Docker，也只是聳人聽聞罷了。在可見的將來，Kubernetes 都無法真正擺脫 Docker 的影響。
先說說容器運行時，符合 CRI 標準的 containerd，以及底層的 runC，都是從Docker 項目中分拆出來的，蘊含了揮之不去的 Docker 印記。
此外，Docker 最精華的部分並不是容器運行時。因爲容器的運行時歸根到底僅僅是 Linux 內核功能的調用而已，Docker 的容器運行時是可以被替代的。
Docker 最具革命性的創新，是應用程序的封裝方式，即容器鏡像的格式定義。筆者在 2015 年文章中就旗幟鮮明地指出，Docker的核心價值是容器鏡像。容器鏡像是真正改變世界的技術，這個觀點至今仍然未變。Kubernetes 上跑的容器，離不開 Docker 鏡像的使用。
截至2020年初，Docker Hub 中的鏡像累計下載了 1300 億次，用戶創建了約 600 萬個容器鏡像庫。 -- 摘自《Harbor權威指南》
Docker 鏡像格式已是實際上的標準， OCI 的鏡像規範是以 Docker 鏡像格式爲藍本制定的，在大多數情況下兩者是兼容的。開發者平時用到的“Docker”，除了可以運行容器之外，還有一個重要的功能就是構建容器鏡像（例如 docker build），是上圖中 dockerd 提供的主要功能之一。這部分面向開發者的功能在運行環境中確實用處不大，是 dockershim 被移除的原因之一。
因爲鏡像的格式已經標準化了，除了 Docker 以外，其他工具也可以構建鏡像，如紅帽的 Podman 等，但這些工具萬變不離其宗，依然（必須）使用 Docker 開創的鏡像格式標準。
Docker 公司有個著名的口號：“Build, Ship and Run”，翻譯過來就是三個動詞：“構建、傳送和運行”，簡練地描繪出了應用開發的精髓，其中隱含的意思是：構建鏡像、傳送鏡像和運行鏡像，一切皆以鏡像爲中心。OCI 組織對應有三個規範，分別與上述三個動詞對應，即鏡像規範（構建）、運行時規範（運行）和正在制定的分發規範（傳送）。鏡像是容器應用的關鍵技術，圍繞鏡像的一系列管理工作將是實際運維中的重要組成部分，這也是我們當初創建 Harbor 開源項目所希望解決的問題。
Kubernetes 還將在較長時間內使用 Docker 創立的技術和規範。爲幫助讀者理解，下面摘錄《Harbor權威指南》第1章的部分內容，介紹各種容器運行時之間的關係。本公衆號後續文章將給大家解釋容器鏡像的各種原理，請關注本號的文章更新。
Harbor 是原創於中國、廣泛應用於全球的雲原生開源項目，主要的維護者和貢獻者均來自中國。《Harbor權威指南》是第一本全面介紹 Harbor 雲原生製品倉庫的書籍，由 Harbor 項目維護者和貢獻者編寫。雙十二期間在京東、噹噹等網站半價優惠中。
容器的運行時 （《Harbor權威指南》節選）
Linux提供了命名空間和控制組兩大系統功能，它們是容器的基礎。但是，要把進程運行在容器中，還需要有便捷的 SDK 或命令來調用 Linux 的系統功能，從而創建出容器。容器的運行時（runtime）就是容器進程運行和管理的工具。
容器運行時分爲低層運行時和高層運行時，功能各有側重。低層運行時主要負責運行容器，可在給定的容器文件系統上運行容器的進程；高層運行時則主要爲容器準備必要的運行環境，如容器鏡像下載和解壓並轉化爲容器所需的文件系統、創建容器的網絡等，然後調用低層運行時啓動容器。主要的容器運行時的關係如下圖所示。
OCI運行時規範
成立於 2015 年的 OCI 是Linux基金會旗下的合作項目，以開放治理的方式制定操作系統虛擬化（特別是Linux容器）的開放工業標準，主要包括容器鏡像格式和容器運行時（runtime）。初始成員包括 Docker、亞馬遜、谷歌和VMware等公司。OCI成立之初，Docker 公司爲其捐贈了容器鏡像格式和運行時的草案及相應的實現代碼。原來屬於Docker 的 libcontainer 項目被捐贈給OCI，成爲獨立的容器運行時項目 runC。
OCI 運行時規範定義了容器配置、運行時和生命週期的標準，主流的容器運行時都遵循OCI運行時的規範，從而提高系統的可移植性和互操作性，用戶可根據需要進行選擇。
首先，容器啓動前需要在文件系統中按一定格式存放所需的文件。OCI運行時規範定義了容器文件系統包（filesystem bundle）的標準，在OCI運行時的實現中通常由高層運行時下載 OCI 鏡像，並將OCI鏡像解壓成OCI運行時文件系統包，然後 OCI 運行時讀取配置信息和啓動容器裏的進程。OCI運行時文件系統包主要包括以下兩部分。
config.json：這是必需的配置文件，存放於文件系統包的根目錄下。OCI運行時規範對Linux、Windows、Solaris和虛擬機4種平臺的運行時做了相應的配置規範。
容器的根文件系統：容器啓動後進程所使用的根文件系統，由 config.json 中的root.path屬性確定該文件系統的路徑，通常是“rootfs/”。
然後，在定義文件系統包的基礎上，OCI運行時規範制定了運行時和生命週期管理規範。生命週期定義了容器從創建到刪除的全過程。
runC
runC 是 OCI 運行時規範的參考實現，也是最常用的容器運行時，被其他多個項目使用，如 containerd 和CRI-O等。runC也是低層容器運行時，開發人員可通過runC實現容器的生命週期管理，避免煩瑣的操作系統調用。根據OCI運行時規範，runC不包括容器鏡像的管理功能，它假定容器的文件包已經從鏡像裏解壓出來並存放於文件系統中。runC創建的容器需要手動配置網絡才能與其他容器或者網絡節點連通，爲此可在容器啓動之前通過OCI定義的事件鉤子來設置網絡。
由於runC提供的功能比較單一，複雜的環境需要更高層的容器運行時來生成，所以runC常常成爲其他高層容器運行時的底層實現基礎。
containerd
在OCI成立時，Docker公司把其Docker項目拆分爲runC的低層運行時及高層運行時功能。2017年，Docker公司把這部分高層容器運行時的功能集中到containerd項目裏，捐贈給雲原生計算基金會。
containerd 已經成爲多個項目共同使用的高層容器運行時，提供了容器鏡像的下載和解壓等鏡像管理功能，在運行容器時，containerd先把鏡像解壓成OCI的文件系統包，然後調用runC運行容器。containerd提供了API，其他應用程序可以通過API與containerd交互。“ctr”是containerd的命令行工具，和“docker”命令很相像。但作爲容器運行時，containerd只注重在容器運行等方面，因而不包含開發者使用的鏡像構建和鏡像上傳鏡像倉庫等功能。
Docker
Docker引擎是最早流行也是最廣泛使用的容器運行時之一，是一個容器管理工具，架構如下圖所示。Docker的客戶端（命令行CLI工具）通過API調用容器引擎Docker Daemon（dockerd）的功能，完成各種容器管理任務。
Docker 引擎在發佈時是一個單體應用，所有功能都集中在一個可執行文件裏，後來按功能分拆成 runC 和 containerd 兩個不同層次的運行時，分別捐獻給了OCI和CNCF。上面兩節已經分別介紹了runC和containerd的主要特點，剩下的dockerd就是Docker公司維護的容器運行時。
dockerd同時提供了面向開發者和麪向運維人員的功能。其中，面向開發者的命令主要提供鏡像管理功能。容器鏡像一般可由Dockerfile構建（build）而來。Dockerfile是一個文本文件，通過一組命令關鍵字定義了容器鏡像所包含的基礎鏡像（base image）、所需的軟件包及有關應用程序。在Dockerfile編寫完成以後，就可以用“docker build”命令構建鏡像了。下面是一個Dockerfile的簡單例子：
FROM ubuntu:18.04
EXPOSE 8080
CMD ["nginx", "-g", "daemon off;"]
容器的鏡像在構建之後被存放在本地鏡像庫裏，當需要與其他節點共享鏡像時，可上傳鏡像到鏡像倉庫（Registry）以供其他節點下載。
Docker還提供了容器存儲和網絡映射到宿主機的功能，大部分由containerd實現。應用的數據可以被保存在容器的私有文件系統裏面，這部分數據會隨着容器一起被刪除。對需要數據持久化的有狀態應用來說，可用數據卷Volume的方式導入宿主機上的文件目錄到容器中，對該目錄的所有寫操作都將被保存到宿主機的文件系統中。Docker可以把容器內的網絡映射到宿主機的網絡上，並且可以連接外部網絡。
CRI和CRI-O
Kubernetes是當今主流的容器編排平臺，爲了適應不同場景的需求，Kubernetes需要有使用不同容器運行時的能力。爲此，Kubernetes從1.5版本開始，在kubelet中增加了一個容器運行時接口CRI（Container Runtime Interface），需要接入Kubernetes的容器運行時必須實現CRI接口。由於kubelet的任務是管理本節點的工作負載，需要有鏡像管理和運行容器的能力，因此只有高層容器運行時才適合接入CRI。CRI和容器運行時的關係如下圖所示。
CRI和容器運行時之間需要有個接口層，通常稱之爲shim（墊片），用以匹配相應的容器運行時。
由於 Docker運行時被普遍使用，它的CRI shim被稱爲dockershim，內置在Kubernetes 的 kubelet 中，由 Kubernetes 項目組開發和維護。其他運行時則需要提供外置的shim。containerd 從1.1版本開始內置了CRI plugin，不再需要外置shim來轉發請求，因此效率更高。在安裝 Docker 的最新版本時，會自動安裝 containerd，所以在一些系統中，Docker 和 Kubernetes 可以同時使用 containerd 來運行容器，但是二者的鏡像用了命名空間隔離，彼此是獨立的，即鏡像不可以共用。因爲Docker 和 containerd常常同時存在，因此在不需要使用Docker的系統中只安裝 containerd 即可。
containerd最早是爲 Docker 設計的代碼，包含一些用戶相關的功能。相比之下，CRI-O是替代Docker或者containerd的高效且輕量級的容器運行時方案，是CRI的一個實現，能夠運行符合OCI規範的容器，所以被稱爲CRI-O。CRI-O是原生爲生產系統運行容器設計的，有個簡單的命令行工具供測試用，但並不能進行容器管理。CRI-O支持OCI的容器鏡像格式，可以從容器鏡像倉庫中下載鏡像。CRI-O支持runC和Kata Containers這兩種低層容器運行時。
更多容器運行時和鏡像的說明，請參考新書《Harbor權威指南》，目前京東、噹噹半價優惠中，不要錯過。
要想了解雲原生、區塊鏈和人工智能等技術原理，請立即長按以下二維碼，關注本公衆號亨利筆記 （ henglibiji )，以免錯過更新。
