本文永久链接: https://www.xtplayer.cn/rancher/rancher-nginx-ingress-canary/
简介
Nginx-ingress 是一个以 Nginx 为核心组件的 K8S 负载均衡工具,支持通过配置 Ingress 规则的 Annotations 来实现不同场景下的灰度发布和测试。
Ingress Annotations 支持以下 4 种 Canary 规则:
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 并将请求与其他金丝雀规则进行优先级的比较。
注意:金丝雀规则按优先顺序进行如下排序: canary-by-header - > canary-by-cookie - > canary-weight
我们可以把以上的四个 Annotation 规则可以总体划分为以下两类:
基于权重的 Canary 规则
基于用户请求的 Canary 规则
注意: Nginx-ingress 在 0.21.0 版本中引入的 Canary 功能,因此要确保 ingress 版本大于等于 0.21.0。
测试准备
通过 RancherUI 创建 deployment,分别为 nginx-v1和nginx-v2。
创建 ingress 规则
接着进入容器中,修改 nginx 默认页面 /usr/share/nginx/html/index.html,页面修改后访问效果分别为:
-
测试步骤
测试场景 1:基于 header 实现蓝绿或者 A/B test
我们基于 V2 进行 ingress 的配置,添加 ingress 的 annotation:
我们在客户端执行命令(带 Rancher:Best 的请求头):
curl -H "Rancher: Best" http://es01.zyl.com
可以看到当我们带请求头去访问 es01.zyl.com 这个页面时,流量会被自动转发到 V2 的页面里,当我们不带请求头直接访问就会是 V1 版本的页面
curl http://es01.zyl.com
测试场景 2:基于流量实现灰度或者蓝绿
v2 版本 ingress annotation 配置如下:
此例中我配置的权重是 50%流量会进入 V2 版本,因此我们在浏览器里不断刷新访问后会发现 V1 和 V2 两个页面,总体概率是 50%到 V2,50%到 V1,可以直接调整权重的值实现灰度发布。
两种场景的 yaml 文件截图
基于 Header
基于流量权重
所有评论(0)