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

題圖攝於北京前門

上個月 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這兩種低層容器執行時。