Kubernetes 不再支持 dockershim

前言

2020 年 5 月 3 日延迟发布的 Kubernetes 1.24 版本发生了重大转变，因为它将结束对 dockershim 的原生支持。Docker 是 Kubernetes 使用的第一个容器运行时。随着 Kubernetes 项目向自己的开放容器倡议 (OCI) 过渡，它需要一个权宜之计来实现与其他各种容器运行时的可移植性。这个权宜之计就是 dockershim。

从本质上讲，dockershim 最初的目的是作为一种临时解决方案，允许流行的 Docker Engine 容器运行时将 OCI 调用转换为 Kubernetes 自己的容器运行时接口 (CRI) 中的 Docker 调用。随着时间的推移，dockershim 在 Kubernetes 部署中变得根深蒂固，由于这种方式会减慢部署的速度，给维护者带来了负担。淘汰它成为了一种必然的选择。

一、如何为 dockershim 弃用做准备

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

虽然 Kubernetes 节点将不再默认使用 Docker 运行时，但许多开发人员和管理员已经切换到其他符合 CRI 的运行时，例如 Docker 自己在 2017 年捐赠给 CNCF 的 containerd 和本机 CRI-O。这就要求在集群中的每个节点上运行的 kubelet 代理配置成调用 containerd 或者 CRI-O 套接字。

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

二、切换到符合 CRI 运行时的优势

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

“在这一点上，我们相信您（和 Kubernetes）从 dockershim 移除中获得的价值弥补了给您带来的迁移工作量，”Kubernetes 发布团队在一月份的博客文章中写道。

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