2

容器江湖的爱恨情仇-51CTO.COM

 2 years ago
source link: https://developer.51cto.com/article/708883.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

容器江湖的爱恨情仇-51CTO.COM

容器江湖的爱恨情仇 原创
作者:Thoughtworks洞见 2022-05-13 09:47:28
从各方面来看,无论从技术的领导力,还是盈利能力,Docker公司都已经开始掉队,不禁要问,曾经风头无二的容器化大佬究竟怎么了?

作者  |卢爱飞

近两年Docker可谓充满了争议,例如去年底K8s宣布不打算支持Docker,消息一出,大家争相讨论Docker的可替代方案,Colima作为Docker Desktop的热门开放替代方案,Podman作为Docker的替代方案,收到许多开发者和企业的关注。在今年Docker公司又宣布了Docker Desktop准备向中大型企业用户收费,“再见Docker”的声音再度高涨。

c50354056736ff2ddcd4703ea5552775be8c17.jpg

从各方面来看,无论从技术的领导力,还是盈利能力,Docker公司都已经开始掉队,不禁要问,曾经风头无二的容器化大佬究竟怎么了?

把时间往回推几年,大家提起Docker,都会把它与容器技术画上等号,Docker引领容器技术变革的光荣岁月,依然让人满怀激动。在2013年,Cloud Foundry是云服务领域的绝对焦点,以Cloud Foundry为核心的PaaS平台服务能力变革席卷了整个云服务领域,同时也涌现了一批优秀的PaaS平台,包括Salesforce Heroku、IBM Red Hat等。其中一家叫dotCloud的公司,也是这股 PaaS 热潮中的一份子。但在当时的Cloud Foundry项目中,容器是最底层、最没人关注的那一部分,因此dotCloud的产品一直无人问津。为改变这种被动的现状,dotCloud公司决定开源自家的容器项目Docker。

就在短短的几个月的时间里,Docker项目迅速崛起,很快就颠覆了Cloud Foundry定义的PaaS平台的玩法。那相比于Cloud Foundry,Docker到底存在什么样的决定性优势呢?

这要从Cloud Foundry的应用托管说起,Cloud Foundry最核心的组件就是一套应用的打包和分发机制。用户只需要执行一个命令,就能一键将应用发布到云端。为支持这样的特性,Cloud Foundry实际上会为不同语言或框架发布不同的打包器(BuildPack),然后把本地的可执行应用打包,并上传到Cloud Foundry,Cloud Foundry会调度合适的agent来下载应用,并完成部署。为保障agent上的服务相互隔离,Cloud Foundry会通过Cgroup和Namespace为应用提供隔离的“沙箱”运行环境。

Cloud Foundry 的首席产品经理在对比Cloud Foundry和Docker之后,也说过Docker并没有什么黑科技,和Cloud Foundry一样,也是依赖Cgroup和Namespace创建了“沙箱”运行环境而已。

那究竟Docker比Cloud Foundry强在哪呢?答案就在镜像这种特别的应用打包方式。

c255d4a58044dbc1392200c41ffc364e39ef2d.png

典型的应用运行环境包括代码、依赖和操作系统,Cloud Foundry可以保证代码和依赖一致,但无法保障系统环境,所以有时本地运行正常,在云端却不行,出了问题,也很难定位到系统环境的差异性。但Docker正好解决了这个痛点,通过Image构建出Rootfs,完美保障本地和云端运行环境的一致性。

在此基础上,Docker还提供了友好的Docker CLI来创建Image,同时提供了Docker Hub来快速分发Image和同性交友。在Docker迅速取得成功之后,dotCloud公司也顺势改名为Docker,Docker公司俨然已经成为容器技术的代言人。

容器云之争

单纯解决应用打包并没有价值,企业真正需要解决的是应用部署问题。Docker公司也意识到容器平台化能力才是致胜关键。在2014年Docker公司很快发布了Swarm项目,依然保持着Docker的友好命令风格,几个命令就可以完成多机集群部署。在此基础上,不断招兵买马,例如收购了Fig项目(后改名为Compose),以及专门负责容器网格的SocketPlane等,充实着自己的平台化能力。此时Docker公司掌握着容器的绝对话语权,而Docker公司的平台化战略,又切实挑战到了其它云服务平台的切身利益,其中就包括Google和RedHat等公司。

为了改变Docker一家独大的局面,由Docker、Google、RedHat等公司共同成立了OCI(Open Container Initiative),旨在定义出镜像和容器运行时标准,将标准从Docker项目实现中抽离出来。显然,Docker公司不会花精力在这种削弱自己影响力的项目上,所以OCI规范一直进度缓慢。

e4cfd5965877fcf7bca16665118ea41f35f817.png

但Google和RedHat没有坐以待毙,随后祭出了大杀器 --- Kubernetes,大家拉帮结伙,共同成立了CNCF基金会,以 Kubernetes 项目为基础,建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区,来对抗以 Docker 公司为核心的容器商业生态。Kubernetes凭借强大的设计和RedHat的优秀社区运营,很快催生了一个与众不同的容器编排与管理的生态,催生了Prometheus、Istio等一批优秀的开源产品。为了应对Kubernetes带来的挑战,Docker公司主打的则是Docker Native的战略,放弃现有的Swarm 项目,将容器编排和集群管理功能全部内置到 Docker 项目当中,这也为将来埋下了隐患 --- 尾大难掉。

即使这样,Docker也无法与日益壮大的Kubernates社区相抗衡,最终以失败收场,Docker公司将容器运行时runc项目捐赠给 CNCF 社区,将 Docker 项目改名为 Moby,交给社区自行维护,而 Docker 公司将占有 Docker 这个注册商标,将Docker的客户转移到自己的手上,彻底地开始了自己的商业化运营。

Docker的困局

容器云之争,最终以Docker公司的失败收场,痛失云平台高地之后,留给Docker公司的盈利点也不算太多:

  • 私有Hub
  • 容器云平台
  • 专业技术支持和培训

容器云平台的低占有率限制了收益,Docker公司为了保障盈利,宣布了Docker Hub、Docker Desktop收费的商业决策,颇有饮鸩止渴的感觉。从技术层面,Kubernates已经成为了容器编排的事实标准,而Container在整个版图中,也只属于最底层的部分。

OCI的规范已初见雏形,同类容器运行时containerd已经取代Docker,成为大多数托管 Kubernetes服务采用的容器运行时。再谈Docker Hub,基本上成熟的云平台都有发布自己的Container Registry,例如Amazon Elastic Container Registry (ECR)等,私有Hub的收费方式还很脆弱。

由于设计理念的不同,Docker添加了许多组件来保障友好的用户体验,这是Kubernates不需要的,此外它不支持Kubernates的CRI规范,从下图可以看到,社区需要维护一个Docker Shim项目来桥接Kubernates Node和Docker。一开始Kubernetes为了接入Docker生态,自然愿意维护这一套项目,但随着OCI、CRI规范和产品的成熟,社区便失去继续维护该项目的动力。

b721d2d88a85613f62b202fa4941defd469b24.png
d1b8d28944614c5b313833afa450c70aeb6d46.png

(图片来源:Kubernetes is Removing Docker Support, Kubernetes is Not Removing Docker Support)

痛失容器编排阵地,容器标准的话语权被逐渐削弱,再加上饮鸩止渴般的收费商业模式,仅凭借优秀的用户体验,Docker真的能留住大家吗?不禁让人想问,廉颇老矣,尚能饭否?


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK