Kubernetes 如何通过ingress-nginx实现应用灰度发布？

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

1. 滚动更新：依次进行新旧替换，直到旧的全部被替换为止。

2. 蓝绿发布：两套独立的系统，对外提供服务的称为绿系统，待上线的服务称为蓝系统，当蓝系统里面的应用测试完成后，用户流量接入蓝系统，蓝系统将称为绿系统，以前的绿系统就可以销毁。

3. 灰度发布：在一套集群中存在稳定和灰度两个版本，灰度版本可以限制只针对部分人员可用，待灰度版本测试完成后，可以将灰度版本升级为稳定版本，旧的稳定版本就可以下线了，我们也称之为金丝雀发布。

这里主要给大家分享如果通过ingress-nginx controller实现灰度发布。

如何通过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版本