我们来看看Kubernetes、Docker、Dockershim、Containerd、runc、CRI、CRI-O、OCI的到底有什么关系?

Kubernetes v1.20版本 的 release note 里说 deprecated docker。并且在后续版本 v1.24 正式删除了 dockershim 组件,这对我们有什么影响呢?

为了搞明白这件事情,以及理解一系列容器名词 docker, dockershim, containerd, containerd-shim, runC, CRI, OCI...。我们先捋一下 Kubernetes 与 Docker 的发展与关系。

1、Docker:

Docker 是一个开源的容器化平台,可以创建、部署和运行容器应用程序。Docker 使用了自己的容器格式(Docker Image)和运行时(Docker Engine),并提供了一整套容器生态系统,包括 Docker Compose、Docker Swarm 等。

从 Docker 1.11 版本开始,Docker 容器运行就不是简单通过 Docker Daemon 来启动了,而是通过集成 containerd、containerd-shim、runC 等多个组件共同完成。

其中 containerd 是 CRI(contianer runtime interface:标准 grpc 接口,容器管理操作标准) 的一种实现,containerd-shim 是 containerd 和 runC 之间的中间层, 而 runC 则是 OCI(开放容器标准)参考实现。

containerd:containerd 是一个开源的容器运行时,可以管理和运行容器。它是 Docker 在 2016 年开源的一个组件,可以独立于 Docker 运行。Docker 默认使用 containerd 来管理容器。

2、OCI:

Open Container Initiative,开放容器倡议,是一个开放组织,致力于创建容器格式和运行时的开放标准。OCI 标准化了容器镜像格式和运行时规范,使得不同厂商和组织可以共享相同的容器格式和运行时。

OCI是由 Docker、CoreOS 等组织对容器格式及运行时建立统一的行业标准。

OCI主要定义两个规范:

  • 镜像规范(image-spec)定义了镜像的主要格式及内容

  • 运行时规范(runtime-spec) 运行时规范定义镜像文件运行的管理, 而 runC 则是 目前使用最广泛的Low-Level容器运行时(runC 包含libcontainer,包括对namespace和cgroup的调用操作)。

接下去看下目前市面上最主流的3个High-Level容器运行时(High-Level包括镜像传输、镜像管理、镜像解包和 API等高级功能)

  • Containerd :CNCF孵化器的开源项目,由 Docker捐献的

  • Podman():Redhat孵化的项目,Podman 工具在RHEL8中作为完全支持的功能发布。

  • CRI-O : CNCF孵化器的开源项目

我们再继续看一下 容器运行关系:

基于Containerd作为容器运行时的Docker可以定义为"High-High-Level"容器运行时。

关于 containerd 和 CRI 的关系要注意一些时间点:

  • containerd 在 2016年初被拆出来

  • CRI 标准在2016 年末出来的 (早于 containerd)

  • containerd 在2017年3月进入CNCF之后才添加了CRI支持.

3、CRI(Container Runtime Interface):

如上面所说,目前比较主流的High-Level容器运行时有Containerd、CRI-O 以及PodMan等,每个容器运行时都有其自身的特性和优势, 而为了统一标准,更具扩性,Kubernetes 提出了容器管理的标准规范 CRI。主要定义了一组 grpc 接口, 它是容器运行时接口,是 Kubernetes 容器管理器与容器运行时之间的接口,定义了 Kubernetes 如何与容器运行时通信,以便启动、停止和管理容器。


4、CRI-O:

CRI-O 是一个符合 CRI 规范的轻量级容器运行时,专门为 Kubernetes 设计。它是一个完全独立于 Docker 的项目,可以支持多种容器格式,如 OCI 和 Docker Image。

5、runc:runc 是一个标准的、轻量级的容器运行时,实现了 OCI 容器运行时规范。runc 是 Docker 容器运行时的核心组件之一,也是其他容器平台(如 Kubernetes、CRI-O)的默认容器运行时。

6、Kubernetes 与 dockershim:

从Kubernetes的架构图中,可以看到 Kubelet 下面还有一层Contianer runtime (容器运行时)是作为真正和OS去交互的,这个容器运行时是真正地管理容器的整个生命周期的以及拉取镜像等操作的。

Kubernetes1.24版本正式删除和弃用dockershim。这件事情的本质是废弃了内置的 dockershim 功能,直接对接Containerd(后续已经支持 CRI)。这种方式更加标准,调用的链路更加的简洁。

从上可见,CRI可以实现kubelet对containerd、CRI-O的统一管理。同时,Kubernetes 1.24将dockershim 组件从 kubelet 中删除后,也建议用户使用更加轻量的容器运行时 containerd 或 CRI-O

小结

综上所述,Docker 是一个完整的容器化平台,包括容器格式、运行时和生态系统;containerd 是 Docker 的一个组件,用于管理容器;CRI 定义了 Kubernetes 与容器运行时之间的接口;CRI-O 是符合 CRI 规范的轻量级容器运行时;OCI 定义了容器镜像格式和运行时规范;runc 实现了 OCI 容器运行时规范,是其他容器平台的默认容器运行时。

思考:

未来什么会替代Kubernetes?


本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场,不承担相关法律责任。如若转载,请注明出处。 如若内容造成侵权/违法违规/事实不符,请点击【内容举报】进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部