您好,登錄后才能下訂單哦!
本篇文章為大家展示了如何使用 Nginx Ingress 實(shí)現(xiàn)金絲雀發(fā)布,內(nèi)容簡明扼要并且容易理解,絕對能使你眼前一亮,通過這篇文章的詳細(xì)介紹希望你能有所收獲。
集群中需要部署 Nginx Ingress 作為 Ingress Controller,并且對外暴露了統(tǒng)一的流量入口,參考 在 TKE 上部署 Nginx Ingress。
使用 Nginx Ingress 來實(shí)現(xiàn)金絲雀發(fā)布,可以用在哪些場景呢?這個主要看使用什么策略進(jìn)行流量切分,目前 Nginx Ingress 支持基于 Header、Cookie 和服務(wù)權(quán)重這 3 種流量切分的策略,基于它們可以實(shí)現(xiàn)以下兩種發(fā)布場景。
假設(shè)線上運(yùn)行了一套對外提供 7 層服務(wù)的 Service A 服務(wù),后來開發(fā)了個新版本 Service A' 想要上線,但又不想直接替換掉原來的 Service A,希望先灰度一小部分用戶,等運(yùn)行一段時間足夠穩(wěn)定了再逐漸全量上線新版本,最后平滑下線舊版本。這個時候就可以利用 Nginx Ingress 基于 Header 或 Cookie 進(jìn)行流量切分的策略來發(fā)布,業(yè)務(wù)使用 Header 或 Cookie 來標(biāo)識不同類型的用戶,我們通過配置 Ingress 來實(shí)現(xiàn)讓帶有指定 Header 或 Cookie 的請求被轉(zhuǎn)發(fā)到新版本,其它的仍然轉(zhuǎn)發(fā)到舊版本,從而實(shí)現(xiàn)將新版本灰度給部分用戶:
假設(shè)線上運(yùn)行了一套對外提供 7 層服務(wù)的 Service B 服務(wù),后來修復(fù)了一些問題,需要灰度上線一個新版本 Service B',但又不想直接替換掉原來的 Service B,而是讓先切 10% 的流量到新版本,等觀察一段時間穩(wěn)定后再逐漸加大新版本的流量比例直至完全替換舊版本,最后再滑下線舊版本,從而實(shí)現(xiàn)切一定比例的流量給新版本:
我們通過給 Ingress 資源指定 Nginx Ingress 所支持的一些 annotation 可以實(shí)現(xiàn)金絲雀發(fā)布,需要給服務(wù)創(chuàng)建兩個 Ingress,一個正常的 Ingress,另一個是帶 nginx.ingress.kubernetes.io/canary: "true"
這個固定的 annotation 的 Ingress,我們姑且稱它為 Canary Ingress,一般代表新版本的服務(wù),結(jié)合另外針對流量切分策略的 annotation 一起配置即可實(shí)現(xiàn)多種場景的金絲雀發(fā)布,以下對這些 annotation 詳細(xì)介紹下:
nginx.ingress.kubernetes.io/canary-by-header
: 表示如果請求頭中包含這里指定的 header 名稱,并且值為 always
的話,就將該請求轉(zhuǎn)發(fā)給該 Ingress 定義的對應(yīng)后端服務(wù);如果值為 never
就不轉(zhuǎn)發(fā),可以用于回滾到舊版;如果是其它值則忽略該 annotation。
nginx.ingress.kubernetes.io/canary-by-header-value
: 這個可以作為 canary-by-header
的補(bǔ)充,允許指定請求頭的值可以自定義成其它值,不再只能是 always
或 never
;當(dāng)請求頭的值命中這里的自定義值時,請求將會轉(zhuǎn)發(fā)給該 Ingress 定義的對應(yīng)后端服務(wù),如果是其它值則將會忽略該 annotation。
nginx.ingress.kubernetes.io/canary-by-header-pattern
: 這個與上面的 canary-by-header-value
類似,唯一的區(qū)別是它是用正則表達(dá)式對來匹配請求頭的值,而不是只固定某一個值;需要注意的是,如果它與 canary-by-header-value
同時存在,這個 annotation 將會被忽略。
nginx.ingress.kubernetes.io/canary-by-cookie
: 這個與 canary-by-header
類似,只是這個用于 cookie,同樣也是只支持 always
和 never
的值。
nginx.ingress.kubernetes.io/canary-weight
: 表示 Canary Ingress 所分配流量的比例的百分比,取值范圍 [0-100],比如設(shè)置為 10,意思是分配 10% 的流量給 Canary Ingress 對應(yīng)的后端服務(wù)。
上面的規(guī)則會按優(yōu)先順序進(jìn)行評估,優(yōu)先順序如下: canary-by-header -> canary-by-cookie -> canary-weight
注意: 當(dāng) Ingress 被標(biāo)記為 Canary Ingress 時,除了nginx.ingress.kubernetes.io/load-balance
和 nginx.ingress.kubernetes.io/upstream-hash-by
之外,所有其他非 Canary 注釋都將被忽略。
下面我們給出一些例子,讓你快速上手 Nginx Ingress 的金絲雀發(fā)布,環(huán)境為 TKE 集群。
本文的示例將使用 yaml 的方式部署工作負(fù)載和創(chuàng)建 Service,有兩種操作方式。
方式一:在 TKE 或 EKS 控制臺右上角點(diǎn)擊 YAML 創(chuàng)建資源
,然后將本文示例的 yaml 粘貼進(jìn)去:
方式二:將示例的 yaml 保存成文件,然后使用 kubectl 指定 yaml 文件來創(chuàng)建,如: kubectl apply -f xx.yaml
。
這里以簡單的 nginx 為例,先部署一個 v1 版本:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-v1 spec: replicas: 1 selector: matchLabels: app: nginx version: v1 template: metadata: labels: app: nginx version: v1 spec: containers: - name: nginx image: "openresty/openresty:centos" ports: - name: http protocol: TCP containerPort: 80 volumeMounts: - mountPath: /usr/local/openresty/nginx/conf/nginx.conf name: config subPath: nginx.conf volumes: - name: config configMap: name: nginx-v1 --- apiVersion: v1 kind: ConfigMap metadata: labels: app: nginx version: v1 name: nginx-v1 data: nginx.conf: |- worker_processes 1; events { accept_mutex on; multi_accept on; use epoll; worker_connections 1024; } http { ignore_invalid_headers off; server { listen 80; location / { access_by_lua ' local header_str = ngx.say("nginx-v1") '; } } } --- apiVersion: v1 kind: Service metadata: name: nginx-v1 spec: type: ClusterIP ports: - port: 80 protocol: TCP name: http selector: app: nginx version: v1
再部署一個 v2 版本:
apiVersion: apps/v1 kind: Deployment metadata: name: nginx-v2 spec: replicas: 1 selector: matchLabels: app: nginx version: v2 template: metadata: labels: app: nginx version: v2 spec: containers: - name: nginx image: "openresty/openresty:centos" ports: - name: http protocol: TCP containerPort: 80 volumeMounts: - mountPath: /usr/local/openresty/nginx/conf/nginx.conf name: config subPath: nginx.conf volumes: - name: config configMap: name: nginx-v2 --- apiVersion: v1 kind: ConfigMap metadata: labels: app: nginx version: v2 name: nginx-v2 data: nginx.conf: |- worker_processes 1; events { accept_mutex on; multi_accept on; use epoll; worker_connections 1024; } http { ignore_invalid_headers off; server { listen 80; location / { access_by_lua ' local header_str = ngx.say("nginx-v2") '; } } } --- apiVersion: v1 kind: Service metadata: name: nginx-v2 spec: type: ClusterIP ports: - port: 80 protocol: TCP name: http selector: app: nginx version: v2
可以在控制臺看到部署的情況:
再創(chuàng)建一個 Ingress,對外暴露服務(wù),指向 v1 版本的服務(wù):
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: nginx annotations: kubernetes.io/ingress.class: nginx spec: rules: - host: canary.example.com http: paths: - backend: serviceName: nginx-v1 servicePort: 80 path: /
訪問驗(yàn)證一下:
$ curl -H "Host: canary.example.com" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對外暴露的 IP nginx-v1
創(chuàng)建 Canary Ingress,指定 v2 版本的后端服務(wù),且加上一些 annotation,實(shí)現(xiàn)僅將帶有名為 Region 且值為 cd 或 sz 的請求頭的請求轉(zhuǎn)發(fā)給當(dāng)前 Canary Ingress,模擬灰度新版本給成都和深圳地域的用戶:
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-header: "Region" nginx.ingress.kubernetes.io/canary-by-header-pattern: "cd|sz" name: nginx-canary spec: rules: - host: canary.example.com http: paths: - backend: serviceName: nginx-v2 servicePort: 80 path: /
測試訪問:
$ curl -H "Host: canary.example.com" -H "Region: cd" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對外暴露的 IP nginx-v2 $ curl -H "Host: canary.example.com" -H "Region: bj" http://EXTERNAL-IP nginx-v1 $ curl -H "Host: canary.example.com" -H "Region: cd" http://EXTERNAL-IP nginx-v2 $ curl -H "Host: canary.example.com" http://EXTERNAL-IP nginx-v1
可以看到,只有 header Region
為 cd 或 sz 的請求才由 v2 版本服務(wù)響應(yīng)。
與前面 Header 類似,不過使用 Cookie 就無法自定義 value 了,這里以模擬灰度成都地域用戶為例,僅將帶有名為 user_from_cd
的 cookie 的請求轉(zhuǎn)發(fā)給當(dāng)前 Canary Ingress 。先刪除前面基于 Header 的流量切分的 Canary Ingress,然后創(chuàng)建下面新的 Canary Ingress:
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-by-cookie: "user_from_cd" name: nginx-canary spec: rules: - host: canary.example.com http: paths: - backend: serviceName: nginx-v2 servicePort: 80 path: /
測試訪問:
$ curl -s -H "Host: canary.example.com" --cookie "user_from_cd=always" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對外暴露的 IP nginx-v2 $ curl -s -H "Host: canary.example.com" --cookie "user_from_bj=always" http://EXTERNAL-IP nginx-v1 $ curl -s -H "Host: canary.example.com" http://EXTERNAL-IP nginx-v1
可以看到,只有 cookie user_from_cd
為 always
的請求才由 v2 版本的服務(wù)響應(yīng)。
基于服務(wù)權(quán)重的 Canary Ingress 就簡單了,直接定義需要導(dǎo)入的流量比例,這里以導(dǎo)入 10% 流量到 v2 版本為例 (如果有,先刪除之前的 Canary Ingress):
apiVersion: extensions/v1beta1 kind: Ingress metadata: annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/canary: "true" nginx.ingress.kubernetes.io/canary-weight: "10" name: nginx-canary spec: rules: - host: canary.example.com http: paths: - backend: serviceName: nginx-v2 servicePort: 80 path: /
測試訪問:
$ for i in {1..10}; do curl -H "Host: canary.example.com" http://EXTERNAL-IP; done; nginx-v1 nginx-v1 nginx-v1 nginx-v1 nginx-v1 nginx-v1 nginx-v2 nginx-v1 nginx-v1 nginx-v1
可以看到,大概只有十分之一的幾率由 v2 版本的服務(wù)響應(yīng),符合 10% 服務(wù)權(quán)重的設(shè)置。
雖然我們使用 Nginx Ingress 實(shí)現(xiàn)了幾種不同姿勢的金絲雀發(fā)布,但還存在一些缺陷:
相同服務(wù)的 Canary Ingress 只能定義一個,所以后端服務(wù)最多支持兩個版本。
Ingress 里必須配置域名,否則不會有效果。
即便流量完全切到了 Canary Ingress 上,舊版服務(wù)也還是必須存在,不然會報(bào)錯。
本文全方位總結(jié)了 Nginx Ingress 的金絲雀發(fā)布用法,雖然 Nginx Ingress 在金絲雀發(fā)布這方面的能力有限,并且還存在一些缺陷,但基本也能覆蓋一些常見的場景,如果集群中使用了 Nginx Ingress,并且發(fā)布的需求也不復(fù)雜,可以考慮使用這種方案。
上述內(nèi)容就是如何使用 Nginx Ingress 實(shí)現(xiàn)金絲雀發(fā)布,你們學(xué)到知識或技能了嗎?如果還想學(xué)到更多技能或者豐富自己的知識儲備,歡迎關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。