Skip to content

如何通过ingress-nginx controller实现应用服务的灰度发布 原创

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

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

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

本文大纲如下。

fc22231e045dbdecce9770220f835923 MD5

如何通过 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 来实现灰度发布,其思路如下:

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

发布场景介绍

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

基于权重的发布场景

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

4f3952f64acd05bc0dfa3f4feec69afe MD5

要实现这种,只需要在 canary 的 ingress 中添加如下 annotation。

shell

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 应用,而是希望只有四川的用户可以访问,待四川地区反馈没问题后,才开放其他地区。

748ffa4cef5ce171c60247f8dce4cdff MD5

对于这种我们需要在 canary 的 ingress 中添加如下 annotation。

shell

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 版本

yaml
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

访问效果如下:

shell

# curl 10.97.112.137:8080

{"data":"hello world","version":"v1"}

(2)canary 版本

yaml
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

访问效果如下:

shell

# curl 10.110.178.174:8080

{"data":"hello SB","version":"v2"}

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

基于权重的发布场景

(1)配置 stable 版本的 ingress

yaml
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

yaml
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

然后我们通过访问测试,效果如下:

shell

# 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

yaml
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

yaml
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 版本应用,如下:

yaml

# curl joker.coolops.cn

{"data":"hello world","version":"v1"}

# curl joker.coolops.cn

{"data":"hello world","version":"v1"}

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

yaml

# curl joker.coolops.cn -H "region: sichuan"

{"data":"hello SB","version":"v2"}

# curl joker.coolops.cn -H "region: sichuan"

{"data":"hello SB","version":"v2"}

实现是不是很简单?

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

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

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

首先来捋捋过程:

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

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

那我们流水线可以这样设计,如下:

e541366836aa715a40011c3e96463ea4 MD5

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

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

43ddf7bf2661bec5f2761e314138d157 MD5

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

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

  1. 流水线名字格式如下:

  2. <APP_NAME>-stable

  3. <APP_NAME>-canary

  4. deployment 的名字格式如下:

  5. <APP_NAME>-stable

  6. <APP_NAME>-canary

  7. service 的名字格式如下:

  8. <APP_NAME>-stable-svc

  9. <APP_NAME>-canary-svc

  10. ingress 的名字格式如下:

  11. <APP_NAME>-stable-ingress

  12. <APP_NAME>-canary-ingress

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

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

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

然后我们会创建两条流水线,如下:

d758cae4a022f6d4b66edd11d4bc4891 MD5

其中joker-gary-devops-canary是用来部署 canary 版本,另外一个是用来部署 stable 版本。

现在在集群里运行着 stable 版本,如下:

yaml
# curl -H "Host: joker.coolops.cn" http://192.168.100.61

{ "data": "hello world!", "version": "v1" }

我们修改了需求,更改了代码,变动如下:

go

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 等,如下:

shell

# 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 的内容,看是否是我们需要的,如下:

yaml
# 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

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

访问测试也没问题,如下:

shell

# 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 版本的应用了,如下:

shell

# 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

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

shell

# curl -H "Host: joker.coolops.cn" http://192.168.100.61

{"data":"hello Joker!","version":"v1"}

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

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

未完成部分

  • RPC 调用,需要过滤灰度版本
  • 需要配置流量占比或者自定义 Header
  • 可以动态更新灰度规则,避免更改一次就需要重启

自定义 Header

  • 版本匹配策略,Header 格式如下任选一个
go

n-d-version=1.0 n-d-version={"discovery-guide-service-a":"2.0", "discovery-guide-service-b":"2.0"}
  • 版本权重策略,Header 格式如下任选一个
go

n-d-version-weight=1.0=90;1.1=10 n-d-version-weight={"discovery-guide-service-a":"1.0=90;1.1=10", "discovery-guide-service-b":"1.0=90;1.1=10"}
  • 区域匹配策略,Header 格式如下任选一个
go

n-d-region=qa n-d-region={"discovery-guide-service-a":"qa", "discovery-guide-service-b":"qa"}
  • 区域权重策略,Header 格式如下任选一个
go

n-d-region-weight=dev=99;qa=1 n-d-region-weight={"discovery-guide-service-a":"dev=99;qa=1", "discovery-guide-service-b":"dev=99;qa=1"}
  • IP 地址和端口匹配策略,Header 格式如下任选一个
go

n-d-address={"discovery-guide-service-a":"127.0.0.1:3001", "discovery-guide-service-b":"127.0.0.1:4002"} n-d-address={"discovery-guide-service-a":"127.0.0.1", "discovery-guide-service-b":"127.0.0.1"} n-d-address={"discovery-guide-service-a":"3001", "discovery-guide-service-b":"4002"}
  • 环境隔离下动态环境匹配策略
go

n-d-env=env1
  • 服务下线实时性的流量绝对无损,全局唯一 ID 屏蔽策略
go

n-d-id-blacklist=e92edde5-0153-4ec8-9cbb-b4d3f415aa33;af043384-c8a5-451e-88f4-457914e8e3bc
  • 服务下线实时性的流量绝对无损,IP 地址和端口屏蔽策略
go

n-d-address-blacklist=192.168.43.101:1201;192.168.*.102;1301

当外界传值 Header 的时候,网关也设置并传递同名的 Header,需要决定哪个 Header 传递到后边的服务去。需要通过如下开关做控制:

go

# 当外界传值Header的时候,网关也设置并传递同名的Header,需要决定哪个Header传递到后边的服务去。如果下面开关为true,以网关设置为优先,否则以外界传值为优先。缺失则默认为true spring.application.strategy.gateway.header.priority=false

# 当以网关设置为优先的时候,网关未配置Header,而外界配置了Header,仍旧忽略外界的Header。缺失则默认为true spring.application.strategy.gateway.original.header.ignored=true

# 当外界传值Header的时候,网关也设置并传递同名的Header,需要决定哪个Header传递到后边的服务去。如果下面开关为true,以网关设置为优先,否则以外界传值为优先。缺失则默认为true spring.application.strategy.zuul.header.priority=false

# 当以网关设置为优先的时候,网关未配置Header,而外界配置了Header,仍旧忽略外界的Header。缺失则默认为true spring.application.strategy.zuul.original.header.ignored=true

最后

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

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

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

最近更新