Kubernetes为什么弃用Docker？

docker
笔记

从 Kubernetes v1.24 开始，Dockershim正式移除

我们在社区中看到了一些困惑（有时达到恐慌的程度），和对这一决定的不满，很大程度上是由于缺乏关于为什么要弃用并最终将 dockershim 从 Kubernetes 移除的原因。

那么，dockershim 是什么

在 Kubernetes 的早期，我们只支持一个容器运行时。那个运行时是 Docker Engine。当时，没有太多其他选择，Docker 是处理容器的主要工具，所以这不是个有争议的选择。最终，我们开始添加更多的容器运行时，比如 rkt 和 hypernetes，很明显 Kubernetes 用户希望选择最适合他们的运行时。因此 Kubernetes 需要种方法，来允许集群操作者灵活地使用他们选择的任何运行时。

发布CRI（Container Runtime Interface，容器运行时接口）就是为了提供这种灵活性。CRI 的引入对项目和用户来说都很棒，但它也引入了一个问题：Docker Engine 作为容器运行时的使用早于 CRI，Docker Engine 与 CRI 不兼容。为了解决这个问题，引入了一个小软件垫片（"shim"，dockershim）作为 kubelet 组件的一部分，专门用于填补 Docker Engine 和 CRI 之间的空白，使得默认情况下继续使用 Docker Engine 作为他们的容器运行时。

为什么要移除它？

然而，这个小小的软件垫片从来就不是永久的解决方案。多年来，它的存在给 kubelet 本身带来了许多不必要的复杂性。由于这个垫片，Docker 的一些集成实现不一致，导致维护人员的负担增加，并且维护特定于供应商的代码不符合我们的开源理念。为了减少这种维护负担，并向一个支持开放标准的更具协作性的社区发展，建议去掉 dockershim。随着 Kubernetes v1.20 的发布，这一弃用成为正式。

不是弃用，而是代码解耦

我们没有很好地传达这一点，不幸的是，弃用声明导致了社区内的一些恐慌，这是我们的过失；我们应该更清楚地沟通当时发生了什么以及原因。为了解决这个问题，Docker 和 Mirantis 共同同意以 cri-docker 的形式继续支持 dockershim 代码，允许你在需要时继续使用 Docker Engine 作为你的容器运行时。

无论是作为工具还是作为公司，Docker 都不会消失。它是云原生社区和 Kubernetes 项目历史的重要组成部分。没有他们我们不会有今天。也就是说，从 kubelet 中移除 dockershim 最终对社区、生态系统、项目和整个开源都有好处。这是我们所有人一起支持开放标准的机会，我们很高兴在 Docker 和社区的帮助下这样做。

最后

所以，当在kubernetes 1.24+之后的版本中，只需要安装cri-docker即可继续使用docker engine了。