Kubernetes v1.24发布，Dockershim弃用！

首先，这对你有影响吗？

如果您正在滚动自己的集群或不确定此删除是否会影响您，请保持安全并检查您是否对 Docker Engine 有任何依赖关系^[3]。

请注意，使用 Docker Desktop 构建的应用程序容器，不是集群的 Docker 依赖项。由 Docker 创建的容器镜像符合开放容器倡议 (OCI)^[4]，这是一种 Linux 基金会治理结构，围绕容器格式和运行时定义行业标准。它们可以在 Kubernetes 支持的任何容器运行时上正常工作。

如果您使用来自云提供商的托管 Kubernetes 服务，并且您没有显式更改容器运行时，那么您可能不需要做任何事。Amazon EKS、Azure AKS 和 Google GKE 现在都默认使用 containerd，但如果您有任何节点自定义，您应该确保它们不需要更新。要检查节点的运行时，请遵循找出节点上使用的容器运行时^[5]。

无论您是滚动自己的集群还是使用来自云提供商的托管 Kubernetes 服务，您都可能需要迁移依赖于 Docker Engine 的遥测或安全代理^[6]。

我有一个 Docker 依赖项。现在怎么办？

如果您的 Kubernetes 集群依赖于 Docker Engine，并且您打算升级到 Kubernetes v1.24（出于安全和类似原因，您最终应该这样做），您需要将容器运行时从 Docker Engine 更改为其他内容或使用cri-dockerd^[7] . 由于containerd^[8]是一个毕业的 CNCF 项目和 Docker 本身的运行时，因此作为替代容器运行时是一个安全的选择。幸运的是，Kubernetes 项目已经记录了更改节点容器运行时^[9]的过程，以 containerd 为例。切换到其他支持的运行时之一的说明类似。

我想升级 Kubernetes，我需要保持与 Docker 作为运行时的兼容性。我有哪些选择？

不要害怕，您不会被冷落，也不必冒着停留在旧版本 Kubernetes 上的安全风险。Mirantis 和 Docker 联合发布并正在维护 dockershim 的替代品。该替换称为cri-dockerd^[10]。如果您确实需要保持与 Docker 作为运行时的兼容性，请按照项目文档中的说明安装 cri-dockerd。

总结

只要您在进入此版本时了解所做的更改和您自己的集群的详细信息，并确保与您的开发团队进行清晰的沟通，出现问题的概率就会降到最低。您可能需要对集群、应用程序代码或脚本进行一些更改，但所有这些要求都已记录在案。从使用 Docker Engine 作为您的运行时切换到使用其他受支持的容器运行时之一^[11]，实际上意味着删除中间人，因为 dockershim 的目的是访问 Docker 本身使用的容器运行时。从实际的角度来看，从长远来看，这种删除对您和 Kubernetes 维护者都更好。

如果您仍有疑问，请先查看Dockershim 移除常见问题解答^[12]

或评论区交流~

参考资料