K8s-发布方式浅谈

蓝绿发布

环境存在两个版本,蓝版本和绿版本同时存在,部署新版本然后进行测试,将流量切到新版本,最终实际运行的只有一个版本(蓝/绿)。好处是无需停机,并且发布风险较小。

蓝绿部署指定的是不停老版本（不影响上一个版本的访问），而是在另外一套环境部署新版本然后进行测试，测试通过后将用户流量切到新版本，其特点为业务无中断，升级风险相对较小。蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低。

蓝绿部署使用场景：

1.不停止老版本，额外部署新版本，等测试发现新版本成功后，删除老版本

2.蓝绿部署是一种用于升级与更新的发布策略，部署的最小维度是容器，而发布的最小维度是应用

3.蓝绿部署对于增量升级有比较好的支持但是对于涉及数据表结构变更等等不可逆转的升级，并不完全适用蓝绿部署发来实现，需要结合一些业务及数据迁移与回滚的策略才能完全满足需求

特点：

• 出现范围影响较大；

• 发布策略简单；

• 用户无感知，平滑过渡；

• 升级/回滚速度快；

缺点：

• 需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发

• 短时间内浪费一定资源成本；

金丝雀/灰度发布

“金丝雀”的由来：17世纪英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；而当瓦斯含量超过一定限度时，虽然鲁钝的人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人每次下井都会带上一只金丝雀作为“瓦斯检测指标”，以便在危险状况下紧急撤离。

金丝雀发布也叫灰度发布，是指在黑白之间，能够平滑过渡的一种发布方式，灰度发布是增量发布的一种类型，灰度发布是在原有版本可用的情况下，同时部署一个新版本应用作为“金丝雀”，测试新版本的性能和表现，以保障整体系统稳定的情况下，尽早发现，调整问题。因此，灰度发布可以保证整个系统的稳定，在初始灰度时候就发现、调整问题，以保证其影响度。

将发行版本发布到一部分用户或者服务器的一种模式。首先将更改部署到一部分服务器，进行测试，然后将更改推广到其余服务器。一旦通过所有运行状况检查，当没有问题时，所有的客户将被路由到该应用程序的新版本，而旧版本删除。

场景：

• 不停老版本，另部署新版本，不同版本共存

• 常常按照用户设置路由权重，如： 90%老用户，10%新用户

特点

• 保证整体系统的稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；

• 新功能逐步评估性能，稳定性和健康状况，如果出现问题影响范围很小，相对用户体验也少

• 用户无感知，平滑过渡

缺点

• 自动化要求高

发布优先级：

header > cookie > weight

滚动发布

一般是取一个或多个服务器停止服务，执行更新，并重新接入使用。周而复始直到集群中所有实例都更新成新版本，可防止同时升级造成服务停止

滚动发布，一般是取出一个或多个服务器停止服务，执行更新，并重新将其投入使用。周而复始，直到集群中所有的实例都更新成新版本，此方式可以防止同时升级，造成服务停止。滚动发布是指每次只升级一个或多个服务器，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级为新版本。

特点：

• 用户无感知，平滑过渡；

• 节约资源

缺点：

• 部署时间慢，取决于每阶段更新时间；

• 发布策略较复杂

发布方式的总结

蓝绿部署、灰度发布、滚动发布三种方式均可做到平滑式升级，在升级的过程中服务仍然保持服务的连续性，升级对外界是无感知的。如果运维自动化能力储备不够，肯定越简单越好，建议蓝绿发布；如果业务对用户依赖性很强，建议灰度发布；如果是k8s平台，滚动更新建议直接使用。

• 蓝绿发布： 两套环境交替升级，旧版本保留一定时间便于回滚

• 灰度发布：根据比例将老版本升级，例如80%用户访问是老版本，20%用户访问的是新版本

• 滚动发布： 按批次停止老版本实例，启动新版本实例