这几天，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]

不要小看这短短的一句话，蕴含了丰富的内容。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接入kubernetes，不管是不是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的重要原因。