近日，Kubernetes 官方发布公告，宣布自 v1.20 起放弃对 Docker 的支持，届时用户将收到 Docker 弃用警告，并需要改用其他容器运行时。
图片来自 Pexels
但 Docker 作为容器镜像构建工具的作用将不受影响，用其构建的容器镜像将一如既往地在集群中与所有容器运行时正常运转。
Kubernetes 将弃用 Docker
没错，这是真的，Kubernetes 现已弃用 Docker!
参考链接：
- https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation
目前，Kubelet 中的 Docker 支持功能现已弃用，并将在之后的版本中被删除。
Kubelet 之前使用的是一个名为 dockershim 的模块，用以实现对 Docker 的 CRI 支持。
但 Kubernetes 社区发现了与之相关的维护问题，因此建议大家考虑使用包含 CRI 完整实现(兼容 v1alpha1 或 v1)的可用容器运行时。
简而言之，Docker 并不支持 CRI(容器运行时接口)这一 Kubernetes 运行时 API，而 Kubernetes 用户一直以来所使用的其实是名为“dockershim”的桥接服务。
Dockershim 能够转换 Docker API 与 CRI，但在后续版本当中，Kubernetes 将不再提供这项桥接服务。
当然，Docker 本身也是一款非常强大的工具，可用于创建开发环境。但为了了解造成当前状况的原因，我们需要全面分析 Docker 在现有 Kubernetes 架构中的作用。
Kubernetes 是一款基础设施工具，可对多种不同计算资源(例如虚拟/物理机)进行分组，使其呈现为统一的巨量计算资源，从而供应用程序使用或与其他人共享。
在这样的架构中，Docker(或者容器运行时)仅用于通过 Kubernetes 控制平面进行调度，从而在实际主机内运行应用程序。
通过以上架构图，可以看到每个 Kubernetes 节点都与控制平面彼此通信。各个节点上的 kubelet 获取元数据，并执行 CRI 以在该节点上运行容器的创建/删除。
Docker 为什么会被弃用?
如前所述，Kubernetes 只能与 CRI 通信，因此要与 Docker 通信，就必须使用桥接服务。这就是第一点原因。
要解释下一个原因，我们必须稍微解释一下 Docker 架构。首先参考以下示意图：
没错，Kubernetes 实际上需要保持在红框之内。Docker 网络与存储卷都被排除在外。
而这些用不到的功能本身就可能带来安全隐患。事实上，你拥有的功能越少，攻击面也就越小。因此，我们需要考虑使用替代方案，即 CRI 运行时。
CRI 运行时的实现方案主要有两种：
①containerd
如果大家只是想从 Docker 迁移出来，那么 containerd 就是最好的选择。因为它实际上就是在 Docker 之内起效，可以完成所有“运行时”工作，如上图所示。更重要的是，它提供的 CRI 其实 100% 就是由 Docker 所提供。
containerd 还属于全开源软件，因此你可以在 GitHub 上查看说明文档甚至参与项目贡献：
- https://github.com/containerd/containerd/
②CRI-O
CRI-O 是主要由 Red Hat 员工开发的 CRI 运行时。它的最大区别在于并不依赖于 Docker，而且目前已经在 Red Hat OpenShift 中得到使用。
有趣的是，RHEL 7 同样不官方支持 Docker。相反，其只为容器环境提供 Podman、Buildah 以及 CRI-O：
- https://github.com/cri-o/cri-o
CRI-O 的优势在于其采用极简风格，或者说它的设计本身就是作为“CRI”运行时存在。
不同于作为 Docker 组成部分的 containerd，CRI-O 在本质上属于纯 CRI 运行时、因此不包含除 CRI 之外的任何其他内容。
从 Docker 迁移至 CRI-O 往往更为困难，但无论如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常运行。
还有一点，当我们谈论容器运行时时，请注意我们到底是在谈论哪种类型的运行时。
运行时分为两种：
- CRI 运行时
- OCI 运行时
CRI 运行时
正如之前所提到，CRI 是 Kubernetes 提供的 API，用于同容器运行时进行通信以创建/删除容器化应用程序。
各容器化应用程序作为 kubelet 通过 IPC 在 gRPC 内通信，而且运行时也运行在同一主机之上;CRI 运行时负责从 kubelet 获取请求并执行 OCI 容器运行时以运行容器。
稍微有点复杂，接下来我们会用图表来解释：
因此，CRI 运行时将执行以下操作：
- 从 kubelet 获取 gRPC 请求。
- 根据规范创建 OCI json 配置。
OCI 运行时
OCI 运行时负责使用 Linux 内核系统调用(例如 cgroups 与命名空间)生成容器。你可能听说过 runC 或者 gVisor，这就是了。
CRI 会通过 Linux 系统调用以执行二进制文件，而后 runC 生成容器。这表明 runC 依赖于 Linux 计算机上运行的内核。
这也意味着，如果你发现 runC 中的漏洞会使你获得主机 root 权限，那么容器化应用程序同样会造成 root 权限外泄。
很明显，恶意黑客会抓住机会入侵主机，引发灾难性的后果。正因为如此，大家才需要不断更新 Docker(或者其他容器运行时)，而不仅仅是更新容器化应用程序本身。
gVisor 是最初由谷歌员工创建的 OCI 运行时。它实际上运行在承载各类谷歌云服务(包括 Google Cloud Run、Google App Engine 以及 Google Cloud Functions)的同一套基础设施之上。
有趣的是，gVisor 中包含一个“访客内核”层，意味着容器化应用程序无法直接接触到主机内核层。
即使是应用程序“认为”自己接触到了，实际接触到的也只是 gVisor 的访客内核。
gVisor的安全模式非常有趣，这里建议大家参阅官方说明文档：
- https://gvisor.dev/docs/
gVisor 与 runC 的显著差别如下：
- 性能更差
- Linux内核层并非 100% 兼容，参见官方文档中的兼容性部分：
- https://gvisor.dev/docs/user_guide/compatibility/
- 不受默认支持
总结：
- Docker 确被弃用，大家应该开始考虑使用 CRI 运行时，例如 containerd 与 CRI-O。containerd 与 Docker 相兼容，二者共享相同的核心组件。如果你主要使用 Kubernetes 的最低功能选项，CRI-O 可能更为适合。
- 明确理解 CRI 运行时与 OCI 运行时之间的功能与作用范围差异。
根据你的实际工作负载与业务需求，runC可能并不总是最好的选择，请酌情做出考量!
废弃 Docker，但别慌!
在 1.20 版本之后，Kubernetes 将不再支持把 Docker 作为容器运行时使用。
不必惊慌，实际上没多大影响。
PS：这里只是不建议将 Docker 作为底层运行时，你仍然可以使用专为Kubernetes创建的容器运行时接口(CRI)一如既往地在集群中运行 Docker 镜像。
对于 Kubernetes 最终用户，此次调整同样不会有太大影响。Docker 不会就此消亡，你也仍然可以继续将 Docker 作为开发工具使用。
Docker 会继续构建起不计其数的容器，而运行 docker build 命令所生成的镜像仍可在 Kubernetes 集群内正常运行。
如果你使用的是 GKE 或者 EKS 等托管 Kubernetes 服务，则需要确保在未来的 Kubernetes 版本彻底去除 Docker 支持之前，为你的工作节点引入受支持的容器运行时。
如果节点中包含自定义项，你可能需要根据当前环境及运行时要求做出更新。请与服务供应商合作，确保正确完成升级测试及规划。
如果你的集群一直在滚动扩展，则需要配合变量以避免服务中断。在 1.20 版本中，你将收到 Docker 弃用警告。
而在未来的 Kubernets 版本(计划在 2021 年下半年发布的 1.23 版本)中，Docker 运行时将被彻底移除、不再受到支持，届时您必须切换至其他兼容的容器运行时，例如 containerd 或者 CRI-O。
只需要保证你所选定的运行时，能够支持当前使用的 Docker 守护程序配置即可(例如日志记录)。
既然问题不大，大家在慌什么?在怕什么?
这里我们需要探讨两种不同的环境，而这也是恐慌情绪的根源。首先，在 Kubernetes 集群内部存在一种叫作容器运行时的东西，负责提取并运行容器镜像。
Docker 是目前最流行的运行时选项(其他常见选项还包括 containerd 与 CRI-O)。
但 Docker 在设计上并未考虑到被嵌入 Kubernetes 这种用法，所以可能引发问题。
很明显，这里我们提到的“Docker”并不是同一种东西——它代表着一整套技术栈，而 containerd 高级容器运行时则是 Docker 中的一部分。
Docker 很酷、实用性极强，提供多种用户体验增强功能，让我们能够在开发过程中轻松完成协同交互。
但是，用户体验增强功能对 Kubernetes 来说并非必需，因为 Kubernetes 并不是什么人类协作方。
结果就是，要想让 containerd 这个人类友好型抽象层发挥作用，Kubernetes 集群就必须引入另一款名为 Dockershimi 的工具。
但这款工具的介入又引发了新的问题，因为我们必须额外加以维护，否则就可能引发安全问题。
事实上，Dockershim 早在 Kubelet 1.23 版本时就已经被移除，或者说 Kubelet 很早就取消了将 Docker 作为容器运行时的功能。
这时候很多朋友可能要问，既然 Docker 栈中已经包含 containerd，Kubernetes 为什么还要画蛇添足地搞出个 Dockershim?
这是因为 Docker 与 CRI(即容器运行时接口)并不相容。正是因为不相容，所以我们才需要 Dockershim 来缓冲一下。
但这不是什么大问题，各位没必要惊慌!这件事的本质，就是把容器运行时从 Docker 转换为另一种受支持的选项。
这里需要注意的是：如果大家将底层 Docker 套接字(/var/run/docker.sock)设定为集群工作流中的一部分，那么转换至其他运行时会破坏掉当前业务的正常运行。
这种模式称为 Docker in Docker，好在我们可以使用多种选项解决这个特定用例，包括 Kaniko、Img 以及 Buildah 等等。
对开发者来说意味着什么?
但这种变化对开发者意味着什么?我们还需要编写 Dockerfiles 吗?未来还应不应该继续使用 Docker?
请注意，本次变更所影响到的环境，其实跟大多数人用于进行 Docker 交互的环境并不是一回事。
你在开发中使用的 Docker 安装，与 Kubernetes 集群中的 Docker 运行时毫无关系。我知道，这事听起来让人有点犯迷糊。
总之，对于开发人员，Docker 在公布此次更改之前提供的所有方案都仍然适用。
Docker 生成的镜像实际上并不特定于 Docker，更准确地说它应该属于 OCI(开放容器倡议)镜像。
任何与 OCI 相兼容的镜像，无论使用哪种工具构建而成，对于 Kubernetes 来说都是一样的。
Containerd 与 CRI-O 都能识别这些镜像并正常运行，这也是我们建立一套统一容器标准的意义所在。
因此，虽然变化即将到来，虽然会给部分用户带来麻烦，但影响并不算大。而且从长远角度看，这其实是件好事。
总而言之，希望大家放下抵触和恐慌情绪，坦然接受这个变化。
参考链接：
- https://kubernetes.io/blog/2020/12/02/dont-panic-kubernetes-and-docker/
- https://dev.to/inductor/wait-docker-is-deprecated-in-kubernetes-now-what-do-i-do-e4m
出处：内容来源公众号分布式实验室(ID：dockerone)
