Kubernetes 棄用 Docker，到底會影響到誰？

Kubernetes 在其最新的 Changelog 中宣布，自 Kubernetes 1.20 之後将棄用 Docker 作為容器運作時。那麼這到底是怎麼回事？開發者和企業會受到什麼樣到影響？

近幾年，Kubernetes 已經成為自有機房、雲上廣泛使用的容器編排方案，最廣泛的使用方式是 Kubernetes+Docker。從 DevOps 人員的角度，一面用 kubctl 指令、k8s API 來操作叢集，一面在單機用 Docker 指令來管理鏡像、運作鏡像。

單獨用 Docker 的情況，在一些公司的場景裡面也是有的。一種場景是“隻分不合”，把一台機器用 Docker 做資源隔離，但是不需要将多容器“編排”。單獨用 Kubernetes，下層不是 Docker 的情況，并不算很多。

Kubernetes 和 Docker 的關系，簡單來說，有互補，也有競争。在一般的認知中，Kubernetes 和 Docker 是互補關系：

Dockers 屬于下層——容器引擎；

Kubernetes 屬于上層——編排排程層。      

Docker 源于 Linux Container，可以将一台機器的資源分成 N 份容器，做到資源的隔離，并将可運作的程式定義為标準的 docker image；Kubernetes 則可以把不同機器的每份容器進行編排、排程，組成分布式系統。

Kubernetes 和 Docker 并不完全是“泾渭分明”的互補關系，它之間有重疊部分，也可以說成是競争，主要在于幾個點：

系統三大移植資源是計算、存儲、網絡，從 Kubernetes 角度 Docker 屬于“Runtime（運作時）”，也就是計算資源；但是 Docker 技術體系裡面，本身也包括存儲層、網絡層。上下層職責的重疊，也可以看作競争。

Docker 原本有個原生的排程引擎——Swarm，幾年前在排程編排領域，還是 Kubernetes、Mesos、Swarm 三者并存，Kubernetes 最終勝出，但 Docker 仍有“繼續向上做一層的意願”。
      

Kubernetes 在如何使用 Docker 方面，存在争議和變數。kubernetes 1.20 ChangeLog 中所謂要廢棄 Docker 的傳言，也是無風不起浪。換句話說，即便 Kubernetes 一直用 Docker，也不是用 Docker 的全部，多少是不一樣的。

而且，“棄用 Docker”這個詞本身有多重的含義，Docker 并非一個單層軟體，Kubernetes 1.20 啟用 dockershim 并不代表棄用了 Docker 的全部，仍有 containerd 可以對接 docker。

1.Kubernetes 有 CRI、OCI 兩個容器标準　　

在目前廣泛使用 kubernetes 與 Runtime 的橋接方案，CRI（Container Runtime Interface）與 OCI（Open Container Initiative）是“套娃“關系。Kubernetes 的 kubelet 調用 CRI，OCI 的實作者然後再調用 OCI。

下圖也說明了 CRI 與 OCI 的關系：

從 Kubernetes 的角度，CRI 是與 CNI（網絡）、CSI（存儲）相同層級的接口。

OCI 是個自下而上的标準，也就是從實作抽象出接口，它是 Linux Foundation 主導的。Docker 實作的核心 RunC，也就是 OCI 的典型實作、标準實作。

CRI 是個自上而下的标準，源于 Kubernetes 對移植層（運作時）的要求。

容器引擎層自下而上定義 OCI，容器編排層自上而下定義 CRI，這也讓它們出現了“套娃“運作情況。

在 Kubernetes 的 dockershim、cri-containerd、cri-o 三種實作中，RedHat 推崇的 cri-o 已經比較主流，它雖然仍是“套娃“，但已經比較精簡。

下面是從 kubernetes 叢集運作的全景圖看 cri-o 的位置：

 2.Docker 本源于 Linux Container

Docker 作為容器引擎，其實作的基礎是 Linux Container——從核心到使用者空間的機制。

Linux Container 可以分成兩個部分，核心裡面的 cgroup，使用者空間的 lxc。Docker 最初實作的時候，也是完全基于 Linux Container 的，基于 lxc 做更上層的東西。

這張很多人認為“與事實不符“的圖，其實代表了過去：

在 Docker 的發展過程中，最終啟用了 C 語言寫成 lxc，換成了 go 語言寫成的 libcontainer。

下面的圖也不是很新，但它更能表示 Docker 後續典型的架構，這裡面已經沒有了 lxc。

然而，萬變不離其宗，Docker 實作的本源，還是 Linux Container。即便不用 lxc，當仍要用核心的 cgroup，并且模式也是類似的。

3.Kubernetes 最終如何橋接容器

從純技術的角度，與其讨 Kubernetes 與 Docker 關系，不如讨論 Kubernetes 與最終容器實作層的關系。因為 Docker 這個名詞，在不同的時候，有着不同的内涵、外延。

下面是 Docker 的簡圖：

從軟體子產品的角度，圖中的 docker Engine、cri-containd、containd-shim、runC 都屬于 Docker 體系的軟體。

下圖中的紫、橙、紅三種顔色，代表了 dockershim、cri-containerd、cri-o 三種 CRI 的典型方式——流程在逐漸縮短，這也是 CRI 實作的一個演進過程。

 如果是 kubelet 的 dockershim 模式（紫色），流程是這樣的：

kubelet 從 CRI 的 gRPC 調用 dockershim，二者在同一個程序

dockershim 調用 docker 守護程序

docker 守護程序調用 containerd；containerd 調用 containerd-shim（有時名為docker-containerd-shim 守護程序）完成建立容器等操作

containerd-shim 通路 OCI 的實作 runC（指令行可執行程式）      

如果是 kubelet 的 cri-containerd 模式（橙色），流程是這樣的：

kubelet 從 CRI 的 gRPC 調用 cri-containerd；

cri-containerd 調用 containerd；containerd 調用 containerd-shim（同上）

containerd-shim 調用 RucnC （同上）；
      

在很多人的印象中，如果不用 docker 守護程序，就相當于“棄用 docker“，這其實也就是從 dockershim 到 containerd 的變化。從另一個角度來說，containerd 這個守護程序，也是 docker 組織做的。

如果是 kubelet 的 cri-o 模式（紅色），則更加簡練：

kubelet 從 CRI 的 gRPC 調用 cri-o；

cri-o 調用 OCI 的實作 runC
      

如果以 kubelet 調用 CRI 為起點，OCI 的 runC 調用為終點，三種模式經曆的可執行程式分别是：　　

dockershim 模式：dockershim(*)->dockd->containerd->containerd-shim
dockershim 模式有 3 個可執行程式，dockershim 一般與 kubelet 同程序；

cri-containerd 模式：cri-containerd(*)-> containerd->containerd-shim
cri-containerd 模式有 2-3 個可執行程式，cri-containerd 可與 containerd 同程序；

cri-o 模式：cri-o
cri-o 模式隻有 1 個可執行程式。      

顯然在這種 Red Hat 推崇的 cri-o 模式下，Docker 體系的 containerd 也用不着了，隻剩 runC 這個指令行的程式。runC 也是用 go 寫成的，裡面有調用 libcontainer。

當 Docker 萎縮到這個地步，其實也隻剩 Linux 核心裡面 cgroup、namespace 功能的封裝了。

總結來說，由于老技術實作的慣性，在生産環境大量使用的經典 Kubernetes+ Docker 方案依然運作，且運維已經成熟，不會很快更新。對于開發人員、企業，對于 K8S API 的使用頻率、變數，遠遠大于 Docker API，至于 Kubernetes 和 Docker 的橋接，更不用關心。是以，即便“徹底棄用 Docker”，對開發者與企業的影響也非常有限。

　

抄自于：https://mp.weixin.qq.com/s?__biz=MzIzNjUxMzk2NQ==&mid=2247503788&idx=1&sn=e6940f629dd56d4e9f3ea8daf1626b2a&chksm=e8d4306edfa3b97814ecc27710ebfb31d08314e7e49f1bf894bfe385483421e5ce2480b5a76e&scene=126&sessionid=1608013820&key=7699cc7e7be7dcfc92288968a4031874596f503924f2a0fe4d86de798482a3d37f32b0dbf5b57fe1ae4999cf67a5efd157734008974dd4e1edaea9d8193db51ff31bcf5dbb9e1e19ca991d24cdf68c1b68244e80fac45dc1b0229754ce42d1980de2f7239ffb6868d2f473e281933284882275b91ecc80da0d28dc0dc5906360&ascene=1&uin=MjM3MjczMTM2MQ%3D%3D&devicetype=Windows+10+x64&version=6300002f&lang=zh_CN&exportkey=AfTZWMfy9ESXczcNuavvncA%3D&pass_ticket=0iAf7dngOlPnLj2404zpBLNzUWXrDCI0d070YhiabyHBfevMErYaEHBAVEli8pVB&wx_header=0　

 作者介紹

　　楊明越，現從事分布式系統、雲架構方面工作，具有全方位的技術，曾任新興網際網路公司（BAT）的主任架構師，世界頂級晶片公司的 OS 技術專家，前 Top2 通訊公司進階工程師。

"一勞永逸" 的話，有是有的，而 "一勞永逸" 的事卻極少