Kubernetes金丝雀发布

已于 2024-11-01 20:40:21 修改
阅读量484 收藏 9
点赞数 5
文章标签： kubernetes 容器 云原生
于 2024-11-01 20:36:54 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/huaz_md/article/details/143439081
版权

华子目录

Canary金丝雀发布

在这里插入图片描述

什么是金丝雀发布

  • 金丝雀发布也称为灰度发布，是一种软件发布策略
  • 主要目的是在将新版本的软件全面推广到生产环境之前，先在一小部分用户或服务器上进行测试和验证，以降低因新版本引入重大问题而对整个系统造成的影响
  • 是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式，保证Pod的总量不低于期望值。并且在更新部分Pod后，暂停更新，当确认新Pod版本运行正常后再进行其他版本的Pod的更新

Canary发布方式

三种发布方式：

  • 优先级：head大于cookie大于weight
  • 其中header和weight用的最多

基于header（http包头）灰度发布

在这里插入图片描述
我们可以看到如果包头中有stage=gray的键值对，就访问新版本，包头中没有那个键值对，就访问旧版本

  • 通过Annotaion扩展
  • 创建灰度ingress，配置灰度头部key以及value
  • 灰度流量验证完毕后，切换正式ingress到新版本
  • 之前我们在做升级时可以通过控制器做滚动更新，默认25%利用header可以使升级更为平滑，通过key和value 测试新的业务体系是否有问题

创建2个deployment控制器

#发现没有运行的pod
[root@k8s-master service]# kubectl get pods
No resources found in default namespace.

#创建一个deployment控制器，控制器中运行一个pod
[root@k8s-master service]# kubectl create deployment deployment --image myapp:v1 --dry-run=client -o yaml > deployment-v1.yml


[root@k8s-master service]# vim deployment-v1.yml
[root@k8s-master service]# cat deployment-v1.yml
apiVersion: apps/v1
kind: Deployment   #指明这是一个deployment控制器
metadata:   #控制器的元数据
  labels:    #控制器的标签
    app: deployment1   #控制器的标签
  name: deployment1   #控制器的名字
spec:  控制器的规格
  replicas: 1  #pod数量
  selector:  #pod选择器
    matchLabels:   #声明的要管理的pod
      app: myappv1  #标签为app=myappv1的pod会被管理
  template:    #pod的模板
    metadata:    #pod的元数据
      labels:     #pod的标签
        app: myappv1
    spec:     #pod的规格
      containers:
      - image: myapp:v1
        name: myappv1

#在克隆一份
[root@k8s-master service]# cp deployment-v1.yml deployment-v2.yml
[root@k8s-master service]# vim deployment-v2.yml
[root@k8s-master services]# cat deployment-v2.yml
apiVersion: apps/v1
kind: Deployment  #指明这个一个deployment控制器
metadata:     #控制器的元数据
  labels:     
    app: deployment2   #控制器的标签
  name: deployment2   #控制器的名字
spec:    #控制器的规格
  replicas: 1    #pod数量
  selector:     #pod选择器
    matchLabels:    
      app: myappv2   #声明需要管理的标签
  template:    #pod的模板
    metadata:    #pod的元数据
      labels:   
        app: myappv2  #pod的标签
    spec:   #pod的规格
      containers:
      - image: myapp:v2
        name: myappv2 

[root@k8s-master service]# kubectl apply -f deployment-v1.yml
deployment.apps/deployment1 created
[root@k8s-master service]# kubectl apply -f deployment-v2.yml
deployment.apps/deployment2 created


[root@k8s-master service]# kubectl get pods -o wide --show-labels
NAME                           READY   STATUS    RESTARTS   AGE     IP            NODE            NOMINATED NODE   READINESS GATES   LABELS
deployment1-5c47495d84-ds4cl   1/1     Running   0          3m20s   10.244.2.15   k8s-node2.org   <none>           <none>            app=myappv1,pod-template-hash=5c47495d84
deployment2-67cc8c4845-bfnvx   1/1     Running   0          6m49s   10.244.2.14   k8s-node2.org   <none>           <none>            app=myappv2,pod-template-hash=67cc8c4845

创建2个service微服务

[root@k8s-master service]# kubectl expose deployment deployment1 --port 8080 --target-port 80 --dry-run=client -o yaml >> deployment-v1.yml

[root@k8s-master service]# kubectl expose deployment deployment2 --port 8080 --target-port 80 --dry-run=client -o yaml >> deployment-v2.yml

[root@k8s-master service]# vim deployment-v1.yml
[root@k8s-master service]# cat deployment-v1.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deployment1
  name: deployment1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myappv1
  template:
    metadata:
      labels:
        app: myappv1
    spec:
      containers:
      - image: myapp:v1
        name: myappv1

---
apiVersion: v1
kind: Service   #指明这是一个service微服务
metadata:   #微服务元数据
  labels:  
    app: deployment1  #微服务标签 
  name: deployment1   #微服务的名字
spec:    #微服务的规格
  ports:   #是一个端口列表，用于描述service应该监听的端口以及如何将流量转发给pod
  - port: 8080   #service微服务监听的端口号
    protocol: TCP   #使用的协议，这里是TCP
    targetPort: 80   #pod上应用程序监听的端口
  selector:    #标签选择器，用于确定哪些pods应该被这个service管理
    app: myappv1  #pod标签为app=myappv1的被该service管理

[root@k8s-master service]# vim deployment-v2.yml
[root@k8s-master service]# cat deployment-v2.yml
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deployment2
  name: deployment2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myappv2
  template:
    metadata:
      labels:
        app: myappv2
    spec:
      containers:
      - image: myapp:v2
        name: myappv2

---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: deployment2
  name: deployment2
spec:
  ports:
  - port: 8080
    protocol: TCP
    targetPort: 80
  selector:
    app: myappv2

[root@k8s-master service]# kubectl apply -f deployment-v1.yml
deployment.apps/deployment1 unchanged
service/deployment1 created
[root@k8s-master service]# kubectl apply -f deployment-v2.yml
deployment.apps/deployment2 unchanged
service/deployment2 created

[root@k8s-master service]# kubectl get pods -o wide --show-labels
NAME                           READY   STATUS    RESTARTS   AGE   IP            NODE            NOMINATED NODE   READINESS GATES   LABELS
deployment1-5c47495d84-ds4cl   1/1     Running   0          15m   10.244.2.15   k8s-node2.org   <none>           <none>            app=myappv1,pod-template-hash=5c47495d84
deployment2-67cc8c4845-bfnvx   1/1     Running   0          18m   10.244.2.14   k8s-node2.org   <none>           <none>            app=myappv2,pod-template-hash=67cc8c4845


[root@k8s-master service]# kubectl get svc -o wide
NAME          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE    SELECTOR
deployment1   ClusterIP   10.108.37.167   <none>        8080/TCP   3m8s   app=myappv1
deployment2   ClusterIP   10.96.202.197   <none>        8080/TCP   3m2s   app=myappv2
kubernetes    ClusterIP   10.96.0.1       <none>        443/TCP    27d    <none>

[root@k8s-master service]# kubectl describe svc deployment1
Name:              deployment1
Namespace:         default
Labels:            app=deployment1
Annotations:       <none>
Selector:          app=myappv1
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.108.37.167
IPs:               10.108.37.167
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         10.244.2.15:80
Session Affinity:  None
Events:            <none>


[root@k8s-master service]# kubectl describe svc deployment2
Name:              deployment2
Namespace:         default
Labels:            app=deployment2
Annotations:       <none>
Selector:          app=myappv2
Type:              ClusterIP
IP Family Policy:  SingleStack
IP Families:       IPv4
IP:                10.96.202.197
IPs:               10.96.202.197
Port:              <unset>  8080/TCP
TargetPort:        80/TCP
Endpoints:         10.244.2.14:80
Session Affinity:  None
Events:            <none>
  • 创建ingress1.yml
[root@k8s-master service]# kubectl create ingress ingress1 --class nginx --rule='/=deployment1:8080' --dry-run=client -o yaml > ingress1.yml

[root@k8s-master service]# vim ingress1.yml
[root@k8s-master service]# cat ingress1.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: ingress1
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: deployment1
            port:
              number: 8080
        path: /
        pathType: Prefix
  • 创建ingress2.yml
[root@k8s-master service]# kubectl create ingress ingress2 --class nginx --rule='/=deployment2:8080' --dry-run=client -o yaml > ingress2.yml

[root@k8s-master service]# vim ingress2.yml
[root@k8s-master service]# cat ingress2.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "name"   #键
    nginx.ingress.kubernetes.io/canary-by-header-value: "huazi"  #值
  name: ingress2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: deployment2
            port:
              number: 8080
        path: /
        pathType: Prefix

[root@k8s-master service]# kubectl apply -f ingress1.yml
ingress.networking.k8s.io/ingress1 created
[root@k8s-master service]# kubectl apply -f ingress2.yml
ingress.networking.k8s.io/ingress2 created

[root@k8s-master service]# kubectl describe ingress ingress1
Name:             ingress1
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /   deployment1:8080 (10.244.2.15:80)
Annotations:  <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    12m (x2 over 13m)  nginx-ingress-controller  Scheduled for sync


[root@k8s-master service]# kubectl describe ingress ingress2
Name:             ingress2
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /   deployment2:8080 (10.244.2.14:80)
Annotations:  nginx.ingress.kubernetes.io/canary: true
              nginx.ingress.kubernetes.io/canary-by-header: name
              nginx.ingress.kubernetes.io/canary-by-header-value: huazi
Events:
  Type    Reason  Age                   From                      Message
  ----    ------  ----                  ----                      -------
  Normal  Sync    2m21s (x2 over 3m3s)  nginx-ingress-controller  Scheduled for sync

在这里插入图片描述

基于权重的金丝雀发布

在这里插入图片描述

  • 通过Annotaion拓展
  • 创建灰度ingress，配置灰度权重以及总权重
  • 灰度流量验证完毕后，切换正式ingress到新版本
#删掉基于header的ingress
[root@k8s-master service]# kubectl delete -f ingress2.yml
ingress.networking.k8s.io "ingress2" deleted

[root@k8s-master service]# vim ingress2.yml
[root@k8s-master service]# cat ingress2.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"    #10/100=10%，将有10%的流量打到新版本上
    nginx.ingress.kubernetes.io/canary-weight-total: "100"
  name: ingress2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: deployment2
            port:
              number: 8080
        path: /
        pathType: Prefix

[root@k8s-master service]# kubectl apply -f ingress2.yml
ingress.networking.k8s.io/ingress2 created

[root@k8s-master service]# kubectl describe ingress ingress1
Name:             ingress1
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /   deployment1:8080 (10.244.2.15:80)
Annotations:  <none>
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    27m (x2 over 27m)  nginx-ingress-controller  Scheduled for sync


[root@k8s-master service]# kubectl describe ingress ingress2
Name:             ingress2
Labels:           <none>
Namespace:        default
Address:          172.25.254.10
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host        Path  Backends
  ----        ----  --------
  *
              /   deployment2:8080 (10.244.2.14:80)
Annotations:  nginx.ingress.kubernetes.io/canary: true
              nginx.ingress.kubernetes.io/canary-weight: 10
              nginx.ingress.kubernetes.io/canary-weight-total: 100
Events:
  Type    Reason  Age                From                      Message
  ----    ------  ----               ----                      -------
  Normal  Sync    34s (x2 over 44s)  nginx-ingress-controller  Scheduled for sync
  • 写检测脚本
[root@harbor ~]# vim check.sh
#!/bin/bash
v1=0
v2=0
for ((i=0;i<100;i++))
do
        response=`curl -s 172.25.254.50 | grep -c v1`
        v1=`expr $v1 + $response`
        v2=`expr $v2 + 1 - $response`
done
echo "v1:$v1  v2:$v2"

[root@harbor ~]# bash check.sh
v1:89  v2:11
[root@harbor ~]# bash check.sh
v1:87  v2:13
#我们发现比例接近于9:1

当我们增加权重后

[root@k8s-master service]# vim ingress2.yml
[root@k8s-master service]# cat ingress2.yml
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "20"
    nginx.ingress.kubernetes.io/canary-weight-total: "100"
  name: ingress2
spec:
  ingressClassName: nginx
  rules:
  - http:
      paths:
      - backend:
          service:
            name: deployment2
            port:
              number: 8080
        path: /
        pathType: Prefix

[root@k8s-master service]# kubectl apply -f ingress2.yml
ingress.networking.k8s.io/ingress2 configured

[root@harbor ~]# bash check.sh
v1:76  v2:24
[root@harbor ~]# bash check.sh
v1:79  v2:21
#我们发现比例进阶于8:2
AI系统金丝雀发布原理与代码实战案例讲解
AI天才研究院
05-31 1053
AI系统金丝雀发布原理与代码实战案例讲解 1.背景介绍 1.1 什么是金丝雀发布？ 金丝雀发布(Canary Release)是一种软件交付策略,它通过逐步向一小部分用户推出新版本,并密切监控其性能和影响,从而降低全面部署带来的风
蓝绿部署与金丝雀发布原理与代码实战案例讲解
AI天才研究院
07-01 618
蓝绿部署与金丝雀发布原理与代码实战案例讲解 作者：禅与计算机程序设计艺术 / Zen and the Art of Computer Programming 关键词：蓝绿部署，金丝雀发布，微服务架构，自动回滚机制，容量规划，用户体验 1. 背景介绍
K8S Deployment 实现 金丝雀(灰度) 发布
matrixlzp的博客
02-06 1106
Deployment pause 的金丝雀发布是一种伪金丝雀发布。在滚动升级过程中，想要在⼀个确切的位置暂停滚动升级无法做到。无法实现流量的按比例分配。需要恢复更新才能执行回滚。相当于将有问题的版本全部更新完才能回滚，将影响面扩大化了。在现代云原生环境中，有许多其他工具和技术可以帮助实现金丝雀发布，如Kubernetes的服务网格Istio、负载均衡器配置等。这些工具允许细粒度控制流量分配，使得从A/B测试到完整的金丝雀发布变得更为容易实现。
15.StatefulSet控制器的金丝雀发布
LQ的博客
10-19 226
15.StatefulSet控制器的金丝雀发布 如果说Deployments和ReplicaSets解决的是无状态服务部署、扩缩容的刚需，那么StatefulSet控制器则是为了解决有状态服务的部署难题。 1.什么是StatefulSet? StatefulSet是一个管理有状态应用的API对象。 StatefulSet作为Controller为Pod提供其唯一的标识。 它可以保证应用程序部署和扩展的先后顺序 2.StatefulSet的应用场景 StatefulSet 适用于有以下某个或多个需求的应
灰度发布、金丝雀发布、蓝绿发布
最新发布
xuweilin的博客
02-27 704
灰度发布、金丝雀发布和蓝绿发布是三种常见的软件发布策略，用于在生产环境中逐步推出新版本，以降低风险并确保系统的稳定性。以下是它们的详细介绍、区别以及实现方法。灰度发布是一种逐步将新版本推送给部分用户的策略。通过控制新版本的流量比例，逐步扩大范围，确保新版本的稳定性。
金丝雀发布
ronshi的博客
04-29 774
金丝雀发布
云原生之Kubernetes：15、StatefulSet控制器的金丝雀发布
LQ的博客
08-30 473
StatefulSet控制器的金丝雀发布
【kubernetes】实战：金丝雀/灰度发布
09-13
在Kubernetes这样的容器编排平台上，实现金丝雀发布和灰度发布需要借助特定的资源对象和服务。Ingress是一种Kubernetes资源，它管理外部访问到集群服务的HTTP和HTTPS路由。Ingress可以结合annotations、自定义资源...
金丝雀发布（Cannary Release）
爱show的小卤蛋的博客
11-04 500
文章目录金丝雀发布（Cannary Release）新版本的流量怎么引过去的呢？新旧pservice如何联结在一起?更新deployment的版本并配置暂停deployment确保更新的pod没有问题，持续更新 修改后退出立即生效 集群外部访问用那个类型：用nodeport nodeip+nodeport外部访问 内部访问clusterip 用什么设置clusterip的端口号 金丝雀发布（Cannary Release） k8s中默认是滚动更新，deployment控制器可以自己控制滚动更新节奏，比如‘
K8S的金丝雀发布（Canary Release）
Riky12的博客
09-12 453
金丝雀发布的声明式管理方法：create/apply 两个的区别：当yaml配置文件发送改动后，使用以下两个更新的过程：create：是一次性的，先delete删除原有的资源再通过yaml’文件再创建。nginx-wang。
DevOps金丝雀发布
Jian Sun_的博客
06-18 3221
金丝雀发布 金丝雀发布（canary release）的名字很是好听。我们都知道以前矿工在下井采矿之前会把一种名叫金丝雀的鸟儿投入或携带到矿井中，如果鸟儿能够从矿井中飞出就表示井下有氧气，矿工就可以安心下井采矿了。通过这个故事的讲述我们可能已经猜到金丝雀发布的含义了。是的，所谓金丝雀发布就是把应用程序的某个新版本部署到生产环境中的部分服务器中，从而快速得到反馈。就像通过金丝雀发现矿井是否有氧气一样，金丝雀发布可以快速而有效地发现软件新版本存在的问题。 以下是关于金丝雀发布的示意图： 在..
Canary Release 金丝雀发布
galoiszhou的博客
11-14 872
金丝雀发布是一种部署策略，指的是在全面发布之前，先将软件的新版本或新功能推送给一小部分用户或系统进行测试。这种方法的灵感来自煤矿工人使用金丝雀检测有毒气体的传统，目的是在小范围内提前发现潜在的问题，从而避免对整个系统造成大范围的影响。
Kubernetes (八) 金丝雀发布
BJZX_OL的博客
01-09 794
一. 金丝雀发布作用：金丝雀发布是指在生产环境中逐步推出新版本应用程序，只在一小部分用户或流量中使用该版本，并根据反馈逐步扩大规模，最终完全替换旧版本。金丝雀发布允许快速检测新版本与旧版本之间是否存在兼容性问题、性能问题或其他问题，并减轻了在实施全新发布时可能遭受的损失二. 官网地址:三. 基于Header灰度实验测试实验前： 删除之前创建的pod svc等资源创建正常接受流量的svc v1版本创建接收带有header流量的svc v2版本查看svc是否正常。
k8s 中的金丝雀发布(灰度发布)
weixin_68398469的博客
10-06 2612
金丝雀发布（Canary Release）也称为灰度发布，是一种软件发布策略。主要目的是在将新版本的软件全面推广到生产环境之前，先在一小部分用户或服务器上进行测试和验证，以降低因新版本引入重大问题而对整个系统造成的影响。是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式，保证Pod的总量不低于期望值。并且在更新部分Pod后，暂停更新，当确认新Pod版本运行正常后再进行其他版本的Pod的更新。
Kubernetes----Deployment控制器实现版本金丝雀发布
mojolang
08-17 723
Kubernetes----Deployment控制器实现版本金丝雀发布
kubernetes金丝雀灰度发布
u010519674的专栏
07-31 1590
kubernetes 服务如何实现灰度发布
k8s七层代理Ingress-nginx基于cookie、请求头、权重实现灰度发布
weixin_38320674的博客
12-11 2807
场景一: 将新版本灰度给部分用户假设线上运行了一套对外提供 7 层服务的 Service A 服务，后来开发了个新版本 Service A’ 想要上线，但又不想直接替换掉原来的 Servi...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

^～^前行者～～～

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值