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 版本。如果金丝雀测试失败，则直接回退金丝雀，发布失败。