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

很长时间以来,谈到容器,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如此火爆的背景之下。这就是双方争夺的焦点。

OCI规范的推出就是双方竞争达成妥协的结果。2015 年 Docker 公司牵头,联合CoreOS、Google、RedHat 等公司共同宣布,Docker 将自己的容器运行时库 Libcontainer 捐出,并改名为 RunC 项目,然后以 RunC 为依据,大家共同制定一套容器和镜像的标准和规范,这就是 OCI( Open Container Initiative )。OCI 的提出目的是将在将容器运行时和镜像的实现从 Docker 项目中完全剥离出来,为其他厂商不依赖于 Docker 项目构建各自的平台提供可能。

OCI对Docker的影响其实不大,特别是相比于同年成立的CNCF(Cloud Native Computing Foundation),这个由Google、RedHat 等开源基础设施领域玩家们牵头发起的基金会,准备以 Kubernetes 项目为基础,建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区,来对抗以 Docker 公司为核心的容器商业生态。

与之间的较量不同,这次的较量已经离开了Docker擅长的开发领域,更多地在应用的部署和运营,也就是PaaS层面展开,这些恰恰是红帽、Google等所擅长的。Kubernetes从最擅长的容器编排入手,把Docker作为其中一个组件,可以说从一开始就站在战略制高点。借助Google 在Borg上积累的先进技术加上Red hat等在开源软件方面运营的经验,很快Kubernetes就在竞争中开始领先。

当然,刚开始时,这种竞争是很温和,2014年Kubernetes诞生时,它使用了Docker,因为Docker是当时最流行的容器运行时。当时,除了Docker + Kubernetes,还可以选择Docker+Mesos、Docker+Swarm。

应该说,Kubernetes与Docker并不是直接的竞争关系,直接竞争的是Docker的Swarm。Swarm是一个集群和调度工具,作用类似于Kubernetes。不过,Swarm与Kubernetes这两者的竞争实质是对容器话语权的竞争,因此,本质上也是Docker与CNCF之间的竞争。

为了对抗Kubernetes,2016 年Docker 公司宣布放弃Swarm 项目,将容器编排和集群管理功能全部内置到 Docker 项目当中。Docker 公司意识到了 Swarm 项目目前唯一的竞争优势,就是跟 Docker 项目的无缝集成。不过,这一招看来不灵,Docker不久就在与CNCF的较量中败下阵来,在2017年10月的DockerCon EU 大会上,Docker官方宣布支持Kubernetes,将在自己的主打产品 Docker 企业版中内置 Kubernetes 项目,这也就是意味着,容器编排领域的争夺已经落幕,Kubernetes得到了认可。

回头看来,失利的Docker开始还能凭借强大的容器开发者生态发挥自己的影响力,这才有了kubelet做出的妥协,专门引入Dockershimi。然而,随着时间的推移,Kubernetes社区的逐渐强大,Kubernetes的生态越来越完善,Docker的话语权逐渐减少,被边缘化也在情理之中,Kubelet撤销对Docker的特殊待遇是迟早要发生的。因此,未来的Docker更大可能是保持在开发领域发挥自己的独特价值。

不过,无论如何,从Docker 2013年正式上市以来,以一己之力带火了容器技术,给软件行业带来了颠覆性变革,推动了软件行业乃至整个IT行业的发展和创新,从这点而言Docker是当之无愧的英雄,即使失败也应该赢得我们的尊重。

来源:至顶网软件与服务频道

0赞

好文章,需要你的鼓励

2020

12/09

18:14

分享

点赞

邮件订阅
白皮书