kubernetes真要放弃docker吗?
这几天，kubernetes社区发生了一件大事，1.20版本宣布放弃docker，圈内一下子炸锅了。我们看一下官方描述：
Docker support in the kubelet is now deprecated and will be removed in
a future release. The kubelet uses a module called "dockershim" which
implements CRI support for Docker and it has seen maintenance issues in
the Kubernetes community. We encourage you to evaluate moving to a container
runtime that is a full-fledged implementation of CRI (v1alpha1 or v1 compliant)
as they become available. (#94624, @dims) [SIG Node]官方链接如下：
https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.20.md#deprecation不要小看这短短的一句话，蕴含了丰富的内容。dockershim？container runtime？CRI？你真的理解吗？今天我们就来聊一聊kubernetes是否真的要放弃docker。
kubernetes体系架构
我们先看一下kubernetes体系架构，如下图：
master节点是空值节点，有3个重要的组件组成。controller manager负责容器编排，api server提供api服务，scheduler负责任务调度。整个集群的状态保存在etcd中。
node节点是计算节点。最重要的组件是kubelet，通过CRI(Container Runtime Interface)远程调用接口跟container runtime进行交互，这个接口定义了容器启动时的各种参数。而真正容器在运行时，是通过OCI（容器运行时规范）跟底层操作系统交互。如下图：
所以，只要容器能够通过CRI接入kubernete，不管是不是docker容器，都是可以被kubernete集群管理的。
聊聊kubelet
kubelet是kubernetes中非常重要的一个组件，它是按照控制器模式来进行工作的。kubelet启动的时候，会注册各种自己关心的事件，比如pod的状态变化(add、update、remove等)、磁盘空间监控、oom监控等。
注册成功后，kubelet就会启动一个循环监控，来监听这些事件。kubelet同时还会控制一些子控制器，这些控制器也是一个循环监控，可以监控volume管理器、image管理器、网络状态以及node状态的管理器等。
这些循环监控的控制器，会收集监控到的内容，比如node状态，上报给api server。
我们看下面的这个yaml文件：
apiVersion: apps/v1
kind: Deployment
metadata:
name: springboot-mybatis-deployment
spec:
selector:
matchLabels:
app: springboot-mybatis
replicas: 1
template:
metadata:
labels:
app: springboot-mybatis
spec:
containers:
- name: spingboot-mybatis
imagePullPolicy: IfNotPresent
image: zjj2006forever/springboot-mybatis:1.2
ports:
- containerPort: 8300我们执行下面的命令后，有一个pod就会被创建出来：
kubectl apply -f springboot-mybatis.yaml那这个过程是怎样的呢？我们看下面的图：
从图中可以看到，当pod被调度到一个node节点后，这个节点的kubelet监听到这个事件后，首先会生成pod status，然后检查pod是否具备创建条件，比如volume是否准备好，最后调用底层的container runtime来创建这个pod里面定义的容器。
聊聊CRI
通过上一节的讲述，其实我们已经明白了kubelet创建容器的过程。有一个要注意的是，kubelet并不会直接调用容器的api来创建容器，而是通过container runtime，具体说就是CRI(Container Runtime Interface)提供gRPC接口给kubelet。
那kubernetes为什么要设计CRI这一层呢？这其实是使用了适配器模式。要知道docker是一种容器，但是容器不光是docker，还有其他类型容器，比如rkt、runV，它们提供的api并不是完全一样的，kubelet要创建这些容器，就需要调用不同的接口。
kubernetes主业务是编排，它的编排功能要支持不同容器的接入，就需要提供一套统一的接口来适配不同的容器。kubernetes的做法是开发了一个GenericRuntime通用组件，这个组件会把CRI请求发送给具体的CRI，最后由CRI把收到的请求封装成OCI请求来调用。
具体到docker而言，这个CRI叫做dockershim，它会把CRI组装成docker api来发送给docker。
上面的过程如下图：
在kubernetes1.20之前，dockershim的代码是在kubelet中的，这给docker使用带来方便，如果要是使用其他类型的容器，比如在操作系统上安装一个CRI shim，来转换请求。
可以看到，kubernetes把dockershim从kubelet的代码中剥离出来，专注于做容器编排，也是合情合理的，并不违背设计原则。
注意：上面提到了OCI，也是一个container runtime，它的规范是用来同底层的linux操作系统来交互的，也就是说container shim的职责就是把CRI请求转换成OCI规范。
目前的CRI主要有2种，containerd和CRI-O，我们来看一下：
- containerd是在docker内部实现的，是docker的一部分，所以如果升级kubernetes到1.20，使用containerd的话，其实是可以很容易使用docker的。
- CRI-O不同，它纯粹就是一个CRI，比较轻，它也是支持docker的。
docker shim何去何从
kubernetes弃用docker的消息确实引起了大家的关注，不过另外一个好消息是Mirantis已经同意在kubernetes之外维护docker shim的代码了。这样我们就可以继续使用docker shim了，不同的是之前是在kubernetes内置使用，现在需要在外部使用。当然我们也可以使用docker内置的CRI。
Mirantis的docker shim开源的地址如下：
https://github.com/Mirantis/cri-dockerd具体内容我们可以参考这个官网连接：
https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/总结
kubernetes放弃docker shim，对使用docker构建容器镜像的用户来说，确实会有一些影响。但是有解决方案的，docker内置的CRI或者我们使用CRI-O都是可以的。
kubernetes作为一个容器编排引擎，创立之初docker已经是容器领域事实的老大了，kubernetes想要发展壮大，就必须对docker大力支持，所以当时就在kubelet上开发了docker shim。
有人说kubernetes现在翅膀硬了，就要甩开docker，这种说法也能说得过去。但是从我们技术人的角度看，业务边界划分和维护成本我想是kubernetes移除docker shim的重要原因。