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

在集群中部署两套系统，一套是 stable 版本，一套是 canary 版本，两个版本都有自己的 service
定义两个 ingress 配置，一个正常提供服务，一个增加 canary 的 annotation
待 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"}

实现是不是很简单？

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

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

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

首先来捋捋过程：

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

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

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

e541366836aa715a40011c3e96463ea4 MD5

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

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

43ddf7bf2661bec5f2761e314138d157 MD5

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

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

流水线名字格式如下：
<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 版本。

然后我们会创建两条流水线，如下：

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" }

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


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 格式如下任选一个


n-d-version=1.0 n-d-version={"discovery-guide-service-a":"2.0", "discovery-guide-service-b":"2.0"}

版本权重策略，Header 格式如下任选一个


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 格式如下任选一个


n-d-region=qa n-d-region={"discovery-guide-service-a":"qa", "discovery-guide-service-b":"qa"}

区域权重策略，Header 格式如下任选一个


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 格式如下任选一个


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"}

环境隔离下动态环境匹配策略


n-d-env=env1

服务下线实时性的流量绝对无损，全局唯一 ID 屏蔽策略


n-d-id-blacklist=e92edde5-0153-4ec8-9cbb-b4d3f415aa33;af043384-c8a5-451e-88f4-457914e8e3bc

服务下线实时性的流量绝对无损，IP 地址和端口屏蔽策略


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

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


# 当外界传值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 面板进行操作。不过要用这套就需要更改现有的发布方式以及应用模板，不复杂，但是存在一定的风险，需要进行一定程度的测试。

Golang基础知识

Golang进阶知识

Golang常用包

Gin框架

Tekton

ArgoWorkflow

Gitlab

Ansible

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

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

发布场景介绍

基于权重的发布场景

基于用户请求的发布场景

灰度发布具体实现

基于权重的发布场景

基于用户请求的发布场景

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

未完成部分

自定义 Header

最后

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

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

发布场景介绍 ​

基于权重的发布场景 ​

基于用户请求的发布场景 ​

灰度发布具体实现 ​

基于权重的发布场景 ​

基于用户请求的发布场景 ​

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

未完成部分 ​

自定义 Header ​

最后 ​

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

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

发布场景介绍

基于权重的发布场景

基于用户请求的发布场景

灰度发布具体实现

基于权重的发布场景

基于用户请求的发布场景

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

未完成部分

自定义 Header

最后