今天偶然看到 Kubernetes 1.20 的 ChangeLog，其中有一行大动作：
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 支持已经进入淘汰阶段，将在未来移除。原因是 Kubelet 中使用 dockershim 组件为 Docker 提供了 CRI 支持，Kubernetes 认为维护这个组件是有问题的。建议用户评估并迁移到 CRI 支持更完善的运行时上。
其中引用了 9 月提出的 PR #94624。其中提出，为了使用 Docker，从 moby 进行了大量移植开发了 dockershim 嵌入到 Kubelet 之中。Kubelet 和 CRI 的正确沟通方式是像 containerd、cri-o 这样。各自使用独自的进程，互相以 gRPC 进行对接。Docker 目前仍然是主流，进行迁移需要广而告之并逐步推进。
实际上早在 2018 年 5 月，Kubernetes 的 Containerd 集成就已经宣告了 GA。其中有两张图很能说明问题：
在 1.0 中，Kubelet 使用 Docker Shim 和 Docker 进行通信，Docker 再和下面的 containerd 进行通信。
此时如果采用 containerd 作为运行时，Kubelet 要使用 CRI Containerd 和 Containerd 打交道，不过相对于 Docker，还是少了一跳。
在 1.1 中这个结构得到了优化——Containerd 直接内置 CRI 接口，Kubelet 甩掉包袱可以直接用 CRI 方式对 Containerd 进行控制，这样就又省了一跳。
此时 Docker 在这个调用链上的位置已经有点尴尬。随着其它 CRI 运行时的发展，这种尴尬越发明显。#94624 中提到过，Docker 有个优势就是提供了 Build 等“Kubelet 不需要但是很有用”的功能；然而换个角度来看，这些功能是有悖于单一职责的原则的。
个人认为，Docker 这样的全能选手，在计算节点上的长期存在证明了这个阶段里，计算节点还没有进入理想的 cattle 状态，用户一方面还没有心思对“多余”的功能进行剪裁，另一方面还有可能人工进入节点上进行运行时范围以外的操作。在 GA 一年多之后，砍刀开始落下，说明了什么呢？
- 容器和 Docker 这两个经常被混用的词，其间的边界可能会变得越来越清晰，构建、运行、管理越来越倾向于使用各自领域的专业工具各司其职；
- 计算节点会变得更加“没性格”，换句话说，仅为了“运行容器”为目的的基础设施软件，例如操作系统、CRI 这样的工具会逐步代替大而全的通用 Linux Server 操作系统和 Docker 出现在容器节点上；
- “没性格”的计算节点将会更加容易地被创建、运行、调整和销毁，也就是说会提高容器集群规模的伸缩能力，甚至逐渐形成普遍的动态扩缩容能力。
- 集群级别的批量化、自动化运维能力的要求会越来越高——或者以后的节点上没有 ssh、vim 也未可知。
带点个人感情的说，前两天刚刚遭遇 DockerHub 限流的我还是生出了一点卑鄙的快意，Google 的铁拳再一次敲在了 Docker 的头上，Docker EE 怎么办？但是 Docker Desktop for Mac 还是真香的。
文章来源于互联网:（闲聊）听说 K8s 要甩了 Docker？
