Docker与k8s的恩怨情仇（一）—成为PaaS前浪的Cloud Foundry

迈不过友情╰ 2022-10-12 01:03 228阅读 0赞

> 转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

大家在工作中或许或多或少都接触过Docker，那你知道Docker以及容器化背后的原理到底是什么吗？

容器化技术满天下，那为什么只有Docker被大家所熟知呢？

后Docker时代，到底谁才是云原生时代的王者？

我们相信本系列文章能帮您解答这些疑惑。

# 被“嫌弃”的物理服务器 #

在云时代以前，开发者如需构建一个线上的站点，必须自己维护物理服务器。但是随着业务发展，大体量服务器逐渐增多，随之而来的是硬件、场地和维护成本的不断提高。对于面向C端的站点来说，网络热点事件具有随机性，流量的变化并不可控，难免会遭遇站内流量暴涨的情况。此时如果没有备用服务器，突发的大流量很可能会冲垮整个站点。但在没有突发事件的时候，备用服务器的采购和维护成本又让人不可忽略。

![2.png][]  
（运维的传统艺能：上线拜祖，图片来自网络）

哪里有问题，哪里就有商机。有人想到，如果买一批服务器放在外网，安排专人管理，然后按照用户的需要租赁出去，不正好解决了这个问题吗？

于是，一场云计算的好戏，正式上演。

# 虚拟机还是“超重”了 #

云计算时代的大幕拉开，大厂先后登台，让我们先简单做一下回顾。

*  2006年，亚马逊成立aws，从云端存储业务开始。
 *  2008年，云计算初创。
 *  2009年，阿里云成立。目前最新的数据表明，2020年度IaaS市场份额调查，阿里云位居全球第三，亚太第一；前两名分别是亚马逊和微软，市场份额达9.5%，超过谷歌的6.1%，亚马逊40.8%，微软17%。国内市场份额40% ，第二是华为云，占18%。
 *  2010年，OpenStack由NASA发布。OpenStack是一个IaaS架构，可以用其架构来搭建自己的私有云，让任何人都可以自行创建和提供云计算服务。对比而言，AWS和aliyun都是自研架构，OpenStack是开源的。所以公司如果需要，完全可以接入OpenStack搭建自己的私有云。（当然前提需要有OpenStack核心开发能力）。
 *  2010-2013年之间，云计算的全球份额被aws和OpenStack瓜分。

这时的云计算技术，本质都是虚拟化技术，将硬件资源作为基础设施提供给用户，简称IaaS。简单理解，IaaS就是将一个很大的服务器，通过虚拟化技术拆分成多个小的虚拟服务器，提供服务，类似于在本机装了虚拟机。

![1.png][]  
（云计算主力玩家的进场时间，图片来自网络）

但是，IaaS时代的虚拟机还是太过于笨重了。每一台虚拟机都需要消耗CPU、内存等计算资源才能支撑应用的运行。即便应用再小，系统的开销都是固定的成本。如何为IaaS减肥，让虚拟机系统的开销降到最低？

2013年开始，云计算正式进入了PaaS时代。PaaS时代，云计算所销售的单元，从虚拟机变成了应用运行平台。于是，云厂商提供的服务更多，资源利用率也更高了。

什么是PaaS？我们用一个通俗的例子来解释。如果我们现在是一个烧饼店老板，采用IaaS模式意味着我们需要用别人厨房、锅炉、煤气，自己和面做馅料，做烧饼。如果是PaaS，我们烧饼的面粉、馅料和调料都是别人提供好了，我们只需要把饼烤熟。

云厂商该如何构建一套好用的PaaS服务呢？借力开源项目，成为各厂商的共识。

# Cloud Foundry开启PaaS开源时代 #

PaaS的核心是平台。最早出现在开发者视野中的PaaS开源项目中，vmware创立的Cloud Foundry是知名度最高的。与IaaS提供云上虚拟机的服务方式不同，基于Cloud Foundry的云计算能够提供应用托管的功能。开发者只需要通过一条简单的命令比如：cf push “我的应用”，就可以将项目打成一个压缩包，上传到Cloud Foundry服务器。而Cloud foundry会开启自己的调度器，在一群云主机中找到满足用户需求的主机（系统版本、性能、个数），然后通过容器化技术，在主机上创建一个容器，在容器中下载压缩包，解压并运行，最终成为一个对外提供服务的应用。

此外，Cloud Foundry平台对这些应用项目提供分发，灾备，监控，重启等等服务（这也是我们提供给用户的核心服务）。这种托管服务解放了开发者的生产力，让他们不用再关心应用的运维状况，而是专心开发自己的应用。而这就是PaaS的“初心”，平台即服务。

![5.png][]  
（Cloud Foundry提供的服务）

这里就会有同学问了，容器是什么？容器是用来解决多个应用资源冲突与隔离性问题的技术。Linux上的namespace机制和cgroups命令都能用做资源隔离和限制，这些都是容器技术。

容器技术并不是Docker创建的，在Docker兴起之前，就已经被其他公司商用了，但是为什么现在一谈起容器，所有人第一时间想到的就是Docker呢？这就要提到Cloud Foundry的死亡。

# 从Cloud Foundry到Docker #

Cloud Foundry似乎已经和我们现在使用的云功能区别不大，但2021年的现实情况却是Cloud Foundry已经死了。

我们看过互联网上很多文章，再结合我们活字格公有云开发的经验，我们认为这个项目的致命缺陷集中它的打包机制上。

Cloud Foundry最核心的组件就是应用的打包和分发机制，也是开发者打交道最多的功能。Cloud Foundry为每一种主流的语言都定义了一套打包的方式，这些方式之间毫无章法。但就是这个打包功能，成了Cloud Foundry的软肋，一直为用户所诟病。开发者不得不为每一种语言，每一种框架，甚至是每个版本应用维护一个打好的包，还有可能出现本机运行成功，打了个包上传上去之后就无法运行的情况。情况最严重的时候，开发者在调试云平台系统上花的时间都已经比开发一个新软件的时间要长了。

本来是为赋能开发者的而生的技术，Cloud Foundry却对开发者如此不友好。当开发者的抱怨积累到一定程度，想要在PaaS浪潮中央站稳脚跟的Cloud Foundry被后起之秀Docker“红牌罚出局”也就顺理成章了。

最初，Docker是一个当时还叫dotCloud的公司（2010年由所罗门海克斯创建，Y Combinator孵化）开发的容器项目。在Cloud Foundry困于打包问题时，Docker正在悄悄积蓄力量，在开源后的短短几个月内就迅速崛起，成为一个不容忽视的PaaS技术方案，吸引了云服务开发者的眼球。

滑稽的是，在Docker刚开源的时候，Cloud Foundry的首席产品经理 James Bayer就在社区做了一次详细的对比，告诉用户Docker和Cloud Foundry一样，都是使用了Namespace和Cgroups技术的沙箱而已，没什么值得关注的。

事实上，Docker也确实就和他所说的一样，采用了这个“传统”的技术方案，但是Docker与Cloud Foundry相比，做了一点小小的创新，体现了所罗门海克斯的远见。从2010他就开始考虑应用打包的一致性与复用性问题，并提出了创新的解决方案，最终对Cloud Foundry造成了毁灭性的打击。这个解决方案就是Docker镜像。

![4.jpg][]

（Docker，图片来自官网）

刚开源的Docker迅速爆火，憨态可掬的小鲸鱼，对用户友好的文档，三分钟部署一个Nginx集群的宣传语，以及Docker Image这个 “微不足道的创新”，让Docker席卷整个PaaS领域。

# Docker的制胜法宝：镜像 #

Docker成功的关键，在于Docker镜像几乎完美地解决了Cloud Foundry在打包方面的软肋。

所谓的镜像，其实也是一个压缩包，但是比起Cloud Foundry那种执行文件+启动脚本的打包结果，镜像提供给用户的是一套完整的运行环境，每一个镜像都可以指定操作系统版本，内部可以构建程序执行的文件结构，并且一份镜像可以完全共享在多处使用。

![6.png][]

此外，Docker还给开发者提供了一套完善的镜像制作流程，这套流程与编程语言和框架无关。开发者只需要按照该流程，定制对应程序所需要的运行的操作系统环境即可。

总之，Docker 镜像完美解决了两个问题：

1.本地环境和服务器环境的差异  
2.同一份镜像可以让所有的机器进行复用

从这一刻开始，PaaS的市场已经完全是Docker的天下。

# 小结 #

本文是系列文章的第一期，我们一起回顾了IaaS取代物理服务器，基于IaaS构建PaaS的发展路线。在构建PaaS时，我们经历了Cloud Foundry的衰败，见证了Docker的成功。

但是，只依靠Docker就能构建起完整的PaaS服务吗？我们的[活字格][Link 1]公有云版最终选择了哪个技术方案？云计算的故事还没有讲完，敬请期待下期精彩内容。

[2.png]: /images/20221005/4656e30b875540929008ecf8e25d86e0.png
[1.png]: /images/20221005/c20c02afbc0a4f45a06f0603740cd908.png
[5.png]: /images/20221005/5ae055e7373942bda10809f7244fb068.png
[4.jpg]: /images/20221005/3c9af569812443549f0d6f1b7c90250e.png
[6.png]: /images/20221005/1676aceb54b44066837d256f648ddacd.png
[Link 1]: https://www.grapecity.com.cn/solutions/huozige