Docker OCI容器标准和引擎架构

网友投稿 908 2022-11-30

docker OCI容器标准和引擎架构

Docker OCI容器标准和引擎架构

docker利用namespace技术,可以将进程放到一个隔离环境里面,同时cgroup技术将容器进程限制资源配额,可以通过overyfs来模拟一个完整的这种文件系统。

那么业界又是如何定义这一切的呢?这就是OCI的容器标准了。

OCl 容器标准

Open Container Initiative

OCl 组织于2015年创建,是一个致力于定义容器镜像标准和运行时标准的开放式组织。OCI定义了镜像标准(Image Specification)、运行时标准(Runtime Specification)和分发标准(Distribution Specification)

镜像标准定义         应用如何打包(其实也就是overyfs那块,怎么通过容器镜像的驱动来将分层的文件系统标准化)运行时标准定义     如何解压应用包并运行(将容器镜像进行解压,并且运行)分发标准定义         如何分发容器镜像

docker当时认为它是标准,但是docker本生实现是很重的,当kubernetes对接docker的时候会发现很多东西对不上的,中间功能会有相互冲突和覆盖的地方,所以kubernetes起了一个OCI的规范,它尝试去将容器技术规范化,标准化。当你要去实现一套自己定义容器规范的时候,那么那就需要去遵循这套规范。

docker 引擎架构

在每台机器上你安装了docker之后,它会有一个docker daemon,这个是docker本身的一个后台服务端,它实际上就是rest api,同时机器上面还会安装docker command,这个时候就可以将请求给到docker daemon,现在新的docker版本都已经支持了对OCI的兼容,docker daemon接收到请求之后通过GRPC的调用将请求转到containerd里面去,containerd是真正用来控制这些运行时的,containerd也是一个单独可以运行的组件。

containerd会去真正启动containerd的shim进程,然后再通过runc,也就是底层运行时的一个接口

,通过runc再去启动容器进程。

通过上面,docker就整个和OCI规范完全匹配起来了。

docker shim它的作用是什么:在早期containerd和containerd shim是不存在的,在早期docker命令去启动容器的时候,这个容器进程是由docker daemon直接拉起的,也就是docker daemon下面是你的容器进程,这会有什么问题呢?docker daemon是你所有容器的父进程每当你去升级docker或者重启docker的时候,父进程就不存在了,那么所有的子进程就全部会重启。也就是说你不能轻易的去升级docker,在早期docker是有一个这样致命问题的。

所以后面就有了containerd,它是一个更加轻量级的容器管理进程,在启动容器进程的时候,不是以父进程的身份去启动,而是启动shim,这个shim进程是用来维护容器进程生命周期的,shim进程在运行起来之后,它会将shim进程交给操作系统的init system,由systemd去管理的。

这样的话containerd下面就不挂任何的子进程的,那么containerd就可以随便更新,升级,重启,下面的应用是不受影响的。

它就将控制组件和正真运行业务的组件分开了,所以containerd就相对docker优势就是可以随便升级,随意修改,后面docker也不得不这样,kubernetes是可以直接使用contained,因为contained已经是一个完整的运行时了。所以docker不得不加入支持containerd行列中来,所以就有了上面的架构。

RunC简介

runC是一个根据OCI(Open Container Initiative)标准创建并运行容器的CLI工具,目前Docker引擎内部也是基于runc构建的。

runC是⼀个CLI⼯具,⽤于根据OCI规范⽣成和运⾏容器,该⼯具被⼴泛的应⽤于各种​​虚拟化​​环境中,如Kubernetes。

为了让​​容器​​生态更加开放,Linux基金会发起OCI(Open Container Initiative),目标是标准化容器格式和运行时[4],其中一个重要产物就是CRI(Container Runtime Interface),抽象了容器运行时接口,使得上层调控容器更加便捷。containerd和runC都是其中代表产物,从dockerd中再剥离出containerd[5],向上提供rpc接口,再通过containerd去管理runC。containerd在初期也是直接对runC进行管理,但为了解决containerd进行升级等操作时会造成不可用的问题,containerd再拆出containerd-shim,独立对接runC。containerd从Runtime、Distribution、Bundle维度提供容器全生命周期的管理能力[6],runC专注于Runtime

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:传输层 可靠传输 重传与确认 停止等待协议工作原理
下一篇:Ansible 配置文件
相关文章

 发表评论

暂时没有评论,来抢沙发吧~