【k8s】：DevOps 模式详解

1.什么是DevOps模式？

DevOps 是当下非常火爆的一个概念，受到了很多互联网巨头的推崇。那么什么是 DevOps？它的全称是：集成开发与运维。至于它到底是干什么用的，为什么现在这么火爆，还得从源头说起。

1.1 瀑布模型

一个软件从零开始到最终交付，大概会经历规划、编码、构建、测试、发布、部署、维护等几个阶段：

最初，程序比较简单，工作量也不大，程序员一个人就能完成各阶段的工作。

随着软件行业的不断发展，软件的规模也逐渐庞大，软件的复杂度不断提升，一个人已经无法应付自如，因此开始出现精细化的分工。

程序员的数量扩大，工种增多，除了软件开发工程师，还有软件测试工程师、软件运维工程师等等。

软件开发人员花费数周甚至数月的时间编写代码，然后将代码交给 QA（质量保证）团队进行测试，然后将最终版本交给运营团队进行部署。全部三个阶段：开发、测试、部署。

早期采用的软件交付模型称为“瀑布模型”：

简而言之，瀑布模型意味着等待一个阶段的所有工作完成后再进入下一个阶段。

这种模式适合条件比较理想的项目（用户需求非常明确，开发时间非常充足），大家按照流程，轮流做事，各司其职。

1.2 敏捷开发

但是项目不可能是单向运作的，客户也有需求，产品也有问题，需要改进，随着时间的推移，用户对系统的要求不断提高，而与此同时，用户给出的时间周期却越来越短，在这种情况下，大家发现繁琐、缓慢的瀑布式开发已经不再合适。

因此，软件开发团队引入了一个新概念，即著名的“敏捷开发”。

敏捷开发在 2000 年左右开始受到关注，是一种能够应对快速变化需求的软件开发能力。简单来说就是把大项目变成小项目，把大时间点变成小时间点，然后：

与 DevOps 经常出现的两个词是 CI 和 CD。CI 代表持续集成 (Continuous Integration)，而 CD 则对应多个英文单词，持续交付 (Continuous Delivery) 或持续部署 (Continuous Deployment)。

说是“连续”，其实就是“加速-重复-加速-重复……”，就像这样。画个图大家可能更明白：

敏捷开发大大提高了开发团队的工作效率，版本更新更加快捷。

很多人可能会想：更新速度快的话，风险不是更大吗？

事实上，事实并非如此。

敏捷开发可以帮助更快地发现问题，更快地将产品交付给用户，更快地得到用户的反馈，因此团队可以更快地做出响应。而且 DevOps 小步子、快跑带来的版本变更相对较少，风险也较小（如下图所示），即使出现问题，也会相对容易修复。

1.3 DevOps开发与运营一体化

敏捷开发虽然大大提高了软件开发的效率和版本更新的速度，但是其效果却仅限于开发阶段，研发人员发现运维端依然是一块坚实的阻碍，成为了新的瓶颈。

运维工程师和开发工程师的思维逻辑完全不一样，运维团队的座右铭很简单，就是“稳定压倒一切”，运维最核心的诉求就是避免出现问题。

什么时候最容易出现问题？当发生变化的时候，最容易出现问题。所以运维是非常排斥“变化”的。

于是，两人的矛盾就爆发了：

这时候，DevOps出现了。DevOps这个词，其实是Development和Operations两个词的组合，它的英文发音是/de'vɒps/，类似“迪沃普斯”。

DevOps 是一组流程、方法和系统，旨在促进开发、技术运营和质量保证 (QA) 部门之间的沟通、协作和集成：

从目标上来看，DevOps就是为了让开发人员和运维人员能够更好地沟通和协作，并通过自动化的流程让整体软件流程更加快捷、可靠。

很多人可能觉得，所谓的 DevOps，无非就是 Dev+Ops，只要把两个团队合并起来，或者把运维划归到开发，就可以了，简单粗暴。

注意，这种观点是错误的，这也是近年来DevOps难以落地的主要原因。

想要真正把 DevOps 做到极致，首先要做的就是转变思维方式，或者说“洗脑”。不但运维人员需要洗脑，开发人员也需要洗脑，员工需要洗脑，领导更需要洗脑。

DevOps 不只是组织架构的改变，更是企业文化和思维模式的改变，如果思维模式不能改变，就算员工拼凑在一起，也不会擦出火花。

除了洗脑之外，整个流程的规范和标准都按照DevOps的思维进行重新梳理。

在DevOps流程下，运维人员会在项目开发期间介入开发过程，了解开发人员所使用的系统架构和技术路线，制定合适的运维计划。开发人员也会在运维前期参与系统部署，并为系统部署提供优化建议。

DevOps的推行促进了开发和运维人员之间的沟通，增进了相互的了解。

在转变思维和流程的同时，如果要全面推行DevOps，当然离不开软件和平台的支持。

支持 DevOps 的软件有很多，篇幅有限就不一一介绍了，不过现在 DevOps 这么火也是因为这些软件和平台，你可以趁机卖掉赚钱。

在上述关键因素中，技术（工具与平台）最容易落地，其次是流程，而思维方式的转变最难。

也就是说，DevOps考验的不只是一家公司的技术，更考验公司的管理水平和企业文化。

对比上面提到的瀑布式开发与敏捷开发，我们可以明显的看到，DevOps贯穿了整个软件生命周期，并不局限于开发阶段。

云计算技术近几年发展很快，虚拟化、容器、微服务等概念大家应该都很熟悉，提到这些概念的时候我们偶尔也会提到DevOps。

它们之间有什么联系？

事实上非常简单。

你可以想象一下，如果我们要将一项任务划分成更小的部分，是加工一大块铁更方便，还是把它分割成几块进行加工更方便？

显然拆分之后会更加方便。

所谓“微服务”，就是将原本黑箱化的整体产品从提供多个服务的整体拆分（解耦）成多个提供不同服务的个体。如下图所示：

在微服务架构下，不同的工程师可以处理他们负责的模块，例如开发，测试，部署和迭代。

虚拟化其实是一种敏捷的云计算服务，它从硬件角度把一个系统“划分”成多个系统，使系统之间相互隔离，便于微服务化。

容器则更加彻底，不再划分到不同的操作系统，而是划分到操作系统上的不同“运行环境”（Container），占用资源更少，部署速度更快。

虚拟化和容器其实为DevOps提供了很好的前提条件，开发环境和部署环境可以得到更好的隔离，减少互相的影响。

这也是为什么DevOps在2009年并不流行，而现在却越来越流行的主要原因之一。