标签：容器 kubernetes shim kubelet docker CRI 真要
这几天，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的重要原因。
标签：容器,kubernetes,shim,kubelet,docker,CRI,真要 来源： https://blog.51cto.com/u_15095774/2718591
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。