您好,登錄后才能下訂單哦!
這篇文章主要講解了“Kubernetes如何實(shí)現(xiàn)前后端應(yīng)用的金絲雀發(fā)布”,文中的講解內(nèi)容簡(jiǎn)單清晰,易于學(xué)習(xí)與理解,下面請(qǐng)大家跟著小編的思路慢慢深入,一起來(lái)研究和學(xué)習(xí)“Kubernetes如何實(shí)現(xiàn)前后端應(yīng)用的金絲雀發(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ù)值 5rollingUpdate.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掉此方案,另尋他路。
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ī)則允許用戶自定義 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ù)用戶標(biāo)簽或者手動(dòng)在瀏覽器中設(shè)置cookie的值canary=always
,前端代碼如果檢測(cè)到此cookie,則傳遞canary=always
的請(qǐng)求頭到后端,那么就可以實(shí)現(xiàn)前端正常版本訪問(wèn)后端正常版本,或者前端金絲雀版本訪問(wèn)后端金絲雀版本,不會(huì)出現(xiàn)版本混淆的情況。
如果是第一次發(fā)布,必須是正常版本。
如果發(fā)布金絲雀版本,則先檢測(cè)是否有-canary
后綴的ingress、service、deployment,如果有則替換金絲雀版本的鏡像,如果沒(méi)有則創(chuàng)建-canary
后綴的ingress、service、deployment。
如果發(fā)布正常版本,則先檢測(cè)是否有-canary
后綴的ingress、service、deployment,如果有則先刪除它們,再替換正常版本的鏡像。
前端代碼改造
以React為例,修改axios請(qǐng)求攔截器,從cookie中獲取當(dā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瀏覽器訪問(wèn)前端網(wǎng)站F12,在Console中輸入document.cookie='canary =
always'手動(dòng)設(shè)置canary的cookie值。
在Cookies中可以看到設(shè)置,此時(shí)訪問(wèn)前端網(wǎng)站為灰度版本。
如果刪除canary的cookie,此時(shí)訪問(wèn)前端網(wǎng)站為正常版本
后端Postman測(cè)試
使用Postman訪問(wèn)后端接口,在請(qǐng)求頭中輸入canary = always。此時(shí)訪問(wèn)后端服務(wù)為灰度版本。
如果刪除canary的請(qǐng)求頭,此時(shí)訪問(wèn)后端服務(wù)為正常版本
感謝各位的閱讀,以上就是“Kubernetes如何實(shí)現(xiàn)前后端應(yīng)用的金絲雀發(fā)布”的內(nèi)容了,經(jīng)過(guò)本文的學(xué)習(xí)后,相信大家對(duì)Kubernetes如何實(shí)現(xiàn)前后端應(yīng)用的金絲雀發(fā)布這一問(wèn)題有了更深刻的體會(huì),具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云,小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章,歡迎關(guān)注!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。