基於Kubernetes實現前後端應用的金絲雀釋出
公司的研發管理平臺實現了Gitlab+Kubernetes的Devops，在ToB和ToC場景中，由於使用者量大，且預釋出環境和生產環境或多或少存在差異，使得生產環境釋出版本的時候還是存在很多不確定性和很大的風險。於是需求方就提出了支援金絲雀釋出的需求，金絲雀釋出方案有很多，以下為兩種常用的方案。
1、Deployment滾動更新策略實現金絲雀釋出
利用Deployment的滾動更新策略maxSurge和maxUnavailable設定最大可超期望的節點數和最大不可用節點數可實現簡單的金絲雀釋出。
rollingUpdate。maxSurge最大可超期望的節點數，百分比 10% 或者絕對數值 5
rollingUpdate。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
前端Chrome測試
使用Chrome瀏覽器訪問前端網站F12，在Console中輸入document。cookie=‘canary =
always’手動設定canary的cookie值。
在Cookies中可以看到設定，此時訪問前端網站為灰度版本。
如果刪除canary的cookie，此時訪問前端網站為正常版本
後端Postman測試
使用Postman訪問後端介面，在請求頭中輸入canary = always。此時訪問後端服務為灰度版本。
如果刪除canary的請求頭，此時訪問後端服務為正常版本
最後
總體來說Ingress Annotations實現了我們的需求，如果要進一步的實現使用者標籤來確定使用者是否訪問金絲雀版本，還需要繼續迭代，難度不大。就實現金絲雀釋出來說，istio也是支援的，它是屬於基礎設施層面的，對於程式碼入侵性小，後續大家可以考慮一下。另外，由於時間倉促，寫得不太細緻，但是核心的思想和程式碼都在上面，希望可以給大家帶來幫助！
原文連結：https：//www。cnblogs。com/fulu/p/15648351。html
