kubernetes实现蓝绿发布&金丝雀发布

一、 什么是蓝绿发布
  蓝绿发布是指在项目逻辑上分为AB组,在项目发布时,首先把A组从负载均衡中摘除,进行新版本的部署,B组仍然继续提供服务,做到用户体验无中断。

 当A组升级完毕,负载均衡重新接入A组,再把B组从负载列表中摘除,进行新版本的部署。A组重新提供服务。

 

 最后,B组也升级完成,负载均衡重新接入B组,此时,AB组版本都已经升级完成,并且都对外提供服务。

优点:

  1. 如果出问题,影响范围较大。

  2. 发布策略简单。

  3. 用户无感知,平滑过渡。

  4. 升级/回滚速度快。

缺点:

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

  2. 短时间内浪费一定资源成本。

  3. 基础设施无改动,增大升级稳定性。

  蓝绿发布需要两套环境交替升级,旧版本保留一定时间便于回滚。

   

 给Selector和labels都添加version标签。假如当前version = v1.0.0在对外提供服务,这时候要发布version = v1.0.1新版本,将新版本发布上线,这时候新版本还不接受线上的流量,为了将老版本的流量切到新版本上,需要将Service上Selector的version标签改为v1.0.1,这样就可以切换为新版本,如果新版本有问题,也可以将指回老版本。

金丝雀发布

  金丝雀发布又称灰度发布、灰度更新,金丝雀发布一般是先发1台机器,或者一个小比例,例如2%的服务器,主要做流量验证用,也称为金丝雀 (Canary) 测试,国内常称灰度测试。以前旷工下矿前,会先放一只金丝雀进去用于探测洞里是否有有毒气体,看金丝雀能否活下来,金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证,复杂的金丝雀测试需要比较完善的监控基础设施配合,通过监控指标反馈,观察金丝雀的健康状况,作为后续发布或回退的依据。如果金丝测试通过,则把剩余的 V1 版本全部升级为 V2 版本。如果金丝雀测试失败,则直接回退金丝雀,发布失败。

原文地址:https://www.cnblogs.com/songgj/p/14392336.html