代码驿站移动版

当前位置：主页 > 软件编程 > .NET代码 >

基于Kubernetes实现前后端应用的金丝雀发布(两种方案)

时间：2022-09-10 09:19:44 | 栏目：.NET代码 | 点击：次

公司的研发管理平台实现了Gitlab+Kubernetes的Devops，在ToB和ToC场景中，由于用户量大，且预发布环境和生产环境或多或少存在差异，使得生产环境发布版本的时候还是存在很多不确定性和很大的风险。于是需求方就提出了支持金丝雀发布的需求，金丝雀发布方案有很多，以下为两种常用的方案。

1、Deployment滚动更新策略实现金丝雀发布

利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。
rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5
rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
    name: demo-deployment
    namespace: default
spec:
  replicas: 10
  selector:
    matchLabels:
      name: hello-deployment
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 10%
      maxUnavailable: 0     
  template:
    metadata:
      labels:
        name: demo-deployment
    spec:
      containers:
      - name: webserver
        image: nginx:1.14
        ports:
        - containerPort:80

此方案只适合单个应用的金丝雀发布，如果是前后端应用就不合适了，会出现前端正常版本调用后端金丝雀版本，或者前端金丝雀版本调用后端正常版本的情况。于是乎，Pass掉此方案，另寻他路。

2、Ingress-Nginx配置Ingress Annotations实现金丝雀发布

Ingress-Nginx 支持配置 Ingress Annotations 来实现不同场景下的金丝雀发布。Nginx Annotations 支持以下 4 种 Canary 规则：

注意：金丝雀规则按优先顺序进行如下排序：
canary-by-header - > canary-by-cookie - > canary-weight
很显然canary-weight也是一种随机策略，也会导致前端正常版本调用后端金丝雀版本的情况，故Pass掉此策略。
canary-by-cookie和canary-by-header-value适合后端金丝雀发布实现，canary-by-cookie适合前端金丝雀发布实现。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: demo-canary
  annotations:    
    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.com
    http:
      paths:
      - backend:
          serviceName: demo-api-canary
          servicePort: 80

前端根据用户标签或者手动在浏览器中设置cookie的值canary=always，前端代码如果检测到此cookie，则传递canary=always的请求头到后端，那么就可以实现前端正常版本访问后端正常版本，或者前端金丝雀版本访问后端金丝雀版本，不会出现版本混淆的情况。

2.1 流程

2.2 代码

前端代码改造

以React为例，修改axios请求拦截器，从cookie中获取当前是否访问金丝雀版本，如果是，传递金丝雀版本请求头给后端服务。

import cookie from 'react-cookies'

axios.interceptors.request.use(
  (config) => {
    // 金丝雀版本
    const canaryCookie = cookie.load('canary')
    if (canaryCookie !== undefined) {
      config.headers.canary = canaryCookie
}
return config
  },
  (error) => {
    return Promise.reject(error)
  }
)

后端代码改造

以.Net为例，通过代理透传canary请求头到其他Api服务

public class CanaryHttpMessageHandler : DelegatingHandler
{
    private readonly IHttpContextAccessor _httpContextAccessor;
    private const string Canary = "canary";
    public CanaryHttpMessageHandler(IHttpContextAccessor httpContextAccessor)
    {
        _httpContextAccessor = httpContextAccessor;
    }
    protected override async Task<HttpResponseMessage> SendAsync(HttpRequestMessage request, 
CancellationToken cancellationToken)
    {
        var headers = _httpContextAccessor?.HttpContext?.Request?.Headers;
        if (headers != null && headers.ContainsKey(Canary))
        {
            // 透传请求头canary
            var canary = headers[Canary].ToString() ?? "";
            if (!string.IsNullOrWhiteSpace(canary))
                request.Headers.TryAddWithoutValidation(Canary, canary);
        }
        return await base.SendAsync(request, cancellationToken);
    }
}

前端Chrome测试

使用Chrome浏览器访问前端网站F12，在Console中输入document.cookie='canary =
always'手动设置canary的cookie值。

在Cookies中可以看到设置，此时访问前端网站为灰度版本。

如果删除canary的cookie，此时访问前端网站为正常版本

后端Postman测试

使用Postman访问后端接口，在请求头中输入canary = always。此时访问后端服务为灰度版本。


如果删除canary的请求头，此时访问后端服务为正常版本

最后

总体来说Ingress Annotations实现了我们的需求，如果要进一步的实现用户标签来确定用户是否访问金丝雀版本，还需要继续迭代，难度不大。就实现金丝雀发布来说，istio也是支持的，它是属于基础设施层面的，对于代码入侵性小，后续大家可以考虑一下。另外，由于时间仓促，写得不太细致，但是核心的思想和代码都在上面，希望可以给大家带来帮助！

您可能感兴趣的文章:

相关文章