与Kubernetes渐行渐远,Docker未来在哪里?

这几天一则Kubernetes将放弃Docker的消息引起业内广泛关注。根据Kubernetes社区给出的说明,在1.20版本之后,Kubernetes将不再支持把Docker作为容器运行时使用,据此不少人开始担心Docker未来不能用了。实际上,这并不是说Kubernetes要完全抛弃Docker,CNCF也提醒说不要惊慌,Docker 生成的镜像将继续在用户的集群中与所有运行时一起工作。但这件事还是让人不免产生联想,Docker还有一个怎样的未来?很长时间以来,谈到容器,Kubernetes + Docker好像是标配,现在看来并不一定。

Kubelet不再支持Docker运行时

人们对Docker未来的担心源于Kubernetes 在1.20版本中 的 ChangeLog 提到,kubelet 中的 Docker 支持功能现已弃用,并将在之后的版本中被删除。社区解释说,这么做的原因是,Kubelet 之前使用的是一个名为 dockershim 的模块,用以实现对 Docker 的 CRI 支持,但 Kubernetes 社区发现其维护存在问题,因此建议大家考虑使用包含 CRI 完整实现的可用容器运行时。

首先要说明的是,这里提到的Docker运行时并不等同于我们经常说的Docker,这可能是让人们以为Docker被Kubernetes抛弃的一个原因。运行时(Runtime)为应用程序运行时提供保障的一个环境,通常是一些可以重用的程序/库或者实例,这些实例可以在它们运行的时候被连接或者被任何程序调用。在Kubernetes集群内部也有一种称为容器运行时的组件,负责提取并运行容器镜像。Docker就是目前最流行的容器运行时,除此之外容器运行时还有Containerd与CRI-O。

与Containerd与CRI-O的定位就是一个运行时不同,Docker集成了太多功能,而很多功能作为一个运行时并非必须,比如容器创建,而且Docker最初在设计上也并未考虑到被嵌入到Kubernetes这种用法。

应该说,当初为了支持使用Docker的这个运行时,kubelet做出了妥协。如果采用Containerd与CRI-O运行时,其调用流程是:kubelet向CRI-Container插件发出调用请求,由CRI-Container再和容器运行时通信,完成请求的各种操作,但采用Docker运行时,这个流程就需要做出改变。由于Docker运行时并不兼容CRI,不得不引入一个新的插件Dockershimi作为缓冲。此时流程变成:kubelet先向Dockershimi发出请求,由Dockershimi调用Docker运行时,Docker运行时再调用其中的Containerd,由Containerd来负责完成请求的各种操作。可以看出,这个过程中Docker运行时有点尬尴,它的加入不仅在流程上多了一个环节,引入了Dockershimi,而Dockershimi的介入又引发了新的问题,必须额外加以维护,否则就可能引发安全问题。

如今,随着Kubernetes社区的逐渐强大,当初Kubernetes向Docker做出的妥协现在不打算继续了,这才有了kubelet不再支持Docker运行时的举措。目前来看这件事的影响不大,正如CNCF所言,Docker不会就此消亡,Docker会继续构建起不计其数的容器,开发人员仍然可以继续采用Docker,继续将Docker作为开发工具,Docker所生成的镜像仍可在Kubernetes集群内正常运行。

如果使用的是云上的容器服务,比如GKE或者EKS等托管Kubernetes服务,则需要确保在未来的Kubernetes版本彻底去除Docker支持之前,为工作节点引入受支持的容器运行时。如果是自己负责管理的集群,则要注意更新和调整运行时以避免服务中断。在1.20版本中,将收到Docker弃用警告。而在未来的Kubernets版本(计划在2021年下半年发布的1.23版本)中,Docker运行时将被彻底移除、不再受到支持。

然而,长期来看呢?

Docker的未来在哪里?

毋庸置疑,容器的流行Docker功不可没。在Docker出来之前,容器已经存在多年,但并不普及,直到Docker的出现。2013年,Docker的出现第一次把运行容器变得这么简单,使用Docker开发人员可以轻松启动、停止和撤销容器,而且其低学习曲线和易用性使其成为软件开发过程中的主流。

可以说,Docker以一己之力将容器这种相对边缘的技术硬生生地变成了网红。Docker的走红带动了Docker生态,大量围绕着 Docker 项目的网络、存储、监控、CI/CD、甚至 UI 项目纷纷出台,也涌现出了Rancher等一批在开源创业公司。与此同时,竞争的种子也就此埋下。

Docker最初从开发端发力,一家独大,但是要Docker希望继续做大,特别是获取商业价值,就需要向应用部署和运营方向发力,提供部署、监控和管理等放方方面面的工具,Swarm就是其中之一。而对CoreOS、Red Hat、谷歌和微软等这些应用程序运行平台提供方而言,支持容器是刚需,但它们希望通过容器运行时的标准化,来尽可能降低Docker的影响。显然,Docker并不愿意,特别是当时Docker如此火爆的背景之下。这就是双方争夺的焦点。

与Kubernetes渐行渐远,Docker未来在哪里?http://www.yywgx.com/123/3197.html

若获得转载权,请注明出处:http://www.yywgx.com/123/3197.html

声明:未经许可不得转载;部分内容或来自其它媒体,转载目的在于传递更多信息,版权归原作者所有,今日新鲜事不承担任何法律责任。

我要评论

请自觉遵守互联网相关的政策法规

全部评论
最热最早最新

热点文章