容器技术近年来越来越火，作为云原生技术的最底层基石，要开发云原生应用，就有必要对于容器技术有一个更加深入的了解。容器的概念特别多，docker、oci、cri、runc、containerd名字容易看晕，这边做一下总结

Container

首先先来了解一下，什么是容器？这边我们一般说的“容器”，都是“Linux容器”（当然现在微软也在搞容器，但还没linux上面那么成熟）。不同于一般认识，其实容器本身并不是一个特别新的技术，早在2000年就已经有了，当时是用来在chroot环境(隔离mount namespac的工具)中做进程隔离（使用namespac和cgroups），容器的历史可以看这篇文章。而现在docker所用的容器技术，和当时并没有本质上的区别。容器的本质，一句话解释，就是一组受到资源限制，彼此间相互隔离的进程。实现起来也并不复杂，隔离所用到的技术都是由linux内核本身提供的（所以说目前绝大部分的容器都是必须要跑在linux里面的）。其中namespace用来做访问隔离（每个容器进程都有自己独立的进程空间，看不到其他进程），cgroups用来做资源限制（cpu、内存、存储、网络的使用限制）。总的来说容器就是一种基于操作系统能力的隔离技术，这和基于hypervisor的虚拟化技术（能完整模拟出虚拟硬件和客户机操作系统）复杂度不可同日而语。这边是一个对比图

image

了解了容器的技术原理，接下来就可以说说容器的那些名词概念了

OCI

Open Container Initiative，是由多家公司共同成立的项目，并由linux基金会进行管理，致力于container runtime的标准的制定和runc的开发等工作。所谓container runtime，主要负责的是容器的生命周期的管理。oci的runtime spec标准中对于容器的状态描述，以及对于容器的创建、删除、查看等操作进行了定义。

runC

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

containerd

containerd 是一个守护进程，它可以使用runC管理容器，并使用gRPC暴露容器的其他功能。相比较Docker引擎，使用 gRPC ，containerd暴露出针对容器的增删改查的接口，Docker engine调用这些接口完成对于容器的操作。

Docker架构

docker在早期所有功能都是做在docker engine里面的，但是之后功能越来越多，越来越重，很多功能已经和基础的容器运行时没有关系了（比如swarm项目）。所以为了响应社区的呼声，也为了兼容oci标准，docker也做了架构调整。将容器运行时相关的程序从docker daemon剥离出来，形成了containerd。Containerd向docker提供运行容器的API，二者通过grpc进行交互。containerd最后会通过runc来实际运行容器。调整完后的docker架构图如下（docker 1.12版本以后）：

image

[root@localhost ~]# ps -ef|grep docker
root      1431     1  1  2018 ?        10:35:01 /usr/bin/dockerd --bip=10.1.100.1/24 --ip-masq=true --mtu=1472
root      1498  1431  0  2018 ?        01:23:31 docker-containerd -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-runc
root      1802  1431  0  2018 ?        00:00:03 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 4567 -container-ip 10.1.100.2 -container-port 4567
root      1820  1431  0  2018 ?        00:00:03 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 443 -container-ip 10.1.100.2 -container-port 443
root      1848  1498  0  2018 ?        00:00:07 docker-containerd-shim 2abb8ab1515e9dd491fc6e7d747e6ec8cdff3e98bcb6ae67c9b90ddfa120f1ed /var/run/docker/libcontainerd/2abb8ab1515e9dd491fc6e7d747e6ec8cdff3e98bcb6ae67c9b90ddfa120f1ed docker-runc
root      1852  1431  0  2018 ?        00:13:47 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 80 -container-ip 10.1.100.2 -container-port 80
root      1869  1431  0  2018 ?        00:00:03 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 10022 -container-ip 10.1.100.2 -container-port 22
root      1886  1498  0  2018 ?        01:24:27 docker-containerd-shim dd06d2cc632f45af1c53cd8df219c6275862bd94fed811bd3331290f8cf4a9a7 /var/run/docker/libcontainerd/dd06d2cc632f45af1c53cd8df219c6275862bd94fed811bd3331290f8cf4a9a7 docker-runc
root     15443 30672  0 13:08 pts/0    00:00:00 grep --color=auto docker

从上图可以看出，dockerd、docker-containerd、docker-containerd-shim分别对应上述架构图中的docker daemon、containerd、containerd-shim，在这边我启动了两个docker容器，所以会有两个docker-containerd-shim进程。docker-runc就是docker-containerd-shim调用的真正来创建容器的模块。

总结一下，其实docker总的架构来说，真正用来创建容器的就是runC，其他的都是一些容器的管理和增强功能，所以说你如果想创建一个容器玩一下，直接下载一个runC的二进制跑一下就行了，当然生产上面不能这么搞。

CRI

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

kubelet做适配的问题，就是容器项目每次升级更新，kubelet都需要相应的进行配合变更测试，很多api可能这一版能用，下一版就不能用了，由于容器项目一直在高速迭代，k8项目组苦不堪言。痛定思痛后，sig-node项目组在k8s 1.5版本之后，推出了自己的运行时接口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的标准中。

CRI-O

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

Kubernetes架构

cri.png

看到这张图可能大家都晕了，其实这也反应了容器及容器编排技术高速发展的现状，K8的容器接入方案分别经历了四个阶段(从右往左)：

1.最早是在kubelet这一层进行适配，通过启动docker-manager来访问docker（不同的容器产品有不同的manager，这部分代码是kubelet项目标准代码的一部分）

2.K8 1.5之后引入了CRI接口，通过docker-shim（垫片）的方式接入docker。shim程序一般由容器厂商根据CRI规范自己开发，实现方式可以自己定义（即CRI规范定义了要做什么，怎么做可以基于自己的理解）。而docker-shim由于历史原因，还是k8项目组来做的，这部分代码也包含在kubelet代码里面，但架构上是分开的。

3.docker在分出containerd后，k8也顺应潮流，孵化了cri-containerd项目，用于和containerd对接，这样就不走docker daemon了。

4.目前孵化的cri-o项目，则连containerd都绕过了，直接使用runC去创建容器（你可以把cri-o看作是k8生态里面的containerd）

值得注意的是，在containerd的1.1版本中，甚至已经去除了cri-containerd这样一个守护进程，cri接口以插件的形式直接整合在了containerd项目里面，目前docker和kubernetes分别调用containerd的架构图如下：

containerd.png

容器项目发展趋势

可以看到，随着k8生态的不断成熟和业界影响力的不断增大，k8项目对于docker的依赖已经越来越少，从cri-containerd开始就已经可以脱离docker体系，到cri-o更是连docker的影子都看不到了（containerd项目主要还是docker在维护）。而现在还有crictl这样的工具，连容器的日常维护都不需要使用docker命令了。Docker inc.基于自身的商业诉求，也是不断再往平台化发展（swarm项目），也在不断添加复杂的功能，可惜凭一己之力还是很难和谷歌一手搭建出来的CNCF的宏伟蓝图去抗争。

目前在CNCF里面有两个容器运行时项目，分别是rkt和containerd。rkt从目前的发展情况看很有可能被移出CNCF，cri-o和containerd都在同时发展，这两个项目其实重合度是比较高的，做的事情也差不多，只不过cri-o是专门为k8s设计的，而containerd设计之初的定义就是一个通用的容器运行时平台，有说containerd即将通过委员会评审，从CNCF中毕业。

安全容器

最后讨论一个比较前沿的话题，叫做“安全容器”。根据前面的介绍，相信你也了解了，容器有诸多好处，但也并不是完美的。它有个很大的软肋--隔离性。基于内核提供的namespace功能，其实很多东西还是无法隔离的，一个简单的例子就是时间，一旦在某个容器内修改了系统时间，所有运行在这个宿主机上的容器内的时间都会改变，这显然不符合“沙盒”原则。再比如容器里面的jvm，如果不修改内核代码的话，看到的都是宿主机的cpu和内存情况。而更加严重的问题是，由于共享宿主机内核，一旦某个容器被植入恶意代码，攻击宿主机内核，会影响到该宿主机上的所有容器。而这个问题在虚拟机时代是不存在的，因为虚拟机都是独立操作系统和内核，里面可以随便你折腾。目前所有的公有云，还都是使用虚拟机进行多租户管理，安全性是一个很重要的原因。

基于上述情况，很容易就能想到，是否有一种技术，既可以拥有容器的速度，还可以拥有虚拟机的隔离性呢？你别说，还真有人在研究这个，而且已经有了几个有一定成熟度的项目，比如kata container和gvisor。

kata containers是由OpenStack基金会管理，但独立于OpenStack项目之外的容器项目。kata containers整合了Intel的 Clear Containers 和 国内HyperHQ团队 的 runV项目，它的本质是在容器中建立一个经过裁剪的，轻量化的内核，所以在你启动一个kata container后，你就能看到一个正常的虚拟机在运行，而Qemu就是这个虚拟机的VMM（虚拟机管理程序）。作为标准的虚拟机，kata container自然原生就带了pod的概念，一个虚拟机就是一个pod，而用户定义的容器，就是这个pod里面的进程。这边是kata container的一个架构图：

kata.png

从这个架构图可以看到，kata-runtime是和runc平级的，而kata container是完全按照OCI规范来进行设计的。大家不难想到，根据前面的介绍，containerd可以直接通过containerd-shim来对kata-runtime进行调用，所以对于docker来说，完全可以通过原来的方式创建kata容器，管理的方式也都和原来一样。而你也不难想到，k8自然也是可以非常方便的创建和管理kata container容器（通过docker-shim、cri-containerd或者cri-o）。

可以看到，kata container项目基本还是走的传统虚拟机的路子，通过裁剪出一个精简的guest kernel（这个内核是经过高度优化的，只用于一个容器的运行），以及通过hypervisor(QEMU)虚拟出来的硬件设备，提供一个完整的虚拟机环境。相对而言，gVisor设计更加激进，gVisor的设计中有个一个sentry进程，负责转发应用对于内核各类功能的调用，简单说，就是对应用“冒充”内核的系统组件，在这种思想下，不难理解，sentry需要自己实现一个完成的linux内核的网络栈，以便于处理应用进程间的通讯请求。目前gVisor还处于早期阶段，能调用的内核功能还相当有限，并且在重I/O或者重网络的情况下性能会急剧下降。但这种通过用户态去运行一个操作系统内核，来为应用进程提供强隔离的思路，确实是未来安全容器进一步演化的一个方向。

就目前来说，我更加看好kata container的发展。一方面gVisor这种“冒充内核组件”的方式虽思路很好，但还不够成熟，功能和性能各方面还有限制，另外更重要的是，gVisor本质上不是内核，它所有的调用还是要依赖于宿主机内核的能力，而kata container是一个独立内核，这可以让kata起来的内核版本不同于宿主机的内核，提供真正虚拟机级别的隔离性，对于cilium这类对于内核版本要求非常高的项目具有非常重大的意义。其实目前业界其实已有这方面的试水，华为云的CCI（云容器实例）明确提到了是基于kata container的安全容器技术，阿里也推出了ECI(弹性容器实例，是不是基于kata不确定)，应该说安全容器的发展前景还是非常良好的。

kata container与service mesh

这两个一个是基于虚拟化技术的容器运行时，一个是微服务治理框架，有什么关系呢？先来看一下下面这个图

image

service mesh理念很好，真正实现起来难度却很大。究其原因，sidecar仍然是一个用户态的进程，proxy拦截了所有进出service的流量，iptables本身性能就不行，对于服务调用来说又多了几跳，用户态的上下文切换，性能必然会有损失，事实上istio的性能问题至今一直为人诟病，也不能大规模使用于生产环境。为了解决这个问题，也诞生了诸如cilium这样的项目，直接绕过内核的tcp堆栈来提高性能。而安全容器项目，为这个问题的解决提供了一个新的思路，因为kata container本身就是一个精简的guest kernel，那为何不把这部分服务治理逻辑直接下沉到guest kernel中，作为内核网络协议栈的一部分，真正的成为基础设施。这样只要基于虚拟化的容器启动，自动就具有了服务治理的全部功能，而且是内核级别的，应用完全无感知。之前小剑老师分享的service mesh介绍中，有这么一张PPT

image