应用发布策略

蓝绿发布

# 概念定义：
蓝绿发布是一种以最小的停机时间做服务升级的策略。需要维护的两个版本的环境分别称为 “蓝环境” 和 “绿环境”。一般当前生产流量指向环境为绿环境，而在蓝环境上部署新版本，短时间内作为测试环境。

#发布流程
首先将一半的服务流量从负载均衡列表中移除，并且更新服务版本，验证新版本没有问题后，将生产流量指向蓝环境，然后对于老版本的绿环境进行版本升级，最后将所有服务流量加回负载均衡。

#特点：
升级过程无需停机，用户感知小
升级过程一半资源提供服务
升级/回滚速度快
如果出了问题，影响面较广

**红黑发布**

#概念定义：
与蓝绿发布类似，红黑发布也是通过两个环境完成软件版本的升级，将当前生产流量指向的环境称为红环境，新版本环境称为黑环境。

#发布流程：
需申请新资源用于部署黑环境，在黑环境部署新版本的服务；黑环境部署完成后，一次性将生产流量指向黑环境；释放红环境的资源。

#特点：
升级过程无需停机，用户感知小
短时间内需要使用双倍资源
与蓝绿发布相比，红黑发布充分利用了云计算的弹性伸缩的优势，实现：
简化发布流程
避免在升级的过程中，由于只有一半资源提供服务，而导致的系统过载问题

灰度发布

#概念定义：
灰度发布属于增量发布，新老版本同时为用户提供服务。灰度发布的主要目的是保证系统的可用性。每一次的线上变更都无法保证系统 100% 的无 bug，所以变更后要在线上小范围验证，等没问题再全面放开。而金丝雀发布是灰度发布的一种实现。

金丝雀发布由来：以前矿工开矿，在下矿洞前需要检查下方是否有毒气，矿工们先会放一只金丝雀进去探是否有毒气体，看金丝雀能否活下来。

#发布流程：
在现有环境中部署少量服务的新版本（金丝雀），部署完成后，对线上流量进行监测，如果没有问题就对老版本服务进行全量升级。

#特点：
用户体验影响小，灰度发布过程出现问题影响范围较小
新版本功能逐步发布，可以逐步评估新版服务性能、稳定性和健康状态
发布自动化程度不够，发布期间可能引发服务中断

滚动发布

# 在金丝雀发布基础上的进一步优化改进，是一种自动化程度较高的发布方式，用户体验比较平滑，是目前成熟型技术组织所采用的主流发布方式。

kubectl陈述式方式做灰度发布（金丝雀发布）

金丝雀发布（Canary Release）
Deployment控制器支持自定义控制更新过程中的滚动节奏，如“暂停(pause)”或“继续(resume)”更新操作。比如等待第一批新的Pod资源创建完成后立即暂停更新过程，此时，仅存在一部分新版本的应用，主体部分还是旧的版本。然后，再筛选一小部分的用户请求路由到新版本的Pod应用，继续观察能否稳定地按期望的方式运行。确定没问题之后再继续完成余下的Pod资源滚动更新，否则立即回滚更新操作。这就是所谓的金丝雀发布。

先基于deployment控制器创建pod，然后发布

kubectl -n hanbao create deployment deploy-nginx --image=soscscs/myapp:v1 --port=80 --replicas=3

基于命令行灰度发布

kubectl -n hanbao set image deployment deploy-nginx myapp=soscscs/myapp:v2 && kubectl -n hanbao rollout pause deployment deploy-nginx

灰度发布，更新版本为v2，然后停止回滚
//因为deployment的默认回滚策略是滚动更新，那么停止就会在第一波更新的时候  停止回滚

监控更新的过程，可以看到已经新增了一个资源，但是并未按照预期的状态去删除一个旧的资源，就是因为使用了pause暂停命令
kubectl -n hanbao get pod -o wide -w

测试等到版本稳定以后，再完成继续发布

kubectl -n hanbao expose pod deploy-nginx-7cb95f9469-9f246 --name svc-nginx-v2

kubectl -n hanbao expose pod deploy-nginx-7cb95f9469-9f246 --name svc-nginx-nodeport-v2 --type NodePort --port=7090 --target-port=80

 #实时检测

滚动发布详解

kubectl -n hanbao describe deployments.apps deploy-nginx 

关于滚动发布的参数

deployment控制器更新Pod的方式是 RollingUpdate（滚动更新）
RollingUpdateStrategy（滚动更新策略）:  25% max unavailable, 25% max surge

Replicas: 3 desired 控制器的期望副本数
25% max surge 滚动更新时允许创建的最大副本数或比例，向上取整。值调的越大，副本更新速度越快。
25% max unavailable 滚动更新时允许销毁的最大副本数或比例，向下取整。值越小，越能保证服务稳定，更新越平滑；

滚动发布的过程

假设期望副本数是3，那么滚动更新时能够创建的副本数是 3 * 25% = 0.75  再向上取整为 1，能够销毁的副本数向下取整为 0
                   
假设期望副本数是10，10 * 25% = 2.5  向上取整为 3     向上取整为 2
整个滚动更新过程中Pod副本数始终处在 （10-2）<= Pod副本数 <= （10+3）之间

结论

#概述
蓝绿部署用的就比较少了，毕竟太浪费资源了。滚动发布和灰度发布其实都可以用矿工(用户)下井(使用的版本)来理解，旧矿井(日版本)和新矿井(新版本)。滚动发布就是发现新矿井，直接让矿工排队下新矿井，结果瓦斯浓度过高(bug)，死伤惨重(版本回退)。灰度发布就是这些人学鸡贼了，发现新矿井后，矿工还是留在旧矿井干活，下新井的就是金丝雀(按规则负载均衡过来的部分用户、测试者)。直到确认新矿井没问题，再让矿工全部从旧矿井迁移到新矿井。



蓝绿发布: 两套环境交替升级，旧版本保留一定时间便于回滚，优点:用户无感知，缺点浪费资源成本高
滚动发布: 按批次停止老版实例，更新启动新版本实例。优点: 节约资源，缺点部署和回滚较慢
灰度发布(金丝雀发布): 根据比列将老版本升级，例如80%用户访问时老版本，20%用户访问时新版本。优点:保证给整体系统稳定性，如果出问题影响范围很小，缺点:自动化要求高
kubectl set image deployment <资源名称> <容器名>=<容器镜像> && kubectl rollout pause deployment <资源名称> 
kubectl rollout resume deployment <资源名称>