docker、oci、runc以及kubernetes梳理

整理自：https://www.cnblogs.com/xuxinkun/p/8036832.html

http://alexander.holbreich.org/docker-components-explained/

1、概念

1.1、container

首先说的是container容器。随着docker的大热，docker的经典图标，一条鲸鱼拖着若干个集装箱的经典形象已经深入人心。docker中container的翻译是译为容器还是集装箱，中文社区做过一次小小的讨论。讨论参见http://dockone.io/question/408。在这次讨论中，笔者的意见是container并不是docker出现了才有的，而在之前，linux container就已经翻译为linux容器并被大家接受。而从含义来看，一开始选定把“容器”作为container的翻译，也应该是准确的。而随着docker出现，container的概念深入人心，而其与原来的linux container中的container，含义应该说是一致的。所以沿用容器的翻译，笔者认为是比较合适的。

那么何为容器。容器本质上是受到资源限制，彼此间相互隔离的若干个linux进程的集合。这是有别于基于模拟的虚拟机的。对于容器和虚拟机的区别的理解，大家可以参考《京东基础架构建设之路》中的阐释，这里不再赘述。一般来说，容器技术主要指代用于资源限制的cgroup，用于隔离的namespace，以及基础的linux kernel等。

OCI

Open Container Initiative，也就是常说的OCI，是由多家公司共同成立的项目，并由linux基金会进行管理，致力于container runtime的标准的制定和runc的开发等工作。

所谓container runtime，主要负责的是容器的生命周期的管理。oci的runtime spec标准中对于容器的状态描述，以及对于容器的创建、删除、查看等操作进行了定义。

runc，是对于OCI标准的一个参考实现，是一个可以用于创建和运行容器的CLI(command-line interface)工具。我们可以认为它就是个命令行小工具，可以不用通过 docker 引擎，直接运行容器。runc直接与容器所依赖的cgroup/linux kernel等进行交互，负责为容器配置cgroup/namespace等启动容器所需的环境，创建启动容器的相关进程。

为了兼容oci标准，docker也做了架构调整。将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。

事实上，runC 是标准化的产物，它根据 OCI 标准来创建和运行容器。而 OCI(Open Container Initiative)组织，旨在围绕容器格式和运行时制定一个开放的工业化标准。

 

 

 

 

容器引擎

容器引擎，或者说容器平台，不仅包含对于容器的生命周期的管理，还包括了对于容器生态的管理，比如对于镜像等。现在的docker、rkt以及阿里推出的pouch均可属于此范畴。

docker，笔者认为可以分为两个阶段来理解。在笔者接触docker之初，docker版本为1.2，当时的docker的主要作用是容器的生命周期管理和镜像管理，当时的docker在功能上更趋近于现在的container runtime。而后来，随着docker的发展，docker就不再局限于容器的管理，还囊括了存储(volume)、网络(net)等的管理，因此后来的docker更多的是一个容器及容器生态的管理平台。

kubernetes与容器

kubernetes在初期版本里，就对多个容器引擎做了兼容，因此可以使用docker、rkt对容器进行管理。以docker为例，kubelet中会启动一个docker manager，通过直接调用docker的api进行容器的创建等操作。

在k8s 1.5版本之后，kubernetes推出了自己的运行时接口api--CRI(container runtime interface)。cri接口的推出，隔离了各个容器引擎之间的差异，而通过统一的接口与各个容器引擎之间进行互动。

与oci不同，cri与kubernetes的概念更加贴合，并紧密绑定。cri不仅定义了容器的生命周期的管理，还引入了k8s中pod的概念，并定义了管理pod的生命周期。在kubernetes中，pod是由一组进行了资源限制的，在隔离环境中的容器组成。而这个隔离环境，称之为PodSandbox。在cri开始之初，主要是支持docker和rkt两种。其中kubelet是通过cri接口，调用docker-shim，并进一步调用docker api实现的。

如上文所述，docker独立出来了containerd。kubernetes也顺应潮流，孵化了cri-containerd项目，用以将containerd接入到cri的标准中。

为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。

 

 

2、DOCKER中的组件说明：

dockerd 等一系列的组件，其中比较重要的有下面几个。

2.1、Docker CLI(docker)
docker 程序是一个客户端工具，用来把用户的请求发送给 docker daemon(dockerd)。该程序的安装路径为：

/usr/bin/docker

2.2、Dockerd
docker daemon(dockerd)，一般也会被称为 docker engine。该程序的安装路径为：

/usr/bin/dockerd

 

2.3、Containerd

/usr/bin/docker-containerd

我们可以把 docker 抽象为下图所示的结构：

 

 

从图中可以看出，docker 对容器的管理和操作基本都是通过 containerd 完成的。 那么，containerd 是什么呢？
Containerd 是一个工业级标准的容器运行时，它强调简单性、健壮性和可移植性。Containerd 可以在宿主机中管理完整的容器生命周期：容器镜像的传输和存储、容器的执行和管理、存储和网络等。详细点说，Containerd 负责干下面这些事情：

• 管理容器的生命周期(从创建容器到销毁容器)
• 拉取/推送容器镜像
• 存储管理(管理镜像及容器数据的存储)
• 调用 runC 运行容器(与 runC 等容器运行时交互)
• 管理容器网络接口及网络

注意：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。

为什么需要 containerd？

我们可以从下面几点来理解为什么需要独立的 containerd：

• 继续从整体 docker 引擎中分离出的项目(开源项目的思路)
• 可以被 Kubernets CRI 等项目使用(通用化)
• 为广泛的行业合作打下基础(就像 runC 一样)

重复一遍：Containerd 被设计成嵌入到一个更大的系统中，而不是直接由开发人员或终端用户使用。所以 containerd 具有宏大的愿景。

当 containerd 和 runC 成为标准化容器服务的基石后，上层的应用就可以直接建立在 containerd 和 runC 之上。图中展示的容器平台都已经支持 containerd 和 runC 的组合了，相信接下来会有更多类似的容器平台出现。

Containerd 的技术方向和目标

• 简洁的基于 gRPC 的 API 和 client library
• 完整的 OCI 支持(runtime 和 image spec)
• 同时具备稳定性和高性能的定义良好的容器核心功能
• 一个解耦的系统(让 image、filesystem、runtime 解耦合)，实现插件式的扩展和重用

下图展示了 containerd 的架构：

在架构设计和实现方面，核心开发人员在他们的博客里提到了通过反思 graphdriver 的实现，他们将 containerd 设计成了 snapshotter 的模式，这也使得 containerd 对于 overlay 文件系、snapshot 文件系统的支持比较好。
storage、metadata 和 runtime 的三大块划分非常清晰，通过抽象出 events 的设计，containerd 也得以将网络层面的复杂度交给了上层处理，仅提供 network namespace 相关的一些接口添加和配置 API。这样做的好处无疑是巨大的，保留最小功能集合的纯粹和高效，而将更多的复杂性及灵活性交给了插件及上层系统。

2.4、Containerd-shim
它是 containerd 的组件，是容器的运行时载体，我们在 docker 宿主机上看到的 shim 也正是代表着一个个通过调用 containerd 启动的 docker 容器。该程序的安装路径为：

/usr/bin/docker-containerd-shim

Docker 很贴心的为我们提供了 hello-world 镜像来验证安装是否成功，但是透过这个镜像我们还能看到更多的信息：

$ docker run hello-world

上面的输出信息指出，hello-world 容器的运行经历了如下四步：

Docker 客户端向 docker daemon 发送请求
Docker daemon 从 Docker Hub 上拉取镜像
Docker daemon 使用镜像运行了一个容器并产生了输出
Docker daemon 把输出的内容发送给了 docker 客户端
这是一个很抽象也很容器理解的过程，但是我们还想知道更多：docker daemon 是如何创建并运行容器的？
其实容器部分的操作和管理都被 dockerd 外包给 containerd 了，下图描述了运行一个容器时各个组件之间的关系：

Docker Engine API

从本质上说，docker 是一个客户端/服务器架构的应用。Dockerd 以 Engine API (REST)的方式对外提供服务，Engine API 里描述了 dockerd 支持的所有请求。Docker 客户端与 dockerd 之间就是通过 REST 的方式通信的。在 ubuntu 16.04 中，dockerd 默认是不监听 tcp 端口的，为了方便演示，我们让 dockerd 监听 tcp 端口。这样就可以使用 curl 代替 docker 客户端向 dockerd 发送请求了。具体的操作为，先修改 /lib/systemd/system/docker.service 文件，注释掉默认的 ExecStart 并添加新的 ExecStart 配置：

# ExecStart=/usr/bin/dockerd -H fd://
ExecStart=/usr/bin/dockerd -H tcp://0.0.0.0:2375 -H unix:///var/run/docker.sock

然后重启 docker.service：

$ sudo systemctl daemon-reload
$ sudo systemctl restart docker.service

这样 dockerd 就开始监听 tcp 端口 2375 了：

Docker 与 Dockerd 的交互

Docker 客户端与 dockerd 之间就是通过 REST 的方式通信的。前面我们已经让 dockerd 监听 tcp 端口了，所以我们可以使用 curl 来代替 docker 客户端。这里我们简单的演示如何请求 dockerd 从 docker hub 上下载 hello-world 镜像：

$ curl '127.0.0.1:2375/v1.37/images/create?fromImage=hello-world&tag=latest' -X POST

如果去看看 Engine API，你会发现其它的请求也都是用类似方式发送的，是不是很简单啊！

创建容器

容器镜像的下载是由 dockerd 完成的，但容器的创建和运行就需要 containerd(docker-containerd) 来完成了。Dockerd 与 docker-containerd 之间是通过 grpc 协议通信的。当 docker-containerd 收到 dockerd 启动容器的请求之后，会做一些初始化工作，然后启动 docker-containerd-shim 进程，并将相关配置作为参数传给它。docker-containerd 负责管理所有本机正在运行的容器，而一个 docker-containerd-shim 进程只负责管理一个运行的容器，它相当于 docker-runc 的一个封装，充当 docker-containerd 和 docker-runc 之间的桥梁，docker-runc 能干的就交给 docker-runc 来做，docker-runc 做不了的就放到这里来做。下面我们用 ubuntu 镜像运行一个容器：

$ docker run -id ubuntu bash

上图中黄线框起来的是几个主要的进程，它们之间是有父子关系的(systemd 没有出现在上图)：

systemd---dockerd---docker-containerd---docker-containerd-shim---bash

细心的朋友一定发现了，上图中没有出现 docker-runc 进程，这是为什么呢？
实际上，在容器启动的过程中，docker-runc 进程是作为 docker-containerd-shim 的子进程存在的。docker-runc 进程根据配置找到容器的 rootfs 并创建子进程 bash 作为容器中的第一个进程。当这一切都完成后 docker-runc 进程退出，然后容器进程 bash 由 docker-runc 的父进程 docker-containerd-shim 接管。

为什么需要 docker-containerd-shim？

也许大家会问，为什么在容器的启动或运行过程中需要一个 docker-containerd-shim 进程呢？把它移除掉整个架构会更简洁也更优美一些！事实上 docker-containerd-shim 的存在是非常有必要的，其目的有如下几点：

• 它允许容器运行时(即 runC)在启动容器之后退出，简单说就是不必为每个容器一直运行一个容器运行时(runC)
• 即使在 containerd 和 dockerd 都挂掉的情况下，容器的标准 IO 和其它的文件描述符也都是可用的
• 向 containerd 报告容器的退出状态

前两点尤其重要，有了它们就可以在不中断容器运行的情况下升级或重启 dockerd(这对于生产环境来说意义重大)。 从这里可以看到对 containerd-shim 的一些解释。https://groups.google.com/forum/#!topic/docker-dev/zaZFlvIx1_k