作者：叶苇

秋高气爽的这天，老大又找到了埋头写脚本的小伟…

老大：小伟，我们的 CMDB 服务要上线了，你准备一下部署，这周把地址发出来。

小伟：好的老大！保证完成任务！

传统部署篇——刀耕火种的脚本部署

在接到任务后，小伟心想，我都部署过了这么多的项目了，再部署个CMDB也不在话下。心中就画好了部署的蓝图：

接着小伟有条不絮的按照以往套路来 申请机器、改配置文件、复制粘贴脚本，改脚本… 吭吭哧哧的一天过去了，CMDB服务也部署起来了，地址也发出来了，并且改造后的脚本也足够方便，还能一键启停。

一天后，小伟向老大交差了，CMDB也正式进入了服务…

过了两天，运行CMDB的机器承受了这个年纪不该承受的压力，运维建议停机加一下配置

老大：之前申请机器的时候没考虑性能压力的吗？现在升级一下配置中途中断服务体验也忒差了吧。

小伟（羞愧到）：也确实是自己考虑没到位，我这就去找方法！

小伟记得之前留意到一个现象，有些项目占用资源不多，有些资源占用比较多，但初始都申请配置一样的机器，就显得不很均衡。

于是小伟的脑海里面出现了这样一个构想：要是我有很多机器组成的机器群组，每个机器都有不多不少的资源，然后上面能同时不冲突的运行很多组项目，这个项目要是占用资源多，就给他多分一点，哪个少就少分一点，多台机器组成互相备份，一台机器宕机了不影响其他业务…

有了这个想法的小伟就差自己造轮子了，但是小伟还是打开了搜索引擎找起了轮子…

一天后…

老大：小伟，帮忙看一下容器技术和容器编排技术

小伟：好的老大！

(过了一会儿，小伟像找到宝一样，突然大喊，我找到解决方案了)

老大：咋回事啊？小伟

小伟：老大，谢谢你给的思路，我终于知道怎么优化现在刀耕火种的运维部署了

老大：哦？说来听听…

小伟：容器技术恰好因为他的隔离性，适合多个项目同时部署到一台机器，然后容器编排技术恰好可以把多个容器调度到一组机器组成的群集

老大：你这说的是什么啊，有没有得看一下啊？

小伟：老大，过几天我给你表演一个魔术 ~

(小伟根据需求，在容器化部署、分布式容器编排中查资料，终于确定了kubernetes 这个方案)

Kubernetes篇——面向终态的应用部署

(后来小伟申请了7台机器，忙活了几天几夜，搭出了一个3个主节点，4个工作节点的k8s集群)

一天，他找来了老大，给他表演个魔术

小伟：老大，你看我写了一份文件，就这个文件就可以让这个K8S集群为我部署CMDB

(只见小伟，把一个yaml格式的文件传递给集群的主节点)

此时集群接受了这份文件，并且忙碌了起来，过了一会儿..

小伟：老大你看，CMDB现在已经被我部署到这个K8S集群了，现在CMDB主程序我起了一个实例

(老大看了看,还真是)

(没过一会儿，整个CMDB微服务所有的组件都按照同样的套路被部署起来，并且调试通过)

小伟：现在这个集群可听我的，如果1个实例处理能力不足，那我让他扩张到3个他都是一瞬间的事情

(小伟在一个页面输入了3)

在很短的时间内，CMDB主程序已经扩展到了3个，并且分布在不同的4个工作节点之间

小伟：用了这个K8S集群，我们只需要告诉K8S集群，我要什么，要几个，K8S集群就会自动帮我们去部署，最终会达到我们指定的目标。这种方法叫做面向终态的应用部署。就像老大你给我们一个目标，剩下的就是交给我们去完成。

小伟：对了，除了像我刚刚手动指定每个程序的副本数量以外，k8s集群还支持配置成自动扩容缩容。简单来说，就是有一个插件会时时刻刻监控应用的资源占用情况，若是指标低于某个阈值，则会减少部署的副本数，若是高于某个阈值，则会增加部署的副本数。

老大：不错，这个方法好，在同一个地方就能管理这么多东西了。那么他故障转移能力如何？

小伟：这个问题我也计算过了，按照我们这个架构主节点可以允许挂1台，工作节点只要有机器挂了，那么其他的僚机会为他承担那台机器上面的部署任务，直到他修好了，重新加入才会把任务重新分到他身上。这样我们维护机器也方便多了，可以按照计划，一台一台轮流关机维护，待这一台维护完成后，再维护另一台，这样服务也不会造成中断啦

小伟：而且，这里的容器也是不怕删的，CMDB主程序这里，我们启动了多个实例，只要不同时删完，剩下的实例还是可以继续处理请求的，你删掉的那个他很快会检测出来，并且重新给你启动起来

(于是老大随手点了一下删除一个容器)

(此时页面还可以正常访问，并且过了一阵子，又重新启动起来了)

很快，CMDB正式被部署到了K8S集群上了，解决了以前很多痛点问题，同时服务质量也变好了

小伟这时候埋头研究K8S集群的更深入的功能了…