手把手教你使用 Nginx Ingress 實現金絲雀釋出

騰訊雲原生發表於2020-10-23

概述

本文將介紹如何使用 Nginx Ingress 實現金絲雀釋出，從使用場景分析，到用法詳解，再到上手實踐。

前提條件

叢集中需要部署 Nginx Ingress 作為 Ingress Controller，並且對外暴露了統一的流量入口，參考在 TKE 上部署 Nginx Ingress。

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 建立資源

本文的示例將使用 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 金絲雀註解官方文件: https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary
在 TKE 上部署 Nginx Ingress: https://cloud.tencent.com/document/product/457/47293

【騰訊雲原生】雲說新品、雲研新術、雲遊新活、雲賞資訊，掃碼關注同名公眾號，及時獲取更多幹貨！！

使用Kubernetes演示金絲雀釋出
2019-04-20
Isito 入門（八）：金絲雀釋出
2023-11-02
kubernetes實踐之六十六：Istio實現金絲雀釋出原理
2018-07-25
基於Kubernetes實現前後端應用的金絲雀釋出
2021-12-06
後端
Istio Routing 實踐掌握virtualservice/gateway/destinationrule/AB版本釋出/金絲雀釋出
2020-08-18
Gateway
Kubernetes 使用 Ingress-nginx 實現灰度釋出功能
2020-11-09
Nginx
使用Knative和Tekton在Kubernetes上釋出金絲雀版本 - Piotr
2022-03-30
你要的 Helm Chart 應用金絲雀釋出終於來了！
2022-08-12
Linkerd 2.10(Step by Step)—2. 自動化的金絲雀釋出
2021-06-13
CODING DevOps + Nginx-ingress 實現自動化灰度釋出
2020-07-23
devNginx
手把手教你在Nginx上使用CertBot
2016-06-25
Nginx
使用 Flux+Flagger+Istio+Kubernetes 實戰 GitOps 雲原生漸進式(金絲雀)交付
2021-06-02
UXGit
手把手教你封裝 Vue 元件，並使用 npm 釋出
2018-07-11
封裝Vue元件NPM
nginx 實現實用的灰度釋出
2019-10-29
Nginx
nginx+lua+redis實現灰度釋出
2023-12-18
NginxRedis
手把手教你釋出一個Python包
2018-08-07
Python
手把手教你實現boost::bind
2018-04-16
手把手教你在 TKE 叢集中實現簡單的藍綠髮布和灰度釋出
2020-09-27
手摸手教你把Ingress Nginx整合進Skywalking
2024-04-23
Nginx
手把手教你擼出跑男動畫 CSS3-Animation抽絲剝繭
2017-03-14
動畫CSSS3
Kubernetes Ingress-nginx使用
2020-12-03
Nginx
手把手教你搭建一個灰度釋出環境
2020-03-31
Nginx Ingress 高併發實踐
2020-09-02
Nginx
手把手教你如何實現繼承
2018-03-15
繼承
手把手教你釋出一個vue元件到npm上
2019-03-01
Vue元件NPM
Apache APISIX Ingress 1.6 正式釋出！
2023-01-10
ApacheAPI
手把手教你用Java實現AOP
2015-03-29
Java
Ingress-nginx工作原理和實踐
2021-03-18
Nginx
除錯 Ingress Nginx
2020-08-26
除錯Nginx
手把手教你實現H5微信分享
2019-04-18
H5
手把手教你實現一個引導動畫
2018-10-07
動畫
手把手教你實現一個完整的 Promise
2016-11-15
Promise
手把手教你使用 ArkTS 中的 canvas 實現簽名板功能
2023-12-20
Canvas
Git + Jenkins 自動化 NGINX 釋出簡易實現
2023-01-27
GitJenkinsNginx
實戰四：手把手教你實現數字識別
2019-04-10
kubernetes之Ingress釋出Dashboard(二)
2023-02-27
使用騰訊雲容器服務玩轉 Nginx Ingress
2020-12-28
Nginx
使用Ingress-Nginx來暴露ArgoCD Web-UI
2023-03-05
NginxGoWebUI

手把手教你使用 Nginx Ingress 實現金絲雀釋出

概述

前提條件

Nginx Ingress 可以用在哪些釋出場景 ?

場景一: 將新版本灰度給部分使用者

場景二: 切一定比例的流量給新版本

註解說明

上手實踐

使用 YAML 建立資源

部署兩個版本的服務

基於 Header 的流量切分

基於 Cookie 的流量切分

基於服務權重的流量切分

存在的缺陷

總結

參考資料

相關文章