docker利用namespace技术，可以将进程放到一个隔离环境里面，同时cgroup技术将容器进程限制资源配额，可以通过pveryfs来模拟一个完整的这种文件系统。
那么业界又是如何定义这一切的呢？这就是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行列中来，所以就有了上面的架构。