公司的研發(fā)管理平臺(tái)實(shí)現(xiàn)了Gitlab+Kubernetes的Devops，在ToB和ToC場(chǎng)景中，由于用戶(hù)量大，且預(yù)發(fā)布環(huán)境和生產(chǎn)環(huán)境或多或少存在差異，使得生產(chǎn)環(huán)境發(fā)布版本的時(shí)候還是存在很多不確定性和很大的風(fēng)險(xiǎn)。于是需求方就提出了支持金絲雀發(fā)布的需求，金絲雀發(fā)布方案有很多，以下為兩種常用的方案。

1、Deployment滾動(dòng)更新策略實(shí)現(xiàn)金絲雀發(fā)布

利用Deployment的滾動(dòng)更新策略maxSurge和maxUnavailable設(shè)置最大可超期望的節(jié)點(diǎn)數(shù)和最大不可用節(jié)點(diǎn)數(shù)可實(shí)現(xiàn)簡(jiǎn)單的金絲雀發(fā)布。
rollingUpdate.maxSurge最大可超期望的節(jié)點(diǎn)數(shù)，百分比 10% 或者絕對(duì)數(shù)值 5
rollingUpdate.maxUnavailable最大不可用節(jié)點(diǎn)數(shù)，百分比或者絕對(duì)數(shù)值

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

此方案只適合單個(gè)應(yīng)用的金絲雀發(fā)布，如果是前后端應(yīng)用就不合適了，會(huì)出現(xiàn)前端正常版本調(diào)用后端金絲雀版本，或者前端金絲雀版本調(diào)用后端正常版本的情況。于是乎，Pass掉此方案，另尋他路。

2、Ingress-Nginx配置Ingress Annotations實(shí)現(xiàn)金絲雀發(fā)布

Ingress-Nginx 支持配置 Ingress Annotations 來(lái)實(shí)現(xiàn)不同場(chǎng)景下的金絲雀發(fā)布。Nginx Annotations 支持以下 4 種 Canary 規(guī)則：

• nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，適用于灰度發(fā)布以及 A/B 測(cè)試。當(dāng) Request Header 設(shè)置為 always時(shí)，請(qǐng)求將會(huì)被一直發(fā)送到 Canary 版本；當(dāng) Request Header 設(shè)置為 never時(shí)，請(qǐng)求不會(huì)被發(fā)送到 Canary 入口；對(duì)于任何其他 Header 值，將忽略 Header，并通過(guò)優(yōu)先級(jí)將請(qǐng)求與其他金絲雀規(guī)則進(jìn)行優(yōu)先級(jí)的比較。
• nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 將請(qǐng)求路由到 Canary Ingress 中指定的服務(wù)。當(dāng) Request Header 設(shè)置為此值時(shí)，它將被路由到 Canary 入口。該規(guī)則允許用戶(hù)自定義 Request Header 的值，必須與上一個(gè) annotation (即：canary-by-header）一起使用。
• nginx.ingress.kubernetes.io/canary-weight：基于服務(wù)權(quán)重的流量切分，適用于藍(lán)綠部署，權(quán)重范圍 0 - 100 按百分比將請(qǐng)求路由到 Canary Ingress 中指定的服務(wù)。權(quán)重為 0 意味著該金絲雀規(guī)則不會(huì)向 Canary 入口的服務(wù)發(fā)送任何請(qǐng)求。權(quán)重為 100 意味著所有請(qǐng)求都將被發(fā)送到 Canary 入口。
• nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，適用于灰度發(fā)布與 A/B 測(cè)試。用于通知 Ingress 將請(qǐng)求路由到 Canary Ingress 中指定的服務(wù)的cookie。當(dāng) cookie 值設(shè)置為 always時(shí)，它將被路由到 Canary 入口；當(dāng) cookie 值設(shè)置為 never時(shí)，請(qǐng)求不會(huì)被發(fā)送到 Canary 入口；對(duì)于任何其他值，將忽略 cookie 并將請(qǐng)求與其他金絲雀規(guī)則進(jìn)行優(yōu)先級(jí)的比較。

注意：金絲雀規(guī)則按優(yōu)先順序進(jìn)行如下排序：
canary-by-header - > canary-by-cookie - > canary-weight
很顯然canary-weight也是一種隨機(jī)策略，也會(huì)導(dǎo)致前端正常版本調(diào)用后端金絲雀版本的情況，故Pass掉此策略。
canary-by-cookie和canary-by-header-value適合后端金絲雀發(fā)布實(shí)現(xiàn)，canary-by-cookie適合前端金絲雀發(fā)布實(shí)現(xiàn)。

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

前端根據(jù)用戶(hù)標(biāo)簽或者手動(dòng)在瀏覽器中設(shè)置cookie的值canary=always，前端代碼如果檢測(cè)到此cookie，則傳遞canary=always的請(qǐng)求頭到后端，那么就可以實(shí)現(xiàn)前端正常版本訪(fǎng)問(wèn)后端正常版本，或者前端金絲雀版本訪(fǎng)問(wèn)后端金絲雀版本，不會(huì)出現(xiàn)版本混淆的情況。

2.1 流程

• 如果是第一次發(fā)布，必須是正常版本。
• 如果發(fā)布金絲雀版本，則先檢測(cè)是否有-canary后綴的ingress、service、deployment，如果有則替換金絲雀版本的鏡像，如果沒(méi)有則創(chuàng)建-canary后綴的ingress、service、deployment。
• 如果發(fā)布正常版本，則先檢測(cè)是否有-canary后綴的ingress、service、deployment，如果有則先刪除它們，再替換正常版本的鏡像。

2.2 代碼

前端代碼改造

以React為例，修改axios請(qǐng)求攔截器，從cookie中獲取當(dāng)前是否訪(fǎng)問(wèn)金絲雀版本，如果是，傳遞金絲雀版本請(qǐng)求頭給后端服務(wù)。

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為例，通過(guò)代理透?jìng)鱟anary請(qǐng)求頭到其他Api服務(wù)

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))
        {
            // 透?jìng)髡?qǐng)求頭canary
            var canary = headers[Canary].ToString() ?? "";
            if (!string.IsNullOrWhiteSpace(canary))
                request.Headers.TryAddWithoutValidation(Canary, canary);
        }
        return await base.SendAsync(request, cancellationToken);
    }
}

前端Chrome測(cè)試

使用Chrome瀏覽器訪(fǎng)問(wèn)前端網(wǎng)站F12，在Console中輸入document.cookie='canary =
always'手動(dòng)設(shè)置canary的cookie值。

在Cookies中可以看到設(shè)置，此時(shí)訪(fǎng)問(wèn)前端網(wǎng)站為灰度版本。

如果刪除canary的cookie，此時(shí)訪(fǎng)問(wèn)前端網(wǎng)站為正常版本

后端Postman測(cè)試

使用Postman訪(fǎng)問(wèn)后端接口，在請(qǐng)求頭中輸入canary = always。此時(shí)訪(fǎng)問(wèn)后端服務(wù)為灰度版本。

如果刪除canary的請(qǐng)求頭，此時(shí)訪(fǎng)問(wèn)后端服務(wù)為正常版本

最后

總體來(lái)說(shuō)Ingress Annotations實(shí)現(xiàn)了我們的需求，如果要進(jìn)一步的實(shí)現(xiàn)用戶(hù)標(biāo)簽來(lái)確定用戶(hù)是否訪(fǎng)問(wèn)金絲雀版本，還需要繼續(xù)迭代，難度不大。就實(shí)現(xiàn)金絲雀發(fā)布來(lái)說(shuō)，istio也是支持的，它是屬于基礎(chǔ)設(shè)施層面的，對(duì)于代碼入侵性小，后續(xù)大家可以考慮一下。另外，由于時(shí)間倉(cāng)促，寫(xiě)得不太細(xì)致，但是核心的思想和代碼都在上面，希望可以給大家?guī)?lái)幫助！

到此這篇關(guān)于基于Kubernetes實(shí)現(xiàn)前后端應(yīng)用的金絲雀發(fā)布的文章就介紹到這了,更多相關(guān)Kubernetes金絲雀發(fā)布內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論