广告

直击KubeCon欧洲:Runtime 技术概览

  • 浏览(177)
  • 评论(0)
  • 译者:k8s

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的应用实践。

  • 分享到:
  • icon
  • icon
  • icon
  • icon
箭头