kubernetes系列之《构建企业级CICD平台(一)》

前言：本文是构建CICD的开篇文章，主要介绍常用的几种发布方案以及k8s采用的发布方案，为构建CICD平台做知识铺垫。

一、项目发布方案
1.1、蓝绿发布
蓝绿发布又称蓝绿部署，英文名Vlue Green Deployment，是一种可以保证在“不间断提供服务”的情况下上线的部署方法。

如何保证系统不间断提供服务呢？

蓝绿部署的模型中包含两个集群：

在没有上线的正常情况下，集群A和集群B的代码版本是一致的，并且同事对外提供服务。

在系统升级的时候，我们首先把一个集群（比如集群A）从负载列表中摘除，进行新版本的部署，集群B任然继续提供服务。

当集群A升级完毕，我们把负载均衡重新指向集群A，再把集群B从集群列表中摘除，进行新版本的部署，集群A重新提供服务。

最后，当集群B也升级完成，吧集群B也恢复到负载列表当中。这时两个集群的版本都已经升级完成，并且对外的服务几乎没有间断过。

优点：

同一时间对外提供的服务只有一个版本，容易定位问题。
升级和回滚以集群为粒度，操作相对简单。
缺点：

需要维护两个集群，成本较高
1.2、灰度发布
灰度发布又称金丝雀发布，有一个典故：以前旷工开矿下矿洞前先会放一只金丝雀进去探是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。
金丝雀发布一般先发布1台，或者一个小比例，例如20%的服务器，主要做流量验证用。

发布前：

先发布一台金丝雀：

全部发完：

如果金丝雀测试通过，则把剩余的V1版本全部升级为V2版本。如果金丝雀测试失败，则直接退回金丝雀，发布失败。

优点：

用户体验影响小，金丝雀发布过程出现问题只影响少量用户
缺点：

发布自动化程度不够，发布期间可引发服务中断
1.3、滚动发布
滚动发布又称滚动部署，英文名Rolling Update，同样是一种可以保证系统在“不间断提供服务”的情况下上线的部署方式。

和蓝绿部署不同的是，滚动部署对外提供服务的版本并不是非此即彼，而是在“更细的粒度下平滑完成版本的升级”

如何做到细粒度平滑升级版本呢？

滚动部署只需要一个集群，集群下的不同节点可以独立进行版本升级。比如在一个16节点的集群中，选择每次升级4个节点：

滚动升级中：

滚动升级中：

以此类推，最终所有的节点都升级到新版，并且保证不间断服务。

优点：

只需要维护一个集群，成本较低
缺点：

上线过程中，两个版本同时对外提供服务，不容易定位问题，且容易造成数据错乱。
升级和回滚以节点为粒度，操作相对复杂。
1.4、K8s中的滚动更新
蓝绿发布和灰度发布两种方案在k8s里本身不支持，但也可以另寻他法来实现。

Kubernetes使用Rolling Update解决了不停服务正常更新部署的困境，简单到只要一条语句就解决了这个问题。简单来说，kubernetes会滚动更新，一个一个的替换，从全部是旧的replica到新旧共存再到全部是新的。接下来我们看一下这个过程：

更新之前：
Service A在3个Node上启动了4个Pod，每个Pod中存放的都是相同的容器应用

滚动更新：
更新的时候，使用新的容器替换旧的

滚动更新所有Pod：


经过上面步骤后，滚动更新就完成了，而且全程是可以访问的状态。