与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。

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!