docker是什么？OCI又是什么？CRI又是什么？containerd又TM是什么？有没有感觉概念非常的乱？

造成这一切乱象的根本，是各个利益公司之间的竞争造成的。商业竞争造成了用户的困扰，尤其是每个公司都在推销自己技术概念的时候。

接下来，俺将按照自己的理解方式，尝试为你解读这些操蛋的名词，让你对容器技术更多一些了解。如果你正在使用的是docker，你会发现这个可怜的，容器时代的引领者，正在慢慢丢掉自己的所有。

Docker并不是全部

自从docker加入了镜像仓库，引爆了容器技术，很多人认为docker就代表了容器的全部。这种观点很普遍，主要是由于docker实在是太火了。即使k8s二次官宣抛弃docker，它的热度依然不减。

其实，现阶段，docker只是众多容器技术中的其中一种。它有三个主要的概念。

• 镜像  代表了终的软件包，不可变的软件载体。相当于安装文件
• 容器 镜像的运行时，实际运行的实例，具有明确的进程号
• 仓库 存放镜像的仓库，可以进行统一的版本管理和权限管理

docker是运行时和一堆开发工具集合的统称。docker-cli就不必多说了，就是一堆命令行的集合，我们主要看一下运行时。

• docker 我们平常操作docker，使用的就是docker命令，它就是我们所说的命令行接口，相当于一个客户端。它将指令发送到dockerd

• dockerd docker的服务端。比如我们在Linux上安装docker，就要启动一个常驻进程，才能管理所有的docker进程

• containerd 这个组件，是从Docker1.11版本才有的，是从dockerd里拆出来的，是容器标准化后的产物。它遵循的是OCI标准，这个标准后面我们还会用图来说明它的位置。containerd功能齐全，换句话说，你的服务器上可以没有dockerd，只需要containerd就能运行你的容器

• runc 容器运行时组件，是一个标准的OCI容器实现运行时，可用来直接创建和运行容器。可以看到containerd和runc都是OCI的实现，区别是前者是管理工具，后者是运行容器

• containerd-shim 垫片的意思，主要是将containerd与真正的容器进行解耦

• ctr 也叫做containerd-ctr，是containerd的客户端

你可能会特别奇怪，仅仅一个小小的docker，怎么就分了这么多层！按照常理，俺只需要一个client端，一个守护进程就够了，怎么拆分了这么多层？

这是由于历史发展原因引起的。为了解耦，为了实现OCI标准，docker的组件不得不拆了又拆，后形成了一个松耦合的架构。后来，由于k8s加入竞争，又出现了一个新的名词：CRI。接下来，我们综合k8s，来看一下各个组件所存在的层次。

两个标准割裂世界

为什么搞得这么复杂，主要是因为两个标准的加入。CRI和OCI。下面这张大图，大体体现了它们之间的关系。

OCI全称是Open Container Initiative，定义得是容器运行时得标准。这个标准，使用Linux的cgroup和namespace等技术，和docker所使用的技术没什么两样。docker只不过是OCI的一个实现而已，就像gVisor（runsc）所实现的一样。

CRI是全称是Container Runtime Interface，是k8s定义的一套与容器运行时进行交互的接口。containerd就是docker为了适应这个标准而开发的CRI实现，但它已经是CNCF的了，不再属于docker了。

当然，除了containerd其他厂商也可以基于CRI-O做一些事情，同样实现了CRI接口。这样就可以无缝接入到k8s中，比如redhat的OpenShift，就选用的CRI-O。但对于容器的真正调度，其实还是OCI负责的，CRI只是个中转站而已。比如，Podman，原来就是CRI-O项目的一部分，现在它可以直接操作runc来启动容器。

docker整个体系，被两个标准拦腰斩了两次，组件多也就不足为怪了。

在早些版本中，k8s为了支持docker，不得不包含一个叫做dockershim的组件。后来，k8s宣布不再支持docker，其实是放弃了dockershim组件，我们依然可以使用containerd来调用docker的所有功能。

”k8s不再支持docker“，这种文字游戏，让很多人过早的放弃了docker。

总结

2020年12月8日，k8s再次发布了弃用docker的文章。

https://kubernetes.io/blog/2020/12/08/kubernetes-1-20-release-announcement/

这种文字游戏，无疑再次给docker以暴击。很多公司，其实运行的docker好好的，但主流调度系统这么一发声，就必须研究一些雷同的技术，来应对可能会出现的技术变革。

早在2014年，docker的商业化态度还是非常强硬的，先后得罪了coreos，redhat等一系列组织，拒绝了google推出中立容器的合作。从关系亲密到反目成仇，也是让人无限感概。CNCF云原生基金的成立，已经宣告了docker商业化的失败，docker甚至自己搞了个开源版本moby。丢了编排调度，理念被fork，这一切都让docker慢慢的丢掉自己的话语权。

事实证明，docker的母公司，撑不起云原生这么大的蛋糕。大众还是希望选择一些巨人公司，然后匍匐在它的脚下。

这个选择，就是CNCF，目前还是一个比较开放的组织。相比较而言，docker是一个商业化产品。受益于开源，podman定位于取代docker，它是redhat出品。

不开源让你灭亡，是docker的终结果。但开源呢？目前来看，开源界，绝大部分，不过是集体为google，亚马逊，oracle等几家巨头打免费的工罢了。