当对服务进行版本更新升级时,需要使用到滚动升级、分批暂停发布、蓝绿发布以及灰度发布等发布方式。本文将介绍在ACK集群中如何通过Nginx Ingress Controller来实现应用服务的灰度发布。
背景信息
灰度及蓝绿发布是为新版本创建一个与老版本完全一致的生产环境,在不影响老版本的前提下,按照一定的规则把部分流量切换到新版本,当新版本试运行一段时间没有问题后,将用户的全量流量从老版本迁移至新版本。
其中AB测试就是一种灰度发布方式,一部分用户继续使用老版本的服务,将一部分用户的流量切换到新版本,如果新版本运行稳定,则逐步将所有用户迁移到新版本。
- canary-*注解方式:使用
canary-*
Annotation配置蓝绿发布与灰度发布,canary-*
Annotation是社区官方实现的灰度发布方式。 - service-*注解方式:使用
service-*
Annotation配置蓝绿发布与灰度发布。service-*
Annotation是ACK Nginx Ingress Controller早期实现灰度发布的方式。service-match
与service-weight
功能已不再维护,并即将废弃。service-*
Annotation功能目前仍正常保留,不影响使用。
应用场景
基于客户端请求的流量切分场景
foo=bar
或者Cookie中包含foo=bar
的客户端请求转发到Service A'服务中。待运行一段时间稳定后,可将所有的流量从Service A切换到Service A'服务中,再平滑地将Service A服务下线。
基于服务权重的流量切分场景

- 基于Request Header的流量切分,适用于灰度发布以及AB测试场景。
- 基于Cookie的流量切分,适用于灰度发布以及AB测试场景。
- 基于Query Param的流量切分,适用于灰度发布以及AB测试场景。
- 基于服务权重的流量切分,适用于蓝绿发布场景。
canary-*注解方式
注解说明
canary-*
Annotation来支持应用服务的灰度发布机制。
Annotation | 说明 | 适用的ACK Nginx Ingress Controller版本 |
---|---|---|
nginx.ingress.kubernetes.io/canary |
|
≥v0.22.0 |
nginx.ingress.kubernetes.io/canary-by-header |
|
≥v0.22.0 |
nginx.ingress.kubernetes.io/canary-by-header-value |
|
≥v0.30.0 |
nginx.ingress.kubernetes.io/canary-by-header-pattern |
|
≥v0.44.0 |
nginx.ingress.kubernetes.io/canary-by-cookie |
|
≥v0.22.0 |
nginx.ingress.kubernetes.io/canary-weight |
|
≥v0.22.0 |
nginx.ingress.kubernetes.io/canary-weight-total |
|
≥v1.1.2 |
不同灰度方式的优先级由高到低为:
canary-by-header
>canary-by-cookie
>canary-weight
操作步骤
步骤一:部署服务
部署Nginx服务并通过Nginx Ingress Controller对外提供7层域名访问。
- 创建Deployment和Service。
- 部署Ingress。
- 测试访问情况。
步骤二:灰度发布新版本服务
发布一个新版本的Nginx服务并配置路由规则。
步骤三:删除老版本服务
系统运行一段时间后,当新版本服务已经稳定并且符合预期后,需要下线老版本的服务 ,仅保留新版本服务在线上运行。为了达到该目标,需要将旧版本的Service指向新版本服务的Deployment,并且删除旧版本的Deployment和新版本的Service。
service-*注解方式
注解说明
- nginx.ingress.kubernetes.io/service-match
该注解用来配置新版本服务的路由匹配规则。
nginx.ingress.kubernetes.io/service-match: | <service-name>: <match-rule> # 参数说明: # service-name:服务名称,满足match-rule的请求会被路由到该服务中。 # match-rule:路由匹配规则 # # 路由匹配规则: # 1. 支持的匹配类型 # - header:基于请求头,支持正则匹配和完整匹配。 # - cookie:基于cookie,支持正则匹配和完整匹配。 # - query:基于请求参数,支持正则匹配和完整匹配。 # # 2. 匹配方式 # - 正则匹配格式:/{regular expression}/,//表明采用正则方式匹配。 # - 完整匹配格式:"{exact expression}",""表明采用完整方式匹配。
路由匹配规则配置示例:# 请求头中满足foo正则匹配^bar$的请求被转发到新版本服务new-nginx中。 new-nginx: header("foo", /^bar$/) # 请求头中满足foo完整匹配bar的请求被转发到新版本服务new-nginx中。 new-nginx: header("foo", "bar") # cookie中满足foo正则匹配^sticky-.+$的请求被转发到新版本服务new-nginx中。 new-nginx: cookie("foo", /^sticky-.+$/) # query param中满足foo完整匹配bar的请求被转发到新版本服务new-nginx中。 new-nginx: query("foo", "bar")
- nginx.ingress.kubernetes.io/service-weight
该注解用来配置新旧版本服务的流量权重。
nginx.ingress.kubernetes.io/service-weight: | <new-svc-name>:<new-svc-weight>, <old-svc-name>:<old-svc-weight> 参数说明: new-svc-name:新版本服务名称 new-svc-weight:新版本服务权重 old-svc-name:旧版本服务名称 old-svc-weight:旧版本服务权重
服务权重配置示例:nginx.ingress.kubernetes.io/service-weight: | new-nginx: 20, old-nginx: 60
操作步骤
步骤一:部署服务
部署Nginx服务并通过Nginx Ingress Controller对外提供7层域名访问。
- 创建Deployment和Service。
- 部署Ingress。
- 测试访问情况。
步骤二:灰度发布新版本服务
发布一个新版本的Nginx服务并配置路由规则。
步骤三:删除老版本服务
系统运行一段时间后,当新版本服务已经稳定并且符合预期后,需要下线老版本的服务 ,仅保留新版本服务在线上运行。