Logo

Menu

乔克
乔克
Published on 2024-11-15 / 61 Visits
0
0

如何通过ingress-nginx实现应用的灰度发布？

#Kubernetes#灰度发布#ingress-nginx

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

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

​

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

本文大纲如下。
ingress.jpg

如何通过 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 版本。
​

image.png

要实现这种，只需要在 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 应用，而是希望只有四川的用户可以访问，待四川地区反馈没问题后，才开放其他地区。
​

ingress2.jpg

对于这种我们需要在 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 版本。

由于两个场景只有在 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"}

实现是不是很简单？
​

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

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

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

首先来捋捋过程：

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

​

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

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

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

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

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

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

  1. 流水线名字格式如下：
    1. APP_NAME-stable
    2. APP_NAME-canary
  2. deployment 的名字格式如下：
    1. APP_NAME-stable
    2. APP_NAME-canary
  3. service 的名字格式如下：
    1. APP_NAME-stable-svc
    2. APP_NAME-canary-svc
  4. ingress 的名字格式如下：
    1. APP_NAME-stable-ingress
    2. APP_NAME-canary-ingress

​

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

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

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

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

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

如何开发ChatOps
如何通过Kubernetes安装K...

Comment