【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年并不流行，而现在却越来越流行的主要原因之一。