Runc简介一

Open Container Initiative（OCI）

开放容器计划:

OCI 标准包含 运行时标准 和 镜像标准 两个部分，而 OCI 这个组织则是由 Docker, CoreOS 和其他的一些公司共同发起创建的，致力于将容器运行时和格式标准化。

即：凡是遵守此标准的实现，无论是 Docker 还是 rkt 或者其他的运行时实现，均可以通过标准的镜像启动容器。

Runc:

runc 则是在 OCI 成立后，Docker 将其容器运行时 libcontainer 贡献出来后，并加以改造而成的，是Docker按照开放容器格式标准（OCF, Open Container Format）制定的一种具体实现。

目前，它是一个命令行工具，它的远景是：由Docker、Google、IBM、Microsoft、RedHat还有其他参与者创建一个通用且标准化的运行环境，提供容器运行时的元素可读文档，由Docker向OCI提供基于代码的可用实现方法。这包括libcontainer，Docker使用的原生底层接口，支持操作系统构建。

如果试图将链从最终用户绘制到实际的容器进程，它可能如下所示：

runc 是一个命令行客户端，用于运行根据 Open Container Initiative (OCI) 格式打包的应用程序，并且是 Open Container Initiative 规范的兼容实现。

有一个关于如何运行容器和管理容器映像的开放容器计划(OCI) 和规范。runc 符合此规范，但还有其他符合 OCI 的运行时。甚至可以运行符合 OCI 标准的虚拟机，Kata Containers 与gVisor就是符合符合 OCI 标准的虚拟机。gVisor 为代表的用户态 Kernel 方案是安全容器的未来，只是现在还不够完善。

runc 希望提供一个“ OCI 包”，它只是一个根文件系统和一个config.json 文件。而不是Podman 或 Docker 那样有“镜像”概念，所以不能只执行runc run nginx:latest这样来启动一个容器。

Runc 符合 OCI 规范（具体来说，是runtime-spec），这意味着它可以使用 OCI 包并从中运行一个容器。值得重申的是，这些bundle并不是“容器镜像”，它们要简单得多。层、标签、容器注册表和存储库等功能 - 所有这些都不是 OCI 包甚至运行时规范的一部分。有一个单独的 OCI-spec （image-spec ）定义镜像。

文件系统包是你下载容器镜像并解压后得到的。所以它是这样的：

OCI Image -> OCI Runtime Bundle -> OCI Runtime

容器世界的影子统治者

Podman、Docker 和所有其他工具，包括在那里运行的大多数 Kubernetes 集群，都归结为runc启动容器进程的二进制文件。

在实际工作中，几乎永远不会做我刚刚给你展示的事情 - 除非正在开发或者调试自己的或现有的容器工具。不能从容器映像中组装应用程序包，并且使用 Podman 而不是直接使用 runc 会更好。

runc就是Low-Level实现的实现，我们了解幕后发生的事情以及运行容器真正涉及的内容是非常有帮助的。最终用户和最终容器过程之间仍然有很多层，但是如果了解最后一层，那么容器将不再是神奇的东西，有时也很奇怪。最后你会发现容器它只是 runc 在命名空间中生成一个进程。当然最后一层是Linux内核。

runc 最重要的部分是它跟踪 OCI运行时规范。可以将其与遵循运行时规范的任何其他容器运行时交换，并且容器引擎（如 CRI-O）应该以相同的方式工作。

规范的任何其他容器运行时交换，并且容器引擎（如 CRI-O）应该以相同的方式工作。

High-Level容器运行时可以不依赖于 runc 本身。它们依赖于一些遵循 OCI 规范的容器运行时。这是当今容器世界真正美丽的部分。