目 录CONTENT

文章目录

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

乔克
2022-03-05 / 0 评论 / 0 点赞 / 1,256 阅读 / 11,795 字 / 正在检测是否收录...
温馨提示:
本文最后更新于 2022-03-05,若内容或图片失效,请留言反馈。部分素材来自网络,若不小心影响到您的利益,请联系我们删除。
广告 广告

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

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

这里主要给大家分享如果通过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版本。

  • 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