关注
HarmonyOS技术社区
，回复
【鸿蒙】
送
小米小爱音箱mini
（数量不多，先到先得）
，还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
近日，Kubernetes 官方发布公告，宣布自 v1.20 起放弃对 Docker 的支持，届时用户将收到 Docker 弃用警告，并需要改用其他容器运行时。
图片来自 Pexels
但 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 以在该节点上运行容器的创建/删除。
如前所述，Kubernetes 只能与 CRI 通信，因此要与 Docker 通信，就必须使用桥接服务。这就是第一点原因。
要解释下一个原因，我们必须稍微解释一下 Docker 架构。
首先参考以下示意图：
没错，Kubernetes 实际上需要保持在红框之内。Docker 网络与存储卷都被排除在外。
而这些用不到的功能本身就可能带来安全隐患。事实上，你拥有的功能越少，攻击面也就越小。因此，我们需要考虑使用替代方案，即 CRI 运行时。
CRI 运行时的实现方案主要有两种：
①containerd
如果大家只是想从 Docker 迁移出来，那么 containerd 就是最好的选择。因为它实际上就是在 Docker 之内起效，可以完成所有“运行时”工作，如上图所示。更重要的是，它提供的 CRI 其实 100% 就是由 Docker 所提供。
containerd 还属于全开源软件，因此你可以在 GitHub 上查看说明文档甚至参与项目贡献：
https://github.com/containerd/containerd/
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 是 Kubernetes 提供的 API，用于同容器运行时进行通信以创建/删除容器化应用程序。
各容器化应用程序作为 kubelet 通过 IPC 在 gRPC 内通信，而且运行时也运行在同一主机之上；CRI 运行时负责从 kubelet 获取请求并执行 OCI 容器运行时以运行容器。
