目录一.灰度发布策略二.金丝雀发布策略2.1简单介绍2.2创建金丝雀发布策略2.2.1工作流程2.2.2第一个版本2.2.2第二个版本新版本2.3测试2.4版本回退三.AB测试灰度发布策略3.1简单介绍3.2基于header的流量切分3.2.1创建header规则3.2.2运行Ingress规则并测试3.3基于Cookie的流量切分3.3.1创建Ingress规则3.3.2运行Ingress规则并测试一.灰度发布策略概念在KubernetesK8s集群中灰度发布是一种通过逐步将流量从旧版本切换到新版本以降低发布风险的核心策略。其核心目标是让新版本先接受小范围真实流量的检验在确认稳定后再逐步扩大范围实现“风险可控”的上线。二.金丝雀发布策略2.1简单介绍1.概念指先将集群中的一部分流量引入到新版本中剩余部分流量仍然在旧版本中运行。等新版本稳定后再次将另一部分流量引入到新版本中直至流量全部流入新版本当中。如果流量在新版本中出现错误可以立即回滚到旧版本中不用担心故障无法恢复的情况。2.核心特征1.部分流量先行先放行一部分流量进入到新版本中剩余的流量依然在旧版本中。2.观察验证观察新版本中是否出现异常等待新版本流量稳定。3.版本依次迭代可以使用多种迁移策略如均等迁移每次迁移20%逐步扩大先是1%接着10% ,后面30%。3.优点按比例将流量无差别地导向新版本新版本故障影响范围小发布期间逐步对新版本扩容同时对老版本缩容资源利用率高。4.缺点流量无差别地导向新版本可能会影响重要用户的体验发布周期长。2.2创建金丝雀发布策略2.2.1工作流程概念创建两个Ingress分别对应两个不同的Service。新版本的Ingress按照策略定义的流量权重将旧版本的流量转移到新版本的Ingress上运行。2.2.2第一个版本vim ingress-canary-v1.yml #第一个版本添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-canary-v1 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v1 port: number: 80运行旧版本将流量全部放到旧版本上kubectl apply -f ingress-canary-v1.yml kubectl get ingress2.2.2第二个版本新版本vim ingress-canary-v2.yml #第二个版本添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-canary-v2 annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀发布策略 nginx.ingress.kubernetes.io/canary-weight: 10 #新版本流量的权重 nginx.ingress.kubernetes.io/canary-weight-total: 100 #流量总权重 10/10010% spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 80运行新版本的Ingress将旧版本的10%的流量转移到新版本上测试,流量稳定后继续执行直到流量全部转移kubectl apply -f ingress-canary-v2.yml kubectl get ingress2.3测试1.创建域名解析vim /etc/hosts添加解析192.168.7.101 myapp.example.com2.编写.sh脚本vim ingress-canary.sh添加以下内容v10 v20 for (( i0; i100; i)) #循环一百次 do responsecurl -s myapp.example.com |grep -c v1 v1expr $v1 $response #检测到v1版本次数加1 v2expr $v2 1 - $response #没检测到v1版本v2次数加1 done echo v1:$v1, v2:$v2 #输出一百次中访问v1,v2的次数3.运行脚本chmod x ingress-canary.sh #添加执行权限 ./ingress-canary.sh流量转移约10%2.4版本回退主要有两种方式修改新版本的流量权重为0和删除新版本的Ingress注意该方法适合在更新的过程中使用。方法一修改新版本的流量权重为0vim ingress-canary-v2修改以下内容nginx.ingress.kubernetes.io/canary-weight: false #关闭流量转发运行Ingress:kubectl apply -f ingress-canary-v2.yml ./ingress-canary.sh方法二删除Ingresskubectl delete -f ingress-canary-v2.yml ./ingress-canary.sh三.AB测试灰度发布策略3.1简单介绍1.概述根据业务head,cookie的不同将用户随机分为A,B两组A组用旧版本B组用新版本对比两组的关键业务指标用数据决定哪个版本更好。2.工作流程它基于用户请求的元信息将流量路由到新版本这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本。3.2基于header的流量切分1.header请求响应头htttp协议中客户端和服务器在传输真正数据之前附加的一段说明信息。它不包含页面内容本身而是告诉对方这个请求/响应是什么、该怎么处理。3.2.1创建header规则说明只有访问中带有stage请求头与其对应的请求值 gray才能够进入ingress-ab-header规则vim ingress-ab-header.yml #编写规则添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-ab-header annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀规则 nginx.ingress.kubernetes.io/canary-by-header: stage #请求头 nginx.ingress.kubernetes.io/canary-by-header-value: gray #指定匹配值 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 803.2.2运行Ingress规则并测试kubectl apply -f ingress-ab-header.ymlcurl myapp.example.com curl -H stage:gray myapp.example.com #指定访问的请求头3.3基于Cookie的流量切分说明Cookie是由浏览器保存并在后续请求中自动带回的一小段数据通常用来存储用户访问的证书压迫等信息。3.3.1创建Ingress规则vim ingress-ab-cookie.yml添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-ab-cookie annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀规则 nginx.ingress.kubernetes.io/canary-by-cookie: user_from_sz #匹配cookie规则 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 803.3.2运行Ingress规则并测试kubectl apply -f ingress-ab-cookie.yml kubectl get ingresscurl myapp.example.com curl --cookie user_from_bjalways myapp.example.com curl --cookie user_from_szalways myapp.example.com 
长河君 · 2026/10/9 5:41:11 · 阅读 1.2k kubernetes集群——灰度发布
目录一.灰度发布策略二.金丝雀发布策略2.1简单介绍2.2创建金丝雀发布策略2.2.1工作流程2.2.2第一个版本2.2.2第二个版本新版本2.3测试2.4版本回退三.AB测试灰度发布策略3.1简单介绍3.2基于header的流量切分3.2.1创建header规则3.2.2运行Ingress规则并测试3.3基于Cookie的流量切分3.3.1创建Ingress规则3.3.2运行Ingress规则并测试一.灰度发布策略概念在KubernetesK8s集群中灰度发布是一种通过逐步将流量从旧版本切换到新版本以降低发布风险的核心策略。其核心目标是让新版本先接受小范围真实流量的检验在确认稳定后再逐步扩大范围实现“风险可控”的上线。二.金丝雀发布策略2.1简单介绍1.概念指先将集群中的一部分流量引入到新版本中剩余部分流量仍然在旧版本中运行。等新版本稳定后再次将另一部分流量引入到新版本中直至流量全部流入新版本当中。如果流量在新版本中出现错误可以立即回滚到旧版本中不用担心故障无法恢复的情况。2.核心特征1.部分流量先行先放行一部分流量进入到新版本中剩余的流量依然在旧版本中。2.观察验证观察新版本中是否出现异常等待新版本流量稳定。3.版本依次迭代可以使用多种迁移策略如均等迁移每次迁移20%逐步扩大先是1%接着10% ,后面30%。3.优点按比例将流量无差别地导向新版本新版本故障影响范围小发布期间逐步对新版本扩容同时对老版本缩容资源利用率高。4.缺点流量无差别地导向新版本可能会影响重要用户的体验发布周期长。2.2创建金丝雀发布策略2.2.1工作流程概念创建两个Ingress分别对应两个不同的Service。新版本的Ingress按照策略定义的流量权重将旧版本的流量转移到新版本的Ingress上运行。2.2.2第一个版本vim ingress-canary-v1.yml #第一个版本添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-canary-v1 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v1 port: number: 80运行旧版本将流量全部放到旧版本上kubectl apply -f ingress-canary-v1.yml kubectl get ingress2.2.2第二个版本新版本vim ingress-canary-v2.yml #第二个版本添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-canary-v2 annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀发布策略 nginx.ingress.kubernetes.io/canary-weight: 10 #新版本流量的权重 nginx.ingress.kubernetes.io/canary-weight-total: 100 #流量总权重 10/10010% spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 80运行新版本的Ingress将旧版本的10%的流量转移到新版本上测试,流量稳定后继续执行直到流量全部转移kubectl apply -f ingress-canary-v2.yml kubectl get ingress2.3测试1.创建域名解析vim /etc/hosts添加解析192.168.7.101 myapp.example.com2.编写.sh脚本vim ingress-canary.sh添加以下内容v10 v20 for (( i0; i100; i)) #循环一百次 do responsecurl -s myapp.example.com |grep -c v1 v1expr $v1 $response #检测到v1版本次数加1 v2expr $v2 1 - $response #没检测到v1版本v2次数加1 done echo v1:$v1, v2:$v2 #输出一百次中访问v1,v2的次数3.运行脚本chmod x ingress-canary.sh #添加执行权限 ./ingress-canary.sh流量转移约10%2.4版本回退主要有两种方式修改新版本的流量权重为0和删除新版本的Ingress注意该方法适合在更新的过程中使用。方法一修改新版本的流量权重为0vim ingress-canary-v2修改以下内容nginx.ingress.kubernetes.io/canary-weight: false #关闭流量转发运行Ingress:kubectl apply -f ingress-canary-v2.yml ./ingress-canary.sh方法二删除Ingresskubectl delete -f ingress-canary-v2.yml ./ingress-canary.sh三.AB测试灰度发布策略3.1简单介绍1.概述根据业务head,cookie的不同将用户随机分为A,B两组A组用旧版本B组用新版本对比两组的关键业务指标用数据决定哪个版本更好。2.工作流程它基于用户请求的元信息将流量路由到新版本这是一种基于请求内容匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本。3.2基于header的流量切分1.header请求响应头htttp协议中客户端和服务器在传输真正数据之前附加的一段说明信息。它不包含页面内容本身而是告诉对方这个请求/响应是什么、该怎么处理。3.2.1创建header规则说明只有访问中带有stage请求头与其对应的请求值 gray才能够进入ingress-ab-header规则vim ingress-ab-header.yml #编写规则添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-ab-header annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀规则 nginx.ingress.kubernetes.io/canary-by-header: stage #请求头 nginx.ingress.kubernetes.io/canary-by-header-value: gray #指定匹配值 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 803.2.2运行Ingress规则并测试kubectl apply -f ingress-ab-header.ymlcurl myapp.example.com curl -H stage:gray myapp.example.com #指定访问的请求头3.3基于Cookie的流量切分说明Cookie是由浏览器保存并在后续请求中自动带回的一小段数据通常用来存储用户访问的证书压迫等信息。3.3.1创建Ingress规则vim ingress-ab-cookie.yml添加以下内容apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: ingress-ab-cookie annotations: nginx.ingress.kubernetes.io/canary: true #开启金丝雀规则 nginx.ingress.kubernetes.io/canary-by-cookie: user_from_sz #匹配cookie规则 spec: ingressClassName: nginx rules: - host: myapp.example.com http: paths: - pathType: Prefix path: / backend: service: name: web-v2 port: number: 803.3.2运行Ingress规则并测试kubectl apply -f ingress-ab-cookie.yml kubectl get ingresscurl myapp.example.com curl --cookie user_from_bjalways myapp.example.com curl --cookie user_from_szalways myapp.example.com