（閑聊）聽說 K8s 要甩了 Docker 了
今天偶然看到 Kubernetes 1.20 的 ChangeLog，其中有一行大動(dòng)作：
Deprecation
Docker support in the kubelet is now deprecated and will be removed in a future release. The kubelet uses a module called "dockershim" which implements CRI support for Docker and it has seen maintenance issues in the Kubernetes community. We encourage you to evaluate moving to a container runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant) as they become available. (#94624, @dims) [SIG Node]大意是，Kubelet 中的 Docker 支持已經(jīng)進(jìn)入淘汰階段，將在未來移除。原因是 Kubelet 中使用 dockershim 組件為 Docker 提供了 CRI 支持，Kubernetes 認(rèn)為維護(hù)這個(gè)組件是有問題的。建議用戶評(píng)估并遷移到 CRI 支持更完善的運(yùn)行時(shí)上。
其中引用了 9 月提出的 PR #94624。其中提出，為了使用 Docker，從 moby 進(jìn)行了大量移植開發(fā)了 dockershim 嵌入到 Kubelet 之中。Kubelet 和 CRI 的正確溝通方式是像 containerd、cri-o 這樣。各自使用獨(dú)自的進(jìn)程，互相以 gRPC 進(jìn)行對(duì)接。Docker 目前仍然是主流，進(jìn)行遷移需要廣而告之并逐步推進(jìn)。
實(shí)際上早在 2018 年 5 月，Kubernetes 的 Containerd 集成就已經(jīng)宣告了 GA。其中有兩張圖很能說明問題：
在 1.0 中，Kubelet 使用 Docker Shim 和 Docker 進(jìn)行通信，Docker 再和下面的 containerd 進(jìn)行通信。
此時(shí)如果采用 containerd 作為運(yùn)行時(shí)，Kubelet 要使用 CRI Containerd 和 Containerd 打交道，不過相對(duì)于 Docker，還是少了一跳。
在 1.1 中這個(gè)結(jié)構(gòu)得到了優(yōu)化——Containerd 直接內(nèi)置 CRI 接口，Kubelet 甩掉包袱可以直接用 CRI 方式對(duì) Containerd 進(jìn)行控制，這樣就又省了一跳。
此時(shí) Docker 在這個(gè)調(diào)用鏈上的位置已經(jīng)有點(diǎn)尷尬。隨著其它 CRI 運(yùn)行時(shí)的發(fā)展，這種尷尬越發(fā)明顯。#94624 中提到過，Docker 有個(gè)優(yōu)勢(shì)就是提供了 Build 等“Kubelet 不需要但是很有用”的功能；然而換個(gè)角度來看，這些功能是有悖于單一職責(zé)的原則的。
個(gè)人認(rèn)為，Docker 這樣的全能選手，在計(jì)算節(jié)點(diǎn)上的長期存在證明了這個(gè)階段里，計(jì)算節(jié)點(diǎn)還沒有進(jìn)入理想的 cattle 狀態(tài)，用戶一方面還沒有心思對(duì)“多余”的功能進(jìn)行剪裁，另一方面還有可能人工進(jìn)入節(jié)點(diǎn)上進(jìn)行運(yùn)行時(shí)范圍以外的操作。在 GA 一年多之后，砍刀開始落下，說明了什么呢？
容器和 Docker 這兩個(gè)經(jīng)常被混用的詞，其間的邊界可能會(huì)變得越來越清晰，構(gòu)建、運(yùn)行、管理越來越傾向于使用各自領(lǐng)域的專業(yè)工具各司其職；
計(jì)算節(jié)點(diǎn)會(huì)變得更加“沒性格”，換句話說，僅為了“運(yùn)行容器”為目的的基礎(chǔ)設(shè)施軟件，例如操作系統(tǒng)、CRI 這樣的工具會(huì)逐步代替大而全的通用 Linux Server 操作系統(tǒng)和 Docker 出現(xiàn)在容器節(jié)點(diǎn)上；
“沒性格”的計(jì)算節(jié)點(diǎn)將會(huì)更加容易地被創(chuàng)建、運(yùn)行、調(diào)整和銷毀，也就是說會(huì)提高容器集群規(guī)模的伸縮能力，甚至逐漸形成普遍的動(dòng)態(tài)擴(kuò)縮容能力。
集群級(jí)別的批量化、自動(dòng)化運(yùn)維能力的要求會(huì)越來越高——或者以后的節(jié)點(diǎn)上沒有 ssh、vim 也未可知。
帶點(diǎn)個(gè)人感情的說，前兩天剛剛遭遇 DockerHub 限流的我還是生出了一點(diǎn)卑鄙的快意，Google 的鐵拳再一次敲在了 Docker 的頭上，Docker EE 怎么辦？但是 Docker Desktop for Mac 還是真香的。