kubernetes集群——灰度发布

一.灰度发布策略

二.金丝雀发布策略

2.1简单介绍

2.2创建金丝雀发布策略

一.灰度发布策略

概念：在Kubernetes（K8s）集群中，灰度发布是一种通过逐步将流量从旧版本切换到新版本 ，以降低发布风险的核心策略。其核心目标是让新版本先接受小范围真实流量的检验，在确认稳定后再逐步扩大范围，实现"风险可控"的上线。

二.金丝雀发布策略

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第一个版本

bash 复制代码

vim ingress-canary-v1.yml    #第一个版本

添加以下内容：

bash 复制代码

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

运行旧版本，将流量全部放到旧版本上：

bash 复制代码

kubectl apply -f ingress-canary-v1.yml
kubectl get ingress

2.2.2第二个版本（新版本）

bash 复制代码

vim ingress-canary-v2.yml    #第二个版本

添加以下内容：

bash 复制代码

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/100=10%
spec:
  ingressClassName: nginx
  rules:
  - host: myapp.example.com
    http:
      paths:
      - pathType: Prefix
        path: /
        backend:
          service:
            name: web-v2
            port:
              number: 80

运行新版本的Ingress，将旧版本的10%的流量转移到新版本上测试,流量稳定后，继续执行，直到流量全部转移：

bash 复制代码

kubectl apply -f ingress-canary-v2.yml
kubectl get ingress

2.3测试

1.创建域名解析

bash 复制代码

vim /etc/hosts

添加解析：

bash 复制代码

192.168.7.101 myapp.example.com

2.编写.sh脚本

bash 复制代码

vim ingress-canary.sh

添加以下内容：

bash 复制代码

v1=0
v2=0

for (( i=0; i<100; i++))    #循环一百次
do
    response=`curl -s myapp.example.com |grep -c v1`
    v1=`expr $v1 + $response`    #检测到v1版本，次数加1
    v2=`expr $v2 + 1 - $response`    #没检测到v1版本，v2次数加1

done

echo "v1:$v1, v2:$v2"    #输出一百次中，访问v1,v2的次数

3.运行脚本：

bash 复制代码

chmod +x ingress-canary.sh    #添加执行权限
./ingress-canary.sh

流量转移约10%：

2.4版本回退

主要有两种方式：修改新版本的流量权重为0 和删除新版本的Ingress

注意：该方法适合在更新的过程中使用。

方法一 ：修改新版本的流量权重为0

bash 复制代码

vim ingress-canary-v2

修改以下内容：

bash 复制代码

nginx.ingress.kubernetes.io/canary-weight: "false"    #关闭流量转发

运行Ingress:

bash 复制代码

kubectl apply -f ingress-canary-v2.yml
./ingress-canary.sh

方法二：删除Ingress

bash 复制代码

kubectl delete -f ingress-canary-v2.yml
./ingress-canary.sh

三.AB测试灰度发布策略

3.1简单介绍

1.概述： 根据业务（head,cookie）的不同，**将用户随机分为A,B两组，A组用旧版本，B组用新版本，**对比两组的关键业务指标，用数据决定哪个版本更好。

2.工作流程 ：它基于用户请求的元信息将流量路由到新版本，这是一种基于请求内容****匹配的灰度发布策略。只有匹配特定规则的请求才会被引流到新版本。

1.header ：请求响应头，htttp协议中，客户端和服务器在传输真正数据之前，附加的一段"说明信息"。它不包含页面内容本身，而是告诉对方"这个请求/响应是什么、该怎么处理"。

说明：只有访问中带有stage请求头，与其对应的请求值 gray才能够进入ingress-ab-header规则

bash 复制代码

vim ingress-ab-header.yml    #编写规则

添加以下内容：

bash 复制代码

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: 80

3.2.2运行Ingress规则并测试

bash 复制代码

kubectl apply -f ingress-ab-header.yml

bash 复制代码

curl myapp.example.com
curl -H "stage:gray" myapp.example.com    #指定访问的请求头

3.3基于Cookie的流量切分

说明：Cookie是由浏览器保存并在后续请求中自动带回的一小段数据，通常用来存储用户访问的证书，压迫等信息。

3.3.1创建Ingress规则

bash 复制代码

vim ingress-ab-cookie.yml

添加以下内容：

bash 复制代码

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: 80

3.3.2运行Ingress规则并测试

bash 复制代码

kubectl apply -f ingress-ab-cookie.yml
kubectl get ingress

bash 复制代码

curl myapp.example.com
curl --cookie "user_from_bj=always" myapp.example.com
curl --cookie "user_from_sz=always" myapp.example.com