Py学习  »  docker

docker概念很乱?俺来替你理一下!

小姐姐味道 • 2 年前 • 212 次点击  

原创:小姐姐味道(微信公众号ID:xjjdog),欢迎分享,转载请保留出处。

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等几家巨头打免费的工罢了。

作者简介:小姐姐味道  (xjjdog),一个不允许程序员走弯路的公众号。聚焦基础架构和Linux。十年架构,日百亿流量,与你探讨高并发世界,给你不一样的味道。俺的个人微信xjjdog0,欢迎添加好友,进一步交流。

推荐阅读:

1. 玩转Linux
2. 什么味道专辑

3. 蓝牙如梦
4. 杀机!
5. 失联的架构师,只留下一段脚本
6. 架构师写的BUG,非比寻常

Python社区是高质量的Python/Django开发社区
本文地址:http://www.python88.com/topic/118960
 
212 次点击