【译文】原文地址
当你想到Kubernetes你会想到容器。当你想到容器时，你会想到Docker。因此，当Kubernetes的维护者在2020年12月宣布将放弃Docker对Kubernetes v1.20+的支持时，人们感到非常惊讶。这引起了相当多的关注和困惑。
在Kubernetes中弃用Docker?这听起来像是2020年非常热门的一条信息。虽然Docker是容器的同义词，但很多人没有意识到作为一个产品，Docker是由多个组件组成的，是一个容器的技术栈。
其中一个组件是容器运行时，是kubernetes与容器交互需要的。容器运行时可以拆分成high-level运行时和low-level运行时两部分。两者作用不同，但工作在一块。high-level运行时主要负责比如从仓库拉取镜像、管理镜像、和处理镜像到low-level运行时的工作。low-level运行时将根据镜像具体负责创建、删除和运行容器。high-level和low-level运行时都遵循特定的规范：容器运行时接口（CRI）和开放容器标准协议（OCI）。
容器运行时接口(CRI)是在Kubernetes 1.5中作为alpha版本引入的。CRI的目标是使Kubernetes生态系统更具可扩展性，为开发人员提供Kubernetes将如何与运行时交互的蓝图。开发人员如何实际设计和实现运行时完全取决于他们，只要满足接口。作为集群维护者，CRI的标准化允许我们决定在我们的环境中使用哪个容器运行时。 这也使得Kubernetes变得更加灵活，因为它现在不需要我们掌握每种特定的运行时。当前可用的两个流行容器运行时是containerD和CRI-O。
开放容器标准协议 (OCI)于2015年由Container领域的领导者发起，他们认为构建容器镜像的方式应该标准化。根据OCI规范构建的镜像将与任何容器运行时适配，只要运行时遵循并符合OCI规范。因此，无论你是用docker还是podman构建容器映像，你的容器镜像都将兼容多个规格，并继续在你的集群中运行。一些主流的OCI运行时有runC、Kata容器（英特尔Clear Containers和Hyper RunV项目）和Gvisor（goole项目）。
现在让我们重新回到主题Docker以及它被弃用的原因。Docker知道如何与容器交互，因为它使用ContainerD作为它的high-level运行时，使用runC作为它的low-level运行时，这两个运行时都位于Docker的多个内层组件中，并被抽象化给用户。尽管ContainerD和runC都是遵循CRI和OCI标准，我们也会遇到一个问题，因为Docker本身不能满足CRI的要求，而CRI是Kubernetes需要与运行时交互的。随着Dockershim的引入，这个问题得到了解决。Dockershim作为Kubernetes和Docker之间的中间件，并且兼容CRI。
然而，Dockershim的一个缺点是，你正在加载整个Docker堆栈，并让Kubernetes与shim通信，shim然后与Dock通信，docker通过调用栈直到它到达containerD。这在容器工作流程中增加了不必要的步骤，因为Kubernetes可以直接与containerD或任何其他CRI兼容的运行时交互。使用Dockershim本来是一种临时的解决方案，但它慢慢地变成了一种负担，因此不得不弃用它。
总之，Kubernetes需要一种与容器交互的方式。这是由处理容器生命周期的容器运行时解决的。Kubernetes可以与任何容器运行时交互，如果它们符合容器运行时接口(container runtime Interface)，该接口定义了Kubernetes将如何与提供的运行时交互。此外，所有的镜像/容器和运行时必须遵循OCI，它定义了如何创建镜像或容器。至于Docker，它是一个抽象了一个容器运行时的技术栈，不符合CRI。
