K8s 版本发布

Posted 2023-02-27 奋斗的蜗牛灬

目录

• 前言
• 一、版本发布机制
• • 蓝绿发布
  • 滚动发布
  • 灰度发布（金丝雀发布）
• 二、金丝雀发布（Canary Release）
• • 2.1 更新 deployment 的版本，并配置 暂停 deployment
  • 2.2 监控更新的过程
  • 2.3 确保更新的 pod 没问题了，继续更新
  • 2.4 查看最后的更新情况

前言

-w //可以看到实时状态变化

kubectl get pod -w

一、版本发布机制

蓝绿发布

• 成本高，整个服务器组整体替换部署

• 

• 

滚动发布

• 滚动发布（k8s默认的更新机制）：先生成一个新的pod，然后删除一个旧的pod，往后以此类推。
• 每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
• 一直拿旧的变成新的，如果有问题就进行回滚

灰度发布（金丝雀发布）

• 找一部分旧的，更新成新的，拿这个新的给一小部分用户使用测试，如果用户使用没有问题，就把其他的POD 都更新成新的。
• 灰度发布只升级部分服务，即让一部分用户继续用老版本，一部分用户开始用新版本，如果用户对新版本没什么意见，那么逐步扩大范围，把所有用户都迁移到新版本上面来。
• 和滚动发布的区别，就是会让用户测试这个部分新版本

二、金丝雀发布（Canary Release）

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

eg：

查看更新机制

就比如有100个 pod，会先更新25个新pod，找用户测这25个，没问题，就在剩下继续创建 25%个新pod更新。。。直至完成。

2.1 更新 deployment 的版本，并配置 暂停 deployment

• 更新一部分之后会暂停，暂停时会生成一个新的POD，那这个新的POD进行使用测试，如果没问题的话就会继续进行更新。
• 原来的 service 还是能负载均衡轮询到新pod上，也可以添加 label 再创建新的 service 进行关联单独引一部分流量

kubectl set image deployment/nginx nginx=nginx:1.14 && kubectl rollout pause deployment/nginx

kubectl rollout status deployment/nginx       #观察更新状态

测试

kubectl describe ***
kubectl scale deployment nginx-test1 --replicas=2
kubectl get pod,svc

可以找用户去访问这个了
测试没问题
继续更新

2.2 监控更新的过程

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

kubectl get pods -w

curl -I http://10.96.6.104

2.3 确保更新的 pod 没问题了，继续更新

kubectl rollout resume deployment/nginx-test1

2.4 查看最后的更新情况

kubectl get pods -w
curl -I http://10.96.6.104