K8S基于Rancher的灰度发布

简介

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. 

  2. 

测试步骤

测试场景 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

  

• 基于流量权重