今天就跟大家聊聊有關KubeSphere基于Ingress-Nginx怎樣實現(xiàn)灰度發(fā)布，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

利州ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：13518219792（備注：SSL證書合作）期待與您的合作！

在 Bookinfo 微服務的灰度發(fā)布示例 中，KubeSphere 基于 Istio 對 Bookinfo 微服務示例應用實現(xiàn)了灰度發(fā)布。有用戶表示自己的項目還沒有上 Istio，要如何實現(xiàn)灰度發(fā)布？

在 Ingress-Nginx (0.21.0 版本) 中，引入了一個新的 Canary 功能，可用于為網(wǎng)關入口配置多個后端服務，還可以使用指定的 annotation 來控制多個后端服務之間的流量分配。 KubeSphere 在 2.0.2 的版本 中，升級了項目網(wǎng)關 (Ingress Controller) 版本至 0.24.1，支持基于 Ingress-Nginx 的灰度發(fā)布。

小編將直接介紹和演示基于 KubeSphere 使用應用路由 (Ingress) 和項目網(wǎng)關 (Ingress Controller) 實現(xiàn)灰度發(fā)布。

說明： 本文用到的示例 yaml 源文件及代碼已上傳至 GitHub，可 clone 至本地方便參考。

Ingress-Nginx Annotation 簡介

KubeSphere 基于 Nginx Ingress Controller 實現(xiàn)了項目的網(wǎng)關，作為項目對外的流量入口和項目中各個服務的反向代理。而 Ingress-Nginx 支持配置 Ingress Annotations 來實現(xiàn)不同場景下的灰度發(fā)布和測試，可以滿足金絲雀發(fā)布、藍綠部署與 A/B 測試等業(yè)務場景。

Nginx Annotations 支持以下 4 種 Canary 規(guī)則：

• nginx.ingress.kubernetes.io/canary-by-header：基于 Request Header 的流量切分，適用于灰度發(fā)布以及 A/B 測試。當 Request Header 設置為 always 時，請求將會被一直發(fā)送到 Canary 版本；當 Request Header 設置為 never 時，請求不會被發(fā)送到 Canary 入口；對于任何其他 Header 值，將忽略 Header，并通過優(yōu)先級將請求與其他金絲雀規(guī)則進行優(yōu)先級的比較。

• nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用于通知 Ingress 將請求路由到 Canary Ingress 中指定的服務。當 Request Header 設置為此值時，它將被路由到 Canary 入口。該規(guī)則允許用戶自定義 Request Header 的值，必須與上一個 annotation (即：canary-by-header）一起使用。

• nginx.ingress.kubernetes.io/canary-weight：基于服務權重的流量切分，適用于藍綠部署，權重范圍 0 - 100 按百分比將請求路由到 Canary Ingress 中指定的服務。權重為 0 意味著該金絲雀規(guī)則不會向 Canary 入口的服務發(fā)送任何請求。權重為 100 意味著所有請求都將被發(fā)送到 Canary 入口。

• nginx.ingress.kubernetes.io/canary-by-cookie：基于 Cookie 的流量切分，適用于灰度發(fā)布與 A/B 測試。用于通知 Ingress 將請求路由到 Canary Ingress 中指定的服務的cookie。當 cookie 值設置為 always 時，它將被路由到 Canary 入口；當 cookie 值設置為 never 時，請求不會被發(fā)送到 Canary 入口；對于任何其他值，將忽略 cookie 并將請求與其他金絲雀規(guī)則進行優(yōu)先級的比較。

注意：金絲雀規(guī)則按優(yōu)先順序進行如下排序：

canary-by-header - > canary-by-cookie - > canary-weight

把以上的四個 annotation 規(guī)則可以總體劃分為以下兩類：

• 基于權重的 Canary 規(guī)則

• 基于用戶請求的 Canary 規(guī)則

第一步：創(chuàng)建項目和 Production 版本的應用

1.1. 在 KubeSphere 中創(chuàng)建一個企業(yè)空間 (workspace) 和項目 (namespace) ，可參考 多租戶管理快速入門。如下已創(chuàng)建了一個示例項目。

1.2. 為了快速創(chuàng)建應用，在項目中創(chuàng)建工作負載和服務時可通過 編輯 yaml 的方式，或使用 KubeSphere 右下角的工具箱打開 web kubectl 并使用以下命令和 yaml 文件創(chuàng)建一個 Production 版本的應用并暴露給集群外訪問。如下創(chuàng)建 Production 版本的 deployment 和 service。

$ kubectl appy -f production.yaml -n ingress-demo
deployment.extensions/production created
service/production created

其中用到的 yaml 文件如下：

production.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: production
spec:
  replicas: 1
  selector:
    matchLabels:
      app: production
  template:
    metadata:
      labels:
        app: production
    spec:
      containers:
      - name: production
        image: mirrorgooglecontainers/echoserver:1.10
        ports:
        - containerPort: 8080
        env:
          - name: NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: POD_NAME
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: POD_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: POD_IP
            valueFrom:
              fieldRef:
                fieldPath: status.podIP

---

apiVersion: v1
kind: Service
metadata:
  name: production
  labels:
    app: production
spec:
  ports:
  - port: 80
    targetPort: 8080
    protocol: TCP
    name: http
  selector:
    app: production

1.3. 創(chuàng)建 Production 版本的應用路由 (Ingress)。

$ kubectl appy -f production.ingress -n ingress-demo
ingress.extensions/production created

其中用到的 yaml 文件如下：

production.ingress

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: production
  annotations:
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: kubesphere.io
    http:
      paths:
      - backend:
          serviceName: production
          servicePort: 80

第二步：訪問 Production 版本的應用

2.1. 此時，在 KubeSphere UI 的企業(yè)空間 demo-workspace 下，可以看到 ingress-demo 項目下的所有資源。

Deployment

Service

Ingress

2.2. 訪問 Production 版本的應用需確保當前項目已開啟了網(wǎng)關，在外網(wǎng)訪問下打開網(wǎng)關，類型為 NodePort。

2.3. 如下訪問 Production 版本的應用。

$ curl kubesphere.io:30205

Hostname: production-6b4bb8d58d-7r889

Pod Information:
	node name:	ks-allinone
	pod name:	production-6b4bb8d58d-7r889
	pod namespace:	ingress-demo
	pod IP:	10.233.87.165

Server values:
	server_version=nginx: 1.12.2 - lua: 10010

Request Information:
	client_address=10.233.87.225
	method=GET
	real path=/
	query=
	request_version=1.1
	request_scheme=http
	request_uri=http://kubesphere.io:8080/

Request Headers:
	accept=*/*
	host=kubesphere.io:30205
	user-agent=curl/7.29.0
apiVersion: extensions/v1beta1
	x-forwarded-for=192.168.0.88
	x-forwarded-host=kubesphere.io:30205
	x-forwarded-port=80
	x-forwarded-proto=http
	x-original-uri=/
	x-real-ip=192.168.0.88
	x-request-id=9596df96e994ea05bece2ebbe689a2cc
	x-scheme=http

Request Body:
	-no body in request-

第三步：創(chuàng)建 Canary 版本

參考將上述 Production 版本的 production.yaml 文件，再創(chuàng)建一個 Canary 版本的應用，包括一個 Canary 版本的 deployment 和 service (為方便快速演示，僅需將 production.yaml 的 deployment 和 service 中的關鍵字 production 直接替換為 canary，實際場景中可能涉及業(yè)務代碼變更)。

第四步：Ingress-Nginx Annotation 規(guī)則

基于權重 (Weight)

基于權重的流量切分的典型應用場景就是藍綠部署，可通過將權重設置為 0 或 100 來實現(xiàn)。例如，可將 Green 版本設置為主要部分，并將 Blue 版本的入口配置為 Canary。最初，將權重設置為 0，因此不會將流量代理到 Blue 版本。一旦新版本測試和驗證都成功后，即可將 Blue 版本的權重設置為 100，即所有流量從 Green 版本轉向 Blue。

4.1. 使用以下 canary.ingress 的 yaml 文件再創(chuàng)建一個基于權重的 Canary 版本的應用路由 (Ingress)。

注意：要開啟灰度發(fā)布機制，首先需設置 nginx.ingress.kubernetes.io/canary: "true" 啟用 Canary，以下 Ingress 示例的 Canary 版本使用了基于權重進行流量切分的 annotation 規(guī)則，將分配 30%的流量請求發(fā)送至 Canary 版本。

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: canary
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "30"
spec:
  rules:
  - host: kubesphere.io
    http:
      paths:
      - backend:
          serviceName: canary
          servicePort: 80

4.2. 訪問應用的域名。

說明：應用的 Canary 版本基于權重 (30%) 進行流量切分后，訪問到 Canary 版本的概率接近 30%，流量比例可能會有小范圍的浮動。

基于 Request Header

4.3. 基于 Request Header 進行流量切分的典型應用場景即灰度發(fā)布或 A/B 測試場景。參考以下截圖，在 KubeSphere 給 Canary 版本的 Ingress 新增一條 annotation nginx.ingress.kubernetes.io/canary-by-header: canary (這里的 annotation 的 value 可以是任意值)，使當前的 Ingress 實現(xiàn)基于 Request Header 進行流量切分。

說明：金絲雀規(guī)則按優(yōu)先順序 canary-by-header - > canary-by-cookie - > canary-weight 進行如下排序，因此以下情況將忽略原有 canary-weight 的規(guī)則。

4.4. 在請求中加入不同的 Header 值，再次訪問應用的域名。

說明：

舉兩個例子，如開篇提到的當 Request Header 設置為 never 或 always 時，請求將不會或一直被發(fā)送到 Canary 版本；

對于任何其他 Header 值，將忽略 Header，并通過優(yōu)先級將請求與其他 Canary 規(guī)則進行優(yōu)先級的比較（如下第二次請求已將基于 30% 權重作為第一優(yōu)先級）。

4.5. 此時可以在上一個 annotation (即 canary-by-header）的基礎上添加一條 nginx.ingress.kubernetes.io/canary-by-header-value: user-value 。用于通知 Ingress 將請求路由到 Canary Ingress 中指定的服務。

4.6. 如下訪問應用的域名，當 Request Header 滿足此值時，所有請求被路由到 Canary 版本（該規(guī)則允許用戶自定義 Request Header 的值）。

基于 Cookie

4.7. 與基于 Request Header 的 annotation 用法規(guī)則類似。例如在 A/B 測試場景 下，需要讓地域為北京的用戶訪問 Canary 版本。那么當 cookie 的 annotation 設置為 nginx.ingress.kubernetes.io/canary-by-cookie: "users_from_Beijing"，此時后臺可對登錄的用戶請求進行檢查，如果該用戶訪問源來自北京則設置 cookie users_from_Beijing 的值為 always，這樣就可以確保北京的用戶僅訪問 Canary 版本。

總結

灰度發(fā)布可以保證整體系統(tǒng)的穩(wěn)定，在初始灰度的時候就可以對新版本進行測試、發(fā)現(xiàn)和調(diào)整問題，以保證其影響度。本文通過多個示例演示和說明了基于 KubeSphere 使用應用路由 (Ingress) 和項目網(wǎng)關 (Ingress Controller) 實現(xiàn)灰度發(fā)布，并詳細介紹了 Ingress-Nginx 的四種 Annotation，還未使用 Istio 的用戶也能借助 Ingress-Nginx 輕松實現(xiàn)灰度發(fā)布與金絲雀發(fā)布。

看完上述內(nèi)容，你們對KubeSphere基于Ingress-Nginx怎樣實現(xiàn)灰度發(fā)布有進一步的了解嗎？如果還想了解更多知識或者相關內(nèi)容，請關注創(chuàng)新互聯(lián)行業(yè)資訊頻道，感謝大家的支持。