騰訊云手把手教你使用Nginx Ingress實(shí)現(xiàn)金絲雀發(fā)布

概述

本文將介紹如何使用Nginx Ingress實(shí)現(xiàn)金絲雀發(fā)布，從使用場景分析，到用法詳解，再到上手實(shí)踐。

前提條件

集群中需要部署Nginx Ingress作為Ingress Controller，并且對外暴露了統(tǒng)一的流量入口，參考Nginx Ingress on TKE部署最佳實(shí)踐。

Nginx Ingress可以用在哪些發(fā)布場景?

使用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注釋都將被忽略。

上手實(shí)踐

下面我們給出一些例子，讓你快速上手Nginx Ingress的金絲雀發(fā)布，環(huán)境為TKE集群。

使用YAML創(chuàng)建資源

本文的示例將使用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。

部署兩個版本的服務(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，實(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: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ā)給當(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)重的流量切分

基于服務(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ù)也還是必須存在，不然會報錯。

總結(jié)

本文全方位總結(jié)了Nginx Ingress的金絲雀發(fā)布用法，雖然Nginx Ingress在金絲雀發(fā)布這方面的能力有限，并且還存在一些缺陷，但基本也能覆蓋一些常見的場景，如果集群中使用了Nginx Ingress，并且發(fā)布的需求也不復(fù)雜，可以考慮使用這種方案。

參考資料

Nginx Ingress金絲雀注解官方文檔:https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#canary

Nginx Ingress on TKE部署最佳實(shí)踐:https://mp.weixin.qq.com/s/NAwz4dlsPuJnqfWYBHkfGg