基于Kubernetes实现前后端应用的金丝雀发布
公司的研发管理平台实现了Gitlab+Kubernetes的Devops，在ToB和ToC场景中，由于用户量大，且预发布环境和生产环境或多或少存在差异，使得生产环境发布版本的时候还是存在很多不确定性和很大的风险。于是需求方就提出了支持金丝雀发布的需求，金丝雀发布方案有很多，以下为两种常用的方案。
1、Deployment滚动更新策略实现金丝雀发布
利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。
rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5
rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值
apiVersion:extensions/v1beta1kind:Deploymentmetadata:name:demo-deploymentnamespace:defaultspec:replicas:10selector:matchLabels:name:hello-deploymentstrategy:type:RollingUpdaterollingUpdate:maxSurge:10%maxUnavailable:0template:metadata:labels:name:demo-deploymentspec:containers:-name:webserverimage:nginx:1.14ports:-containerPort:80
此方案只适合单个应用的金丝雀发布，如果是前后端应用就不合适了，会出现前端正常版本调用后端金丝雀版本，或者前端金丝雀版本调用后端正常版本的情况。于是乎，Pass掉此方案，另寻他路。
2、Ingress-Nginx配置Ingress Annotations实现金丝雀发布
Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的金丝雀发布。Nginx 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很显然canary-weight也是一种随机策略，也会导致前端正常版本调用后端金丝雀版本的情况，故Pass掉此策略。canary-by-cookie和canary-by-header-value适合后端金丝雀发布实现，canary-by-cookie适合前端金丝雀发布实现。
apiVersion: extensions/v1beta1kind: Ingressmetadata:name: demo-canaryannotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary:"true"nginx.ingress.kubernetes.io/canary-by-header:"canary"nginx.ingress.kubernetes.io/canary-by-cookie:"canary"spec:rules: -host: demo-api.fulu.comhttp:paths: -backend:serviceName: demo-api-canaryservicePort:80
前端根据用户标签或者手动在浏览器中设置cookie的值canary=always，前端代码如果检测到此cookie，则传递canary=always的请求头到后端，那么就可以实现前端正常版本访问后端正常版本，或者前端金丝雀版本访问后端金丝雀版本，不会出现版本混淆的情况。
2.1 流程
如果是第一次发布，必须是正常版本。
如果发布金丝雀版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则替换金丝雀版本的镜像，如果没有则创建-canary后缀的ingress、service、deployment。
如果发布正常版本，则先检测是否有-canary后缀的ingress、service、deployment，如果有则先删除它们，再替换正常版本的镜像。
2.2 代码
前端代码改造
以React为例，修改axios请求拦截器，从cookie中获取当前是否访问金丝雀版本，如果是，传递金丝雀版本请求头给后端服务。
importcookiefrom'react-cookies'axios.interceptors.request.use((config) =>{// 金丝雀版本constcanaryCookie = cookie.load('canary')if(canaryCookie !==undefined) { config.headers.canary = canaryCookie}returnconfig },(error) =>{returnPromise.reject(error) })
后端代码改造
以.Net为例，通过代理透传canary请求头到其他Api服务
publicclassCanaryHttpMessageHandler:DelegatingHandler{privatereadonlyIHttpContextAccessor _httpContextAccessor;privateconststringCanary ="canary";publicCanaryHttpMessageHandler(IHttpContextAccessor httpContextAccessor){ _httpContextAccessor = httpContextAccessor; }protectedoverrideasyncTaskSendAsync(HttpRequestMessage request,
CancellationToken cancellationToken){varheaders = _httpContextAccessor?.HttpContext?.Request?.Headers;if(headers !=null&& headers.ContainsKey(Canary)) {// 透传请求头canaryvarcanary = headers[Canary].ToString() ??"";if(!string.IsNullOrWhiteSpace(canary)) request.Headers.TryAddWithoutValidation(Canary, canary); }returnawaitbase.SendAsync(request, cancellationToken); }}
前端Chrome测试
使用Chrome浏览器访问前端网站F12，在Console中输入document.cookie='canary =
always'手动设置canary的cookie值。
在Cookies中可以看到设置，此时访问前端网站为灰度版本。
如果删除canary的cookie，此时访问前端网站为正常版本
后端Postman测试
使用Postman访问后端接口，在请求头中输入canary = always。此时访问后端服务为灰度版本。
如果删除canary的请求头，此时访问后端服务为正常版本
最后
总体来说Ingress Annotations实现了我们的需求，如果要进一步的实现用户标签来确定用户是否访问金丝雀版本，还需要继续迭代，难度不大。就实现金丝雀发布来说，istio也是支持的，它是属于基础设施层面的，对于代码入侵性小，后续大家可以考虑一下。另外，由于时间仓促，写得不太细致，但是核心的思想和代码都在上面，希望可以给大家带来帮助！