recreate(重建)模式
一次性终止所有的旧版本后并一次性发布新版本
定义的部署将终止所有正在运行的实例,然后使用较新的版本重新创建它们 最适合开发环境的发布
优点:
应用状态完全更新
缺点:
停机时间取决于应用程序的关闭和启动持续时间
ramped(滚动)模式
以滚动更新的方式发布新版本,成功创建一个新pod后再终止一个旧版本的Pod
渐变部署以滚动更新方式更新 pod,使用应用程序的新版本创建辅助ReplicaSet,然后减少旧版本的副本数,并增加新版本,直到达到正确的副本数
优点：
版本会在实例之间缓慢发布
对于可以处理数据重新平衡的有状态应用程序很方便
缺点：
推出/回滚可能需要一些时间
支持多个API很难
无法控制流量
blue/green(蓝色/绿色)模式
与旧版本一起发布新版本,然后切换流量
蓝色/绿色部署与渐变部署不同,因为应用程序的“绿色”版本与“蓝色”版本同时部署.在测试新版本满足要求之后,我们更新Kubernetes Service对象
该对象扮演负载平衡器的角色,通过替换选择器字段中的版本标签将流量发送到新版本.
优点:
即时部署/回滚
避免版本问题,一次性更改整个群集状态
缺点：
需要两倍的资源
在正式发布之前,应该对整个平台进行适当的测试
处理有状态的应用程序可能很困难
canary(金丝雀)模式
向一部分用户发布新版本,然后进行全面部署
金丝雀部署将用户的子集路由到新功能.在k8s中,可以使用两个具有通用Pod标签的部署来完成金丝雀部署.新版本的一个副本与旧版本一起发布
在一段时间后,如果未检测到错误,请按比例增加新版本的副本数量并删除旧的部署
优点：
为部分用户发布的版本
方便出错率和性能监控
快速回滚
缺点：
缓慢推出
精细调整的流量分配可能会很昂贵(99％A / 1％B = 99个Pod A，1个Pod B)
a/b testing(a/b测试)模式
A/B测试实际上是一种基于统计信息而不是部署策略制定业务决策的技术.但是,它是相关的,可以使用canary部署来实现
以精确的方式(HTTP标头,cookie,权重等)向一部分用户发布新版本.A / B测试实际上是一种基于统计信息做出业务决策的技术
除了根据权重在各个版本之间分配流量外,还可以基于一些参数(cookie,用户代理等)精确定位给定的用户群.此技术被广泛用于测试给定功能的转换
并且仅推出转换最多的版本,最适合部分用户的功能测试
优点:
需要智能负载均衡器
多个版本并行运行
完全控制流量分配
缺点:
难以解决给定会话的错误,因此必须进行分布式跟踪
不简单,您需要设置其他工具
shadow(影子部署)模式
和旧版本一起发布新的版本 把旧版本接收到的所有流量全部镜像到新版本用来测试新版本的稳定性 但是新版本并不会对流量进行任何响应
Deployment实现应用部署
实现水平扩展/收缩
水平扩展/收缩非常容易实现,Deployment Controller只需要修改它所控制的ReplicaSet的Pod副本个数就可以了
把值从3改成4那么Deployment所对应的ReplicaSet,就会根据修改后的值自动创建一个新的 Pod.这就是“水平扩展”了.“水平收缩”则反之
kubectl scale deployment nginx-deployment --replicas=4
实现滚动更新
READY 表示当前处于Running状态的Pod个数,但容器的镜像版本不一定是最新的
UP-TO-DATE 表示当前处于最新版本的Pod的个数 最新版本指的是Pod的Spec字段和Deployment里Pod模板中定义的完全一致
AVAILABLE 表示当前已经可用的Pod的个数 即是Running状态又是最新版本并且容器已经Ready状态的Pod个数,描述的是用户期望的最终状态的个数
滚动更新流程:
1.当修改了Deployment里的Pod定义之后,Deployment Controller会使用这个修改后的Pod模板创建一个新的ReplicaSet.这个新的 ReplicaSet 的初始Pod副本数是0
2.然后Deployment Controller 开始将这个新的ReplicaSet 所控制的Pod副本数从0个变成1个.即:“水平扩展”出一个副本
3.Deployment Controller又将旧的ReplicaSet所控制的旧Pod 副本数减少一个.即:“水平收缩”成两个副本
4.如此交替进行,新ReplicaSet管理的Pod副本数,从0个变成1个,再变成 2个,最后变成 3个.而旧的ReplicaSet管理的Pod副本数则从3个变成 2个,再变成 1个,最后变成 0个.这样就完成了这一组 Pod 的版本升级过程
将一个集群中正在运行的多个Pod版本 交替地逐一升级的过程,就是“滚动更新”
在升级刚开始的时候,集群里只有1个新版本的 Pod.如果这时新版本Pod有问题启动不起来,那么“滚动更新”就会停止.而在这个过程中,由于应用本身还有两个旧版本的Pod在线,所以服务并不会受到太大的影响
Deployment Controller还会确保在任何时间窗口内,只有指定比例的Pod处于离线状态.同时它也会确保,在任何时间窗口内只有指定比例的新Pod被创建出来.这两个比例的值都是可以配置的默认都是DESIRED值的25%
在RollingUpdateStrategy 的配置中:
maxSurge=1指定的是除了DESIRED数量之外在一次“滚动”中,Deployment 控制器还可以创建多少个新Pod
maxSurge=50%指的是我们最多可以一次创建 “50%*DESIRED 数量” 个新版本 Pod
maxUnavailable=1指的是在一次“滚动”中,Deployment控制器可以删除多少个旧Pod
maxUnavailable=50%指的是我们最多可以一次删除 “50%*DESIRED 数量” 个旧版本 Pod
1. Deployment 的控制器实际上控制的是ReplicaSet 的数目以及每个ReplicaSet的属性
2. 一个应用的版本对应的正是一个ReplicaSet这个版本应用的Pod数量.则由ReplicaSet通过它自己的控制器(ReplicaSet Controller)来保证
3.这样的多个ReplicaSet对象Kubernetes项目就实现了对多个“应用版本”的描述
4.应用版本和ReplicaSet是 一一对应的关系
我们对 Deployment 进行的每一次更新操作,默认都会生成一个新的ReplicaSet对象 相当于创建一个程序的版本
Kubernetes 项目还提供了一个指令,使得我们对Deployment的多次更新操作最后只生成一个ReplicaSet 相当于多次更新操作的集合作为一个程序版本
在更新Deployment 前你要先执行一条 kubectl rollout pause 指令
由于此时 Deployment 正处于“暂停”状态所以我们对 Deployment 的所有修改,都不会触发新的“滚动更新”也不会创建新的ReplicaSet
等到我们对 Deployment 修改操作都完成之后,只需要再执行一条 kubectl rollout resume 指令就可以把这个Deployment“恢复”回来
而在这个kubectl rollout resume指令执行之前,在kubectl rollout pause 指令之后的这段时间里我们对 Deployment 进行的所有修改最后只会触发一次“滚动更新相当于只会创建一个ReplicaSet(表示一个程序版本)