使用Nginx Ingress實現(xiàn)金絲雀發(fā)布
概述
本文將介紹如何使用 Nginx Ingress 實現(xiàn)金絲雀發(fā)布，從使用場景分析，到用法詳解，再到上手實踐。
前提條件
集群中需要部署 Nginx Ingress 作為 Ingress Controller，并且對外暴露了統(tǒng)一的流量入口，參考 Nginx Ingress on TKE 部署最佳實踐。
Nginx Ingress 可以用在哪些發(fā)布場景 ?
使用 Nginx Ingress 來實現(xiàn)金絲雀發(fā)布，可以用在哪些場景呢？這個主要看使用什么策略進行流量切分，目前 Nginx Ingress 支持基于 Header、Cookie 和服務(wù)權(quán)重這 3 種流量切分的策略，基于它們可以實現(xiàn)以下兩種發(fā)布場景。
場景一: 將新版本灰度給部分用戶 （Header Cookie）
假設(shè)線上運行了一套對外提供 7 層服務(wù)的 Service A 服務(wù)，后來開發(fā)了個新版本 Service A' 想要上線，但又不想直接替換掉原來的 Service A，希望先灰度一小部分用戶，等運行一段時間足夠穩(wěn)定了再逐漸全量上線新版本，最后平滑下線舊版本。
這個時候就可以利用 Nginx Ingress 基于 Header 或 Cookie 進行流量切分的策略來發(fā)布，業(yè)務(wù)使用 Header 或 Cookie 來標識不同類型的用戶，我們通過配置 Ingress 來實現(xiàn)讓帶有指定 Header 或 Cookie 的請求被轉(zhuǎn)發(fā)到新版本，其它的仍然轉(zhuǎn)發(fā)到舊版本，從而實現(xiàn)將新版本灰度給部分用戶:
場景二: 切一定比例的流量給新版本（權(quán)重）
假設(shè)線上運行了一套對外提供 7 層服務(wù)的 Service B 服務(wù)，后來修復(fù)了一些問題，需要灰度上線一個新版本 Service B'，但又不想直接替換掉原來的 Service B，而是讓先切 10% 的流量到新版本，等觀察一段時間穩(wěn)定后再逐漸加大新版本的流量比例直至完全替換舊版本，最后再滑下線舊版本，從而實現(xiàn)切一定比例的流量給新版本:
注解說明
我們通過給 Ingress 資源指定 Nginx Ingress 所支持的一些 annotation 可以實現(xiàn)金絲雀發(fā)布，需要給服務(wù)創(chuàng)建兩個 Ingress，一個正常的 Ingress，另一個是帶 nginx.ingress.kubernetes.io/canary: "true" 這個固定的 annotation 的 Ingress，我們姑且稱它為 Canary Ingress，一般代表新版本的服務(wù)，結(jié)合另外針對流量切分策略的 annotation 一起配置即可實現(xiàn)多種場景的金絲雀發(fā)布，以下對這些 annotation 詳細介紹下:
- 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的補充，允許指定請求頭的值可以自定義成其它值，不再只能是 always 或 never；當請求頭的值命中這里的自定義值時，請求將會轉(zhuǎn)發(fā)給該 Ingress 定義的對應(yīng)后端服務(wù)，如果是其它值則將會忽略該 annotation。
- nginx.ingress.kubernetes.io/canary-by-header-pattern: 這個與上面的 canary-by-header-value 類似，唯一的區(qū)別是它是用正則表達式對來匹配請求頭的值，而不是只固定某一個值；需要注意的是，如果它與 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)先順序進行評估，優(yōu)先順序如下：canary-by-header -> canary-by-cookie -> canary-weight
注意: 當 Ingress 被標記為 Canary Ingress 時，除了nginx.ingress.kubernetes.io/load-balance和 nginx.ingress.kubernetes.io/upstream-hash-by 之外，所有其他非 Canary 注釋都將被忽略。
上手實踐
下面我們給出一些例子，讓你快速上手 Nginx Ingress 的金絲雀發(fā)布，環(huán)境為 TKE 集群。
使用 YAML 創(chuàng)建資源
本文的示例將使用 yaml 的方式部署工作負載和創(chuàng)建 Service，有兩種操作方式。
方式一：在 TKE 或 EKS 控制臺右上角點擊 YAML 創(chuàng)建資源，然后將本文示例的 yaml 粘貼進去:
方式二：將示例的 yaml 保存成文件，然后使用 kubectl 指定 yaml 文件來創(chuàng)建，如: kubectl apply -f xx.yaml 。
部署兩個版本的服務(wù)
這里以簡單的 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: /訪問驗證一下:
$ curl -H "Host: canary.example.com" http://EXTERNAL-IP # EXTERNAL-IP 替換為 Nginx Ingress 自身對外暴露的 IP nginx-v1
基于 Header 的流量切分
創(chuàng)建 Canary Ingress，指定 v2 版本的后端服務(wù)，且加上一些 annotation，實現(xiàn)僅將帶有名為 Region 且值為 cd 或 sz 的請求頭的請求轉(zhuǎn)發(fā)給當前 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: sz" http://EXTERNAL-IP nginx-v2 $ curl -H "Host: canary.example.com" http://EXTERNAL-IP nginx-v1
可以看到，只有 header Region 為 cd 或 sz 的請求才由 v2 版本服務(wù)響應(yīng)。
基于 Cookie 的流量切分
與前面 Header 類似，不過使用 Cookie 就無法自定義 value 了，這里以模擬灰度成都地域用戶為例，僅將帶有名為 user_from_cd 的 cookie 的請求轉(zhuǎn)發(fā)給當前 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)重的流量切分
基于服務(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 實現(xiàn)了幾種不同姿勢的金絲雀發(fā)布，但還存在一些缺陷:
- 相同服務(wù)的 Canary Ingress 只能定義一個，所以后端服務(wù)最多支持兩個版本。
- Ingress 里必須配置域名，否則不會有效果。
- 即便流量完全切到了 Canary Ingress 上，舊版服務(wù)也還是必須存在，不然會報錯。
總結(jié)
本文全方位總結(jié)了 Nginx Ingress 的金絲雀發(fā)布用法，雖然 Nginx Ingress 在金絲雀發(fā)布這方面的能力有限，并且還存在一些缺陷，但基本也能覆蓋一些常見的場景，如果集群中使用了 Nginx Ingress，并且發(fā)布的需求也不復(fù)雜，可以考慮使用這種方案。
到此這篇關(guān)于使用Nginx Ingress實現(xiàn)金絲雀發(fā)布的文章就介紹到這了,更多相關(guān)Nginx Ingress金絲雀發(fā)布內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
web頁面做了一個功能,在websocket請求失敗的情況,會定時向服務(wù)端進行重試進行建立連接,這篇文章給大家介紹NGINX阻止指定ip的請求問題及解決方案,感興趣的朋友一起看看吧2024-02-02
這篇文章主要介紹了nginx源碼分析configure腳本詳解的相關(guān)資料,需要的朋友可以參考下2017-05-05
這篇文章主要介紹了nginx下gzip配置參數(shù)詳解,本文同時給出了配置例子,以及一些注意事項,需要的朋友可以參考下2014-08-08
Nginx中使用Lua腳本與圖片的縮略圖處理的實現(xiàn)
本文主要介紹了Nginx中使用Lua腳本與圖片的縮略圖處理的實現(xiàn)，文中通過示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-03-03
nginx界面管理工具之nginxWebUI?搭建與使用方法
本文主要介紹了nginx界面管理工具之nginxWebUI?搭建與使用方法2024-08-08
本文主要介紹了nginx訪問路徑映射資源目錄,Nginx映射資源目錄是指在Nginx配置文件中設(shè)定規(guī)則,使得當客戶端向Nginx服務(wù)器發(fā)送請求訪問某個URL時,Nginx能夠?qū)⒃揢RL映射到服務(wù)器本地的實際文件目錄,感興趣的可以了解一下2024-06-06
今天小編就為大家分享一篇關(guān)于Nginx的信號控制，小編覺得內(nèi)容挺不錯的，現(xiàn)在分享給大家，具有很好的參考價值，需要的朋友一起跟隨小編來看看吧2018-10-10
本文主要介紹了檢查 Nginx 是否啟動的幾種方法,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧2025-12-12
這篇文章主要介紹了Nginx安裝與使用教程詳解的相關(guān)資料2016-09-09
這篇文章主要介紹了分布式限流之Nginx層限流方式,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-08-08