K8S项目发布
确定无问题之后,再把剩下的老版本,升级成新的版本,把暂停取消,继续发布。立项---定稿---需求发布---开发---测试---发布,测试之后上线,再完美也会有问题,为了不让发生的问题影响所有用户,也就产生了上述的三种发布方式。在发布升级的过程中,只有一部分集群在对外提供服务,可能会使集群的负载能力下降,响应变慢,需要注意给这个集群增加负载能力(现在一般来说没有什么特殊需求,都是大半夜开始升级的服务
蓝绿发布
金丝雀发布(灰度发布)
滚动发布
应用程序升级,面临的最大困难就是新旧业务之间的切换。立项---定稿---需求发布---开发---测试---发布,测试之后上线,再完美也会有问题,为了不让发生的问题影响所有用户,也就产生了上述的三种发布方式。
蓝绿发布:把应用服务集群标记为两个组,蓝组和绿组,先升级蓝组,要把蓝组从负载均衡中移除,绿组继续提供服务
蓝组升级完毕,再把绿组从负载均衡中移除,绿组升级,然后都加入回负载均衡当中去,完成对外服务
这种发布对于硬件资源要求比较高,但是现在有了云计算和微服务,现在的成本也降低下来了
蓝绿发布的特点:
1、一旦出现问题,受到影响的范围很大
2、发布策略较为简单
3、基于现在的云计算技术和微服务,用户是无感知的
4、升级和回滚都比较方便
缺点:
在发布升级的过程中,只有一部分集群在对外提供服务,可能会使集群的负载能力下降,响应变慢,需要注意给这个集群增加负载能力(现在一般来说没有什么特殊需求,都是大半夜开始升级的服务)
在短时间内可能会浪费一定的资源成本
金丝雀发布(灰度发布):
deployment(控制器创建的服务才可以使用这种发布方式)
暂停:发布的过程中,暂时停止,只有一部分的pod先升级
其他的pod还是处于老的版本。只有一部分用户可以访问新的版本,绝大多数用户还是在老版本。确定无问题之后,再把剩下的老版本,升级成新的版本,把暂停取消,继续发布。如果有问题可以立即回滚,暂停不是回滚,一旦取消暂停只能全部升级完毕之后,再回滚。
[root@master01 ~]# kubectl set image deployment nginx2 nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx2
deployment.apps/nginx2 image updated
deployment.apps/nginx2 paused
[root@master01 ~]# kubectl get pod
NAME READY STATUS RESTARTS AGE
nginx2-5fc4444698-nrx5m 1/1 Running 0 37m
nginx2-5fc4444698-vgqwt 1/1 Running 0 37m
nginx2-7d97dbbb8c-jhtxf 0/1 ContainerCreating 0 25s
[root@master01 ~]# kubectl rollout status deployment nginx2
Waiting for deployment "nginx2" rollout to finish: 1 out of 2 new replicas have been updated...
取消暂停,全部更新
[root@master01 ~]# kubectl set image deployment nginx2 nginx=nginx:1.24 --record && kubectl rollout pause deployment nginx2
deployment.apps/nginx2 image updated
deployment.apps/nginx2 paused
[root@master01 ~]# curl -I 192.168.211.10:31000
HTTP/1.1 200 OK
Server: nginx/1.24.0
Date: Tue, 02 Jan 2024 01:49:33 GMT
Content-Type: text/html
Content-Length: 615
Last-Modified: Tue, 11 Apr 2023 01:45:34 GMT
Connection: keep-alive
ETag: "6434bbbe-267"
Accept-Ranges: bytes
所有POD已全部更新为1.24版本
灰度发布:
1、自动化的要求比较,对运维人员的要求比较高
2、方便发现问题,及时解决。影响范围比较小
3、用户无感知,平滑过度,节约资源
4、发布策略比较复杂
5、不易回滚,必须要等到全部发布成功后才能回滚
滚动更新:
deployment默认的就是滚动更新
更多推荐
所有评论(0)