【ingress-nginx】通过特定的请求参数做灰度发布

原创

Jokey

修改于 2025-02-01 12:59:41

1550

使用背景

一般在 web 业务灰度发布中，在使用 ingress-nginx时，比较常用的灰度策略是通过请求路径、header或者 cookie 的方式，使用方式官网文档都有介绍，参考：Canary 和 annotations 。今天介绍一种特殊场景下的灰度思路，即通过请求参数的方式来做灰度流量接入，下面将介绍如何操作。

操作步骤

实验环境准备：

1.创建一个 TKE 集群。

2.安装 Ingress-nginx（注意需要开启allow-snippet-annotations 特性，风险参考：allow-snippet-annotations）。

3.创建两个试验用的工作负载（原服务 Nginx 和要灰度的 php 服务），如下图：

4.分别创建两个工作负载的 ingress 路由，业务接口 path 为 /test (如第一个 ingress path 所示) 。

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-demo
    kubernetes.io/ingress.rule-mix: "false"
    # 下面格式 $arg_<queryParamKey> queryParamKey为请求参数key
    nginx.ingress.kubernetes.io/configuration-snippet: |
      if ($arg_jokey){ # 判断条件，可以使用正则匹配值判断，例如若匹配数字范围 30.0～31.0, 则条件为 $arg_jokey ~* ^(30\\.[0-9]+|31\\.[0-9]+)$ 

                rewrite ^ /test/foo last; # 内部地址重写直接响应重定向后的内容，/test/foo 为重定向到第二个ingress 规则 path。
                
                # 301 永久重定向，需要 Location 跳转, http://a.com/test/foo 为重定向到第二个ingress 规则URL。
                # rewrite ^ http://a.com/test/foo permanent;  
                }
  name: jokey1
  namespace: default
spec:
  rules:
  - host: a.com
    http:
      paths:
      - backend:
          service:
            name: nginx # 原服务 nginx
            port:
              number: 80
        path: /test # 业务接口 path
        pathType: ImplementationSpecific

---

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx-demo
    kubernetes.io/ingress.rule-mix: "false"
    nginx.ingress.kubernetes.io/rewrite-target: /test$1 # rewrite 回正常的业务 Path 并带上原始请求参数
    nginx.ingress.kubernetes.io/use-regex: "true"  #需开启正则表达式 
  name: jokey2
  namespace: default
spec:
  rules:
  - host: a.com
    http:
      paths:
      - backend:
          service:
            name: php-apache # 灰度服务PHP
            port:
              number: 80
        path: /test/foo(.*) # 重定向跳转 path（与第一个ingress 重定向配置对应）
        pathType: ImplementationSpecific

实验思路原理：

第一个 ingress 为原业务接入路由，第二个 ingress 为灰度业务接入路由。
在第一个原业务 ingress 中通过 configuration-snippet 来检查匹配请求参数是否含有特定的key(jokey) ,如果有则将请求重定向到第二个ingress的 URL（灰度服务后端）获取响应 , 否则原服务后端响应。
第二个灰度服务的 ingress 在接收流量时对请求 path rewrite 回写为原业务接口(/test) , 并带上原始请求参数，灰度后端响应后返回，从而实现特定请求参数的流量灰度。

实验过程验证：

1.没有匹配指定请求参数的请求，可以得到原服务正常请求，如下图：

2.匹配指定请求参数（key为 jokey）的请求，这里做了两种不同策略的重定向，可以根据实际业务调整。

如果重定向策略如下（推荐）：

rewrite ^ /test/foo last; # 内部地址重写直接响应重定向后的内容。

则会直接获取重定向后的灰度后端响应（无须客户端跳转链接），如下图：

如果重定向策略如下：

rewrite ^ http://a.com/test/foo permanent; # 301 永久重定向，需要 Location 跳转

则可以得到 301 的响应，响应 Location 为第二个ingress 路径，如下图：

此时访问重定向的URL（浏览器环境下可自动跳转），得到灰度服务的响应，如下图：

3.检查最终 rewrite 回业务实际 Path 是否成功。

查看灰度服务的后端日志，可以看到请求 path 已经按照预期 Rewrite 回业务接口 path, 如下图：

总结

通过上面的试验过程详细介绍了如何在 ingress-nginx 下通过特定请求参数的方式来做灰度发布策略，不过此方式仅是为特殊需求场景下的解决方案（思路），非业界最佳灰度方式，实际业务场景下，能使用常用方式还是建议尽量使用常用方式来做流量灰度。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

nginx

容器服务

kubernetes-ingress

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

登录后参与评论

0 条评论

热度