本文永久链接: 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

  1. 我们基于 V2 进行 ingress 的配置，添加 ingress 的 annotation：

  2. 我们在客户端执行命令（带 Rancher：Best 的请求头）：

    curl -H "Rancher: Best" http://es01.zyl.com

    可以看到当我们带请求头去访问 es01.zyl.com 这个页面时，流量会被自动转发到 V2 的页面里，当我们不带请求头直接访问就会是 V1 版本的页面

    curl  http://es01.zyl.com

测试场景 2：基于流量实现灰度或者蓝绿

  1. v2 版本 ingress annotation 配置如下：

    此例中我配置的权重是 50%流量会进入 V2 版本，因此我们在浏览器里不断刷新访问后会发现 V1 和 V2 两个页面，总体概率是 50%到 V2，50%到 V1，可以直接调整权重的值实现灰度发布。

两种场景的 yaml 文件截图

  • 基于 Header

  • 基于流量权重