DevOps(Development和Operations的组合词)是一组过程、方法与系统的统称,用于促进开发(应用程序/软件工程)、技术运营和质量保障(QA)部门之间的沟通、协作与整合。
分享到: 分享到QQ  分享到Twitter

作者: BigLoser    访问次数: 455 创建时间: 2020-12-09 21:02:49 更新时间: 2024-03-28 17:44:31

12 月 2 日,Kubernetes 发布了一则消息,表示将在即将发布的 Kubernetes 1.20 版本中弃用 Docker 支持。CNCF 大使 Ian Coldwater 特地发了一条Twitter消息,呼吁大家对此进行关注:“ Kubernetes 中已弃用了 Docker 支持。你需要注意这一点并做一些计划。这将破坏你的集群。”

 

这些举动,在技术圈子里引起的震荡就好比又宣布了一次 Docker 的死亡(第一次是“Swarm 的没落”)。虽然这只是一盘大棋中最无关紧要的最后一小步,目的就是让 Kubernetes“不再依赖”Docker。

 

容器技术圈子在短短几年发生了一些重大的变数。

 

Docker 以提供镜像打包的创新技术实现了“一次构建、处处运行”的软件交付方式,开启了一个全新的容器时代。面对平台化的竞争,Docker 推出了调度引擎 Swarm,但 Swarm 从未真正流行起来,因为整个行业更倾向于采用 Kubernetes,这是 Docker 第一次死亡:它失去了平台之战。2016 年 9 月,Google 和 RedHat联合宣布了“fork Docker”,也就是后来的 CRI-O 项目,这就是这次弃用事件的起始,同时也宣告了竞争的结束。

 

谁会受到影响?

 

Docker 源于 Linux Container,可以将一台机器的资源分成 N 份容器,做到资源的隔离,并将可运行的程序定义为标准的 docker image。相对来说,Kubernetes 属于 Docker 容器引擎的上层:编排调度层,它可以把不同机器的每份容器进行编排、调度,组成分布式系统。

 

近几年,Kubernetes 已经成为自有机房、云上广泛使用的容器编排方案,最广泛的使用方式是 Kubernetes+Docker。运维工程师一方面用 Kubernetes 中的 kubctl 命令、k8s API 来操作集群,一方面在单机用 docker 命令来管理镜像、运行镜像。技术专家杨明越给 InfoQ 总结道:“单独用 Kubernetes,下层不是 Docker 的情况,并不算很多”。

 

“弃用 Docker”,具体来说,是 Kubernetes 将在 1.20 版本中弃用 dockershim。它是一个桥接服务,帮助 Kubernetes 与 Docker 通信时屏蔽下层容器运行时之间的差异。

 

 

这种桥接服务带来便利性的同时也带来了复杂性。留着时间的流逝,这种复杂性不断“膨胀”,维护 Dockershim 已成为运维/开发人员的沉重负担。在下一版中,去掉 Dockershim 将是一个极大的简化,并且恢复了调用的一致性。

 

 

尽管 Kubernetes 在发布消息的时候,表示开发人员对这种转变“不必恐慌”,“Docker 还没有死,它仍然有其用途”。但显然 Kubernetes 的解释并不能令人满意:“是否有人质疑为什么不选择一种更顺畅的迁移方式,而不是像谷歌那样抨击 Docker,劝人们赶紧迁移,越快越好”。也有更多开发人员表达了他们并不明白接下来他们需要做些什么。

 

 

在生产环境中,企业大量的使用的是经典 Kubernetes+ Docker 方案,同时在一些公司的场景中也有单独使用 Docker 的情况。

 

如果用户的业务部署比较简单,规模也较小,仅仅是为了使用容器做应用交付的便利,也没有其他的功能需求的话,仅仅通过 docker run/docker-compose 这种方式也能管得好的话,实际上是没必要非得引入 Kubernetes 这样非常重的编排组件的。反而直接仅仅使用 Docker 会更轻量,也更好运维。比如 toB 的软件交付的情况,如果要部署的软件的部署架构比较简单的话,仅仅涉及少量几台机器,服务进程也不多的情况下,也有不少是直接使用 Docker,而不引入 Kubernetes 的,比较轻量、简单。

 

还有一个就是,使用 kubernetes 做编排引擎的情况下,实际开发者在日常的开发中,也会比较多地使用 Docker。

 

“对于一般的应用开发者来说,他们一般不会直接去面对 Kubernetes 的,因此,对于他们来说,可能压根就是无感知的,应用开发者甚至都不用知道他们的业务是用容器运行的。对于整个基于 Kubernetes 生态的各个解决方案提供商来说,由于当前基于 Kubernetes 的编排是事实标准,容器的镜像格式又是都遵守 OCI 的,因此可以说所有的之前的交付的构件,无论容器运行时怎样变化,实际上都不会有啥影响。”网易轻舟容器平台 NCS 负责人王新勇在接受 InfoQ 的采访中表示,“但对于容器平台提供商来说,可能需要一些适配和准备动作。”

 

 

根据 Sysdig 发布的 2019 年容器使用报告显示,Docker 占据了容器平台市场的大部分份额,占比为 79%,而排在第二位的是 containerd,占比为 18%,排在第三位的 CRI-O 项目,占比为 4%。

 

CRI-O 是 Kubernetes 的轻量级运行时,希望绕过现有 Docker 容器的大部分机制直接操作 Linux 容器,由 RedHat 主导,并且也是目前 Kubernetes 推崇的方式。

 

“网易已经有比较好的准备,实际上 Kubernetes 弃用 Docker 从很早就开始讨论了。很早我们就开始关注和使用 Containerd 作为我们的容器运行时的一个选项了。后续我们会提供相关的运行时多个选项 ,并逐步过渡到使用 Containerd 作为运行时。”王新勇表示。

 

“我们还可以通过将 Dockershim 从 Kubernetes 中抠出来,独立运行,作为 Kubernetes 的 cri 到 Docker API 的适配器,实现 Kubernetes 继续支持 Docker,从而保持之前的使用习惯。”

 

杨明越也认为由于老技术实现的惯性,在生产环境大量使用的经典 Kubernetes+ Docker 方案依然运行,且运维已经成熟,不会很快升级。对于开发人员、企业,对于 K8S API 的使用频率、变数,远远大于 Docker API,至于 Kubernetes 和 Docker 的桥接,更不用关心。因此,即便“彻底弃用 Docker”,对开发者与企业的影响也非常有限。

 

Docker 会消亡吗?

 

Docker 和 Kubernetes 的往事已经非常久远,从亲密伙伴到反目成仇,令人不胜唏嘘。

 

2013 年,当时名叫 dotCloud 的 Docker 公司,开源出来了自己的容器项目 Docker。Docker 通过镜像打包的方式保持了本地环境和云端环境的高度一致,解决了运维人员的一大心病,将运维人员从一遍遍的重复劳动中解放了出来。同时友好简洁的封装,对开发人员十分具有亲和力,这让 Docker 一举走红。很多后端和云计算领域的优秀的开发力量都汇集在了 Docker 的周围,生态一时间变得异常繁荣。

 

但此时的这个开源创业公司还必须考虑盈利压力,于是 dotCloud 公司决定将公司名称改为“Docker”。将这个开源项目的名称变成了 Docker 公司的注册商标,这意味着,任何人在商业活动中使用这个单词,以及鲸鱼的 Logo,都会立刻受到法律警告。

 

2014 年到 2015 年期间,是容器技术的鼎盛时期,Docker 公司一家独大,具有十足的话语权,主导着整个社区的发展。Google 公司曾向 Docker 公司表达了合作的愿望,希望共同推进一个中立的容器运行时(container runtime)库作为 Docker 项目的核心依赖。不过,Docker 公司并没有认同这个明显会削弱自己地位的提议,不久后 Docker 自己还发布了一个容器运行时库 Libcontainer。

 

作为开源生态的一部分,Docker 还缺少有效的商业模式,他们将眼光放到了容器编排领域,推出了 Swarm。作为 Docker 项目早期的重要贡献者,RedHat 对 Docker 公司的这个平台化战略表示很不满并愤愤退出该项目。

 

面对 Docker 的强硬态度,Google 联合 RedHat,共同牵头发起了一个名为 CNCF(Cloud Native Computing Foundation)的中立基金会,来推动 Kubernetes 的发展。

 

从此之后,面对 Kubernetes 社区的崛起和壮大,Docker 公司不得不面对失败的现实。2017 年 Docker 公司宣布将 Docker 项目改名为 Moby,交给社区自行维护,而 Docker 公司的商业产品将占有 Docker 这个注册商标,希望以此将原本属于 Docker 社区的用户转化成了自己的客户。

 

 

杨明越认为现在的 Kubernetes,从技术上可以说是非常开放的产物,但 Docker 已经不是。开源社区的 Moby 项目,图标由一条鲸鱼变成了一条鲸鱼的尾巴,也可以看出 Docker 对开源版本的态度。原本是开源的项目,是开源生态的一部分,盈利的目标对于 Docker 来说,属于“强扭的瓜”。正如人际关系,从风雨同舟到分道扬镳,甚至到反目成仇,这其中的转折点,并非一两次冲突,而是价值取向的背离。

 

他强调说:“总体来说,Docker 的弱势来自于公司的盈利、技术应用面两方面,但如果谈 Docker 的消亡,还为时过早。因为 Docker 本身也是一系列技术模块的组合体系,而非一个东西。”

 

王新勇也认为 Docker 技术(或者说 Moby 项目)和 Docker 公司得分开看待。短时间内,Moby 项目不会消亡,会使用 Docker 命令可能会成为一个开发人员的必备技能,毕竟技术的惯性是很强大的。至于 Docker 公司,就算处境不乐观,应该也是不影响 Docker 技术本身的,毕竟其背后还有强大的开源社区。

 

云原生技术的未来

 

近几年,云原生技术发展速度很快,“Kubernetes 1.20 版本中弃用 Docker 支持”可能只是其中很小的一段插曲,毕竟在云原生的全局图中,运行时只占很小的一部分,而且又是比较标准化的部分。

 

“从云原生的角度来看 Kubernetes 弃用 Docker,其实是件好事,”杨明越表示:“Docker 已经是个商业化产品了,如果能找到一个开源替代品,对整个技术的发展会更有益处。”那么,谁将会代替 Docker 成为云原生技术的“新势力”呢?在我们的采访中,多位老师表示很看好 Podman。

 

Podman(Pod Manager)是一个由 RedHat 公司推出的容器管理工具,其定位就是 Docker 的替代品,在使用上与 Docker 的体验类似。Podman 源于 CRI-O 项目,可以直接访问 OCI 的实现(如 runC),流程比 Docker 要短。

 

为什么说 Podman 是比 Docker 更先进的存在呢?晓川表示:“首先,Docker 已经是商业化的产品,而 podman 是个开源产品,在以开源为主的云原生技术体系中更容易得到推广和应用;其次,Docker 在实现 CRI 时,需要一个守护进程,并且以 root 来运行,这就带来了安全隐患,而 podman 不需要,可以直接通过 OCI runtime(默认也是 runc)来启动容器。”

 

 

Docker 与 Podman 的区别

 

由于 podman 的定位是 Docker 的替代品,因此在使用习惯方面也与 Docker 十分类似。

 

从系统构建者角度看,podman 默认软件与 Docker 的区别不大,只是在进程模型、进程关系方面有所区别,例如关联进程的调试方面、进程的树状结构查看等等,而且总体来看,podman 要比 Docker 简单;从使用者角度看,podman 与 Docker 的命令基本兼容,包括容器运行时、本地镜像、镜像仓库等。因此,podman 命令行工具与 docker 类似,比如构建镜像、启停容器等,甚至可以通过 alias docker=podman 可以进行替换,即便使用了 podman,仍然可以使用 docker.io 作为镜像仓库。

 

除了 Kubernetes,RHEL 7 同样官方也不支持 Docker,只为容器环境提供 Podman、Buildah 以及 CRI-O。

 

采访嘉宾:

 

杨明越,现从事分布式系统、云架构方面工作,具有全方位的技术,曾任新兴互联网公司(BAT)的主任架构师,世界顶级芯片公司的 OS 技术专家,前 Top2 通讯公司高级工程师。

 

王新勇,网易数帆资深架构师,网易轻舟容器平台 NCS 负责人。

 

晓川,曾在 RedHat 任产品测试开发工程师,具有多年 Docker 容器、K8s、Linux 和 Python 方面的经验,在 OpenShift 从事 PaaS 平台比较前沿的技术项目。

年度最有价值文章

季度最有价值文章

月度最有价值文章

投票统计

是否原创: 0 %

0 % Complete (success)

是否有价值: 0 %

0% Complete

是否有素质: 0 %

0% Complete (warning)

是否合法: 0 %

0% Complete

   群组工具

   外部链接