kubernetes真要放弃docker吗?
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了kubernetes真要放弃docker吗?,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含4801字,纯文字阅读大概需要7分钟。
内容图文
![kubernetes真要放弃docker吗?](/upload/InfoBanner/zyjiaocheng/1005/058115f45981415896be12ed900e52c2.jpg)
这几天,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真要放弃docker吗?全部内容,希望文章能够帮你解决kubernetes真要放弃docker吗?所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。