Kubernetes为什么弃用Docker?

半兽人 发表于: 2022-08-22   最后更新时间: 2022-08-22 15:09:57  
{{totalSubscript}} 订阅, 134 游览

从 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了。

更新于 2022-08-22
在线,1小时前登录

查看docker更多相关的文章或提一个关于docker的问题,也可以与我们一起分享文章
提问