Docker的陨落

2019年Mirantis突然宣布收购Docker的Enterprise业务和团队，Mirantis也是一个没落的公司，但是他有一个名气很大产品 OpenStack，想不明白为啥收购，可能是英雄惜英雄吧。这个昔日的独角兽从他那个倔强的CTO和kubernetes之争那天就注定了被收购的命运。而追溯到2016年，当时正是docker鼎盛时期，却拒绝了微软40亿美元的邀约收购，估计现在肠子都悔青了。
今天为啥要谈docker呢？因为kubernetes正式宣布从1.20开始不支持docker了，这个消息听起来有点唬人，但对我们这些普通用户来说影响并不大，下面我就来说说这里面的事。

Docker

很久之前为了防止docker一家独大，docker当年的实现被拆分出了几个标准化的模块，标准化的目的是模块是可被其他实现替换的，不由任何一个厂商控制

image.png

这几个模块分别是：

• docker-client：docker的前端，提供docker 命令，如docker run 、docker build等
• dockerd(docker daemon)：docker的服务端，其实就是docker-client的后台
• containerd：容器服务，这也是docker的核心组件，负责容器的增删改等操作，这里containerd之所以作为一个单独的服务，而没有和dockerd集成到一块，是为了让其他的项目可以定义自己的客户端，比如kubernetes通过CRI客户端来访问containerd
• containerd-shim： 是containerd的一个组件，主要是用于剥离containerd守护进程与容器进程，每启动一个容器，就会生成一个shim进程，之所以引入shim进程是当containerd进程挂掉，shim进程还正常运行，这样容器不会停掉。

# 发现每启动一个容器就生成一个containerd-shim进程
#  yum -y install psmisc
 $ pstree
 containerd─┬─14*[containerd-shim─┬─pause]
            ├─containerd-shim─┬─nginx───2*[nginx]
            │                 └─9*[{containerd-shim}]
            ├─containerd-shim─┬─kube-controller───5*[{kube-controller}]
            │                 └─9*[{containerd-shim}]
            ├─2*[containerd-shim─┬─coredns───9*[{coredns}]]
            │                    └─9*[{containerd-shim}]]
            ├─containerd-shim─┬─nginx───nginx
                              └─9*[{containerd-shim}]

• runc：是一个命令行工具端，他根据oci（开放容器组织）的标准来创建和运行容器，containerd会调用runc命令来运行镜像。

Kubernetes

image.png

• dockershim ：下面就该聊聊我们的kubernetes了，kubernetes从设计之初，就通过CRI插件接口让kubelet无需编译就可以支持多种容器运行时，所以CRI是kubernetes的产物。而之前docker无疑是容器界的老大，所以为了集成docker，Kubelet使用了一个dockershim 的模块，这个模块的作用其实就充当一个网桥。
  随着技术发展和docker的没落，dockershim是时候推出历史舞台了，从上图可以发现，kubernetes其实只需要一个运行时即可，直接通过容器运行时将镜像拉起，所以搞一个网桥只会增加中间环节，这么一说早就应该抛弃docker了。

• CRI：除了CRI外，还有一个CRI-O，这个东东是主要由 Red Hat 员工开发的 CRI 运行时。它的最大区别在于并不依赖于 Docker，而且目前已经在 Red Hat OpenShift 中得到使用。CRI-O 的优势在于其采用极简风格，或者说它的设计本身就是作为“纯 CRI”运行时存在。不同于作为 Docker 组成部分的 containerd，CRI-O 在本质上属于纯 CRI 运行时、因此不包含除 CRI 之外的任何其他内容。从Docker迁移至CRI-O往往更为困难，但无论如何，CRI-O 至少可以支持 Docker 容器在 Kubernetes 上的正常运行。

• OCI：对了，还有一个OCI，也是就开放容器标准，它规定了容器运行时标准（runtime spec）和容器镜像标准（image spec），目的是定义一个业内统一的容器标准，只要按OCI规范实现，上层的 kubernetes、mesos 就都能集成这个容器了。

参考：
https://www.cnblogs.com/sparkdev/p/9129334.html
https://javazhiyin.blog.csdn.net/article/details/110789876
https://zhuanlan.zhihu.com/p/102171749