Docker、OCI 与 运行时

OCI（Open Container Initiative，开放工业标准）的容器运行时规范设定的标准定义了容器运行状态的描述，以及运行时需要提供的容器管理功能，例如创建、删除和查看等操作。容器运行时规范不受上层结构绑定，不受限于任何特定操作系统、硬件、CPU 架构或公有云等，从而允许任何人遵循该标准开发应用容器技术。OCI 项目启动后，Docker 公司将 2014 年开源的 libcontainer 项目移交至 OCI 组织并进化为 runC 项目，成为第一个且目前接受度最广泛的遵循 OCI 规范的容器运行时实现。

为了兼容 OCI 规范，Docker 项目自身也做了架构调整，自 1.11.0 版本起，Docker 引擎由一个单一组件拆分成了 Docker Engine（docker-daemon）、containerd、containerd-shim 和 runC 等 4 个独立的项目，并把 containerd 捐赠给了 CNCF。

containerd 是一个守护进程，它几乎囊括了容器运行时所需要的容器创建、启动、停止、中止、信号处理和删除，以及镜像管理（镜像和元信息等）等所有功能，并通过 gRPC 向上层调用者公开其 API，可被兼容的任何上层系统调用，例如 DockerEngine 或 Kubernetes 等容器编排系统，并由该类系统负责镜像构建、存储卷管理和日志等其他功能。

然而，containerd 只是一个高级别的容器运行时，并不负责具体的容器管理功能，它还需要向下调用类似 runC 一类的低级别容器运行时实现此类任务。containerd 又为其自身和低级别的运行时（默认为 runC）之间添加了一个名为 containerd-shim 的中间层，以支持多种不同的 OCI 运行时，并能够将容器运行为无守护进程模式。这意味着，每启动一个容器，containerd 都会创建一个新的 containerd-shim 进程来启动一个 runC 进程，并能够在容器启动后结束该 runC 进程。

Docker 项目组件架构与运行容器的方式如图所示。

近年来，出于各种设计目标的容器运行时项目越来越多，较主流的有 CRI-O、Podman 和 Kata Containers 等。CRI-O 是一款类似于 containerd 的高级运行时，在底层同样需要调用低级运行时负责具体的容器管理任务，支持与 OCI 兼容的运行时（目前使用 runC）。它为 Kubernetes CRI（容器运行时接口）提供了轻量级的容器运行方案，核心目标是在 kubelet 和 OCI 运行时之间提供一个黏合层，支持从 Kubernetes 直接运行容器（无须再依赖任何其他代码或工具)，以取代有着较长集成链路的 Docker 容器引擎。

由 Red Hat 主要推动和维护的 Podman 项目则是另一款兼容 OCI 规范的高级容器运行时，它起初是 CRI-O 项目的一部分，后来单独分离成为 libpod 项目，Podman 是相关的命令行管理工具。Podman 在管理容器时使用无守护进程模型，它直接通过 runC 容器运行时进程（而非守护程序）与镜像 Registry、容器和镜像存储以及 Linux 内核直接交互。它支持管理容器的整个生态系统，包括 Pod（Kubernetes 引入的组件，由关系紧密的容器组成的容器集）、容器、容器镜像，以及使用 libpod 库的存储卷。Podman 用于构建镜像的功能则交由 Buildah 项目完成，支持基于 Dockerfile 构建镜像的 podman build 命令仅包含该项目的一个子集，使用 bash 脚本构建镜像是该项目更大的亮点。镜像 Registry 也有一个专用的项目 Skopeo，支持 Docker 镜像和 OCI 镜像的签名、存储及推拉操作。

Podman 的命令格式与 Docker 命令几乎完全兼容，用户可直接迁移 Docker 命令行至 Podman 上。

与最初的 Docker 项目一样，CoreOS 开发的 rkt 同时提供了高级容器运行时和低级容器运行时的功能。例如，它支持构建容器镜像、于本地存储库中获取和管理镜像，并通过命令将之启动为容器等。不过，它没有守护进程和远程可用的 API。为了同 Docker 竞争，rkt 还创建了应用程序容器（appc）标准以替代 OCI,但未获得广泛采用。其他常见的容器运行时还有 frakti 和 LxC 等。

Docker 和 rkt 都是经典容器技术的实现，同一主机上的各容器共享内核，轻量、快速，但也因隔离性差、内核版本绑定（容器应用受限于容器引擎宿主机的内核版本）以及不支持异构的硬件平台等原因为人诟病。所以，基于虚拟化或者独立内核的安全容器项目悄然兴起，2017 年底，由 Intel Clear Container 和 Hyper.sh RunV 项目合并而来的 Kata Containers 就是代表之一。Kata Containers 在专用的精简内核中运行容器，提供网络、I/O 和内存的隔离，并可以通过虚拟化 VT 扩展进行硬件强制隔离，因而更像一个传统的、 精简版的或轻量化的虚拟机，如下图所示。

但 Kata Containers 又是一个容器技术，支持 OCI 规范和 Kubernetes CRI 接口，并能够提供与标准 Linux 容器一致的性能。Kata Containers 致力于通过轻量级虚拟机来构建安全的容器运行时，因而也更适用于多租户公有云，以及对项目隔离有着较高标准的私有云场景。

本篇文章摘自：《Kubernetes 进阶实战(第2版) - 马永亮》。