前言

1.24之前安装k8s时，我们都会先安装docker环境

之前，k8s的container是docker engine维护的：

也就是说，我们执行一个yaml文件，kubelet会帮我们删除、扩容（维护）对应的Pod，Pod里面的container是docker engine维护的

docker盛世，K8s选择docker

在遥远的2013年，Docker发布了第一版，当时的docker以app驱动，参考了lxc，当时十分受欢迎

2014年，K8s是基于Borg容器管理的，有他的一套东西。

当时的人肯定会想：我为了用K8s还要学一遍？

K8s很聪明，他在早期的版本选择了docker作为容器化底层支撑

K8s逐渐壮大，想要不受限于docker

随着各大厂商热捧K8s，越来越多的容器技术想加入K8s，K8s就想了：

1. 我怎么样融合别的容器技术，更加多元？
2. 我不能绑定在docker上面，我要主导一些

但是docker也很火！又不能直接剔除，双方都是血亏，又不想受限于docker

于是K8s在2016年的1.5版本就开始计划，官网当年的博客：

K8s提出了自己的一套接口规范 CRI （Container Runtime Interface）

docker就从亲儿子变成了选择之一

K8s没有直接去掉docker，而是在docker和kubelet之间增加了一个docker shim，相当于adapter

相当于折中的妥协！

但是，这样的话肯定会消耗多余性能、网络、cpu

docker的改变

docker这时候想，坏了，这家伙是想把我踢出局？

docker基于自身，移除了一些功能，新构建出了一个项目------containerd，相当于docker的核心功能。并且docker把containerd捐献给了CNCF（Cloud Native Computing Foundation）（云原生计算基金会）

2018年，K8s调用containerd架构图：

再后来

省去了很多环节，大大节约了性能

启动时长：

这样的话，其他的容器化技术也只要安装一个CRI Plugin就可以适配K8s了

1.24版本，docker shim已经被移除了

对我们的影响

containerd对原来的docker功能进行了一些减少，像docker ps都不能用了。

取而代之的是crictl

对我们的影响其实不大，我们学习K8s，实质上操作的是kubectl

发展总结

1.早期 K8s 1.5版本之前 kublet-docker engine

2.K8s 1.5版本 发布了CRI 定义容器管理标准

3.kublet-CRI--docker shim--docker engine 折中方案

4.docker核心剥离出来，形成一个containerd项目，捐献给CNCF，更加拥抱云原生 containerd本质上还是docker，只不过docker换了一种方式陪伴在你身边

5.K8s 1.24开始以后

    kublet- CRI -[CRI plugin]containerd
    kublet- CRI -[CRI plugin]xxx(其他容器化技术)
    kublet- CRI -[CRI plugin]yyy(其他容器化技术)

本文出至：学新通技术网