2020年底K8S不再支持docker。

先了解下docker的历史。

最开始的时候，docker是非常简单的引擎，各种组件放在一起，给用户使用，不用关注内部。

越来越火被别人眼馋，于是docker拿出了一个libcontainer模块捐献了出来，捐献给中立的组织，叫OCI，并且把libcontainer改名称了Runc，没有留下docker公司任何的痕迹。

OCI定义标准:

1镜像规范。Image specification。规定容器的镜像长什么样，镜像的组织结构包含的目录、文件、结构、如何产生一个标准的镜像等。

2运行时规范。Runtime  specification。如何从OCI运行系统去启动一个容器程序，容器程序如何接收容器指令，这些指令的行为是什么，定义了配置，运行时环境，生命周期，如何给容器设置命名空间，挂载文件系统等一系列标准，都是在OCI定义的。

标准定义好了，谁来实现呢？RUNC是第一个来实现的。

为防止docker一家独大，大佬联合成立了基金会CNCF云原生基金会，在更高的维度对docker进行打击。K8S成为CNCF的第一届毕业生，容器大战也以K8S的胜出而结束。

这时，Docker把核心containerd捐献给CNCF，刷了一波存在感。

Containerd是比RUNC更高层级的封装，离用户层更近一些。

这个时候，其实docker把核心内容都捐献给了开源组织，Docker为云原生做了非常重要的贡献，这个时候，云原生还在一直发展。

K8S为表示中立性，在1.5版本推出了CRI的机制，CRI本质是一组GRPC接口的定义，一块是对容器操作的接口(容器创建、启停、镜像拉取删除等)

K8S提供了接口是告诉大家，可以做各自的OCI-runtime，只要实现了这些接口就可以一起用。

Docker可以提供容器运行时接口，但容器运行时接口并不一定非得是docker。

第一个实现这个接口的是containerd。

当时还没有人知道containerd。

1、K8S为了直接支持docker，做了垫片dockershim，一头适配CRI接口，一头适配docker的API，docker调用containerd，最终完成容器的操作。

2、这种架构持续了时间很久，K8S受众越来越高，containerd健壮性越来越好，时机越来越成熟，垫片dockershim可以卸下来了。

3、可以说K8S维护垫片dockershim是十分不容易的，docker中有很多K8S不相干的东西，非常重，垫片dockershim需要随着docker的升级做版本的变化以及兼容性测试，还有一些性能问题。

4、现在说的K8S不支持docker，不是不能用docker，而是CRI的实现不再支持docker，也就是说垫片dockershim干掉了，垫片dockershim是kubelet组件用的。

不用docker，支持CRI接口即可，containerd可以直接来使用。