?k8s极简史,一文看懂k8s如何力战群雄,坐上容器编排老大( 三 )


而引导这一现象的原因却仅仅是**Docker的镜像功能** 。
恐怕连 Docker 项目的作者 Solomon Hykes 自己当时都没想到 , 这个小小的创新 , 在短短几年内就如此迅速地改变了整个云计算领域的发展历程 。
PaaS 之所以能够帮助用户大规模部署应用到集群里 , 是因为它提供了一套应用打包的功能 。可偏偏就是这个打包功能 , 却成了 PaaS日后不断遭到用户诟病的一个“软肋” 。
用户一旦使用了 PaaS , 就必须为每种语言、每种框架 , 甚至每个版本的应用维护一个打好的包 。这个打包过程 , 没有任何章法可循 , 更麻烦的是 , 明明在本地运行得好好的应用 , 却需要做很多修改和配置工作才能在 PaaS 里运行起来 。而这些修改和配置 , 并没有什么经验可以借鉴 , 基本上得靠不断试错 , 直到你摸清楚了本地应用和远端 PaaS 匹配的“脾气”才能够搞定 。
而 Docker 镜像解决的 , 恰恰就是打包这个根本性的问题
就这样 , 容器化的时代开始了!
K8S

?k8s极简史,一文看懂k8s如何力战群雄,坐上容器编排老大

文章插图
 
k8s
那Docker和k8s又有什么关系呢?
前面介绍 , Docker 项目一日千里的发展势头 , 但用户们最终要部署的 , 还是他们的网站、服务、数据库 , 甚至是云计算业务 。
这就意味着 , 只有那些能够为用户提供平台层能力的工具 , 才会真正成为开发者们关心和愿意付费的产品 。而 Docker 项目这样一个只能用来创建和启停容器的小工具 , 最终只能充当这些平台项目的“幕后英雄” 。
即要想Docker能大面积普及 , 还需要解决大量Docker的协作编排问题 。
谈到Docker容器编排问题 , 就不得不说说 Docker 公司的老朋友和老对手 CoreOS 了 。CoreOS 是一个基础设施领域创业公司 。它的核心产品是一个定制化的操作系统 , 用户可以按照分布式集群的方式 , 管理所有安装了这个操作系统的节点 。从而 , 用户在集群里部署和管理应用就像使用单机一样方便了.
Docker 项目发布后 , CoreOS 公司很快就认识到可以把“容器”的概念无缝集成到自己的这套方案中 , 从而为用户提供更高层次的 PaaS 能力 。所以 , CoreOS 很早就成了 Docker 项目的贡献者 , 并在短时间内成为了 Docker 项目中第二重要的力量 。
然而 , 这段短暂的蜜月期到 2014 年底就草草结束了 。CoreOS 公司以强烈的措辞宣布与 Docker 公司停止合作 , 并直接推出了自己研制的 Rocket(后来叫 rkt)容器 。
这次决裂的根本原因 , 正是源于 Docker 公司对 Docker项目定位的不满足 。Docker 公司解决这种不满足的方法就是 , 让 Docker 项目提供更多的平台层能力 , 即向 PaaS 项目进化 。而这 , 显然与 CoreOS 公司的核心产品和战略发生了严重冲突 。
大红大紫不差钱的 Docker 开始大私收购来完善自己的生态和平台能力 。最出名的莫过于 Fig项目 , 即现在的 Compose , 除此外 , 还有 SocketPlane, Flocker, Tutum等项目 。
Docker的异常繁荣终于引起了行业巨头的关注 。
作为 Docker 项目早期的重要贡献者 , RedHat 也是因为对 Docker 公司平台化战略不满而愤愤退出 。但此时 , 它竟只剩下 OpenShift 这个跟 Cloud Foundry 同时代的经典 PaaS 一张牌可以打 , 跟 Docker Swarm 和转型后的 Mesos完全不在同一个“竞技水平”之上 。
2014年6月 , 基础设施领域的翘楚 Google 公司突然发力 , 正式宣告了一个名叫 Kubernetes项目的诞生 。而这个项目 , 不仅挽救了当时的 CoreOS 和 RedHat , 还如同当年 Docker项目的横空出世一样 , 再一次改变了整个容器市场的格局 。
2015年6月22日 , 由 Docker 公司牵头 , CoreOS、Google、RedHat 等公司共同宣布 , Docker公司将 Libcontainer 捐出 , 并改名为 RunC 项目 , 交由一个完全中立的基金会管理 , 然后以 RunC 为依据 , 大家共同制定一套容器和镜像的标准和规范 。
但由于 OCI 的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果 。所以OCI的组织效率一直很低下 。


推荐阅读