k8s三种常用的项目发布方式

k8s三种常用的项目发布方式

1、 蓝绿发布
2、 金丝雀发布(灰度发布)：使用最多
3 、滚动发布

应用程序升级，面临的最大问题是新旧业务之间的切换。
项目的生命周期：立项----定稿----需求发布----开发----测试-----发布
最后测试之后上线。再完美也会有问题，为了不让发生的问题影响所有用户。就产生了上述的三种发布方式。

蓝绿发布

蓝绿发布：把应用服务集群标记为两个组，蓝组和绿组。
1、 先升级蓝组。要把蓝组从负载均衡当中移除，绿组继续提供服务。 蓝组升级完毕。
2、 再把绿组从负载均衡当中移除，绿组升级，然后都加入回负载均衡当中去，完成对外服务。
蓝绿发布的工作流程图：
对硬件资源要求很高，但是有了云计算和微服务。现在成本已经大大降低了。
蓝绿发布的特点
优点：
一旦出现问题，影响范围很大
发布策略简单
基于现在的云计算和微服务，用户无感知
升级和回滚都比较方便
缺点：
在发布升级的过程中，只有一部分集群再对外提供的服务。可能会使集群的负载能力下降，响应便面，需要给集群增加负载能力(一般来说没什么特殊需要)
短时间内可能

金丝雀发布(灰度发布)：

在k8s中必须是基于deployment控制器创建的服务，才可以使用金丝雀这种发布方式。默认滚动跟新。在滚动跟新的基础上实现了暂停功能。
暂停：在发布的过程中暂时停止，只有一部分的pod先升级。其他的pod还是处于老的版本。只有一部分用户可以访问新的版本。绝大多数用户还是老版本。确定问题之后，再把剩下的老版本。升级成新的版本。把暂停取消继续发布。如果有问题可以立即回滚。
暂停并不是回滚。一旦取消暂停只能全部升级完毕之后再统一回滚。

kubectl set image deployment nginx nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx

#只会更新一个

kubectl rollout resume deployment nginx

#统一更新
全部升级完毕后才能回滚

kubectl rollout undo deployment nginx --to-revision=1

灰度发布的特点
优点：
自动化要求比较高。对运维人员的要求比较高
方便发现问题及时解决。影响范围比较小。
用户无感知，可以实现平滑过度。节约资源。
发布策略比较复杂。
不易回滚，必须要全部发布成功后才能回滚。

滚动更新

deployment的默认更新方式。
更新一个新的删除一个旧的