Docker将从Kubernetes中移除，我该怎么办？

对开发者而言

不必惊慌，Docker 容器和镜像依然在，Docker 将不会有任何的改变。
这两篇文章值得大家去阅读：
Don’t Panic: Kubernetes and Docker
Dockershim Deprecation FAQ

对K8S管理员而言

仔细阅读下面的内容并且开始思考 Docker 的替代方案。

是真的吗？

确实如此！Docker 现在不推荐在 K8S 中使用。

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.

摘自 K8S GitHub

简而言之，由于 Docker 不支持 CRI (Kubernetes Runtime API)。K8S 的工程师使用了一个种桥接的方式，我们称之为 “Docker-Shim”，它的作用是将 CRI 转换为 Docker API，但是它在 K8S 后面的发行版本中不在提供。

实话实说，Docker 在本地是一个非常有力的工具去创建开发环境，但是要去理解为什么 K8S 要在以后的发现版本中移除 Docker ，你需要去理解 Docker 在当前的 K8S 环境中做了什么事情。

K8S 是一个底层的编排工具，它的目的是能够对许多不同的虚拟机或者是物理机进行组合，使之看起来是一个巨大的计算资源，提供资源让应用程序运行和相互访问。在这个体系下面，Docker 或者说是其他的容器运行时，被用作在指定的某台主机并且被 K8S 的控制面调度。

可以从上面的这张架构图看到，每个 K8S 节点都和控制面交互。kubelet 在每个节点上获取元数据并且通过执行 CRI 去创建或删除容器。

但是为什么 Docker 要被移除呢？

再强调一遍！K8S 只能通过 CRI 的方式去交互并且 Docker 需要一种桥接服务 Docker-Shim 才能支持。这是第一个原因。

为了去阐述下一个原因，我们有必要去看一下 Docker 的架构图，如图：

可以看到 Docker 的功能非常丰富，但是 K8S 真正需要的只有红框部分。例如 Docker 的网络、卷等都没有在 K8S 中被用到。
有很多的特性没有被采用，但是这些特性又会有安全隐患。有更少的特性，则会有更小的攻击面。
所以这就是你需要开始思考的替代方式，称之为：CRI runtimes。

CRI runtimes

目前有两个主要的 CRI runtime 实现方式。

containerd

如果你仅仅想从Docker迁移，containerd 是最好的选择，因为它本来就作为 Docker 的一部分被采用去做所有的运行时工作，就如上图红色框部分的功能。他由 Docker 完全提供 CRI 实现。

containerd 是完全开源的，所以你能够在 GitHub 查看文档，甚至可以去贡献代码。

containerd GitHub 地址

CRI-O

CRI-O 是一个由 Red Hat （红帽） 开发的 CRI 运行时。事实上，这个运行时正在被 Red Hat OpenShfit 使用。这个方式就一点都不依赖 Docker 了。

有趣的是，RHEL 7 也不正式支持 Docker 了，取代方案是 Podman、Buildah 和 CRI-O 作为容器环境。

CRI-O GItHub地址

CRI-O 的有点在我看来就是极简主义的，因为它被创建来作为 “CRI”运行时。因为 containerd 是作为 Docker 的一部分尝试去做更多的开源，但是 CRI-O 是纯的 CRI 运行时，它的内容都是 CRI 所需要的。

它仍然可以提供在 K8S 上运行应用程序所需要的功能，但是从 Docker 迁移到 CRI-O 可能会更具挑战性。

还有一件事…

当我们在谈论容器运行时的时候，我们需要注意在谈论的是那种类型。我们需要知道有两种类型，分别是 CRI runtimes 和 OCI runtimes。

CRI runtimes

正如我前面提到的那样，CRI 是一个 K8S 提供的 API，目的是为了与容器运行时交互，达到创建和删除容器化应用程序的目的。

他们以 kubelet 为单位通过 gRPC 方式调用并且容器运行时在和 kubelet 相同的主机上。CRI runtimes 的作用就是去获取 kubelet 的请求并且执行 OCI 容器运行时去运行容器。我觉得用一个图能够更好的解释。如图：

所以 CRI 做的事情如下：

1. 获取从 kubelet 的 gRPC 请求
2. 创建 OCI json 配置文件参考链接

OCI runtimes

OCI runtimes 的作用是使用 Linux 内核系统调用（例如cgroups和namespace）创建容器。你可能听说过 runc 或 gVisor。下面就是有关他们内容：

附录一：runC 是如何工作的

CRI 通过调用 Linux 系统调用执行二进制文件后，runC 创建容器。这表明runC依赖Linux机器上运行的内核。
这也意味着，如果您发现runC的漏洞使您获得了主机的root特权，那么容器化的应用程序也可以这样做。一个糟糕的黑客可能会使您的主机根深蒂固！事情肯定会变糟的。这就是为什么您也应该不断更新Docker（或任何其他容器运行时）的原因之一，而不仅仅是容器化的应用程序。

附录二：gVisor 是如何工作的

gVisor是最初由Google员工创建的OCI运行时。它实际上在其基础架构上运行以运行其云服务，例如Google Cloud Run，Google App Engine（第二代）和Google Cloud Functions（甚至更多！。

有趣的是，gVisor具有“来宾内核”层，这意味着容器化的应用程序无法直接接触主机内核层。即使他们认为确实如此，他们也只会接触gVisor的来宾内核。
gVisor的安全模型实际上非常有趣，值得一读gVisor官网

与runC的显着差异如下:

1. 性能较差
2. Linux内核层不是100％兼容的，参考阅读gVisor官网
3. 默认不支持

总结

1. Kubernetes 确定会弃用 Docker。因此，如果您是K8s管理员，则应开始考虑采用CRI运行时（例如 containerd 和 CRI-O）
a. containerd 与 Docker 兼容的，其中核心组件是相同的。
b. CRI-O可以是你想要的 Kubernetes 更多的最小功能强大的选项。

2. 了解 CRI 和 OCI 运行时职责和范围的区别
根据您的工作负载，runC可能并不总是使用最好的选择！

参考文章

Wait, Docker is deprecated in Kubernetes now? What do I do?