K8s为什么要放弃Docker

公司定期分享整理的资料

放弃始由

K8s为什么要放弃Docker_第1张图片
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation

2020 年,k8s 1.20 终于正式向 Docker “宣战”:kubelet将弃用 Docker 支持,并将在未来的版本中完全移除。

但由于 Docker 几乎已经成为容器技术的代名词,而且 K8s 已经使用 Docker 多年,该公告在传播时很快“变味了”,“kubelet 将弃用 Docker 支持”被简化为更吸人眼球的东西 “K8s 将弃用”Docker”。这自然引起了 IT 界的恐慌,“不明真相的群众”纷纷表示震惊:用了这么久的 Docker 突然不能用了。

为什么 K8s 会这样对待 Docker?
现有的大量镜像怎么办?

K8s与Docker之间的关系

什么是Docker?

Docker 于 2013 年发布,解决了开发人员在端到端运行容器时遇到的许多问题。下面是他包含的所有东西:
● 容器镜像格式
● 一种构建容器镜像的方法(Dockerfile/docker build);
● 一种管理容器镜像(docker image、docker rm等);
● 一种管理容器实例的方法(docker ps, docker rm 等);
● 一种共享容器镜像的方法(docker push/pull);
● 一种运行容器的方式(docker run);

K8s为什么要放弃Docker_第2张图片
Docker各组件之间通讯时序图
containerd,container-shim 组件本质上是runC 和dockerd 间的中间件

什么是OCI和runc?

OCI (Open Container Initiative)

标准包含 运行时标准 和 镜像标准 两个部分,而 OCI 这个组织则是由 Docker, CoreOS 和其他的一些公司共同发起创建的,致力于将容器运行时和格式标准化。即:凡是遵守此标准的实现,无论是 Docker 还是 rkt 或者其他的运行时实现,均可以通过标准的镜像启动容器。

runc

是在 OCI 成立后,Docker 将其容器运行时 libcontainer 贡献出来后,并加以改造而成的,是Docker按照开放容器格式标准(OCF, Open Container Format)制定的一种具体实现。runc 是一个命令行客户端,用于运行根据 Open Container Initiative (OCI) 格式打包的应用程序,并且是 Open Container Initiative 规范的兼容实现。

什么是K8s?

2014 年Google 推出 Kubernetes是用于自动部署、扩展和管理容器化应用程序的开源系统,它旨在提供跨主机集群的自动部署、扩展以及运行应用程序容器的平台。下面是他包含的所有东西
● 可以使用 containerd、cri-o 或其他 CRI 运行时容器、编配器需要完成很多任务。
● 将容器按照高级原语分组 (Pods、ReplicaSets 等)
● 将运行容器的节点连接到一个公共网络中
● 提供服务发现
K8s为什么要放弃Docker_第3张图片

什么是CRI?

Container Runtime Interface (CRI)

CRI(容器运行时接口)是 Kubernetes 用来控制创建和管理容器的不同运行时的 API,它使 Kubernetes 更容易使用不同的容器运行时。它一个插件接口,这意味着任何符合该标准实现的容器运行时都可以被 Kubernetes 所使用。
K8s为什么要放弃Docker_第4张图片

放弃Docker对K8s有什么好处?

1.Kubernetes 项目增加了对额外运行时的支持

在 Kubernetes 包括一个名为 dockershim 的组件,使它能够支持 Docker。但 Docker 由于比 Kubernetes 更早,并且没有实现 CRI,所以这就是 dockershim 存在的原因,它对docker的支持被硬编码到 Kubernetes 中。随着容器化成为行业标准,比如CRI,Kubernetes 项目增加了对额外运行时的支持,因此 dockershim 成为了 Kubernetes 项目中的一个异类,对 Docker 和 dockershim 的依赖已经渗透到云原生计算基金会(CNCF)生态系统中的各种工具和项目中,导致代码脆弱。那么移除对dockershim对k8s来说好处是巨大的。

K8s为什么要放弃Docker_第5张图片

2.直接调用CRI(containerd等)效率更高

在移除dockershim后,会将conatinerd作为默认容器运行时组件,containerd 1.1 版本已经内置了对 CRI 的实现,比直接使用 Docker 的性能要高很多。并且containerd本身是一个来自 Docker 的高级容器运行时,并实现了 CRI 规范。它是从 Docker 项目中分离出来,之后 containerd 被捐赠给云原生计算基金会(CNCF)为容器社区提供创建新容器解决方案的基础。

放弃Docker原有镜像如何转换?

dockershim 从 Kubernetes 1.24 中完全移除。今后 Kubernetes 将取消对 Docker 的直接支持,而倾向于只使用实现其容器运行时接口的容器运行时。这并不意味着 Kubernetes 将不能运行 Docker 格式的容器。containerd 和 CRI-O 都可以运行 Docker 格式(实际上是 OCI 格式)的镜像,它们只是无需使用 docker 命令或 Docker 守护程序。

K8s1.24后如何构建镜像?Dockerfile?

containerd不能像docker那样可以通过docker commit 容器id或者docker build (dockerfile)这样去直接构建镜像。(本地可以同时存在containerd和docker,但ctr不能在本地直接使用docker的镜像),可以使用buildkit工具进行构建,可以参考下面的文档https://blog.csdn.net/weixin_46015264/article/details/126504718

参考文档

http://k.sina.com.cn/article_1746173800_68147f68019013uo8.html
https://www.51cto.com/article/687502.html
https://www.sohu.com/a/243940957_760387
https://blog.csdn.net/Tongsheng_li/article/details/121650176

你可能感兴趣的:(docker,kubernetes,容器)