5 月 3 日发布的 Kubernetes 1.24 将结束对 dockershim 的支持，需要我们做什么？

最新版本的 Kubernetes 容器编排平台将不再原生支持 Docker 容器运行时，这对用户来说是一个重大变化。

原计划 4 月 19 号，延迟到 5 月 3 日^[1]发布的 Kubernetes 1.24 版本标志着流行的开源容器编排系统的重大转变，因为对内置的 dockershim 支持将一劳永逸地删除^[2]。

Docker^[3]是Kubernetes^[4]使用的第一个容器运行时。但随着 Kubernetes 项目向自己的开放容器倡议 (OCI) 过渡，它需要一个权宜之计，以实现与其他各种容器运行时的可移植性。这个权宜之计就是 dockershim。

从本质上讲，dockershim 最初的目的是作为一种临时解决方案，允许流行的 Docker Engine 容器运行时将 OCI 调用转换为 Kubernetes 自己的容器运行时接口 (CRI) 中的 Docker 调用。随着时间的推移，dockershim 在 Kubernetes 部署中变得根深蒂固，但会减慢部署速度并给维护者带来负担，所以它不得不被移除。

如何为 dockershim 弃用做准备

现在预计在 5 月 3 日发布的 Kubernetes v1.24 版本将要求想要使用最新版本软件的用户从 dockershim 迁移到^[5]与 Kubernetes 自己兼容的另一个运行时，或者使用由 Mirantis 开发的 dockershim 的外部替代品，称为cri-dockerd^[6]。

虽然 Kubernetes 节点将不再默认使用 Docker 运行时，但许多开发人员和管理员已经切换到其他符合 CRI 的运行时，例如 Docker 本身在 2017^[7] 年捐赠给 CNCF 的 containerd 和 CRI-O。这通常涉及确保在集群中的每个节点上运行的 kubelet 代理配置为调用 containerd 或 CRI-O 套接字。

各种托管 Kubernetes 供应商，例如 Red Hat OpenShift，它在 2019 年采用了 CRI-O^[8]。Amazon 的 Elastic Kubernetes Service (EKS)、Microsoft 的 Azure Kubernetes Service (AKS) 和 Google 的 Kubernetes Engine (GKE) 已经默认使用 containerd。Microsoft 还为使用 Kubernetes 1.19 或更高版本创建的 Azure Kubernetes^[9] Linux 节点池采用了 containerd。

切换到符合 CRI 的运行时

不使用符合 CRI 的运行时替换 dockershim 的开发人员可能会使他们的集群落后于安全补丁，同时也会错过新功能。

Kubernetes 维护人员在一月份的一篇博客^[10]文章中写道。“在这一点上，我们相信您（和 Kubernetes）从 dockershim 移除中获得的价值弥补了您将要进行的迁移工作”。

开发人员仍然可以在本地使用 Docker 来开发或测试容器，无论为 Kubernetes 集群使用哪个容器运行时。Docker 生成的镜像将继续在具有所有符合 CRI 的运行时的集群中工作，但不会继续受支持。

参考资料