第1章

容器的发展史

要完全了解容器及Kubernetes，了解它真正解决什么问题，有必要花一定篇幅介绍容器的发展史。容器技术的发展离不开开发过程、应用架构的演变，它们是相辅相成的，在一定程度上说是缺一不可的。

本章会从3个方面来介绍容器的发展史，分别是开发过程的发展、应用架构的发展、部署/打包的发展，介绍容器所扮演的角色，以及它的历史定位，帮助读者真正理解容器的发展史。

1.1 开发过程的发展

开发过程大致经历了3个阶段——瀑布式开发、敏捷式开发和DevOps（在每个阶段发布产品的周期及反馈循环的快慢各不相同）。本节会结合容器技术介绍开发过程的发展。

1.1.1 瀑布式开发

瀑布模型是一种广泛采用的项目开发过程。瀑布模型由各个阶段组成，从上一个阶段流向下一个阶段，各个阶段都会产生反馈，从系统需求分析阶段开始，然后一直流向产品发布和维护阶段。其核心思想在于，按照一定的工序让问题变得有迹可循，将软件开发过程划分为需求分析、需求定义、概要设计、详细设计、编码、系统测试、验收测试、维护这8个阶段。各个阶段自上而下，互相衔接，就像是瀑布流水一样（见图1-1）。

图1-1 瀑布式开发

瀑布式开发的缺点是显而易见的。

（1）由于阶段的划分比较独立，因此各个阶段的衔接会存在脱节情况，即上一个阶段的成果未必适合下一个阶段。

（2）计划非常死板。任何一个环节出现延误，都会像滚雪球一般影响后续阶段。瀑布式开发通过强制的完成日期来跟踪各个项目阶段，毫无弹性。

（3）交付周期太长，过程风险难以控制且不能及时响应变化。

（4）反馈回路太长，几乎到最后阶段才能发现瀑布式开发是否适用。

容器技术在这一代开发过程中没有发挥太大作用，即使使用，也局限于最后一两个阶段。有容器固然很好，但由于瀑布模型的先天劣势，容器对它帮助不大，收效甚微。

1.1.2 敏捷式开发

敏捷式开发是一种以用户需求为核心，通过迭代、循序渐进完成软件开发的方法。它的核心在于，整个项目被拆分为多个拥有联系但相对独立的子项目。这些子项目通常在一个迭代周期（通常为2～4周）发布一次，而每次迭代都经历了完备的开发流程，并通过了各项测试，因此这些子项目可以作为单独的产品使用。

这种方法也非常适合一开始没有或不能完整确定需求和范围的项目，或者经常变化的项目。相对于瀑布式开发，敏捷式开发明显更具有弹性，对风险更可控。敏捷式开发的交付周期适中，反馈回路相对较短，可执行原型和部分实现的可运行系统是了解用户需求与反馈的有效媒介。每次迭代完成后，都可以基于用户反馈或总结，持续优化下一次迭代（见图1-2）。

图1-2 敏捷式开发

敏捷式开发的交付周期适中，反馈回路适中，很多开发团队会使用持续集成时间贯穿整个过程。容器技术开始在这一开发过程中显示出一定的作用。有效利用它会带来可见的良性改观，但容器技术并未起决定性作用。

1.1.3 DevOps

很多人在讨论DevOps的时候，会把Kubernetes等同于DevOps，其实他们并未理解DevOps的精髓。简单地将DevOps理解为自动化部署，其实是很不科学的。

DevOps一词来自Development和Operation的组合，突出了软件开发人员和运维人员的沟通合作，通过自动化流程来使软件构建、测试与发布更加快捷、频繁和可靠。然而，这只是文字上的定义。

前两节已经介绍过瀑布式开发和敏捷式开发，请注意这些过程的关键点。开发过程的发展趋势如下。

（1）越来越快速、越来越频繁的交付，交付周期越来越短。

（2）更迅捷的反馈回路，反馈周期明显变短。

很多业内人士依然使用瀑布模型，一个月甚至更长时间交付一次，然后再对某些小环节实施自动化，并把它当作DevOps。这种对DevOps的理解并未上升到软件工程的高度，这样的自动化也并非DevOps。