容器江湖的爱恨情仇-51CTO.COM
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
作者 |卢爱飞
近两年Docker可谓充满了争议，例如去年底K8s宣布不打算支持Docker，消息一出，大家争相讨论Docker的可替代方案，Colima作为Docker Desktop的热门开放替代方案，Podman作为Docker的替代方案，收到许多开发者和企业的关注。在今年Docker公司又宣布了Docker Desktop准备向中大型企业用户收费，“再见Docker”的声音再度高涨。
从各方面来看，无论从技术的领导力，还是盈利能力，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强在哪呢？答案就在镜像这种特别的应用打包方式。
典型的应用运行环境包括代码、依赖和操作系统，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规范一直进度缓慢。
但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规范和产品的成熟，社区便失去继续维护该项目的动力。
(图片来源：Kubernetes is Removing Docker Support, Kubernetes is Not Removing Docker Support)
痛失容器编排阵地，容器标准的话语权被逐渐削弱，再加上饮鸩止渴般的收费商业模式，仅凭借优秀的用户体验，Docker真的能留住大家吗？不禁让人想问，廉颇老矣，尚能饭否？
Recommend
-
39
你才不是一个没有故事的同学
-
36
首先我们简单了解一下什么堆、栈、队列。 堆是在程序运行时，而不是在程序编译时，申请某个大小的内存空间。即动态分配内存，对其访问和对一般内存的访问没有区别。 栈就是一个容器，后放进去的先拿出来，它下面本
-
24
C# Queue与RabbitMQ的爱恨情仇（文末附源码）：Q与MQ消息队列简单应用（二） ...
-
30
Kubernetes，容器管理领域的领导者；GlusterFS，分布式文件系统的后起之秀，他们之间会擦出什么样的火花呢？ 用Kubernetes部署的应用可以分为无状态的和有状态的，无状态的应用没有数据，Pod（一个或若干容器的集合）挂了被重新拉...
-
22
AV1、H.265与Janus的爱恨情仇（一） 距回顾有关Janus的内容以来已经过去了几周，我们大致陈述了许多不同的改进。现在我觉得是时候深入探讨一个主题了——
-
31
AV1、H.265与Janus的爱恨情仇（三） 要开展下一步，我们就要能访问实际的AV1 / RTP数据包，即弄清楚如何检测关键帧。最重要的是将捕获的数据包转换为可播放的媒体文件。
-
51
本站内容均来自兴趣收集,如不慎侵害的您的相关权益,请留言告知,我们将尽快删除.谢谢. 自己一直以来都是使用的pytorch，最近打算好好的看下tensorflow，新开一个系列：pytorch和tensorflow的爱恨情仇（相爱相杀。。。） ...
-
39
pytorch和tensorflow的爱恨情仇之基本数据类型 pytorch和tensorflow的爱恨情仇之张量
-
10
资讯 长短视频的爱恨情仇，腾讯们能杀死“五分钟看电影”吗？ 电科技杨赛04-26 18:44 110 身处内容爆炸的信息时代，争夺用户的注意力的战争也随之打响。近日，...
-
12
Rvm 与 Bundler 的爱恨情仇 自从2年前 Sam 帮我搭建了 Ruby 环境，除了升级就再没折腾过。懒，不爱折腾，太花时间，投入产出不成正比。 但是在开发的过程中，越来越多 Rvm & Bundler 的问题摆在了我面前，每次都要请教别人，十分的影响效...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK