OCI 简介

在容器化技术的演进中，OCI（Open Container Initiative）提供了一套标准化的规范，帮助统一容器的构建、分发和运行。OCI 规范包含三个部分：

下文将结合从代码到容器的完整 CICD 流程，详细讲解每个 OCI 规范的具体作用。

从代码到容器

1. Code -> OCI Image

代码被集成之后，便可以使用 docker、podman/buildah 或者 kaniko 等工具来构建容器镜像。

此时，OCI Image-spec 便发挥了重要的作用，该规范定义了镜像的组成部分，使得不同工具能够跨平台识别和使用同一个镜像。

由于 docker 对行业的影响力，部分从业者会认为 image 就是 docker image，这其实并不对，准确来说，docker 只是工具之一，不管是使用什么工具构建出来的镜像应该统称为 OCI image。

OCI Image-spec 规范定义了镜像的结构，一个 image 至少包括：

让我们看看 busybox 这个镜像的结构：

从上图中可以看到，manifest 元数据文件、config 配置文件、layers 层文件一应俱全。

一个 image 其实也只是一堆文件和文件夹的集合。

2. OCI Image -> Registry

在镜像构建完成后，需要推送到镜像仓库。OCI Distribution-spec 规范则定义了镜像如何通过标准的 HTTP API 在仓库中存储、拉取和分发。

OCI Distribution-spec 规范确保了不同的仓库和客户端可以使用统一的 API 进行镜像的分发。这样仓库既可以使用公共仓库（如 Docker Hub），也可以使用私有仓库（如 Harbor）。而客户端只要使用规范中的 HTTP 请求则都可以上传或下载镜像。

3. Kube-API-Server -> Kubelet -> Containerd/CRI-O

镜像上传完成之后，便可以创建或更新应用了。所有请求统一先由 kube-api-server 处理，然后 scheduler 将 Pod 调度到节点上，随后节点上的 kubelet 负责后续处理。

kubelet 通过 CRI gRPC 与具体的组件 Containerd 或 CRI-O 进行交互，由后者完成镜像的下载和容器的创建。

4. Containerd/CRI-O -> Runc/Kata-containers

Containerd 和 CRI-O 本身并不直接负责容器的创建和运行，它们会通过 OCI Runtime-spec 与底层容器执行工具 runc 或 kata-containers 交互，由 runc 或 kata-containers 完成容器的执行。

Runc 和 Kata-containers：

OCI runtime-spec 规范规定了：

如何查看 OCI runtime-spec 规定的 config.json 文件？

我创建了一个 busybox ，它的 OCI runtime-spec config.json 如下图所示：

而这个 OCI runtime-spec 规定的 config.json 其实就是 Containerd 或 CRI-O 根据 Pod 的定义（命令及参数、环境变量、资源限制等等）和上下文等信息生成的。

总结

从代码到容器实际运行，整个过程中多个组件和标准紧密协作，本文重点关注了 OCI 的三个核心规范（image-spec、distribution-spec 和 runtime-spec），这些规范确保了容器在不同环境中的兼容性和可移植性，正如 OCI 这个名字的含义一样 —— 开放容器倡议。

(关注我，无广告，专注于技术，不煽动情绪)

参考资料：