K8s根本甩不掉Docker，原因一說就懂

題圖攝于北京前門

注：微信公眾號不按照時間排序，請關注“亨利筆記”，并加星標以置頂，以免錯過更新，

2020云原生生態大會，大咖云集，立刻報名！

上個月 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權威指南》，目前京東、當當半價優惠中，不要錯過，