mod

极客时间专栏/深入剖析Kubernetes/课前必读/01 | 预习篇 · 小鲸鱼大事记（一）：初出茅庐.md

@@ -0,0 +1,116 @@
+<audio id="audio" title="01 | 预习篇 · 小鲸鱼大事记（一）：初出茅庐" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/23/13/23ceb3cf09d7e6502c2cf6dd8bd3e113.mp3"></audio>
+
+你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之初出茅庐。
+
+**如果我问你，现今最热门的服务器端技术是什么？想必你不假思索就能回答上来：当然是容器！可是，如果现在不是2018年而是2013年，你的回答还能这么斩钉截铁么？**
+
+现在就让我们把时间拨回到五年前去看看吧。
+
+2013年的后端技术领域，已经太久没有出现过令人兴奋的东西了。曾经被人们寄予厚望的云计算技术，也已经从当初虚无缥缈的概念蜕变成了实实在在的虚拟机和账单。而相比于如日中天的AWS和盛极一时的OpenStack，以Cloud  Foundry为代表的开源PaaS项目，却成为了当时云计算技术中的一股清流。
+
+这时，Cloud  Foundry项目已经基本度过了最艰难的概念普及和用户教育阶段，吸引了包括百度、京东、华为、IBM等一大批国内外技术厂商，开启了以开源PaaS为核心构建平台层服务能力的变革。如果你有机会问问当时的云计算从业者们，他们十有八九都会告诉你：PaaS的时代就要来了！
+
+这个说法其实一点儿没错，如果不是后来一个叫Docker的开源项目突然冒出来的话。
+
+事实上，当时还名叫dotCloud的Docker公司，也是这股PaaS热潮中的一份子。只不过相比于Heroku、Pivotal、Red  Hat等PaaS弄潮儿们，dotCloud公司实在是太微不足道了，而它的主打产品由于跟主流的Cloud  Foundry社区脱节，长期以来也无人问津。眼看就要被如火如荼的PaaS风潮抛弃，dotCloud公司却做出了这样一个决定：开源自己的容器项目Docker。
+
+显然，这个决定在当时根本没人在乎。
+
+“容器”这个概念从来就不是什么新鲜的东西，也不是Docker公司发明的。即使在当时最热门的PaaS项目Cloud  Foundry中，容器也只是其最底层、最没人关注的那一部分。说到这里，我正好以当时的事实标准Cloud Foundry为例，来解说一下PaaS技术。
+
+**PaaS项目被大家接纳的一个主要原因，就是它提供了一种名叫“应用托管”的能力。** 在当时，虚拟机和云计算已经是比较普遍的技术和服务了，那时主流用户的普遍用法，就是租一批AWS或者OpenStack的虚拟机，然后像以前管理物理服务器那样，用脚本或者手工的方式在这些机器上部署应用。
+
+当然，这个部署过程难免会碰到云端虚拟机和本地环境不一致的问题，所以当时的云计算服务，比的就是谁能更好地模拟本地服务器环境，能带来更好的“上云”体验。而PaaS开源项目的出现，就是当时解决这个问题的一个最佳方案。
+
+举个例子，创建好虚拟机之后，运维人员只需要在这些机器上部署一个Cloud  Foundry项目，然后开发者只要执行一条命令就能把本地的应用部署到云上，这条命令就是：
+
+```
+$ cf push &quot;我的应用&quot;
+
+```
+
+是不是很神奇？
+
+事实上，**像Cloud Foundry这样的PaaS项目，最核心的组件就是一套应用的打包和分发机制。** Cloud  Foundry为每种主流编程语言都定义了一种打包格式，而“cf push”的作用，基本上等同于用户把应用的可执行文件和启动脚本打进一个压缩包内，上传到云上Cloud  Foundry的存储中。接着，Cloud  Foundry会通过调度器选择一个可以运行这个应用的虚拟机，然后通知这个机器上的Agent把应用压缩包下载下来启动。
+
+这时候关键来了，由于需要在一个虚拟机上启动很多个来自不同用户的应用，Cloud  Foundry会调用操作系统的Cgroups和Namespace机制为每一个应用单独创建一个称作“沙盒”的隔离环境，然后在“沙盒”中启动这些应用进程。这样，就实现了把多个用户的应用互不干涉地在虚拟机里批量地、自动地运行起来的目的。
+
+**这，正是PaaS项目最核心的能力。** 而这些Cloud  Foundry用来运行应用的隔离环境，或者说“沙盒”，就是所谓的“容器”。
+
+而Docker项目，实际上跟Cloud  Foundry的容器并没有太大不同，所以在它发布后不久，Cloud  Foundry的首席产品经理James Bayer就在社区里做了一次详细对比，告诉用户Docker实际上只是一个同样使用Cgroups和Namespace实现的“沙盒”而已，没有什么特别的黑科技，也不需要特别关注。
+
+然而，短短几个月，Docker项目就迅速崛起了。它的崛起速度如此之快，以至于Cloud  Foundry以及所有的PaaS社区还没来得及成为它的竞争对手，就直接被宣告出局了。那时候，一位多年的PaaS从业者曾经如此感慨道：这简直就是一场“降维打击”啊。
+
+难道这一次，连闯荡多年的“老江湖”James Bayer也看走眼了么？
+
+并没有。
+
+事实上，Docker项目确实与Cloud  Foundry的容器在大部分功能和实现原理上都是一样的，可偏偏就是这剩下的一小部分不一样的功能，成了Docker项目接下来“呼风唤雨”的不二法宝。
+
+**这个功能，就是Docker镜像。**
+
+恐怕连Docker项目的作者Solomon Hykes自己当时都没想到，这个小小的创新，在短短几年内就如此迅速地改变了整个云计算领域的发展历程。
+
+我前面已经介绍过，PaaS之所以能够帮助用户大规模部署应用到集群里，是因为它提供了一套应用打包的功能。可偏偏就是这个打包功能，却成了PaaS日后不断遭到用户诟病的一个“软肋”。
+
+出现这个问题的根本原因是，一旦用上了PaaS，用户就必须为每种语言、每种框架，甚至每个版本的应用维护一个打好的包。这个打包过程，没有任何章法可循，更麻烦的是，明明在本地运行得好好的应用，却需要做很多修改和配置工作才能在PaaS里运行起来。而这些修改和配置，并没有什么经验可以借鉴，基本上得靠不断试错，直到你摸清楚了本地应用和远端PaaS匹配的“脾气”才能够搞定。
+
+最后结局就是，“cf push”确实是能一键部署了，但是为了实现这个一键部署，用户为每个应用打包的工作可谓一波三折，费尽心机。
+
+而**Docker镜像解决的，恰恰就是打包这个根本性的问题。** 所谓Docker镜像，其实就是一个压缩包。但是这个压缩包里的内容，比PaaS的应用可执行文件+启停脚本的组合就要丰富多了。实际上，大多数Docker镜像是直接由一个完整操作系统的所有文件和目录构成的，所以这个压缩包里的内容跟你本地开发和测试环境用的操作系统是完全一样的。
+
+这就有意思了：假设你的应用在本地运行时，能看见的环境是CentOS 7.2操作系统的所有文件和目录，那么只要用CentOS 7.2的ISO做一个压缩包，再把你的应用可执行文件也压缩进去，那么无论在哪里解压这个压缩包，都可以得到与你本地测试时一样的环境。当然，你的应用也在里面！
+
+这就是Docker镜像最厉害的地方：只要有这个压缩包在手，你就可以使用某种技术创建一个“沙盒”，在“沙盒”中解压这个压缩包，然后就可以运行你的程序了。
+
+更重要的是，这个压缩包包含了完整的操作系统文件和目录，也就是包含了这个应用运行所需要的所有依赖，所以你可以先用这个压缩包在本地进行开发和测试，完成之后，再把这个压缩包上传到云端运行。
+
+在这个过程中，你完全不需要进行任何配置或者修改，因为这个压缩包赋予了你一种极其宝贵的能力：本地环境和云端环境的高度一致！
+
+这，**正是Docker镜像的精髓。**
+
+那么，有了Docker镜像这个利器，PaaS里最核心的打包系统一下子就没了用武之地，最让用户抓狂的打包过程也随之消失了。相比之下，在当今的互联网里，Docker镜像需要的操作系统文件和目录，可谓唾手可得。
+
+所以，你只需要提供一个下载好的操作系统文件与目录，然后使用它制作一个压缩包即可，这个命令就是：
+
+```
+$ docker build &quot;我的镜像&quot;
+
+```
+
+一旦镜像制作完成，用户就可以让Docker创建一个“沙盒”来解压这个镜像，然后在“沙盒”中运行自己的应用，这个命令就是：
+
+```
+$ docker run &quot;我的镜像&quot;
+
+```
+
+当然，docker run创建的“沙盒”，也是使用Cgroups和Namespace机制创建出来的隔离环境。我会在后面的文章中，详细介绍这个机制的实现原理。
+
+所以，**Docker项目给PaaS世界带来的“降维打击”，其实是提供了一种非常便利的打包机制。这种机制直接打包了应用运行所需要的整个操作系统，从而保证了本地环境和云端环境的高度一致，避免了用户通过“试错”来匹配两种不同运行环境之间差异的痛苦过程。**
+
+而对于开发者们来说，在终于体验到了生产力解放所带来的痛快之后，他们自然选择了用脚投票，直接宣告了PaaS时代的结束。
+
+不过，Docker项目固然解决了应用打包的难题，但正如前面所介绍的那样，它并不能代替PaaS完成大规模部署应用的职责。
+
+遗憾的是，考虑到Docker公司是一个与自己有潜在竞争关系的商业实体，再加上对Docker项目普及程度的错误判断，Cloud  Foundry项目并没有第一时间使用Docker作为自己的核心依赖，去替换自己那套饱受诟病的打包流程。
+
+反倒是一些机敏的创业公司，纷纷在第一时间推出了Docker容器集群管理的开源项目（比如Deis和Flynn），它们一般称自己为CaaS，即Container-as-a-Service，用来跟“过时”的PaaS们划清界限。
+
+而在2014年底的DockerCon上，Docker公司雄心勃勃地对外发布了自家研发的“Docker原生”容器集群管理项目Swarm，不仅将这波“CaaS”热推向了一个前所未有的高潮，更是寄托了整个Docker公司重新定义PaaS的宏伟愿望。
+
+在2014年的这段巅峰岁月里，Docker公司离自己的理想真的只有一步之遥。
+
+## 总结
+
+2013~2014年，以Cloud  Foundry为代表的PaaS项目，逐渐完成了教育用户和开拓市场的艰巨任务，也正是在这个将概念逐渐落地的过程中，应用“打包”困难这个问题，成了整个后端技术圈子的一块心病。
+
+Docker项目的出现，则为这个根本性的问题提供了一个近乎完美的解决方案。这正是Docker项目刚刚开源不久，就能够带领一家原本默默无闻的PaaS创业公司脱颖而出，然后迅速占领了所有云计算领域头条的技术原因。
+
+而在成为了基础设施领域近十年难得一见的技术明星之后，dotCloud公司则在2013年底大胆改名为Docker公司。不过，这个在当时就颇具争议的改名举动，也成为了日后容器技术圈风云变幻的一个关键伏笔。
+
+## 思考题
+
+你是否曾经研发过类似PaaS的项目？你碰到过应用打包的问题吗，又是如何解决的呢？
+
+感谢收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

极客时间专栏/深入剖析Kubernetes/课前必读/02 | 预习篇 · 小鲸鱼大事记（二）：崭露头角.md

@@ -0,0 +1,76 @@
+<audio id="audio" title="02 | 预习篇 · 小鲸鱼大事记（二）：崭露头角" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/d1/e8/d102980921aaf598e72438a74dadffe8.mp3"></audio>
+
+你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之崭露头角。
+
+在上一篇文章中，我说到，伴随着PaaS概念的逐步普及，以Cloud Foundry为代表的经典PaaS项目，开始进入基础设施领域的视野，平台化和PaaS化成了这个生态中的一个最为重要的进化趋势。
+
+就在对开源PaaS项目落地的不断尝试中，这个领域的从业者们发现了PaaS中最为棘手也最亟待解决的一个问题：究竟如何给应用打包？
+
+遗憾的是，无论是Cloud Foundry、OpenShift，还是Clodify，面对这个问题都没能给出一个完美的答案，反而在竞争中走向了碎片化的歧途。
+
+而就在这时，一个并不引人瞩目的PaaS创业公司dotCloud，却选择了开源自家的一个容器项目Docker。更出人意料的是，**就是这样一个普通到不能再普通的技术，却开启了一个名为“Docker”的全新时代。**
+
+你可能会有疑问，Docker项目的崛起，是不是偶然呢？
+
+事实上，**这个以“鲸鱼”为注册商标的技术创业公司，最重要的战略之一就是：坚持把“开发者”群体放在至高无上的位置。**
+
+相比于其他正在企业级市场里厮杀得头破血流的经典PaaS项目们，Docker项目的推广策略从一开始就呈现出一副“憨态可掬”的亲人姿态，把每一位后端技术人员（而不是他们的老板）作为主要的传播对象。
+
+简洁的UI，有趣的demo，“1分钟部署一个WordPress网站”“3分钟部署一个Nginx集群”，这种同开发者之间与生俱来的亲近关系，使Docker项目迅速成为了全世界Meetup上最受欢迎的一颗新星。
+
+在过去的很长一段时间里，相较于前端和互联网技术社区，服务器端技术社区一直是一个相对沉闷而小众的圈子。在这里，从事Linux内核开发的极客们自带“不合群”的“光环”，后端开发者们啃着多年不变的TCP/IP发着牢骚，运维更是天生注定的幕后英雄。
+
+而Docker项目，却给后端开发者提供了走向聚光灯的机会。就比如Cgroups和Namespace这种已经存在多年却很少被人们关心的特性，在2014年和2015年竟然频繁入选各大技术会议的分享议题，就因为听众们想要知道Docker这个东西到底是怎么一回事儿。
+
+**而Docker项目之所以能取得如此高的关注，一方面正如前面我所说的那样，它解决了应用打包和发布这一困扰运维人员多年的技术难题；而另一方面，就是因为它第一次把一个纯后端的技术概念，通过非常友好的设计和封装，交到了最广大的开发者群体手里。**
+
+在这种独特的氛围烘托下，你不需要精通TCP/IP，也无需深谙Linux内核原理，哪怕只是一个前端或者网站的PHP工程师，都会对如何把自己的代码打包成一个随处可以运行的Docker镜像充满好奇和兴趣。
+
+这种受众群体的变革，正是Docker这样一个后端开源项目取得巨大成功的关键。这也是经典PaaS项目想做却没有做好的一件事情：PaaS的最终用户和受益者，一定是为这个PaaS编写应用的开发者们，而在Docker项目开源之前，PaaS与开发者之间的关系却从未如此紧密过。
+
+**解决了应用打包这个根本性的问题，同开发者与生俱来的的亲密关系，再加上PaaS概念已经深入人心的完美契机，成为Docker这个技术上看似平淡无奇的项目一举走红的重要原因。**
+
+一时之间，“容器化”取代“PaaS化”成为了基础设施领域最炙手可热的关键词，一个以“容器”为中心的、全新的云计算市场，正呼之欲出。而作为这个生态的一手缔造者，此时的dotCloud公司突然宣布将公司名称改为“Docker”。
+
+这个举动，在当时颇受质疑。在大家印象中，Docker只是一个开源项目的名字。可是现在，这个单词却成了Docker公司的注册商标，任何人在商业活动中使用这个单词，以及鲸鱼的Logo，都会立刻受到法律警告。
+
+那么，Docker公司这个举动到底卖的什么药？这个问题，我不妨后面再做解读，因为相较于这件“小事儿”，Docker公司在2014年发布Swarm项目才是真正的“大事儿”。
+
+那么，Docker公司为什么一定要发布Swarm项目呢？
+
+通过我对Docker项目崛起背后原因的分析，你应该能发现这样一个有意思的事实：虽然通过“容器”这个概念完成了对经典PaaS项目的“降维打击”，但是Docker项目和Docker公司，兜兜转转了一年多，却还是回到了PaaS项目原本深耕了多年的那个战场：**如何让开发者把应用部署在我的项目上。**
+
+没错，Docker项目从发布之初就全面发力，从技术、社区、商业、市场全方位争取到的开发者群体，实际上是为此后吸引整个生态到自家“PaaS”上的一个铺垫。**只不过这时，“PaaS”的定义已经全然不是Cloud Foundry描述的那个样子，而是变成了一套以Docker容器为技术核心，以Docker镜像为打包标准的、全新的“容器化”思路。**
+
+**这，正是Docker项目从一开始悉心运作“容器化”理念和经营整个Docker生态的主要目的。**
+
+而Swarm项目，正是接下来承接Docker公司所有这些努力的关键所在。
+
+## 总结
+
+今天，我着重介绍了Docker项目在短时间内迅速崛起的三个重要原因：
+
+<li>
+Docker镜像通过技术手段解决了PaaS的根本性问题；
+</li>
+<li>
+Docker容器同开发者之间有着与生俱来的密切关系；
+</li>
+<li>
+PaaS概念已经深入人心的完美契机。
+</li>
+
+崭露头角的Docker公司，也终于能够以一个更加强硬的姿态来面对这个曾经无比强势，但现在却完全不知所措的云计算市场。而2014年底的DockerCon欧洲峰会，则正式拉开了Docker公司扩张的序幕。
+
+## 思考题
+
+<li>
+你是否认同dotCloud公司改名并开启扩张道路的战略选择？
+</li>
+<li>
+Docker公司凭借“开源”和“开发者社群”这两个关键词完成崛起的过程，对你和你所在的团队有什么启发？
+</li>
+
+感谢收听，欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。
+
+

极客时间专栏/深入剖析Kubernetes/课前必读/03 | 预习篇 · 小鲸鱼大事记（三）：群雄并起.md

@@ -0,0 +1,106 @@
+<audio id="audio" title="03 | 预习篇 · 小鲸鱼大事记（三）：群雄并起" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/7e/b5/7e53320dcff4ab363fb8da59964d3fb5.mp3"></audio>
+
+你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之群雄并起。
+
+在上一篇文章中，我剖析了Docker项目迅速走红背后的技术与非技术原因，也介绍了Docker公司开启平台化战略的野心。可是，Docker公司为什么在Docker项目已经取得巨大成功之后，却执意要重新走回那条已经让无数先驱们尘沙折戟的PaaS之路呢？
+
+实际上，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公司在2014年就已经定好了平台化的发展方向，并且绝对不会跟CoreOS在平台层面开展任何合作。这样看来，Docker公司在2014年12月的DockerCon上发布Swarm的举动，也就一点都不突然了。
+
+相较于CoreOS是依托于一系列开源项目（比如Container Linux操作系统、Fleet作业调度工具、systemd进程管理和rkt容器），一层层搭建起来的平台产品，Swarm项目则是以一个完整的整体来对外提供集群管理功能。而Swarm的最大亮点，则是它完全使用Docker项目原本的容器管理API来完成集群管理，比如：
+
+- 单机Docker项目：
+
+```
+$ docker run &quot;我的容器
+
+```
+
+- 多机Docker项目：
+
+```
+$ docker run -H &quot;我的Swarm集群API地址&quot; &quot;我的容器&quot;
+
+```
+
+所以在部署了Swarm的多机环境下，用户只需要使用原先的Docker指令创建一个容器，这个请求就会被Swarm拦截下来处理，然后通过具体的调度算法找到一个合适的Docker Daemon运行起来。
+
+这个操作方式简洁明了，对于已经了解过Docker命令行的开发者们也很容易掌握。所以，这样一个“原生”的Docker容器集群管理项目一经发布，就受到了已有Docker用户群的热捧。而相比之下，CoreOS的解决方案就显得非常另类，更不用说用户还要去接受完全让人摸不着头脑、新造的容器项目rkt了。
+
+当然，Swarm项目只是Docker公司重新定义“PaaS”的关键一环而已。在2014年到2015年这段时间里，Docker项目的迅速走红催生出了一个非常繁荣的“Docker生态”。在这个生态里，围绕着Docker在各个层次进行集成和创新的项目层出不穷。
+
+而此时已经大红大紫到“不差钱”的**Docker公司，开始及时地借助这波浪潮通过并购来完善自己的平台层能力**。其中一个最成功的案例，莫过于对Fig项目的收购。
+
+要知道，Fig项目基本上只是靠两个人全职开发和维护的，可它却是当时GitHub上热度堪比Docker项目的明星。
+
+**Fig项目之所以受欢迎，在于它在开发者面前第一次提出了“容器编排”（Container Orchestration）的概念。**
+
+其实，“编排”（Orchestration）在云计算行业里不算是新词汇，它主要是指用户如何通过某些工具或者配置来完成一组虚拟机以及关联资源的定义、配置、创建、删除等工作，然后由云计算平台按照这些指定的逻辑来完成的过程。
+
+而容器时代，“编排”显然就是对Docker容器的一系列定义、配置和创建动作的管理。而Fig的工作实际上非常简单：假如现在用户需要部署的是应用容器A、数据库容器B、负载均衡容器C，那么Fig就允许用户把A、B、C三个容器定义在一个配置文件中，并且可以指定它们之间的关联关系，比如容器A需要访问数据库容器B。
+
+接下来，你只需要执行一条非常简单的指令：
+
+```
+$ fig up
+
+```
+
+Fig就会把这些容器的定义和配置交给Docker API按照访问逻辑依次创建，你的一系列容器就都启动了；而容器A与B之间的关联关系，也会交给Docker的Link功能通过写入hosts文件的方式进行配置。更重要的是，你还可以在Fig的配置文件里定义各种容器的副本个数等编排参数，再加上Swarm的集群管理能力，一个活脱脱的PaaS呼之欲出。
+
+Fig项目被收购后改名为Compose，它成了Docker公司到目前为止第二大受欢迎的项目，一直到今天也依然被很多人使用。
+
+当时的这个容器生态里，还有很多令人眼前一亮的开源项目或公司。比如，专门负责处理容器网络的SocketPlane项目（后来被Docker公司收购），专门负责处理容器存储的Flocker项目（后来被EMC公司收购），专门给Docker集群做图形化管理界面和对外提供云服务的Tutum项目（后来被Docker公司收购）等等。
+
+一时之间，整个后端和云计算领域的聪明才俊都汇集在了这个“小鲸鱼”的周围，为Docker生态的蓬勃发展献上了自己的智慧。
+
+而除了这个异常繁荣的、围绕着Docker项目和公司的生态之外，还有一个势力在当时也是风头无两，这就是老牌集群管理项目Mesos和它背后的创业公司Mesosphere。
+
+Mesos作为Berkeley主导的大数据套件之一，是大数据火热时最受欢迎的资源管理项目，也是跟Yarn项目杀得难舍难分的实力派选手。
+
+不过，大数据所关注的计算密集型离线业务，其实并不像常规的Web服务那样适合用容器进行托管和扩容，也没有对应用打包的强烈需求，所以Hadoop、Spark等项目到现在也没在容器技术上投下更大的赌注；但是对于Mesos来说，天生的两层调度机制让它非常容易从大数据领域抽身，转而去支持受众更加广泛的PaaS业务。
+
+在这种思路的指导下，Mesosphere公司发布了一个名为Marathon的项目，而这个项目很快就成为了Docker Swarm的一个有力竞争对手。
+
+**虽然不能提供像Swarm那样的原生Docker API，Mesos社区却拥有一个独特的竞争力：超大规模集群的管理经验。**
+
+早在几年前，Mesos就已经通过了万台节点的验证，2014年之后又被广泛使用在eBay等大型互联网公司的生产环境中。而这次通过Marathon实现了诸如应用托管和负载均衡的PaaS功能之后，Mesos+Marathon的组合实际上进化成了一个高度成熟的PaaS项目，同时还能很好地支持大数据业务。
+
+所以，在这波容器化浪潮中，Mesosphere公司不失时机地提出了一个名叫“DC/OS”（数据中心操作系统）的口号和产品，旨在使用户能够像管理一台机器那样管理一个万级别的物理机集群，并且使用Docker容器在这个集群里自由地部署应用。而这，对很多大型企业来说具有着非同寻常的吸引力。
+
+这时，如果你再去审视当时的容器技术生态，就不难发现CoreOS公司竟然显得有些尴尬了。它的rkt容器完全打不开局面，Fleet集群管理项目更是少有人问津，CoreOS完全被Docker公司压制了。
+
+而处境同样不容乐观的似乎还有RedHat，作为Docker项目早期的重要贡献者，RedHat也是因为对Docker公司平台化战略不满而愤愤退出。但此时，它竟只剩下OpenShift这个跟Cloud Foundry同时代的经典PaaS一张牌可以打，跟Docker Swarm和转型后的Mesos完全不在同一个“竞技水平”之上。
+
+那么，事实果真如此吗？
+
+2014年注定是一个神奇的年份。就在这一年的6月，基础设施领域的翘楚Google公司突然发力，正式宣告了一个名叫Kubernetes项目的诞生。而这个项目，不仅挽救了当时的CoreOS和RedHat，还如同当年Docker项目的横空出世一样，再一次改变了整个容器市场的格局。
+
+## 总结
+
+我分享了Docker公司平台化战略的来龙去脉，阐述了Docker Swarm项目发布的意义和它背后的设计思想，介绍了Fig（后来的Compose）项目如何成为了继Docker之后最受瞩目的新星。
+
+同时，我也和你一起回顾了2014~2015年间如火如荼的容器化浪潮里群雄并起的繁荣姿态。在这次生态大爆发中，Docker公司和Mesosphere公司，依托自身优势率先占据了有利位置。
+
+但是，更强大的挑战者们，即将在不久后纷至沓来。
+
+## 思考题
+
+你所在团队有没有在2014~2015年Docker热潮中，推出过相关的容器产品或者项目？现在结局如何呢？
+
+欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。
+
+

极客时间专栏/深入剖析Kubernetes/课前必读/04 | 预习篇 · 小鲸鱼大事记（四）：尘埃落定.md

@@ -0,0 +1,140 @@
+<audio id="audio" title="04 | 预习篇 · 小鲸鱼大事记（四）：尘埃落定" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b8/27/b8927beb8546622cc5caa14767de2a27.mp3"></audio>
+
+你好，我是张磊。我今天分享的主题是：小鲸鱼大事记之尘埃落定。
+
+在上一次的分享中我提到，伴随着Docker公司一手打造出来的容器技术生态在云计算市场中站稳了脚跟，围绕着Docker项目进行的各个层次的集成与创新产品，也如雨后春笋般出现在这个新兴市场当中。而Docker公司，不失时机地发布了Docker Compose、Swarm和Machine“三件套”，在重新定义PaaS的方向上走出了最关键的一步。
+
+这段时间，也正是Docker生态创业公司们的春天，大量围绕着Docker项目的网络、存储、监控、CI/CD，甚至UI项目纷纷出台，也涌现出了很多Rancher、Tutum这样在开源与商业上均取得了巨大成功的创业公司。
+
+在2014~2015年间，整个容器社区可谓热闹非凡。
+
+这令人兴奋的繁荣背后，却浮现出了更多的担忧。这其中最主要的负面情绪，是对Docker公司商业化战略的种种顾虑。
+
+事实上，很多从业者也都看得明白，Docker项目此时已经成为Docker公司一个商业产品。而开源，只是Docker公司吸引开发者群体的一个重要手段。不过这么多年来，开源社区的商业化其实都是类似的思路，无非是高不高调、心不心急的问题罢了。
+
+而真正令大多数人不满意的是，Docker公司在Docker开源项目的发展上，始终保持着绝对的权威和发言权，并在多个场合用实际行动挑战到了其他玩家（比如，CoreOS、RedHat，甚至谷歌和微软）的切身利益。
+
+那么，这个时候，大家的不满也就不再是在GitHub上发发牢骚这么简单了。
+
+相信很多容器领域的老玩家们都听说过，Docker项目刚刚兴起时，Google也开源了一个在内部使用多年、经历过生产环境验证的Linux容器：lmctfy（Let Me Container That For You）。
+
+然而，面对Docker项目的强势崛起，这个对用户没那么友好的Google容器项目根本没有招架之力。所以，知难而退的Google公司，向Docker公司表示了合作的愿望：关停这个项目，和Docker公司共同推进一个中立的容器运行时（container runtime）库作为Docker项目的核心依赖。
+
+不过，Docker公司并没有认同这个明显会削弱自己地位的提议，还在不久后，自己发布了一个容器运行时库Libcontainer。这次匆忙的、由一家主导的、并带有战略性考量的重构，成了Libcontainer被社区长期诟病代码可读性差、可维护性不强的一个重要原因。
+
+至此，Docker公司在容器运行时层面上的强硬态度，以及Docker项目在高速迭代中表现出来的不稳定和频繁变更的问题，开始让社区叫苦不迭。
+
+这种情绪在2015年达到了一个小高潮，容器领域的其他几位玩家开始商议“切割”Docker项目的话语权。而“切割”的手段也非常经典，那就是成立一个中立的基金会。
+
+于是，2015年6月22日，由Docker公司牵头，CoreOS、Google、RedHat等公司共同宣布，Docker公司将Libcontainer捐出，并改名为RunC项目，交由一个完全中立的基金会管理，然后以RunC为依据，大家共同制定一套容器和镜像的标准和规范。
+
+这套标准和规范，就是OCI（ Open Container Initiative ）。**OCI的提出，意在将容器运行时和镜像的实现从Docker项目中完全剥离出来**。这样做，一方面可以改善Docker公司在容器技术上一家独大的现状，另一方面也为其他玩家不依赖于Docker项目构建各自的平台层能力提供了可能。
+
+不过，不难看出，OCI的成立更多的是这些容器玩家出于自身利益进行干涉的一个妥协结果。所以，尽管Docker是OCI的发起者和创始成员，它却很少在OCI的技术推进和标准制定等事务上扮演关键角色，也没有动力去积极地推进这些所谓的标准。
+
+这，也正是迄今为止OCI组织效率持续低下的根本原因。
+
+眼看着OCI并没能改变Docker公司在容器领域一家独大的现状，Google和RedHat等公司于是把与第二把武器摆上了台面。
+
+Docker之所以不担心OCI的威胁，原因就在于它的Docker项目是容器生态的事实标准，而它所维护的Docker社区也足够庞大。可是，一旦这场斗争被转移到容器之上的平台层，或者说PaaS层，Docker公司的竞争优势便立刻捉襟见肘了。
+
+在这个领域里，像Google和RedHat这样的成熟公司，都拥有着深厚的技术积累；而像CoreOS这样的创业公司，也拥有像Etcd这样被广泛使用的开源基础设施项目。
+
+可是Docker公司呢？它却只有一个Swarm。
+
+所以这次，Google、RedHat等开源基础设施领域玩家们，共同牵头发起了一个名为CNCF（Cloud Native Computing Foundation）的基金会。这个基金会的目的其实很容易理解：它希望，以Kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的、按照独立基金会方式运营的平台级社区，来对抗以Docker公司为核心的容器商业生态。
+
+而为了打造出这样一条围绕Kubernetes项目的“护城河”，CNCF社区就需要至少确保两件事情：
+
+<li>
+Kubernetes项目必须能够在容器编排领域取得足够大的竞争优势；
+</li>
+<li>
+CNCF社区必须以Kubernetes项目为核心，覆盖足够多的场景。
+</li>
+
+**我们先来看看CNCF社区如何解决Kubernetes项目在编排领域的竞争力的问题。**
+
+在容器编排领域，Kubernetes项目需要面对来自Docker公司和Mesos社区两个方向的压力。不难看出，Swarm和Mesos实际上分别从两个不同的方向讲出了自己最擅长的故事：Swarm擅长的是跟Docker生态的无缝集成，而Mesos擅长的则是大规模集群的调度与管理。
+
+这两个方向，也是大多数人做容器集群管理项目时最容易想到的两个出发点。也正因为如此，Kubernetes项目如果继续在这两个方向上做文章恐怕就不太明智了。
+
+所以这一次，Kubernetes选择的应对方式是：Borg。
+
+如果你看过Kubernetes项目早期的GitHub Issue和Feature的话，就会发现它们大多来自于Borg和Omega系统的内部特性，这些特性落到Kubernetes项目上，就是Pod、Sidecar等功能和设计模式。
+
+这就解释了，为什么Kubernetes发布后，很多人“抱怨”其设计思想过于“超前”的原因：Kubernetes项目的基础特性，并不是几个工程师突然“拍脑袋”想出来的东西，而是Google公司在容器化基础设施领域多年来实践经验的沉淀与升华。这，正是Kubernetes项目能够从一开始就避免同Swarm和Mesos社区同质化的重要手段。
+
+于是，CNCF接下来的任务就是，如何把这些先进的思想通过技术手段在开源社区落地，并培育出一个认同这些理念的生态？这时，RedHat就发挥了重要作用。
+
+当时，Kubernetes团队规模很小，能够投入的工程能力也十分紧张，而这恰恰是RedHat的长处。更难得的是，RedHat是世界上为数不多的、能真正理解开源社区运作和项目研发真谛的合作伙伴。
+
+所以，RedHat与Google联盟的成立，不仅保证了RedHat在Kubernetes项目上的影响力，也正式开启了容器编排领域“三国鼎立”的局面。
+
+这时，我们再重新审视容器生态的格局，就不难发现Kubernetes项目、Docker公司和Mesos社区这三大玩家的关系已经发生了微妙的变化。
+
+其中，Mesos社区与容器技术的关系，更像是“借势”，而不是这个领域真正的参与者和领导者。这个事实，加上它所属的Apache社区固有的封闭性，导致了Mesos社区虽然技术最为成熟，却在容器编排领域鲜有创新。
+
+这也是为何，Google公司很快就把注意力转向了动作更加激进的Docker公司。
+
+有意思的是，Docker公司对Mesos社区也是类似的看法。所以从一开始，Docker公司就把应对Kubernetes项目的竞争摆在了首要位置：一方面，不断强调“Docker Native”的“重要性”，另一方面，与Kubernetes项目在多个场合进行了直接的碰撞。
+
+不过，这次竞争的发展态势，很快就超过了Docker公司的预期。
+
+Kubernetes项目并没有跟Swarm项目展开同质化的竞争，所以“Docker Native”的说辞并没有太大的杀伤力。相反地，Kubernetes项目让人耳目一新的设计理念和号召力，很快就构建出了一个与众不同的容器编排与管理的生态。
+
+就这样，Kubernetes项目在GitHub上的各项指标开始一骑绝尘，将Swarm项目远远地甩在了身后。
+
+**有了这个基础，CNCF社区就可以放心地解决第二个问题了。**
+
+在已经囊括了容器监控事实标准的Prometheus项目之后，CNCF社区迅速在成员项目中添加了Fluentd、OpenTracing、CNI等一系列容器生态的知名工具和项目。
+
+而在看到了CNCF社区对用户表现出来的巨大吸引力之后，大量的公司和创业团队也开始专门针对CNCF社区而非Docker公司制定推广策略。
+
+面对这样的竞争态势，Docker公司决定更进一步。在2016年，Docker公司宣布了一个震惊所有人的计划：放弃现有的Swarm项目，将容器编排和集群管理功能全部内置到Docker项目当中。
+
+显然，Docker公司意识到了Swarm项目目前唯一的竞争优势，就是跟Docker项目的无缝集成。那么，如何让这种优势最大化呢？那就是把Swarm内置到Docker项目当中。
+
+实际上，从工程角度来看，这种做法的风险很大。内置容器编排、集群管理和负载均衡能力，固然可以使得Docker项目的边界直接扩大到一个完整的PaaS项目的范畴，但这种变更带来的技术复杂度和维护难度，长远来看对Docker项目是不利的。
+
+不过，在当时的大环境下，Docker公司的选择恐怕也带有一丝孤注一掷的意味。
+
+而**Kubernetes的应对策略则是反其道而行之，开始在整个社区推进“民主化”架构**，即：从API到容器运行时的每一层，Kubernetes项目都为开发者暴露出了可以扩展的插件机制，鼓励用户通过代码的方式介入Kubernetes项目的每一个阶段。
+
+Kubernetes项目的这个变革的效果立竿见影，很快在整个容器社区中催生出了大量的、基于Kubernetes API和扩展接口的二次创新工作，比如：
+
+- 目前热度极高的微服务治理项目Istio；
+- 被广泛采用的有状态应用部署框架Operator；
+- 还有像Rook这样的开源创业项目，它通过Kubernetes的可扩展接口，把Ceph这样的重量级产品封装成了简单易用的容器存储插件。
+
+就这样，在这种鼓励二次创新的整体氛围当中，Kubernetes社区在2016年之后得到了空前的发展。更重要的是，不同于之前局限于“打包、发布”这样的PaaS化路线，**这一次容器社区的繁荣，是一次完全以Kubernetes项目为核心的“百家争鸣”**。
+
+面对Kubernetes社区的崛起和壮大，Docker公司也不得不面对自己豪赌失败的现实。但在早前拒绝了微软的天价收购之后，Docker公司实际上已经没有什么回旋余地，只能选择逐步放弃开源社区而专注于自己的商业化转型。
+
+所以，从2017年开始，Docker公司先是将Docker项目的容器运行时部分Containerd捐赠给CNCF社区，标志着Docker项目已经全面升级成为一个PaaS平台；紧接着，Docker公司宣布将Docker项目改名为Moby，然后交给社区自行维护，而Docker公司的商业产品将占有Docker这个注册商标。
+
+Docker公司这些举措背后的含义非常明确：它将全面放弃在开源社区同Kubernetes生态的竞争，转而专注于自己的商业业务，并且通过将Docker项目改名为Moby的举动，将原本属于Docker社区的用户转化成了自己的客户。
+
+2017年10月，Docker公司出人意料地宣布，将在自己的主打产品Docker企业版中内置Kubernetes项目，这标志着持续了近两年之久的“编排之争”至此落下帷幕。
+
+2018年1月30日，RedHat宣布斥资2.5亿美元收购CoreOS。
+
+2018年3月28日，这一切纷争的始作俑者，Docker公司的CTO Solomon Hykes宣布辞职，曾经纷纷扰扰的容器技术圈子，到此尘埃落定。
+
+## 总结
+
+容器技术圈子在短短几年里发生了很多变数，但很多事情其实也都在情理之中。就像Docker这样一家创业公司，在通过开源社区的运作取得了巨大的成功之后，就不得不面对来自整个云计算产业的竞争和围剿。而这个产业的垄断特性，对于Docker这样的技术型创业公司其实天生就不友好。
+
+在这种局势下，接受微软的天价收购，在大多数人看来都是一个非常明智和实际的选择。可是Solomon Hykes却多少带有一些理想主义的影子，既然不甘于“寄人篱下”，那他就必须带领Docker公司去对抗来自整个云计算产业的压力。
+
+只不过，Docker公司最后选择的对抗方式，是将开源项目与商业产品紧密绑定，打造了一个极端封闭的技术生态。而这，其实违背了Docker项目与开发者保持亲密关系的初衷。相比之下，Kubernetes社区，正是以一种更加温和的方式，承接了Docker项目的未尽事业，即：以开发者为核心，构建一个相对民主和开放的容器生态。
+
+这也是为何，Kubernetes项目的成功其实是必然的。
+
+现在，我们很难想象如果Docker公司最初选择了跟Kubernetes社区合作，如今的容器生态又将会是怎样的一番景象。不过我们可以肯定的是，Docker公司在过去五年里的风云变幻，以及Solomon Hykes本人的传奇经历，都已经在云计算的长河中留下了浓墨重彩的一笔。
+
+## 思考题
+
+你如何评价Solomon Hykes在Docker公司发展历程中的所作所为？你又是否看好Docker公司在今后的发展呢？
+
+欢迎你给我留言，也欢迎分享给更多的朋友一起阅读。

极客时间专栏/深入剖析Kubernetes/课前必读/开篇词 | 打通“容器技术”的任督二脉.md

@@ -0,0 +1,81 @@
+<audio id="audio" title="开篇词 | 打通“容器技术”的任督二脉" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fd/da/fde5b177af8b243cbd34413535e72cda.mp3"></audio>
+
+你好，我是张磊，Kubernetes社区的一位资深成员和项目维护者。
+
+2012年，我还在浙大读书的时候，就有幸组建了一个云计算与PaaS基础设施相关的科研团队，就这样，我从早期的Cloud Foundry社区开始，正式与容器结缘。
+
+这几年里，我大多数时间都在Kubernetes项目里从事上游技术工作，也得以作为一名从业者和社区成员的身份，参与和亲历了容器技术从“初出茅庐”到“尘埃落定”的全过程。
+
+而即使从2013年Docker项目发布开始算起，这次变革也不过短短5年时间，可在现如今的技术圈儿里，不懂容器，没听过Kubernetes，你还真不好意思跟人打招呼。
+
+容器技术这样一个新生事物，完全重塑了整个云计算市场的形态。它不仅催生出了一批年轻有为的容器技术人，更培育出了一个具有相当规模的开源基础设施技术市场。
+
+在这个市场里，不仅有Google、Microsoft等技术巨擘们厮杀至今，更有无数的国内外创业公司前仆后继。而在国内，甚至连以前对开源基础设施领域涉足不多的BAT、蚂蚁、滴滴这样的巨头们，也都从AI、云计算、微服务、基础设施等维度多管齐下，争相把容器和Kubernetes项目树立为战略重心之一。
+
+**就在这场因“容器”而起的技术变革中，Kubernetes项目已然成为容器技术的事实标准，重新定义了基础设施领域对应用编排与管理的种种可能。**
+
+2014年后，我开始以远程的方式，全职在Kubernetes和Kata Containers社区从事上游开发工作，先后发起了容器镜像亲密性调度、基于等价类的调度优化等多个核心特性，参与了容器运行时接口、安全容器沙盒等多个基础特性的设计和研发。还有幸作为主要的研发人员和维护者之一，亲历了Serverless Container概念的诞生与崛起。
+
+在2015年，我发起和组织撰写了《Docker容器与容器云》一书，希望帮助更多的人利用容器解决实际场景中的问题。时至今日，这本书的第2版也已经出版快2年了，受到了广大容器技术读者们的好评。
+
+2018年，我又赴西雅图，在微软研究院（MSR）云计算与存储研究组，专门从事基于Kubernetes的深度学习基础设施相关的研究工作。
+
+我与容器打交道的这些年，一直在与关注容器生态的工程师们交流，并经常探讨容器在落地过程中遇到的问题。从这些交流中，我发现总有很多相似的问题被反复提及，比如：
+
+<li>
+为什么容器里只能跑“一个进程”？
+</li>
+<li>
+为什么我原先一直在用的某个JVM参数，在容器里就不好使了？
+</li>
+<li>
+为什么Kubernetes就不能固定IP地址？容器网络连不通又该如何去Debug？
+</li>
+<li>
+Kubernetes中StatefulSet和Operator到底什么区别？PV和PVC这些概念又该怎么用？
+</li>
+
+这些问题乍一看与我们平常的认知非常矛盾，但它们的答案和原理却并不复杂。不过很遗憾，对于刚刚开始学习容器的技术人员来说，它们却很难用一两句话就能解释清楚。
+
+究其原因在于，**从过去以物理机和虚拟机为主体的开发运维环境，向以容器为核心的基础设施的转变过程，并不是一次温和的改革，而是涵盖了对网络、存储、调度、操作系统、分布式原理等各个方面的容器化理解和改造。**
+
+这就导致了很多初学者，对于容器技术栈表现出来的这些难题，要么知识储备不足，要么杂乱无章、无法形成体系。这，也是很多初次参与PaaS项目的从业者们共同面临的一个困境。
+
+其实，容器技术体系看似纷乱繁杂，却存在着很多可以“牵一发而动全身”的主线。比如，Linux的进程模型对于容器本身的重要意义；或者，“控制器”模式对整个Kubernetes项目提纲挈领的作用。
+
+但是，这些关于Linux内核、分布式系统、网络、存储等方方面面的积累，并不会在Docker或者Kubernetes的文档中交代清楚。可偏偏就是它们，才是真正掌握容器技术体系的精髓所在，是每一位技术从业者需要悉心修炼的“内功”。
+
+**而这，也正是我开设这个专栏的初衷。**
+
+我希望借由这个专栏，给你讲清楚容器背后的这些技术本质与设计思想，并结合着对核心特性的剖析与实践，加深你对容器技术的理解。为此，我把专栏划分成了4大模块：
+
+<li>
+**“白话”容器技术基础：** 我希望用饶有趣味的解说，给你梳理容器技术生态的发展脉络，用最通俗易懂的语言描述容器底层技术的实现方式，让你知其然，也知其所以然。
+</li>
+<li>
+**Kubernetes集群的搭建与实践：** Kubernetes集群号称“非常复杂”，但是如果明白了其中的架构和原理，选择了正确的工具和方法，它的搭建却也可以“一键安装”，它的应用部署也可以浅显易懂。
+</li>
+<li>
+**容器编排与Kubernetes核心特性剖析：** 这是这个专栏最重要的内容。“编排”永远都是容器云项目的灵魂所在，也是Kubernetes社区持久生命力的源泉。在这一模块，我会从分布式系统设计的视角出发，抽象和归纳出这些特性中体现出来的普遍方法，然后带着这些指导思想去逐一阐述Kubernetes项目关于编排、调度和作业管理的各项核心特性。“不识庐山真面目，只缘身在此山中”，希望这样一个与众不同的角度，能够给你以全新的启发。
+</li>
+<li>
+**Kubernetes开源社区与生态：**“开源生态”永远都是容器技术和Kubernetes项目成功的关键。在这个模块，我会和你一起探讨，容器社区在开源软件工程指导下的演进之路；带你思考，如何同团队一起平衡内外部需求，让自己逐渐成为社区中不可或缺的一员。
+</li>
+
+我希望通过这些对容器与Kubernetes项目的逐层剖析，能够让你面对容器化浪潮时不再踌躇无措，有一种拨云见日的酣畅淋漓。
+
+最后，我想再和你分享一个故事。
+
+2015年我在InfoQ举办的第一届容器技术大会上，结识了当时CoreOS的布道师Kelsey Hightower，他热情地和大家一起安装和体验微信，谈笑风生间，还时不时地安利一番自家产品。
+
+但两年后也就是2017年，Kelsey已经是全世界容器圈儿的意见领袖，是Google公司Kubernetes项目的首席布道师，而他的座右铭也变为了“只布道，不推销”。此时，就算你漂洋过海想要亲自拜会Kelsey ，恐怕也得先预约下时间了。
+
+诚然，Kelsey 的“一夜成名”，与他的勤奋和天赋密不可分，但他对这次“容器”变革走向的准确把握却也是功不可没。这也正应了一句名言：一个人的命运啊，当然要靠自我奋斗，但是也要考虑到历史的行程。
+
+眼下，你我可能已经错过了互联网技术大爆炸的时代，也没有在数字货币早期的狂热里分到一杯羹。可就在此时此刻，在沉寂了多年的云计算与基础设施领域，一次以“容器”为名的历史变革，正呼之欲出。这一次，我们又有什么理由作壁上观呢？
+
+如果你也想登上“容器”这趟高速前进的列车，我相信这个专栏，可以帮助你打通学习容器技术的“任督二脉”。**在专栏开始，我首先为你准备了4篇预习文章，详细地梳理了容器技术自兴起到现在的发展历程，同时也回答了“Kubernetes为什么会赢”这个重要的问题，算是我额外为你准备的一份开学礼物吧。**
+
+机会总是留给有准备的人，现在就让我们一起开启这次充满挑战的容器之旅！
+
+