5月2日，云计算领域技术峰会KubeCon + CloudNativeCon Europe 2018 在丹麦首都哥本哈根盛大举行。这次峰会，参会人数突破4000，再创新高。峰会首日精彩议题不断， 其中分类为”Runtime”的议题主要集中在首日，container runtime作为核心组件也一直备受关注。下面为大家带来Runtime相关议题的详细报道。

谈到Container Runtime，大家应该会想到很多词：Docker，rkt，runC，containerd，kata,  OCI，CRI… 如果对容器技术不熟悉，很容易被这么多的名词搞晕。

为什么会有这么多container runtime?  

他们之间的关系是什么?

用户该如何选择?

下面我们一一解答

为了解释楚，我们得从container 技术的历史讲起。

• Docker是最早的被大家熟知且应用较广的container runtime。

• 2014年，CoreOS release了rkt容器引擎，作为docker的备选方案。

• 2015年，由Docker，CoreOS等容器厂商发起成立OCI(Open Container Initiative), 来统一Container相关的标准规范。目前OCI包含两项规范：Runtime Specification (runtime-spec) 和 Image Specification (image-spec)。

• 2016年，为了能让kubernetes支持更多的container runtime，从kubernetes 1.5起，引入了插件化的容器运行时接口CRI(Container Runtime Interface)

接下来我们分析一下各种技术之间的关系。

Docker vs Containerd vs RunC

为了兼容OCI标准，Docker 拆分成: Docker, containerd, runC. 三者之间由上到下依次调用。

2015年Docker发起成立OCI的同时，也向OCI捐赠了runtime-spec的一个实现 runC。 runC的功能只是对container做生命周期管理。

containerd作为一个可以独立使用的容器引擎，包含了其他更多的必要功能：下载容器镜像，镜像及容器的storage管理，container的network管理。 containerd向下默认使用runC作为container的执行器。

Docker集成containerd作为自己个一个组件，同时包含了更全面的功能包括：build image， Auth等。

从Docker 1.12起，开始抽离出了containerd。  

到containerd 1.0，有更多的功能从Docker中抽离出来。

CRI Deep Dive

containerd，docker，rkt都可以作为容器引擎独立使用，但如果想要集成到kubernetes中使用，则需要兼容CRI接口，CRI主要定义了对Pod、Container、Image三种资源的操作。CRI plugin只要对应实现这些操作即可。

下图是CRI的调用过程：

目前主要的CRI plugin包括：

1.  dockershim(kubernetes 默认的CRI plugin)

2. containerd/cri-containerd

3. CRI-O

4. frakti: hypervisor-based container runtimes

这里以containerd为例介绍CRI plugin的架构。

cri-containerd从v1.1版本开始End-of-life，containerd 1.1以后，不在有独立的cri-containerd，取而代之的是CRI plugin直接build 到containerd里. (ref: https://github.com/containerd/cri)

这样kubelet直接通过gRPC与containerd交互，containerd向下通过runC运行Container。

Container Runtime有很多，实际使用时我们需结合自己的需求，下图可以为用户选型提供帮助。

最后，想和大家分享的是关于Google的gVisor。就在KubeCon进行的同时，Google宣布开源自己的sandbox container runtime。

ref: https://cloudplatform.googleblog.com/2018/05/Open-sourcing-gVisor-a-sandboxed-container-runtime.html

传统的Linux containers不是sandbox，存在安全性、隔离性问题。gVisor的是核心是Go语言实现的，用户态运行，支持大多数Linux系统调用的kernel。gVisor实现的sandbox Pod比VM更轻量级，但却拥有VM相似的隔离性。而且，gVisor支持集成到Docker和Kubernetes中使用。

VM的隔离性+Container的轻量级，这无疑是Pod运行的最佳形态。gVisor的开源再次推动了container runtime技术的发展，希望很快看到gVisor的应用实践。