K8S 金丝雀发布（Canary Release）- 声明式

最新推荐文章于 2024-05-23 00:00:57 发布

m69zhuang

最新推荐文章于 2024-05-23 00:00:57 发布

阅读量370

点赞数

文章标签： kubernetes 容器云原生运维服务器金丝雀发布

本文链接：https://blog.csdn.net/m69zhuang/article/details/132847588

版权

文章目录

一、项目发布方式

1. 蓝绿发布

（1）概念

首先将所有的应用服务集群为蓝绿两组，首先将绿组的集群从负载均衡中移除，蓝组则继续对用户提供服务。此时移除的绿组进行服务的升级，等升级完毕后，再从新将绿组接入到负载均衡中为用户提供服务。

再把蓝组进行移除，进行服务升级，升级完毕后再接入到负载均衡的集群中。此时整个项目集群得进行升级完毕，我们将此称为蓝绿发布

（2）特点：

如果出问题，影响范围较大；发布策略简单；用户无感知，平滑过渡；升级/回滚速度快。

（3）缺点：

需要准备正常业务使用资源的两倍以上服务器，防止升级期间单组无法承载业务突发；短时间内浪费一定资源成本；基础设施无改动，增大升级稳定性。

蓝绿发布在早期物理服务器时代，还是比较昂贵的，由于云计算普及，成本也大大降低

2. 滚动发布

（1）概念：

滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。

（2）特点：

用户无感知，平滑过渡；节约资源。

（3）缺点：

部署时间慢，取决于每阶段更新时间；发布策略较复杂；无法确定OK的环境，不易回滚。

3. 灰度发布 /金丝雀发布

（1）概念：

灰度发布又叫金丝雀发布，灰度是指在黑与白之间，能够平滑过渡的一种发布方式

该过程类似于游戏中的体验服，首先会让一部分用户进行使用测试，如果没什么问题后，会逐步面积推广，彻底替代旧的版本

（2）特点：

保证整体系统稳定性，在初始灰度的时候就可以发现、调整问题，影响范围可控；新功能逐步评估性能，稳定性和健康状况，如果出问题影响范围很小，相对用户体验也少；用户无感知，平滑过渡。

（3）缺点：

自动化要求高

二、金丝雀发布（Canary Release）

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

简而言之就是，会有一个对外暴露测试，没有问题再更新剩余的，更新一个对外开放一个

原理架构图

1. 创建新的资源

kubectl create deployment nginx-test --image=nginx:1.14 --port=80 --replicas=3
kubectl get pod

2. 查看详细信息

kubectl describe pod

3. 实时跟踪资源

打开另开一个终端进行实时跟踪

kubectl get pod -w

4. 更新资源类型

（1）在原本的终端更新资源类型

kubectl set image deployment nginx-test nginx=nginx:1.15 && kubectl rollout pause deployment nginx-test

（2）查看资源

kubectl get pod

（3）查看资源监控

打开刚刚开的那个终端

kubectl get pod -w

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

5. 连接并查看版本

（1）查看详细地址

kubectl get pod -o wide

（2）连接并查看版本

curl -I 10.244.2.31
curl -I 10.244.2.29

6. 测试访问

（1）对端口进行外放访问设置

kubectl expose deployment nginx-test --port=80 --target-port=80 --type=NodePort

kubectl get svc
kubectl describe svc nginx-test

（2）访问

curl 192.168.23.5:31413

7. 金丝雀隔断新的资源

金丝雀隔离新的pod测试新的版本是否有问题，给pod做隔离，需要单独的标签

（1）创建新的pod并给端口

kubectl expose deployment nginx-test --name=new-ngin-test --port=80 --type=NodePort

kubectl get svc
kubectl get endpoints

（2）编辑服务对象

复制里面的new-nginx-test文件内容编辑新的yaml文件

kubectl edit svc new-ngin-test

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2023-09-12T08:45:08Z"
  labels:
    app: nginx-test
  name: new-ngin-test
  namespace: default
  resourceVersion: "166679"
  uid: e435a746-b252-41f3-840e-e15f68e9714f
spec:
  clusterIP: 10.96.237.49
  clusterIPs:
  - 10.96.237.49
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32676
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-test
  sessionAffinity: None
  type: NodePort

（3）获取 pod 标签

kubectl get pod --show-labels

kubectl describe pod nginx-test-db7ddd9d9-jv762
pod-template-hash=db7ddd9d9

（3）编辑 yaml 文件

vim new-ngin-test.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2023-09-12T08:45:08Z"
  labels:
    app: nginx-test
  name: new-ngin-test
  namespace: default
  resourceVersion: "166679"
  uid: e435a746-b252-41f3-840e-e15f68e9714f
spec:
  clusterIP: 10.96.237.49
  clusterIPs:
  - 10.96.237.49
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 32676
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    pod-template-hash: db7ddd9d9
  sessionAffinity: None
  type: NodePort

（4）删除新的标签

kubectl delete svc new-ngin-test
kubectl get scv

（5）创建或更新服务对象

kubectl apply -f new-ngin-test.yaml
kubectl get scv
kubectl get pod --show-labels

（6）访问测试

8. 金丝雀发布更新

（1）编辑 yaml 文件

复制旧的yaml配置文件，复制apiVersion: v1 ~ type: NodePort

kubectl edit svc nginx-test

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2023-09-12T08:25:14Z"
  labels:
    app: nginx-test
  name: nginx-test
  namespace: default
  resourceVersion: "164999"
  uid: ea36ceb4-430a-4b12-99d8-4778dadde157
spec:
  clusterIP: 10.96.106.168
  clusterIPs:
  - 10.96.106.168
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 31413
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-test
  sessionAffinity: None
  type: NodePort

kubectl get pod --show-labels

vim nginx-test.yaml

apiVersion: v1
kind: Service
metadata:
  creationTimestamp: "2023-09-12T08:25:14Z"
  labels:
    app: nginx-test
  name: nginx-test
  namespace: default
  resourceVersion: "164999"
  uid: ea36ceb4-430a-4b12-99d8-4778dadde157
spec:
  clusterIP: 10.96.106.168
  clusterIPs:
  - 10.96.106.168
  externalTrafficPolicy: Cluster
  ports:
  - nodePort: 31413
    port: 80
    protocol: TCP
    targetPort: 80
  selector:
    pod-template-hash: 7b97cf7f78
  sessionAffinity: None
  type: NodePort

（2）删除旧的service

删除 svc 中的 nginx-test

kubectl delete svc nginx-test
kubectl get svc

（3）生成

kubectl apply -f nginx-test.yaml
kubectl get svc

（4）访问测试

更新的访客访问new-ngin-test，未更新的访客访问nginx-test

9. 金丝雀继续更新

（1）查看更新状态信息

kubectl rollout status deployment nginx-test

（2）确保更新的pod没问题了，继续更新

kubectl rollout resume deployment nginx-test

（2）追踪更新

另一个终端

kubectl get pod -w

（3）访问测试

curl -I 10.244.2.32
curl -I 10.244.2.31
curl -I 10.244.1.11

10. 总结

金丝雀发布的声明式管理方法

create/apply 两个的区别：

当yaml配置文件发送改动后，使用以下两个更新的过程

create： 是一次性的，先delete删除原有的资源再通过yaml’文件再创建。

apply： 创建资源没办法更新的，如果想更新，可以直接再执行kubectl apply -f 更新或先修改在删除，最后再创建更新。

m69zhuang

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
K8S 金丝雀发布（Canary Release）- 声明式

金丝雀发布的声明式管理方法create/apply 两个的区别：当yaml配置文件发送改动后，使用以下两个更新的过程是一次性的，先delete删除原有的资源再通过yaml’文件再创建。创建资源没办法更新的，如果想更新，可以直接再执行kubectl apply -f 更新或先修改在删除，最后再创建更新。
复制链接

扫一扫