这一刻已经来了很久。Kubernetes在1.20版本之后弃用Docker作为容器运行时，转而使用使用为Kubernetes创建的Container Runtime Interface(CRI)的运行时。但是，这并不意味着Docker的死亡，也不意味着您也应该放弃自己喜欢的容器化工具。

事实上，作为Kubernetes的最终用户，对您来说并没有很多改变。您仍然可以使用Docker来构建容器，并且通过运行docker build生成的映像仍将在您的Kubernetes集群中运行。

那么，为什么要这么大惊小怪呢?发生了什么变化，为什么Docker突然看起来像是黑羊呢?我们应该继续编写Dockerfiles吗?

不要惊慌

这里引起混乱的原因是我们在谈论两种不同的事情。在Kubernetes集群节点内部，容器运行时守护程序管理着完整的容器生命周期：映像拉取和存储，容器执行和监督，网络附件等等。

Docker无疑是最受欢迎的选择。但是，Docker并非旨在嵌入Kubernetes中。这是所有问题的根源。Docker不仅仅是容器运行时;它是整个技术堆栈，具有许多UX增强功能，使我们可以轻松地与其进行交互。实际上，Docker本身包含一个高级容器运行时：contined。并且containerd将是您前进的容器运行时选项。

而且，这些UX增强功能对于Kubernetes来说不是必需的。如果有的话，它们是Kubernetes必须变通以获取其真正需求的障碍。这意味着Kubernetes集群必须使用另一个名为Dockershim的工具，该工具是容器化的。这增加了一定程度的复杂性以及团队应维护的另一种工具。另一个可能产生错误和问题的来源。

因此，这里真正发生的是Kubernetes将删除1.23版中的Dockershim，这将中断Docker支持。

你应该在乎吗?

那么，作为开发人员，您正在改变什么?没有那么多。如果在开发过程中使用Docker，则将继续这样做，并且不会发现任何差异。当您使用Docker构建映像时，结果并不是特定于Docker的。这是一个OCI(开放容器倡议)图片。Kubernetes及其兼容的容器运行时(例如容器化或CRI-O)知道如何提取和使用这些映像。这就是为什么我们首先要制定容器外观标准的原因。

另一方面，如果您使用的是托管的Kubernetes服务(例如GKE或EKS)，则需要确保节点在运行受支持的容器运行时之前重新应用Docker支持或更新自定义配置(如果使用)任何。如果您是在本地运行Kubernetes，则还应该进行更改以避免不必要的问题和意外情况。

结论

在1.20版中，您将收到Docker的弃用警告。这种变化即将到来，并且像其他任何变化一样，它一开始可能会引起一些问题。但这不是灾难性的，从长远来看，它将使事情变得更容易。

我希望本文能使事情变得更清楚，并减轻一些焦虑。归根结底，这些更改对于您作为开发人员而言可能毫无意义。