使用Nginx Ingress實(shí)現(xiàn)金絲雀發(fā)布
概述
本文將介紹如何使用 Nginx Ingress 實(shí)現(xiàn)金絲雀發(fā)布，從使用場(chǎng)景分析，到用法詳解，再到上手實(shí)踐。
前提條件
集群中需要部署 Nginx Ingress 作為 Ingress Controller，并且對(duì)外暴露了統(tǒng)一的流量入口，參考 Nginx Ingress on TKE 部署最佳實(shí)踐。
Nginx Ingress 可以用在哪些發(fā)布場(chǎng)景 ?
使用 Nginx Ingress 來(lái)實(shí)現(xiàn)金絲雀發(fā)布，可以用在哪些場(chǎng)景呢？這個(gè)主要看使用什么策略進(jìn)行流量切分，目前 Nginx Ingress 支持基于 Header、Cookie 和服務(wù)權(quán)重這 3 種流量切分的策略，基于它們可以實(shí)現(xiàn)以下兩種發(fā)布場(chǎng)景。
場(chǎng)景一: 將新版本灰度給部分用戶 （Header Cookie）
假設(shè)線上運(yùn)行了一套對(duì)外提供 7 層服務(wù)的 Service A 服務(wù)，后來(lái)開發(fā)了個(gè)新版本 Service A' 想要上線，但又不想直接替換掉原來(lái)的 Service A，希望先灰度一小部分用戶，等運(yùn)行一段時(shí)間足夠穩(wěn)定了再逐漸全量上線新版本，最后平滑下線舊版本。
這個(gè)時(shí)候就可以利用 Nginx Ingress 基于 Header 或 Cookie 進(jìn)行流量切分的策略來(lái)發(fā)布，業(yè)務(wù)使用 Header 或 Cookie 來(lái)標(biāo)識(shí)不同類型的用戶，我們通過(guò)配置 Ingress 來(lái)實(shí)現(xiàn)讓帶有指定 Header 或 Cookie 的請(qǐng)求被轉(zhuǎn)發(fā)到新版本，其它的仍然轉(zhuǎn)發(fā)到舊版本，從而實(shí)現(xiàn)將新版本灰度給部分用戶:
場(chǎng)景二: 切一定比例的流量給新版本（權(quán)重）
假設(shè)線上運(yùn)行了一套對(duì)外提供 7 層服務(wù)的 Service B 服務(wù)，后來(lái)修復(fù)了一些問(wèn)題，需要灰度上線一個(gè)新版本 Service B'，但又不想直接替換掉原來(lái)的 Service B，而是讓先切 10% 的流量到新版本，等觀察一段時(shí)間穩(wěn)定后再逐漸加大新版本的流量比例直至完全替換舊版本，最后再滑下線舊版本，從而實(shí)現(xiàn)切一定比例的流量給新版本:
注解說(shuō)明
我們通過(guò)給 Ingress 資源指定 Nginx Ingress 所支持的一些 annotation 可以實(shí)現(xiàn)金絲雀發(fā)布，需要給服務(wù)創(chuàng)建兩個(gè) Ingress，一個(gè)正常的 Ingress，另一個(gè)是帶 nginx.ingress.kubernetes.io/canary: "true" 這個(gè)固定的 annotation 的 Ingress，我們姑且稱它為 Canary Ingress，一般代表新版本的服務(wù)，結(jié)合另外針對(duì)流量切分策略的 annotation 一起配置即可實(shí)現(xiàn)多種場(chǎng)景的金絲雀發(fā)布，以下對(duì)這些 annotation 詳細(xì)介紹下:
- nginx.ingress.kubernetes.io/canary-by-header: 表示如果請(qǐng)求頭中包含這里指定的 header 名稱，并且值為 always 的話，就將該請(qǐng)求轉(zhuǎn)發(fā)給該 Ingress 定義的對(duì)應(yīng)后端服務(wù)；如果值為 never 就不轉(zhuǎn)發(fā)，可以用于回滾到舊版；如果是其它值則忽略該 annotation。
- nginx.ingress.kubernetes.io/canary-by-header-value: 這個(gè)可以作為 canary-by-header的補(bǔ)充，允許指定請(qǐng)求頭的值可以自定義成其它值，不再只能是 always 或 never；當(dāng)請(qǐng)求頭的值命中這里的自定義值時(shí)，請(qǐng)求將會(huì)轉(zhuǎn)發(fā)給該 Ingress 定義的對(duì)應(yīng)后端服務(wù)，如果是其它值則將會(huì)忽略該 annotation。
- nginx.ingress.kubernetes.io/canary-by-header-pattern: 這個(gè)與上面的 canary-by-header-value 類似，唯一的區(qū)別是它是用正則表達(dá)式對(duì)來(lái)匹配請(qǐng)求頭的值，而不是只固定某一個(gè)值；需要注意的是，如果它與 canary-by-header-value 同時(shí)存在，這個(gè) annotation 將會(huì)被忽略。
- nginx.ingress.kubernetes.io/canary-by-cookie: 這個(gè)與 canary-by-header 類似，只是這個(gè)用于 cookie，同樣也是只支持 always 和 never 的值。
- nginx.ingress.kubernetes.io/canary-weight: 表示 Canary Ingress 所分配流量的比例的百分比，取值范圍 [0-100]，比如設(shè)置為 10，意思是分配 10% 的流量給 Canary Ingress 對(duì)應(yīng)的后端服務(wù)。
上面的規(guī)則會(huì)按優(yōu)先順序進(jìn)行評(píng)估，優(yōu)先順序如下：canary-by-header -> canary-by-cookie -> canary-weight
注意: 當(dāng) Ingress 被標(biāo)記為 Canary Ingress 時(shí)，除了nginx.ingress.kubernetes.io/load-balance和 nginx.ingress.kubernetes.io/upstream-hash-by 之外，所有其他非 Canary 注釋都將被忽略。
上手實(shí)踐
下面我們給出一些例子，讓你快速上手 Nginx Ingress 的金絲雀發(fā)布，環(huán)境為 TKE 集群。
使用 YAML 創(chuàng)建資源
本文的示例將使用 yaml 的方式部署工作負(fù)載和創(chuàng)建 Service，有兩種操作方式。
方式一：在 TKE 或 EKS 控制臺(tái)右上角點(diǎn)擊 YAML 創(chuàng)建資源，然后將本文示例的 yaml 粘貼進(jìn)去:
方式二：將示例的 yaml 保存成文件，然后使用 kubectl 指定 yaml 文件來(lái)創(chuàng)建，如: kubectl apply -f xx.yaml 。
部署兩個(gè)版本的服務(wù)
這里以簡(jiǎn)單的 nginx 為例，先部署一個(gè) 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再部署一個(gè) 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可以在控制臺(tái)看到部署的情況:
再創(chuàng)建一個(gè) Ingress，對(duì)外暴露服務(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: /訪問(wèn)驗(yàn)證一下:
$ curl -H "Host: canary.example.com" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對(duì)外暴露的 IP nginx-v1
基于 Header 的流量切分
創(chuàng)建 Canary Ingress，指定 v2 版本的后端服務(wù)，且加上一些 annotation，實(shí)現(xiàn)僅將帶有名為 Region 且值為 cd 或 sz 的請(qǐng)求頭的請(qǐng)求轉(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: /測(cè)試訪問(wèn):
$ curl -H "Host: canary.example.com" -H "Region: cd" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對(duì)外暴露的 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: sz" http://EXTERNAL-IP nginx-v2 $ curl -H "Host: canary.example.com" http://EXTERNAL-IP nginx-v1
可以看到，只有 header Region 為 cd 或 sz 的請(qǐng)求才由 v2 版本服務(wù)響應(yīng)。
基于 Cookie 的流量切分
與前面 Header 類似，不過(guò)使用 Cookie 就無(wú)法自定義 value 了，這里以模擬灰度成都地域用戶為例，僅將帶有名為 user_from_cd 的 cookie 的請(qǐng)求轉(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: /測(cè)試訪問(wèn):
$ curl -s -H "Host: canary.example.com" --cookie "user_from_cd=always" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對(duì)外暴露的 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 的請(qǐng)求才由 v2 版本的服務(wù)響應(yīng)。
基于服務(wù)權(quán)重的流量切分
基于服務(wù)權(quán)重的 Canary Ingress 就簡(jiǎn)單了，直接定義需要導(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: /測(cè)試訪問(wèn):
$ 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)了幾種不同姿勢(shì)的金絲雀發(fā)布，但還存在一些缺陷:
- 相同服務(wù)的 Canary Ingress 只能定義一個(gè)，所以后端服務(wù)最多支持兩個(gè)版本。
- Ingress 里必須配置域名，否則不會(huì)有效果。
- 即便流量完全切到了 Canary Ingress 上，舊版服務(wù)也還是必須存在，不然會(huì)報(bào)錯(cuò)。
總結(jié)
本文全方位總結(jié)了 Nginx Ingress 的金絲雀發(fā)布用法，雖然 Nginx Ingress 在金絲雀發(fā)布這方面的能力有限，并且還存在一些缺陷，但基本也能覆蓋一些常見(jiàn)的場(chǎng)景，如果集群中使用了 Nginx Ingress，并且發(fā)布的需求也不復(fù)雜，可以考慮使用這種方案。
到此這篇關(guān)于使用Nginx Ingress實(shí)現(xiàn)金絲雀發(fā)布的文章就介紹到這了,更多相關(guān)Nginx Ingress金絲雀發(fā)布內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
Nginx實(shí)現(xiàn)接口復(fù)制的示例代碼
本文主要介紹了使用Nginx的mirror指令和Lua腳本實(shí)現(xiàn)接口流復(fù)制,方便將請(qǐng)求同時(shí)轉(zhuǎn)發(fā)到多個(gè)后端服務(wù)器,具有一定的參考價(jià)值,感興趣的可以了解一下2025-01-01
Linux\Nginx 環(huán)境下虛擬域名配置及測(cè)試驗(yàn)證
這篇文章主要介紹了Linux\Nginx 虛擬域名配置及測(cè)試驗(yàn)證的步驟詳解，非常不錯(cuò)，具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2019-11-11
nginx 自定義 404、50x 錯(cuò)誤頁(yè)面的實(shí)現(xiàn)
本文主要介紹了nginx 自定義 404、50x 錯(cuò)誤頁(yè)面的實(shí)現(xiàn),文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2024-12-12
Nginx添加ipv6模塊以及遇到問(wèn)題解決方案詳解(親測(cè)有效)
IPV4日益稀缺,ipv6已經(jīng)慢慢走上日程,待ipv6在國(guó)內(nèi)普及,使用nginx配置ipv6那是肯定的,下面這篇文章主要給大家介紹了關(guān)于Nginx添加ipv6模塊以及遇到問(wèn)題的解決方案,需要的朋友可以參考下2022-09-09
nginx開啟HSTS讓瀏覽器強(qiáng)制跳轉(zhuǎn)HTTPS訪問(wèn)詳解
這篇文章主要介紹了nginx開啟HSTS讓瀏覽器強(qiáng)制跳轉(zhuǎn)HTTPS訪問(wèn)詳解，小編覺(jué)得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過(guò)來(lái)看看吧2019-05-05
root和alias是兩個(gè)重要但經(jīng)常令人混淆的指令,尤其用于指定資源在服務(wù)器文件系統(tǒng)中的位置,本文就來(lái)介紹一下兩個(gè)指令的使用與區(qū)別,感興趣的可以了解一下2024-08-08
Nginx Rewrite規(guī)則與使用介紹和技巧實(shí)例
這篇文章主要介紹了Nginx Rewrite規(guī)則與使用介紹和技巧實(shí)例,本文講解了正則表達(dá)式匹配、文件及目錄匹配、flag標(biāo)記、Nginx Rewrite相關(guān)指令等內(nèi)容,需要的朋友可以參考下2015-01-01
網(wǎng)頁(yè)502?Bad?Gateway?nginx/1.20.1報(bào)錯(cuò)的原因與解決方法
502 bad gateway nginx/1.20.1 是一個(gè)錯(cuò)誤提示,通常出現(xiàn)在訪問(wèn)網(wǎng)站時(shí)出現(xiàn)問(wèn)題,這篇文章主要給大家介紹了關(guān)于網(wǎng)頁(yè)502?Bad?Gateway?nginx/1.20.1報(bào)錯(cuò)的原因與解決方法,需要的朋友可以參考下2024-03-03
nginx容器配置文件獨(dú)立的實(shí)現(xiàn)
本文主要介紹了nginx容器配置文件獨(dú)立，文中通過(guò)示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2021-12-12
Nginx基礎(chǔ)學(xué)習(xí)之realip模塊的使用方法
這篇文章主要給大家介紹了關(guān)于Nginx基礎(chǔ)學(xué)習(xí)之realip模塊使用的相關(guān)資料，文中通過(guò)示例代碼介紹的非常詳細(xì)，對(duì)大家學(xué)習(xí)或者使用Nginx具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來(lái)一起學(xué)習(xí)學(xué)習(xí)吧2020-06-06