Kubernetes如何实现前后端应用的金丝雀发布
这篇文章主要讲解了"Kubernetes如何实现前后端应用的金丝雀发布"，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习"Kubernetes如何实现前后端应用的金丝雀发布"吧！
1、Deployment滚动更新策略实现金丝雀发布
利用Deployment的滚动更新策略maxSurge和maxUnavailable设置最大可超期望的节点数和最大不可用节点数可实现简单的金丝雀发布。rollingUpdate.maxSurge最大可超期望的节点数，百分比 10% 或者绝对数值 5rollingUpdate.maxUnavailable最大不可用节点数，百分比或者绝对数值
apiVersion: extensions/v1beta1kind: Deploymentmetadata: name: demo-deployment namespace: defaultspec: 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 规则：
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-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 流程
如果是第一次发布，必须是正常版本。
如果发布金丝雀版本，则先检测是否有
-canary后缀的ingress、service、deployment，如果有则替换金丝雀版本的镜像，如果没有则创建-canary后缀的ingress、service、deployment。如果发布正常版本，则先检测是否有
-canary后缀的ingress、service、deployment，如果有则先删除它们，再替换正常版本的镜像。
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 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中输入[xss_clean]='canary =
always'手动设置canary的cookie值。
在Cookies中可以看到设置，此时访问前端网站为灰度版本。
如果删除canary的cookie，此时访问前端网站为正常版本
后端Postman测试
使用Postman访问后端接口，在请求头中输入canary = always。此时访问后端服务为灰度版本。
如果删除canary的请求头，此时访问后端服务为正常版本
感谢各位的阅读，以上就是"Kubernetes如何实现前后端应用的金丝雀发布"的内容了，经过本文的学习后，相信大家对Kubernetes如何实现前后端应用的金丝雀发布这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是，小编将为大家推送更多相关知识点的文章，欢迎关注！
