实现应用灰度发布

概述

参考：
原文链接：公众号-运维开发故事，如何通过 ingress-nginx 实现应用灰度发布？

在日常的工作中，我们会经常对应用进行发版升级，在互联网公司尤为频繁，主要是为了满足快速的业务发展。我们经常用到的发布方式有滚动更新、蓝绿发布、灰度发布。

滚动更新：依次进行新旧替换，直到旧的全部被替换为止。
蓝绿发布：两套独立的系统，对外提供服务的称为绿系统，待上线的服务称为蓝系统，当蓝系统里面的应用测试完成后，用户流量接入蓝系统，蓝系统将称为绿系统，以前的绿系统就可以销毁。
灰度发布：在一套集群中存在稳定和灰度两个版本，灰度版本可以限制只针对部分人员可用，待灰度版本测试完成后，可以将灰度版本升级为稳定版本，旧的稳定版本就可以下线了，我们也称之为金丝雀发布。

这里主要给大家分享如果通过 ingress-nginx controller 实现灰度发布。

本文大纲如下。

如何通过 ingress-nginx 实现灰度发布

ingress-nginx 是 Kubernetes 官方推荐的 ingress controller，它是基于 nginx 实现的，增加了一组用于实现额外功能的 Lua 插件。

为了实现灰度发布，ingress-nginx 通过定义 annotation 来实现不同场景的灰度发布，其支持的规则如下：

nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，适用于灰度发布以及 A/B 测试。当 Request Header 设置为 always时，请求将会被一直发送到 Canary 版本；当 Request Header 设置为 never时，请求不会被发送到 Canary 入口；对于任何其他 Header 值，将忽略 Header，并通过优先级将请求与其他金丝雀规则进行优先级的比较。
nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务。当 Request Header 设置为此值时，它将被路由到 Canary 入口。该规则允许用户自定义 Request Header 的值，必须与上一个 annotation (即：canary-by-header）一起使用。
nginx.ingress.kubernetes.io/canary-weight：基于服务权重的流量切分，适用于蓝绿部署，权重范围 0 - 100 按百分比将请求路由到 Canary Ingress 中指定的服务。权重为 0 意味着该金丝雀规则不会向 Canary 入口的服务发送任何请求。权重为 100 意味着所有请求都将被发送到 Canary 入口。
nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，适用于灰度发布与 A/B 测试。用于通知 Ingress 将请求路由到 Canary Ingress 中指定的服务的 cookie。当 cookie 值设置为 always时，它将被路由到 Canary 入口；当 cookie 值设置为 never时，请求不会被发送到 Canary 入口；对于任何其他值，将忽略 cookie 并将请求与其他金丝雀规则进行优先级的比较。

我们也是通过上面的 annotation 来实现灰度发布，其思路如下：

在集群中部署两套系统，一套是 stable 版本，一套是 canary 版本，两个版本都有自己的 service
定义两个 ingress 配置，一个正常提供服务，一个增加 canary 的 annotation
待 canary 版本无误后，将其切换成 stable 版本，并且将旧的版本下线，流量全部接入新的 stable 版本

发布场景介绍

上面介绍了 ingress-nginx 实现灰度发布的方法以及咱们自己的实现思路，这里来探讨一下灰度发布有哪些发布场景。

基于权重的发布场景

假如在生产上已经运行了 A 应用对外提供服务，此时开发修复了一些 Bug，需要发布 A2 版本将其上线，但是我们又不希望直接的将所有流量接入到新的 A2 版本，而是希望将 10%的流量进入到 A2 中，待 A2 稳定后，才会将所有流量接入进来，再下线原来的 A 版本。要实现这种，只需要在 canary 的 ingress 中添加如下 annotation。

nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-weight: "10"

其中nginx.ingress.kubernetes.io/canary表示开启 canary，nginx.ingress.kubernetes.io/canary-weight表示我们设置的权重大小。

基于用户请求的发布场景

基于权重的发布场景比较粗糙，它是所有用户中的 20%，无法限制具体的用户。

我们有时候会有这样的需求，比如我们有广东、北京、四川这三个地区的用户，并且已经有 A 版本的应用为这三个地区提供服务，由于更新了需求，我们需要发布 A2 应用，但是我们不想所有地区都访问 A2 应用，而是希望只有四川的用户可以访问，待四川地区反馈没问题后，才开放其他地区。对于这种我们需要在 canary 的 ingress 中添加如下 annotation。

nginx.ingress.kubernetes.io/canary: "true"
nginx.ingress.kubernetes.io/canary-by-header: "region"
nginx.ingress.kubernetes.io/canary-by-header-value: "sichuan"

主要就是上面两种发布场景，下面会针对这两种场景分别进行实验。

灰度发布具体实现

我这里准备了两个镜像，一个是稳定 stable 版本，一个是灰度 canary 版本。

registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v1
registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v2

由于两个场景只有在 ingress 处的配置不一致，其他都一样的，所以这里先将两个版本的应用都部署好。

（1）stable 版本

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-server-stable
spec:
  selector:
    matchLabels:
      app: go-test
      version: stable
  replicas: 1
  template:
    metadata:
      labels:
        app: go-test
        version: stable
    spec:
      containers:
        - name: app-server
          image: registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v1
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: app-server-stable-svc
spec:
  selector:
    app: go-test
    version: stable
  ports:
    - name: http
      port: 8080

访问效果如下：

# curl 10.97.112.137:8080
{"data":"hello world","version":"v1"}

（2）canary 版本

apiVersion: apps/v1
kind: Deployment
metadata:
  name: app-server-canary
spec:
  selector:
    matchLabels:
      app: go-test
      version: canary
  replicas: 1
  template:
    metadata:
      labels:
        app: go-test
        version: canary
    spec:
      containers:
        - name: app-server
          image: registry.cn-hangzhou.aliyuncs.com/rookieops/go-test:v2
          imagePullPolicy: IfNotPresent
          ports:
            - name: http
              containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: app-server-canary-svc
spec:
  selector:
    app: go-test
    version: canary
  ports:
    - name: http
      port: 8080

访问效果如下：

# curl 10.110.178.174:8080
{"data":"hello SB","version":"v2"}

上面已经将应用部署好了，下面将针对权重和用户请求两个场景进行测试。

基于权重的发布场景

（1）配置 stable 版本的 ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app-server-stable-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
    - host: joker.coolops.cn
      http:
        paths:
          - path:
            backend:
              serviceName: app-server-stable-svc
              servicePort: 8080

（2）配置 canary 版本的 ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app-server-canary-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
spec:
  rules:
    - host: joker.coolops.cn
      http:
        paths:
          - path:
            backend:
              serviceName: app-server-canary-svc
              servicePort: 8080

然后我们通过访问测试，效果如下：

# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello SB","version":"v2"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}

基本保持在9:1的比例。

基于用户请求的发布场景

（1）配置 stable 版本的 ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app-server-stable-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
spec:
  rules:
  - host: joker.coolops.cn
    http:
      paths:
      - path:
        backend:
          serviceName: app-server-stable-svc
          servicePort: 8080

（2）配置 canary 版本的 ingress

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: app-server-canary-ingress
  annotations:
    kubernetes.io/ingress.class: "nginx"
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-by-header: "region"
    nginx.ingress.kubernetes.io/canary-by-header-value: "sichuan"
spec:
  rules:
  - host: joker.coolops.cn
    http:
      paths:
      - path:
        backend:
          serviceName: app-server-canary-svc
          servicePort: 8080

当我们访问的时候不带 header，则只会访问 stable 版本应用，如下：

# curl joker.coolops.cn
{"data":"hello world","version":"v1"}
# curl joker.coolops.cn
{"data":"hello world","version":"v1"}

如果我们在访问的时候带上region: sichuan 的 header，则只会访问到 canary 版本应用，如下：

# curl joker.coolops.cn -H "region: sichuan"
{"data":"hello SB","version":"v2"}
# curl joker.coolops.cn -H "region: sichuan"
{"data":"hello SB","version":"v2"}

实现是不是很简单？

我们现在来想另外一个问题，上面的所有操作都是手动的，我们应该如何进行自动化？应该怎样来设计流水线？

下面来说说我个人的想法。

关于灰度发布流水线设计的想法

首先来捋捋过程：

发布 canary 版本应用进行测试
测试完成将 canary 版本替换成 stable 版本
删除 canary 版本的 ingress 配置
删除老的 stable 版本

整个过程很简单，但是对于已经部署好的deployment是不允许直接修改labels标签的。这时候是不是可以在 canary 版本测试 i 完成后直接更新 stable 版本的镜像？当然这种情况会存在滚动更新的一个过程。

那我们流水线可以这样设计，如下：

这样设计存在一个问题，那就是无法确定等待的时间，如果等待的时间很长，不仅很耗资源，也可能自动超时退出。

那我们是不是可以将其拆分为两条流水线？流程如下：

我比较倾向第二种，这种方式流水线跑完了就退出，不会占用额外的资源。

在开发流水线之前，我们需要先定义好命名标准，这样在操作的时候更加方便。

流水线名字格式如下：
<APP_NAME>-stable
<APP_NAME>-canary
deployment 的名字格式如下：
<APP_NAME>-stable
<APP_NAME>-canary
service 的名字格式如下：
<APP_NAME>-stable-svc
<APP_NAME>-canary-svc
ingress 的名字格式如下：
<APP_NAME>-stable-ingress
<APP_NAME>-canary-ingress

标准定义好之后，在实现的时候就简单多了。

代码位置：https://gitee.com/coolops/gary-devops.git

我定义了两个 Jenkinsfile，一个叫 canary.Jenkinsfile，一个叫 stable.Jenkinsfile，他们分别用来部署 canary 和 stable 版本。

然后我们会创建两条流水线，如下：其中joker-gary-devops-canary是用来部署 canary 版本，另外一个是用来部署 stable 版本。

现在在集群里运行着 stable 版本，如下：

# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}

我们修改了需求，更改了代码，变动如下：

package main

import (
 "net/http"

 "github.com/gin-gonic/gin"
)

func main() {
 g := gin.Default()
 g.GET("/", func(c *gin.Context) {
  c.JSON(http.StatusOK, gin.H{
   "version": "v1",
   "data":    "hello Joker!",
  })

 })
 _ = g.Run(":8080")
}

首先发布 canary 流水线，待流水线发布完成，可以在集群中看到 canary 版本的 pod 以及 ingress 等，如下：

# kubectl get po| grep canary
gray-devops-canary-59c88846dc-j2vlc   1/1     Running   0          55s
# kubectl get svc| grep canary
gray-devops-canary-svc   ClusterIP   10.233.18.235   <none>        8080/TCP            3h14m
# kubectl get ingress| grep canary
gray-devops-canary-ingress   joker.coolops.cn                               192.168.100.61   80        63s

查看一下 canary-ingress 的内容，看是否是我们需要的，如下：

# kubectl get ingress gray-devops-canary-ingress -o yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"
  creationTimestamp: "2022-02-15T05:43:32Z"
  generation: 1
  name: gray-devops-canary-ingress
  namespace: default
  resourceVersion: "412247041"
  selfLink: /apis/extensions/v1beta1/namespaces/default/ingresses/gray-devops-canary-ingress
  uid: fe13b38d-1f6f-45fb-8d89-504b4b8288ea
spec:
  rules:
  - host: joker.coolops.cn
    http:
      paths:
      - backend:
          serviceName: gray-devops-canary-svc
          servicePort: 8080
status:
  loadBalancer:
    ingress:
    - ip: 192.168.100.61

可以发现跟我们预设的一样。

访问测试也没问题，如下：

# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}[root@master ~]# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello world!","version":"v1"}

现在就可以发布 stable 版本了，运行 stable 版本的流水线。发布完成后，集群里就只有 stable 版本的应用了，如下：

# kubectl get po | grep gray
gray-devops-stable-7f977bb6cf-8jzgt   1/1     Running   0          35s
# kubectl get ingress | grep gray
gray-devops-stable-ingress   joker.coolops.cn                               192.168.100.61   80        111m

通过域名访问也是符合预期的。

# curl -H "Host: joker.coolops.cn" http://192.168.100.61
{"data":"hello Joker!","version":"v1"}

到此基本实现了自己的想法。

说明：Jenkinsfile 中涉及的用户名和密码都保存在 Jenkins 的凭据中，插件需要安装 kubernetes deploy 插件，到插件中心搜索就行。

最后

上面我们基本实现了灰度发布的过程，也只是仅仅将手动的变成了自动。但是你有没有发现什么问题？

首先需要切换流水线进行发布，其次是发布控制方面也不是很友好，比如要增加 canary 版本的节点，就需要我们手动去做。

其实我更推荐使用 argo-rollouts 结合 argocd 进行灰度发布，argo-rollouts 自定义了一套 CRD 用于控制发布流程，可以省去很多手动操作过程，argocd 是基于 gitops 实现的一套软件，便于我们进行 CD 控制，也提供了 UI 面板进行操作。不过要用这套就需要更改现有的发布方式以及应用模板，不复杂，但是存在一定的风险，需要进行一定程度的测试。

我是乔克，《运维开发故事》公众号团队中的一员，一线运维农民工，云原生实践者，这里不仅有硬核的技术干货，还有我们对技术的思考和感悟，欢迎关注我们的公众号，期待和你一起成长！

反馈

此页是否对你有帮助？

Glad to hear it! Please tell us how we can improve.

Sorry to hear that. Please tell us how we can improve.

最后修改 March 29, 2024: load balancing, haproxy, hash, update, bypass (33eeace4)