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

 

发布了842 篇原创文章 · 获赞 89 · 访问量 224万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 大白 设计师: CSDN官方博客

分享到微信朋友圈

×

扫一扫,手机浏览