跳到主要内容

一些杂乱知识的总结与比较

CRI​

CRI，即容器运行时接口（Container Runtime Interface），用于定义容器运行时（如Docker、containerd等）与Kubernetes系统之间的接口规范。

CRI主要包括两个部分：

  1. gRPC API：这部分定义了 Kubernetes（特别是 kubelet）与容器运行时之间进行交互所需的一系列远程过程调用（RPC）接口。这些接口规定了如何创建、启动、停止和删除容器，以及如何管理容器的生命周期。但是，它们本身并不包含任何具体的实现代码；它们只是一系列的规范，描述了接口的结构和期望的行为。

  2. 容器运行时实现：这是指根据 CRI gRPC API 规范开发的容器运行时，如 Docker、containerd、CRI-O 等。这些容器运行时实现了 CRI 的接口，使得 Kubernetes 可以通过这些标准化的接口与它们进行交互。

OCI​

OCI（开放容器倡议，Open Container Initiative）是一个由一系列行业领导者共同发起的项目，旨在创建开放的标准，用于构建和运行容器。OCI 的主要目标是确保容器的互操作性和标准化，从而促进容器技术的广泛采用和可持续发展。

OCI 主要包括两个核心标准：

  1. OCI 运行时规范（Runtime Specification）：这个规范定义了容器运行时的环境，包括如何启动容器、容器应该如何运行以及它们与底层系统的交互方式。这使得容器能够在遵循该规范的任何运行时环境中一致地运行。

  2. OCI 镜像规范（Image Specification）：这个规范定义了容器镜像的格式和内容。容器镜像是一种轻量级、可执行的软件包，包含运行应用程序所需的代码、运行时、系统工具、系统库以及设置。遵循 OCI 镜像规范确保了容器镜像可以在不同的容器运行时环境中一致地被创建、管理和运行。

Docker vs containerd vs CRI-O​

在网上找到一张图，很好的解释了这三者之间的关系。

k8s-concepts.png

  • Docker 和 containerd 属于同一血统。

    • 在 Docker 最初的版本中，它包含了容器的整个生命周期管理功能，从容器创建到容器运行再到容器销毁，都由 Docker 自身来完成。
    • 后来，Docker 将容器的生命周期管理功能抽取出来，形成了一个独立的组件，即 containerd。这个过程是为了模块化和简化 Docker 的架构。
    • 在 containerd 分离出来之后，Docker 作为一个更高层级的工具，依赖于 containerd 来处理底层的容器运行时任务。Docker 则提供用户友好的接口和命令行工具，使得用户可以更容易地构建、运行和管理容器。

  • Docker 和 contained 在 Kubernetes 中的运行时架构变化

    • containerd 最初是 Docker Inc. 开发的，后来它被捐赠给了 CNCF，成为了 CNCF 的一个独立项目。CNCF 全称为 Cloud Native Computing Foundation，是一个旨在推动云原生技术发展的非营利组织，由 Linux 基金会托管。

    • Docker 原生并不支持 CRI，所以使用 dockershim 作为媒介来与 kuberlet 通信。

    • 在 containerd 1.0 版本里开始使用 CRI-Containerd 作为 CRI 的实现，这样就可以直接与 kubelet 通信了。

    • 再后来 containerd 1.1 版本里，CRI 支持被作为一个默认的内置插件加入到 containerd 中，这意味着不再需要 CRI-Containerd 了，因为 containerd 本身就能够与 kubelet 通信。这种整合减少了一层通信媒介，从而提高了性能并减少了资源的消耗。

    • 在 kubernetes 1.2 版本里已经开始弃用 dockershim 了，因此在 1.2 版本之后要么使用 containerd 作为 CRI 运行时，要么使用 CRI-O 作为 CRI 运行时。(可能还有其它的，但是这两个是主流的)

      docker-and-containerd-develop-process.jpg