k8s 中的金丝雀发布(灰度发布)

于 2024-10-06 01:22:46 发布
阅读量1.6k 收藏 16
点赞数 29
分类专栏： kubernetes 云原生 文章标签： kubernetes 容器 云原生
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_68398469/article/details/142719441
版权

目录

1 什么是金丝雀发布

2 Canary 发布方式

3 Canary 两种发布方式实操

3.1 准备工作

3.1.1 将 nginx 命名两个版本 v1 与 v2

3.1.2 暴露端口并指定微服务类型

3.1.3 进入 pod 修改默认发布文件

3.1.4 测试 service 是否正常

 3.2 基于权重的灰度发布

3.2.1 创建 Igress 资源类型文件

3.2.2 解释关于配置文件的意思

3.2.3 声明 Igress 文件

3.2.4 客户端测试

3.3 基于客户端请求的灰度发布

3.3.1 如何实现客户端请求的灰度发布介绍

3.3.2 创建 Igress 资源类型文件

3.3.3 关于配置文件的解释：

3.3.4 声明 Igress 文件

3.3.5 客户端进行测试

1 什么是金丝雀发布

金丝雀发布（Canary Release）也称为灰度发布，是一种软件发布策略。

主要目的是在将新版本的软件全面推广到生产环境之前，先在一小部分用户或服务器上进行测试和验证，以降低因新版本引入重大问题而对整个系统造成的影响。

是一种Pod的发布方式。金丝雀发布采取先添加、再删除的方式，保证Pod的总量不低于期望值。并且在更新部分Pod后，暂停更新，当确认新Pod版本运行正常后再进行其他版本的Pod的更新。

2 Canary 发布方式

其中header和weight中的最多

3 Canary 两种发布方式实操

3.1 准备工作

3.1.1 将 nginx 命名两个版本 v1 与 v2

# 创建版本v1的deployment资源类型的nginx
[root@k8s-master ingress]# kubectl create deployment nginx-v1 \
--image nginx:latest \
--dry-run=client \
--port 80 \
--replicas 1  \
-o yaml > nginx-v1.yml

[root@k8s-master ingress]# cat nginx-v1.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-v1    # 此标签一定要与微服务的标签对得上,不然微服务无法找到deployment
  name: nginx-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-v1
  template:
    metadata:
      labels:
        app: nginx-v1
    spec:
      containers:
      - image: nginx:latest
        name: nginx-v1
        ports:
        - containerPort: 80

# 创建版本 v2 的 deployment 资源类型的 nginx
[root@k8s-master ingress]# kubectl create deployment nginx-v2 \
--image nginx:latest \
--dry-run=client \
--port 80 \
--replicas 1  \
-o yaml > nginx-v2.yml

[root@k8s-master ingress]# cat nginx-v2.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-v2
  name: nginx-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-v2
  template:
    metadata:
      labels:
        app: nginx-v2
    spec:
      containers:
      - image: nginx:latest
        name: nginx-v2
        ports:
        - containerPort: 80


# 声明这两个版本的清单文件
[root@k8s-master ingress]# kubectl apply -f nginx-v1.yml 
deployment.apps/nginx-v1 created

[root@k8s-master ingress]# kubectl apply -f nginx-v2.yml 
deployment.apps/nginx-v2 created

# 查看deployment是否正常运行
[root@k8s-master ingress]# kubectl get deployments.apps 
NAME       READY   UP-TO-DATE   AVAILABLE   AGE
nginx-v1   1/1     1            1           12s
nginx-v2   1/1     1            1           6s

3.1.2 暴露端口并指定微服务类型

创建微服务清单文件并将其加入到deployment的清单文件中

# 创建清单文件追加到deployment清单文件中
[root@k8s-master ingress]# kubectl expose deployment nginx-v1 \
--name=svc-nginx-v1 \
--port 80 --target-port 80 \
--dry-run=client \
--type=ClusterIP -o yaml >> nginx-v1.yml 

[root@k8s-master ingress]# kubectl expose deployment nginx-v2 \
--name=svc-nginx-v2 --port 80 --target-port 80 \
--dry-run=client \
--type=ClusterIP -o yaml >> nginx-v2.yml 

[root@k8s-master ingress]# cat nginx-v1.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-v1
  name: nginx-v1
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-v1
  template:
    metadata:
      labels:
        app: nginx-v1
    spec:
      containers:
      - image: nginx:latest
        name: nginx-v1
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-v1
  name: svc-nginx-v1
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-v1
  type: ClusterIP



[root@k8s-master ingress]# cat nginx-v2.yml 
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: nginx-v2
  name: nginx-v2
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nginx-v2
  template:
    metadata:
      labels:
        app: nginx-v2
    spec:
      containers:
      - image: nginx:latest
        name: nginx-v2
        ports:
        - containerPort: 80
---        
apiVersion: v1
kind: Service
metadata:
  labels:
    app: nginx-v2
  name: svc-nginx-v2
spec:
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: nginx-v2
  type: ClusterIP


# 重新声明更新配置

[root@k8s-master ingress]# kubectl apply -f nginx-v1.yml 

[root@k8s-master ingress]# kubectl apply -f nginx-v2.yml 

# 服务创建成功
[root@k8s-master ingress]# kubectl get service
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes     ClusterIP   10.96.0.1        <none>        443/TCP   3d22h
svc-nginx-v1   ClusterIP   10.107.76.175    <none>        80/TCP    15s
svc-nginx-v2   ClusterIP   10.100.188.171   <none>        80/TCP    9s

3.1.3 进入 pod 修改默认发布文件

[root@k8s-master ingress]# kubectl get pods 
NAME                       READY   STATUS    RESTARTS   AGE
nginx-v1-dbd4bc45b-49hhw   1/1     Running   0          5m35s
nginx-v2-bd85b8bc4-nqpv2   1/1     Running   0          5m29s

[root@k8s-master ingress]# kubectl exec -it pods/nginx-v1-dbd4bc45b-49hhw -- bash

root@nginx-v1-dbd4bc45b-49hhw:/# echo this is nginx-v1 `hostname -I` > /usr/share/nginx/html/index.html 

[root@k8s-master ingress]# kubectl exec -it pods/nginx-v2-bd85b8bc4-nqpv2 -- bash

root@nginx-v2-bd85b8bc4-nqpv2:/# echo this is nginx-v2 `hostname -I` > /usr/share/nginx/html/index.html

3.1.4 测试 service 是否正常

[root@k8s-master ingress]# kubectl get service
NAME           TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)   AGE
kubernetes     ClusterIP   10.96.0.1        <none>        443/TCP   3d22h
svc-nginx-v1   ClusterIP   10.107.76.175    <none>        80/TCP    15s
svc-nginx-v2   ClusterIP   10.100.188.171   <none>        80/TCP    9s

[root@k8s-master ingress]# curl 10.107.76.175
this is nginx-v1 10.244.2.54

[root@k8s-master ingress]# curl 10.100.188.171
this is nginx-v2 10.244.1.35

 3.2 基于权重的灰度发布

3.2.1 创建 Igress 资源类型文件

[root@k8s-master Cannary]# kubectl create ingress canary --class nginx \
--rule "nginx.shuyan.com/=svc-nginx-v1:80" \
--dry-run=client -o yaml > canary.yml

[root@k8s-master Cannary]# kubectl create ingress canary --class nginx \
--rule "nginx.shuyan.com/=svc-nginx-v2:80" \
--dry-run=client -o yaml >> canary.yml

# 以下是修改过后的资源类型
[root@k8s-master Cannary]# cat canary.yml 
# 第一个Ingress定义，用于常规服务
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-v1  # 定义Ingress的名称
spec:
  ingressClassName: nginx  # 指定使用的Ingress控制器类型
  rules:
  - host: nginx.shuyan.com  # 设置主机名，所有的请求都会被转发到这个域名下的服务
    http:
      paths:
      - backend:
          service:
            name: svc-nginx-v1  # 指定后端服务的名字
            port:
              number: 80  # 指定后端服务监听的端口
        path: /  # 所有访问根路径的请求都会被转发到此服务
        pathType: Prefix  # 路径类型为前缀，表示所有以"/"开头的请求都将被转发到此服务

---

# 第二个Ingress定义，用于灰度发布服务
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:  # 添加注解来控制灰度发布
    nginx.ingress.kubernetes.io/canary: "true"  # 开启灰度发布模式
    nginx.ingress.kubernetes.io/canary-weight: "10"  # 设置灰度发布的权重为10%，即10%的流量会被路由至此服务
    nginx.ingress.kubernetes.io/canary-weight-total: "100"  # 这个注解并不是标准NGINX Ingress Controller支持的，可以忽略
  name: canary-v2  # 定义Ingress的名称
spec:
  ingressClassName: nginx  # 指定使用的Ingress控制器类型
  rules:
  - host: nginx.shuyan.com  # 设置主机名，所有的请求都会被转发到这个域名下的服务
    http:
      paths:
      - backend:
          service:
            name: svc-nginx-v2  # 指定后端服务的名字
            port:
              number: 80  # 指定后端服务监听的端口
        path: /  # 所有访问根路径的请求都会被转发到此服务
        pathType: Prefix  # 路径类型为前缀，表示所有以"/"开头的请求都将被转发到此服务

3.2.2 解释关于配置文件的意思

第一个Ingress (canary-v1)：

  • 这个Ingress没有使用任何灰度发布的注解。
  • 它将处理所有发往 nginx.shuyan.com 的请求，并将这些请求路由到名为 svc-nginx-v1 的服务上。

第二个Ingress (canary-v2)：

  • 使用了灰度发布的注解 nginx.ingress.kubernetes.io/canary: "true" 和nginx.ingress.kubernetes.io/canary-weight: "10"。
  • 这些注解表明该Ingress将处理一部分流量（本例中为10%），并将这部分流量路由到名为 svc-nginx-v2 的服务上。

3.2.3 声明 Igress 文件

[root@k8s-master Cannary]# kubectl apply -f canary.yml 
ingress.networking.k8s.io/canary-v1 created
ingress.networking.k8s.io/canary-v2 created

3.2.4 客户端测试

# 客户端添加解析
[root@harbor ~]# vim /etc/hosts
192.168.239.241  nginx.shuyan.com

# 测试
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v2 10.244.1.35
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v1 10.244.2.54
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v1 10.244.2.54
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v1 10.244.2.54
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v1 10.244.2.54
[root@harbor ~]# curl nginx.shuyan.com
this is nginx-v1 10.244.2.54

# 编写脚本循环测试

[root@harbor ~]# vim canary.sh
#!/bin/bash

# 初始化计数器
v1=0
v2=0

# 循环发送请求并统计结果
for (( i=0; i<100; i++ )); do
    # 发送请求并检查响应中是否包含 "v1"
    response=`curl -s nginx.shuyan.com | grep -c "v1"`

    # 根据响应结果更新计数器
    if [ "$response" -eq 1 ]; then
        ((v1++))
    else
        ((v2++))
    fi
done

# 输出统计结果
echo "v1: $v1, v2: $v2"

# 运行脚本进行测试
[root@harbor ~]# bash canary.sh 
v1: 88, v2: 12
[root@harbor ~]# bash canary.sh 
v1: 88, v2: 12
[root@harbor ~]# bash canary.sh 
v1: 90, v2: 10
[root@harbor ~]# bash canary.sh 
v1: 90, v2: 10
[root@harbor ~]# bash canary.sh 
v1: 87, v2: 13

 

3.3 基于客户端请求的灰度发布

3.3.1 如何实现客户端请求的灰度发布介绍

基于客户端请求的流量切分要求客户端在 HTTP 请求头中包含指定键值对或在 Cookie 中包含指定键值对。当 HTTP 请求头包含“canary=always”时，流量会被路由到新版本(Canary 版本)，一旦新版本验证通过，流量就会被逐步切分到新版本。这种策略比较适合将特定的客户端请求路由到新版本，以便进行更具体的测试和验证。

3.3.2 创建 Igress 资源类型文件

# 回收以上实验的资源
[root@k8s-master Cannary]# kubectl delete -f canary.yml 

# 创建 ingress 清单文件

[root@k8s-master Cannary]# kubectl create ingress canary-cookie-old \
--class nginx \
--rule "nginx.shuyan.com/=svc-nginx-v1:80" \
--dry-run=client -o yaml > canary-cookie.yml 

[root@k8s-master Cannary]# kubectl create ingress canary-cookie-new \
--class nginx \
--rule "nginx.shuyan.com/=svc-nginx-v2:80" \
--dry-run=client -o yaml >> canary-cookie.yml 


# 修改部分参数

[root@k8s-master Cannary]# cat canary-cookie.yml 
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-cookie-old  # 定义第一个Ingress资源的名称
spec:
  ingressClassName: nginx  # 指定使用的Ingress控制器类型
  rules:
  - host: nginx.shuyan.com  # 设置主机名，所有请求都会被转发到这个域名下的服务
    http:
      paths:
      - backend:
          service:
            name: svc-nginx-v1  # 指定后端服务的名字
            port:
              number: 80  # 指定后端服务监听的端口
        path: /  # 所有访问根路径的请求都会被转发到此服务
        pathType: Prefix  # 路径类型为前缀，表示所有以"/"开头的请求都将被转发到此服务

---
# 分割线，表示这是一个新的Ingress资源定义

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: canary-cookie-new  # 定义第二个Ingress资源的名称
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"  # 开启灰度发布模式
    nginx.ingress.kubernetes.io/canary-by-header: "canary"  # 指定使用HTTP头部来区分流量
    nginx.ingress.kubernetes.io/canary-by-header-value: "new"  # 指定HTTP头部的值为"new"时，请求会被路由到新版本服务
spec:
  ingressClassName: nginx  # 指定使用的Ingress控制器类型
  rules:
  - host: nginx.shuyan.com  # 设置主机名，所有请求都会被转发到这个域名下的服务
    http:
      paths:
      - backend:
          service:
            name: svc-nginx-v2  # 指定后端服务的名字
            port:
              number: 80  # 指定后端服务监听的端口
        path: /  # 所有访问根路径的请求都会被转发到此服务
        pathType: Prefix  # 路径类型为前缀，表示所有以"/"开头的请求都将被转发到此服务

3.3.3 关于配置文件的解释：


第一个Ingress (canary-cookie-old)：

  • 这个Ingress没有使用任何灰度发布的注解。
  • 它将处理所有发往 nginx.shuyan.com 的请求，并将这些请求路由到名为 svc-nginx-v1 的服务上。

第二个Ingress (canary-cookie-new)：

  • 使用了灰度发布的注解 nginx.ingress.kubernetes.io/canary: "true" 来开启灰度发布模式。
  • 使用 nginx.ingress.kubernetes.io/canary-by-header: "canary" 来指定使用HTTP头部来区分流量。
  • 使用 nginx.ingress.kubernetes.io/canary-by-header-value: "new" 来指定HTTP头部的值为 "new" 时，请求会被路由到新版本服务 svc-nginx-v2。

工作原理：

  • 当客户端请求包含头部 canary: new 时，请求将会被路由到 svc-nginx-v2。
  • 如果客户端请求不包含头部 canary: new，请求将会被路由到 svc-nginx-v1。

3.3.4 声明 Igress 文件

[root@k8s-master Cannary]# kubectl apply -f canary-cookie.yml 
ingress.networking.k8s.io/canary-cookie-old created
ingress.networking.k8s.io/canary-cookie-new created

# 查看是否正常创建
[root@k8s-master Cannary]# kubectl get ingress
NAME                CLASS   HOSTS              ADDRESS           PORTS   AGE
canary-cookie-new   nginx   nginx.shuyan.com   192.168.239.241   80      53s
canary-cookie-old   nginx   nginx.shuyan.com   192.168.239.241   80      53s


[root@k8s-master Cannary]# kubectl describe ingress 
Name:             canary-cookie-new
Labels:           <none>
Namespace:        default
Address:          192.168.239.241
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host              Path  Backends
  ----              ----  --------
  nginx.shuyan.com  
                    /   svc-nginx-v2:80 (10.244.1.35:80)
Annotations:        nginx.ingress.kubernetes.io/canary: true
                    nginx.ingress.kubernetes.io/canary-header: canary
                    nginx.ingress.kubernetes.io/canary-header-value: new
Events:
  Type    Reason  Age                    From                      Message
  ----    ------  ----                   ----                      -------
  Normal  Sync    7m37s (x2 over 8m18s)  nginx-ingress-controller  Scheduled for sync


Name:             canary-cookie-old
Labels:           <none>
Namespace:        default
Address:          192.168.239.241
Ingress Class:    nginx
Default backend:  <default>
Rules:
  Host              Path  Backends
  ----              ----  --------
  nginx.shuyan.com  
                    /   svc-nginx-v1:80 (10.244.2.54:80)
Annotations:        <none>
Events:
  Type    Reason  Age                    From                      Message
  ----    ------  ----                   ----                      -------
  Normal  Sync    7m37s (x2 over 8m19s)  nginx-ingress-controller  Scheduled for sync

3.3.5 客户端进行测试

# 客户端添加解析
[root@harbor ~]# vim /etc/hosts
192.168.239.241  nginx.shuyan.com

# 没带 cookie 值的就会被访问到 v1 去
[root@harbor ~]# curl -s  nginx.shuyan.com
this is nginx-v1 10.244.2.54

# 带 cookie 值的就会访问到 v2 去
[root@harbor ~]# curl -s  -H "canary: new" nginx.shuyan.com
this is nginx-v2 10.244.1.35

妍妍的宝贝
关注
专栏目录
基于K8S的灰度发布实践
叱咤少帅的博客
06-29 948
基于K8S的灰度发布实践
在微服务中如何实现全链路的金丝雀发布？
xaiobit_hl的博客
12-28 1668
在微服务中如何实现全链路的灰色发布？
使用k8s实现灰度发布，金丝雀，蓝绿发布
robinhunan的博客
01-17 1879
Nginx Ingress Controller 实现了项目的网关，作为项目对外的流量入口和项目中各个服务的反向代理。而 Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的灰度发布和测试，可以满足金丝雀发布、蓝绿部署与 A/B 测试等业务场景。
K8S的金丝雀发布（Canary Release）
Riky12的博客
09-12 380
金丝雀发布的声明式管理方法：create/apply 两个的区别：当yaml配置文件发送改动后，使用以下两个更新的过程：create：是一次性的，先delete删除原有的资源再通过yaml’文件再创建。nginx-wang。
K8s（8）——金丝雀发布
m0_46652469的博客
04-09 255
好处在能够对架构内每个服务进行拆分管理，如lnmp架构内，将php，ngnix拆出来，分别根据实际情况进行扩缩容，进行流量拆分管理。canary-weight，30%，50%，100%，一点一点把流量到v2，直到把流量全部切换到v2。创建灰度ingress，配置灰度权重以及总权重灰度流量验证完毕后，切换正式ingress到新版本。加了key - v键值的header后，访问到了v2，将新版本局限到一定范围内。- path: /order/(.*)#如果出现order，定向到v2。不同域名定向到不同服务。
k8s-金丝雀发布
野猫的home
08-06 1052
k8s、灰度、金丝雀、流量切换
K8S 金丝雀发布（Canary Release）- 声明式
m69zhuang的博客
09-13 518
金丝雀发布的声明式管理方法create/apply 两个的区别：当yaml配置文件发送改动后，使用以下两个更新的过程是一次性的，先delete删除原有的资源再通过yaml’文件再创建。创建资源没办法更新的，如果想更新，可以直接再执行kubectl apply -f 更新或先修改在删除，最后再创建更新。
K8S 进阶 -3 (金丝雀发布、滚动更新、蓝绿部署)
Bolg of EQuaker
12-04 1296
写在前面： 金丝雀发布（又称灰度发布、灰度更新）： 金丝雀发布一般是先发1台机器，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试，国内常称灰度测试。以前旷工下矿前，会先放一只金丝雀进去用于探测洞里是否有有毒气体，看金丝雀能否活下来，金丝雀发布由此得名。简单的金丝雀测试一般通过手工测试验证，复杂的金丝雀测试需要比较完善的监控基础设施配合，通过监控指标反馈，观察金丝雀的健康状况，作为后续发布或回退的依据。如果金丝测试通过，则把剩余的 V1 版本全部升级为 V2 版本
【K8s】¹版本回退升级&金丝雀发布
yshisu的博客
07-24 1316
k8s的版本回滚升级及金丝雀发布
灰度发布、蓝绿部署、金丝雀都是啥？
m0_38017860的博客
04-19 7090
目录 滚动部署 蓝绿发布 为什么还需要蓝绿 金丝雀发布（canary） 金丝雀和蓝绿的对比 灰度发布 A/B Test 实现 kubernetes istio spring cloud 网关 参考 滚动部署 在滚动部署中，应用的新版本逐步替换旧版本。实际的部署发生在一段时间内。在此期间，新旧版本会共存，而不会影响功能和用户体验。这个过程可以更轻易的回滚和旧组件不兼容的任何新组件。 下图显示了该部署模式：旧版本显示为蓝色，新版本显示为绿色，它们部署在集群中的每一台
k8s灰度/金丝雀发布
最新发布
henanchenxuyuan的博客
09-06 1037
灰度及蓝绿发布是为新版本服务创建一个与老版本服务完全一致的生产环境，在不影老版本服务的前提下，按照一定的规则把部分流量切换到新版本，当新版本试运行一段时间没有问题后，将用户的全量流量从老版本迁移至新版本。灰度发布的方式通常用于AB测试，是指一部分用户继续使用老版本的服务，将一部分用户的流量切换到新版本，如果新版本运行稳定，则逐步将所有用户迁移到新版本。金丝雀发布是指在生产环境中逐步推出新版本应用程序，只在一小部分用户或流量中使用该版本，并根据反馈逐步扩大规模，最终完全替换旧版本。
K8S之实现业务的金丝雀发布
weixin_40364776的博客
03-07 853
金丝雀发布的由来：17 世纪，英国矿井工人发现，金丝雀对瓦斯这种气体十分敏感。空气中哪怕有极其微量的瓦斯，金丝雀也会停止歌唱；当瓦斯含量超过一定限度时，虽然人类毫无察觉，金丝雀却早已毒发身亡。当时在采矿设备相对简陋的条件下，工人们每次下井都会带上一只金丝雀作为瓦斯检测指标，以便在危险状况下紧急撤离。金丝雀发布（又称灰度发布、灰度更新）：一般先发1台，或者一个小比例，例如2%的服务器，主要做流量验证用，也称为金丝雀 (Canary) 测试 （国内常称灰度测试）。
Kubernetes (八) 金丝雀发布
BJZX_OL的博客
01-09 748
一. 金丝雀发布作用：金丝雀发布是指在生产环境中逐步推出新版本应用程序，只在一小部分用户或流量中使用该版本，并根据反馈逐步扩大规模，最终完全替换旧版本。金丝雀发布允许快速检测新版本与旧版本之间是否存在兼容性问题、性能问题或其他问题，并减轻了在实施全新发布时可能遭受的损失二. 官网地址:三. 基于Header灰度实验测试实验前： 删除之前创建的pod svc等资源创建正常接受流量的svc v1版本创建接收带有header流量的svc v2版本查看svc是否正常。
k8s 金丝雀发布 (灰度)
weixin_43929657的博客
05-07 544
背景 线上发布，如果直接将预发或者测试环境的jar或war包发布到线上，如果出现问题，那么就会出现大面积瘫痪，无法正常使用 引入金丝雀发布，先优先发布一台，或者比例较小。主要用来流量验证，如果通过，那么可以快速将其他版本全部更新，失败的话，则回退，只影响小部分用户。 优缺点 优点： 用户体验影响小，发布只影响少部分用户 缺点： 自动化流程不够，发布期间需要人为去操作，可能会引起服务中断等 实战 1、快速构建 deployment、 service 查看namespace为demo下所有资源 kubect
k8s控制器之Deployment第八弹之金丝雀发布（灰度发布）
linus.lin的博客
05-29 935
在 Kubernetes 中不能解决上述局限性的原因是：Kubernetes Service 只在 TCP 层面解决负载均衡的问题，并不对请求响应的消息内容做任何解析和识别。如果您想使用 Deployment 将最新的应用程序版本发布给一部分用户（或服务器），您可以为每个版本创建一个 Deployment，此时，应用程序的新旧两个版本都可以同时获得生产上的流量。第一个版本的 Deployment 包含了 3 个Pod副本，Service 通过 label selector。
使用k8s-ingress进行金丝雀发布
u011830181的博客
03-15 1755
k8s上进行金丝雀发布
k8s之istio实现金丝雀发布(1)
jiayu的博客
04-25 1060
灰度发布也叫金丝雀部署，是指通过控制流量的比例，实现新老版本的逐步更替。比如对于服务 A 有 version1 、 version2 两个版本 当前两个版本同时部署，但是 version1 比例90% version2 比例 10% ，看运行效果，如果效果好逐步调整流量占比 80 20 7030 ·····10 90 0 100 ，最终 version1 版本下线
K8S灰度发布
Ben的博客
07-12 5930
K8S灰度发布
k8s ingress实现灰度发布
07-27
Kubernetes Ingress-Nginx是一个用于管理Kubernetes集群中的Ingress资源的工具。它支持使用Ingress Annotations来实现不同场景下的灰度发布和测试。其中，Nginx Annotations支持基于Cookie的切分流量来实现灰度发布。具体实现方式是通过判断用户请求中的Cookie是否存在灰度标识Cookie来确定是否为灰度用户，从而决定是否返回灰度版本的服务。 在配置中，可以使用以下Annotations来实现灰度发布： - `nginx.ingress.kubernetes.io/canary`：可选值为true/false，表示是否开启灰度功能。 - `nginx.ingress.kubernetes.io/canary-by-cookie`：灰度发布Cookie的键。当键的值等于"always"时，灰度触发生效；其他值则不会走灰度环境。 例如，如果请求的Cookie中包含名为"vip_user"的键，并且值为"always"，则会生效灰度配置，访问灰度版本的服务。 要实际执行灰度发布配置，可以使用以下命令： ``` kubectl apply -f ingress-gray.yaml ``` 如果想查看服务并获取Ingress的外部端口，可以使用以下命令： ``` kubectl -n ingress-nginx get service ``` 这将显示Ingress-Nginx控制器的服务信息，包括集群IP、外部IP和端口等。 #### 引用[.reference_title] - *1* [【云原生 | Kubernetes 实战】20、K8s Ingress 实现业务灰度发布](https://blog.csdn.net/weixin_46560589/article/details/128505651)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item] - *2* *3* [【Kubernetes】第十篇 - 灰度发布的介绍与实现](https://blog.csdn.net/ABAP_Brave/article/details/129220116)[target="_blank" data-report-click={"spm":"1018.2226.3001.9630","extra":{"utm_source":"vip_chatgpt_common_search_pc_result","utm_medium":"distribute.pc_search_result.none-task-cask-2~all~insert_cask~default-1-null.142^v91^insert_down1,239^v3^insert_chatgpt"}} ] [.reference_item] [ .reference_list ]
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

打赏作者

妍妍的宝贝

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

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

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

打赏作者

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

抵扣说明：

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

余额充值