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]

不要小看这短短的一句话,蕴含了丰富的内容。dockershim?container runtime?CRI?你真的理解吗?今天我们就来聊一聊kubernetes是否真的要放弃docker。

kubernetes体系架构

我们先看一下kubernetes体系架构,如下图:

kubernetes真要放弃docker吗?

master节点是空值节点,有3个重要的组件组成。controller manager负责容器编排,api server提供api服务,scheduler负责任务调度。整个集群的状态保存在etcd中。

node节点是计算节点。最重要的组件是kubelet,通过CRI(Container Runtime Interface)远程调用接口跟container runtime进行交互,这个接口定义了容器启动时的各种参数。而真正容器在运行时,是通过OCI(容器运行时规范)跟底层操作系统交互。如下图:

kubernetes真要放弃docker吗?

所以,只要容器能够通过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

那这个过程是怎样的呢?我们看下面的图:

kubernetes真要放弃docker吗?

从图中可以看到,当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。

上面的过程如下图:

kubernetes真要放弃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的重要原因。 

上一篇:Kubernetes集群组件的安全


下一篇:初探Kubernetes Pod