溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章為大家展示了如何使用 Nginx Ingress 實現金絲雀發布，內容簡明扼要并且容易理解，絕對能使你眼前一亮，通過這篇文章的詳細介紹希望你能有所收獲。
集群中需要部署 Nginx Ingress 作為 Ingress Controller，并且對外暴露了統一的流量入口，參考 在 TKE 上部署 Nginx Ingress。
使用 Nginx Ingress 來實現金絲雀發布，可以用在哪些場景呢？這個主要看使用什么策略進行流量切分，目前 Nginx Ingress 支持基于 Header、Cookie 和服務權重這 3 種流量切分的策略，基于它們可以實現以下兩種發布場景。
假設線上運行了一套對外提供 7 層服務的 Service A 服務，后來開發了個新版本 Service A' 想要上線，但又不想直接替換掉原來的 Service A，希望先灰度一小部分用戶，等運行一段時間足夠穩定了再逐漸全量上線新版本，最后平滑下線舊版本。這個時候就可以利用 Nginx Ingress 基于 Header 或 Cookie 進行流量切分的策略來發布，業務使用 Header 或 Cookie 來標識不同類型的用戶，我們通過配置 Ingress 來實現讓帶有指定 Header 或 Cookie 的請求被轉發到新版本，其它的仍然轉發到舊版本，從而實現將新版本灰度給部分用戶:
假設線上運行了一套對外提供 7 層服務的 Service B 服務，后來修復了一些問題，需要灰度上線一個新版本 Service B'，但又不想直接替換掉原來的 Service B，而是讓先切 10% 的流量到新版本，等觀察一段時間穩定后再逐漸加大新版本的流量比例直至完全替換舊版本，最后再滑下線舊版本，從而實現切一定比例的流量給新版本:
我們通過給 Ingress 資源指定 Nginx Ingress 所支持的一些 annotation 可以實現金絲雀發布，需要給服務創建兩個 Ingress，一個正常的 Ingress，另一個是帶 nginx.ingress.kubernetes.io/canary: "true" 這個固定的 annotation 的 Ingress，我們姑且稱它為 Canary Ingress，一般代表新版本的服務，結合另外針對流量切分策略的 annotation 一起配置即可實現多種場景的金絲雀發布，以下對這些 annotation 詳細介紹下:
nginx.ingress.kubernetes.io/canary-by-header: 表示如果請求頭中包含這里指定的 header 名稱，并且值為 always 的話，就將該請求轉發給該 Ingress 定義的對應后端服務；如果值為 never 就不轉發，可以用于回滾到舊版；如果是其它值則忽略該 annotation。
nginx.ingress.kubernetes.io/canary-by-header-value: 這個可以作為 canary-by-header的補充，允許指定請求頭的值可以自定義成其它值，不再只能是 always 或 never；當請求頭的值命中這里的自定義值時，請求將會轉發給該 Ingress 定義的對應后端服務，如果是其它值則將會忽略該 annotation。
nginx.ingress.kubernetes.io/canary-by-header-pattern: 這個與上面的 canary-by-header-value 類似，唯一的區別是它是用正則表達式對來匹配請求頭的值，而不是只固定某一個值；需要注意的是，如果它與 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]，比如設置為 10，意思是分配 10% 的流量給 Canary Ingress 對應的后端服務。
上面的規則會按優先順序進行評估，優先順序如下： 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 的金絲雀發布，環境為 TKE 集群。
本文的示例將使用 yaml 的方式部署工作負載和創建 Service，有兩種操作方式。
方式一：在 TKE 或 EKS 控制臺右上角點擊 YAML 創建資源，然后將本文示例的 yaml 粘貼進去:
方式二：將示例的 yaml 保存成文件，然后使用 kubectl 指定 yaml 文件來創建，如: 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可以在控制臺看到部署的情況:
再創建一個 Ingress，對外暴露服務，指向 v1 版本的服務:
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
創建 Canary Ingress，指定 v2 版本的后端服務，且加上一些 annotation，實現僅將帶有名為 Region 且值為 cd 或 sz 的請求頭的請求轉發給當前 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 版本服務響應。
與前面 Header 類似，不過使用 Cookie 就無法自定義 value 了，這里以模擬灰度成都地域用戶為例，僅將帶有名為 user_from_cd 的 cookie 的請求轉發給當前 Canary Ingress 。先刪除前面基于 Header 的流量切分的 Canary Ingress，然后創建下面新的 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 版本的服務響應。
基于服務權重的 Canary Ingress 就簡單了，直接定義需要導入的流量比例，這里以導入 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 版本的服務響應，符合 10% 服務權重的設置。
雖然我們使用 Nginx Ingress 實現了幾種不同姿勢的金絲雀發布，但還存在一些缺陷:
相同服務的 Canary Ingress 只能定義一個，所以后端服務最多支持兩個版本。
Ingress 里必須配置域名，否則不會有效果。
即便流量完全切到了 Canary Ingress 上，舊版服務也還是必須存在，不然會報錯。
本文全方位總結了 Nginx Ingress 的金絲雀發布用法，雖然 Nginx Ingress 在金絲雀發布這方面的能力有限，并且還存在一些缺陷，但基本也能覆蓋一些常見的場景，如果集群中使用了 Nginx Ingress，并且發布的需求也不復雜，可以考慮使用這種方案。
上述內容就是如何使用 Nginx Ingress 實現金絲雀發布，你們學到知識或技能了嗎？如果還想學到更多技能或者豐富自己的知識儲備，歡迎關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
