管理员们可以直到2021年下半年才改弦易辙，但是Windows容器需要谨慎了。
云原生计算基金会（CNCF）大使Ian Coldwater近日在Twitter上说：“Kubernetes现已弃用了对Docker的支持。您需要注意这一点，并作好相应的规划。这会搞坏您的集群。”
这则消息无异于在开发者群体当中扔了一颗重磅炸弹，不过需要引起管理员们的注意：Kubernetes仍将运行Docker容器。
Coldwater的推文旨在引起人们的注意，它的确收到了这种效果。Docker容器无处不在，并嵌入到现代应用程序开发和部署中。那么，这到底是怎么一回事？
问题就在于，“Docker”在不同的上下文中有不同的含义。即将发布的Kubernetes 1.20的版本发布说明声明如下：
kubelet中对Docker的支持现已被弃用，并将在未来的版本中被删除。kubelet使用一个名为“dockershim”的模块，该模块实现了针对Docker的CRI支持，结果发现Kubernetes社区中出现了维护问题。我们鼓励大家进行一番评估，考虑完整实现CRI（与v1alpha1或v1兼容）的容器运行时环境在第一时间发布后要不要改用。
CRI的全称是“容器运行时接口”，这种API面向主要用来启动和停止容器的运行时环境。Docker是一种容器运行时环境，但是它没有实现CRI，因此需要版本发布说明中提到的库（shim）。最好使用一种替代的运行时环境，比如containerd或CRI-O。Docker本身使用containerd，但添加了对开发有用，Kubernetes却通常不需要的额外功能。
Docker发言人称：“开发人员仍然可以使用Docker来构建镜像，无需任何更改。这主要影响使用Docker Engine作为运行时环境的运维人员/管理员，因为Kubernetes完全改而使用containerd来运行它们。他们将需要改而使用containerd作为其Kubernetes集群的容器运行时环境。Docker Engine是拥有某种额外功能的containerd，比如就Kubernetes而言无论如何开发人员其实不需要的UX（用户体验）。由于containerd现在已成为Docker和Kubernetes的核心部分，这种精简是个好消息。”
还请注意，Kubernetes 1.20仍支持Docker。针对该话题的常见问题解答（FAQ）简单回答如下：“如果使用Docker作为运行时环境，1.20中唯一出现变化的是kubelet启动时打印输出一个警告日志。”工作团队声称，没有dockershim的最早版本“将是2021年年底发布的1.23。”
话虽如此，从Docker改为一种不同的运行时环境还是存在一些问题。上面的FAQ附有列表，其中包括日志记录配置、节点配置脚本、可能需要Docker的Kubectl（面向Kubernetes的命令行工具）插件以及与GPU或其他特殊硬件的集成。
还存在Windows容器方面的问题，FAQ并没有提到。如该文（https://cloudblogs.microsoft.com/opensource/2020/04/03/kubernetes-v1-18-advances-windows-container-support/）所述，在Kubernetes 1.18之前，Docker是“唯一受支持的面向Windows的容器运行时环境”。在1.18中，添加了对containerd的支持，不过是alpha测试版的质量，因此不打算用于生产环境。文档声称，到目前为止，“Docker EE-basic 19.03+是受推荐的面向所有Windows Server版本的容器运行时环境。这可与kubelet中包含的dockershim代码兼容，”不过“ContainerD 1.4.0-beta.2 +还可以用作Windows Kubernetes节点的容器运行时环境。”ContainerD Windows支持拥有面向Kubernetes 1.20或更高版本的“稳定发行版目标”。这给使用Windows容器的那些人传达的消息就是别急着更换。
VMware的首席工程师Joe Beda 是Kubernetes的联合创始人说：“真没想到弃用docker/docker-shim的这则消息造成了如此大范围的混乱。”那边Coldwater则反思：“很抱歉今天早上我引起了恐慌。我的本意是想提前请大家注意弃用对Docker的支持，以便大家对此有所规划，因为对于一些人来说，这将是一个重大的突发性变化，需要时间来解决，看看是否可行。但这也使大家备感压力。”
