Kubernetes 对 dockershim 的支持将于 5 月 3 日结束

即将于 5 月 3 日延迟发布的 Kubernetes 1.24 版本标志着流行的开源容器编排系统的重大转变，因为对 dockershim 的内置支持将一劳永逸地删除。 Docker 是 Kubernetes 使用的第一个容器运行时。
但随着 Kubernetes 项目向自己的开放容器倡议 (OCI) 过渡，它需要一个权宜之计，以实现与各种其他容器运行时的可移植性。这个权宜之计就是 dockershim。 从本质上讲，dockershim 最初旨在作为一种临时解决方案，允许流行的 Docker 引擎容器运行时将 OCI 调用转换为 Kubernetes 自己的容器运行时接口 (CRI) 中的 Docker 调用。
随着时间的推移，dockershim 在 Kubernetes 部署中变得根深蒂固，但速度变慢了降低部署并给维护者带来负担。它不得不去。 Kubernetes v1.
24 版本现在预计在 5 月 3 日发布，它将要求想要使用最新版本软件的用户从 dockershim 迁移到与 Kubernetes 自己兼容的另一个运行时，或者使用 dockershim 开发的外部替代品通过 Mirantis，称为 cri-dockerd。 虽然 Kubernetes 节点将不再默认使用 Docker 运行时，但许多开发人员和管理员已经切换到其他符合 CRI 的运行时，例如 Docker 本身在 2017 年捐赠给 CNCF 的 containerd 和本机 CRI-O。这通常涉及确保在集群中的每个节点上运行的 kubelet 代理配置为调用 containerd 或 CRI-O 套接字。
各种托管 Kubernetes 供应商已经开始行动，例如 Red Hat OpenShift，它在 2019 年采用了 CRI-O。亚马逊的 Elastic Kubernetes Service (EKS)、微软的 Azure Kubernetes Service (AKS) 和 Google 的 Kubernetes Engine (GKE) 已经默认使用 containerd . Microsoft 还为使用 Kubernetes 版本 1.
19 或更高版本创建的 Azure Kubernetes Linux 节点池采用了 containerd。 不使用符合 CRI 的运行时替换 dockershim 的开发人员可能会破坏他们的集群并落后于安全补丁，同时也会错过新功能。 “在这一点上，我们相信您（和 Kubernetes）从 dockershim 移除中获得的价值弥补了您将要进行的迁移工作，”Kubernetes 发布团队在一月份的一篇博文中写道。
开发人员仍然可以在本地使用 Docker 来开发或测试他们的容器，无论他们为 Kubernetes 集群使用哪个容器运行时。 Docker 生成的映像将继续在具有所有 CRI 兼容运行时的集群中工作，但不会继续受支持..