2. 程式人生 > >Istio 太複雜？KubeSphere基於Ingress-Nginx實現灰度釋出

Istio 太複雜？KubeSphere基於Ingress-Nginx實現灰度釋出

阿新 • • 發佈：2019-08-27

在 Bookinfo 微服務的灰度釋出示例 中，KubeSphere 基於 Istio 對 Bookinfo 微服務示例應用實現了灰度釋出。有使用者表示自己的專案還沒有上 Istio，要如何實現灰度釋出？

在 Ingress-Nginx (0.21.0 版本) 中，引入了一個新的 Canary 功能，可用於為閘道器入口配置多個後端服務，還可以使用指定的 annotation 來控制多個後端服務之間的流量分配。 KubeSphere 在 2.0.2 的版本 中，升級了專案閘道器 (Ingress Controller) 版本至 0.24.1，支援基於 Ingress-Nginx 的灰度釋出。

上一篇文章已經對灰度釋出的幾個應用場景進行了詳細介紹，本文將直接介紹和演示基於 KubeSphere 使用應用路由 (Ingress) 和專案閘道器 (Ingress Controller) 實現灰度釋出。

說明： 本文用到的示例 yaml 原始檔及程式碼已上傳至 GitHub，可 clone 至本地方便參考。

Ingress-Nginx Annotation 簡介

KubeSphere 基於 Nginx Ingress Controller 實現了專案的閘道器，作為專案對外的流量入口和專案中各個服務的反向代理。而 Ingress-Nginx 支援配置 Ingress Annotations 來實現不同場景下的灰度釋出和測試，可以滿足金絲雀釋出、藍綠部署與 A/B 測試等業務場景。

Nginx Annotations 支援以下 4 種 Canary 規則：

  • nginx.ingress.kubernetes.io/canary-by-header
    ：基於 Request Header 的流量切分，適用於灰度釋出以及 A/B 測試。當 Request Header 設定為 always 時，請求將會被一直髮送到 Canary 版本；當 Request Header 設定為 never 時，請求不會被髮送到 Canary 入口；對於任何其他 Header 值，將忽略 Header，並通過優先順序將請求與其他金絲雀規則進行優先順序的比較。
  • nginx.ingress.kubernetes.io/canary-by-header-value：要匹配的 Request Header 的值，用於通知 Ingress 將請求路由到 Canary Ingress 中指定的服務。當 Request Header 設定為此值時，它將被路由到 Canary 入口。該規則允許使用者自定義 Request Header 的值，必須與上一個 annotation (即：canary-by-header）一起使用。
  • nginx.ingress.kubernetes.io/canary-weight：基於服務權重的流量切分，適用於藍綠部署，權重範圍 0 - 100 按百分比將請求路由到 Canary Ingress 中指定的服務。權重為 0 意味著該金絲雀規則不會向 Canary 入口的服務傳送任何請求。權重為 100 意味著所有請求都將被髮送到 Canary 入口。
  • nginx.ingress.kubernetes.io/canary-by-cookie：基於 Cookie 的流量切分，適用於灰度釋出與 A/B 測試。用於通知 Ingress 將請求路由到 Canary Ingress 中指定的服務的cookie。當 cookie 值設定為 always 時，它將被路由到 Canary 入口；當 cookie 值設定為 never 時，請求不會被髮送到 Canary 入口；對於任何其他值，將忽略 cookie 並將請求與其他金絲雀規則進行優先順序的比較。

注意：金絲雀規則按優先順序進行如下排序：

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

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

  • 基於權重的 Canary 規則

  • 基於使用者請求的 Canary 規則

第一步：建立專案和 Production 版本的應用

1.1. 在 KubeSphere 中建立一個企業空間 (workspace) 和專案 (namespace) ，可參考 多租戶管理快速入門。如下已建立了一個示例專案。

1.2. 為了快速建立應用，在專案中建立工作負載和服務時可通過 編輯 yaml 的方式，或使用 KubeSphere 右下角的工具箱開啟 web kubectl 並使用以下命令和 yaml 檔案建立一個 Production 版本的應用並暴露給叢集外訪問。如下建立 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. 建立 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 的企業空間 demo-workspace 下，可以看到 ingress-demo 專案下的所有資源。

Deployment

Service

Ingress

2.2. 訪問 Production 版本的應用需確保當前專案已開啟了閘道器，在外網訪問下開啟閘道器，型別為 NodePort。

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

<!-- ![](https://oscimg.oschina.net/oscnet/532e25b8a24f1de4a03b209064501bbe2f8.jpg) -->

$ 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-

第三步：建立 Canary 版本

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

第四步：Ingress-Nginx Annotation 規則

基於權重 (Weight)

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

4.1. 使用以下 canary.ingress 的 yaml 檔案再建立一個基於權重的 Canary 版本的應用路由 (Ingress)。

注意：要開啟灰度釋出機制，首先需設定 nginx.ingress.kubernetes.io/canary: "true" 啟用 Canary，以下 Ingress 示例的 Canary 版本使用了基於權重進行流量切分的 annotation 規則，將分配 30% 的流量請求傳送至 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 進行流量切分的典型應用場景即灰度釋出或 A/B 測試場景。參考以下截圖，在 KubeSphere 給 Canary 版本的 Ingress 新增一條 annotation nginx.ingress.kubernetes.io/canary-by-header: canary (這裡的 annotation 的 value 可以是任意值)，使當前的 Ingress 實現基於 Request Header 進行流量切分。

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

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

說明：

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

對於任何其他 Header 值，將忽略 Header，並通過優先順序將請求與其他 Canary 規則進行優先順序的比較（如下第二次請求已將基於 30% 權重作為第一優先順序）。

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

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

基於 Cookie

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

總結

灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以對新版本進行測試、發現和調整問題，以保證其影響度。本文通過多個示例演示和說明了基於 KubeSphere 使用應用路由 (Ingress) 和專案閘道器 (Ingress Controller) 實現灰度釋出，並詳細介紹了 Ingress-Nginx 的四種 Annotation，還未使用 Istio 的使用者也能借助 Ingress-Nginx 輕鬆實現灰度釋出與金絲雀釋出。

參考

相關推薦

Istio 太複雜？KubeSphere基於Ingress-Nginx實現灰度釋出

在 Bookinfo 微服務的灰度釋出示例 中，KubeSphere 基於 Istio 對 Bookinfo 微服務示例應用實現了

K8S基於ingress-nginx實現灰度釋出

之前介紹過使用ambassador實現灰度釋出，今天介紹如何使用ingre-nginx實現。 介紹 Ingress-Nginx 是一個K8S ingress工具，支援配置 Ingress Annotations 來實現不同場景下的灰度釋出和測試。 Nginx Annotations 支援以下 4 種 Cana

K8s 1.18.6版本基於 ingress-nginx 實現金絲雀釋出（灰度釋出）

# K8s 1.18.6版本基於 ingress-nginx 實現金絲雀釋出（灰度釋出） ## 環境 | 軟體 | 版本 | | ------------------------ | ------- | | kubernetes |

乾貨｜採用Istio實現灰度釋出(金絲雀釋出)

點選上方“中興開發者社群”，關注我們 每天讀一篇一線開發者原創好文 灰度釋出（又名金絲雀釋出）介紹 當應用上線以後，運維面臨的一大挑戰是如何能夠在不影響已上線業務的情況下進行升級。做過產品的同

利用nginx+lua+memcache實現灰度釋出

一、灰度釋出原理說明 灰度釋出在百度百科中解釋： 灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面 來。灰度釋出可以保證整體系統的穩定，在初

Openresty+redis實現灰度釋出

一、架構 環境： 192.168.189.131：tomcat服務 192.168.189.132：tomcat服務 192.168.189.130：OpenResty服務、redis服務 流程： 請求到達openresty，openresty從redis獲取白名單，然後判斷請求地址是否再白名單，

Apollo學習(四)：建立灰度配置並與zuul協作實現灰度釋出

說明 通過之前對Apollo的學習，對Apollo的使用已經有了大概的瞭解。本篇博文通過與Spring Cloud Zuul作為閘道器配合，Apollo配置灰度例項來學習灰度釋出。本文的核心是以github上的灰度釋出開源專案ribbon-discovery-filter-sprin

採用輕量ServiceMesh實現灰度釋出的實踐

軟體總會有缺陷的，解決問題的同時往往會引入新的問題，關鍵是看這些問題是否在我們的控制範圍內，“灰度釋出”就是讓問題受控的方法之一。    前言    我們的 CTO 經常說：“研發團隊最首要的任務是提供穩定的服務，然後才是提供符合客戶需求的、易用和低成本的產品”

架構設計：微服務模式下，實現灰度釋出模式

本文原始碼：[GitHub·點這裡](https://github.com/cicadasmile/data-manage-parent) || [GitEE·點這裡](https://gitee.com/cicadasmile/data-manage-parent) # 一、基本邏輯 請求通過8001

灰度釋出-基於nginx的cookie實現

1、概念 灰度釋出是指在黑與白之間，能夠平滑過渡的一種釋出方式。AB test就是一種灰度釋出方式，讓一部分使用者繼續用A，一部分使用者開始用B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。灰度釋出可以保證整體系統的穩

基於ambassador實現K8S灰度釋出

為什麼需要灰度釋出 灰度釋出（又名金絲雀釋出）是指在黑與白之間，能夠平滑過渡的一種釋出方式。在其上可以進行A/B testing，即讓一部分使用者繼續用產品特性A，一部分使用者開始用產品特性B，如果使用者對B沒有什麼反對意見，那麼逐步擴大範圍，把所有使用者都遷移到B上面來。 總結下一些應用場景： 微服務依賴

基於 Istio 與 Kubernetes 對應用進行灰度釋出與 Tracing

灰度釋出，是指在黑與白之間，能夠平滑過渡的一種釋出方式。通俗來說，即讓產品的迭代能夠按照不同的灰度策略對新版本進行線上環境的測試，灰度釋出可以保證整體系統的穩定，在初始灰度的時候就可以對新版本進行測試、發現和調整問題，以保證其影響度。KubeSphere 基於 Istio 提供了藍綠部署、金絲雀釋出、流量映象

【Nginx】實現負載均衡、限流、快取、黑白名單和灰度釋出，這是最全的一篇了！

## 寫在前面 > 在《[【高併發】面試官問我如何使用Nginx實現限流，我如此回答輕鬆拿到了Offer！](https://mp.weixin.qq.com/s?__biz=Mzg3MzE1NTIzNA==&mid=2247485388&idx=1&sn=0854d3f9b4

vs2015+opencv3.3.1 實現 灰度高斯濾波器

3.3 edwin ont eight end wid img pre i++ #include <opencv2\highgui\highgui.hpp> #include <iostream> #include<vector> u

基於springcloud服務灰度釋出(二)

灰度鏈路測試 文章目錄 灰度鏈路測試 1測試介面實現 2 繞過測度介面攔截 2.1 建立filter 或HandlerInterceptor 代理 2.2 處理是否跳過攔截

otsu結合OpenCV實現灰度影象自動閾值處理

   簡單的說，這種演算法假設一副影象由前景色和背景色組成，通過統計學的方法來選取一個閾值，使得這個閾值可以將前景色和背景色儘可能的分開。 或者更準確的說是在某種判據下最優。與數理統計領域的 fisher 線性判別演算法其實是等價的。 otsu演算法中這個判據就是最大類間方差

灰度釋出系統的實現

                灰度釋出，已經不是一個很新的概念了．一個產品，如果需要快速迭代開發上線，又要保證質量，保證剛上線的系統，一旦出現問題那麼可以很快的控制影響面，就需要設計一套灰度釋出系統．灰度釋出系統的作用在於，可以根據自己的配置，來將使用者的流量導到新上線的系統上，來快速驗證新的功能修改，而一

Nginx配置之負載均衡、限流、快取、黑名單和灰度釋出

一、Nginx安裝（基於CentOS 6.5） 1.yum命令安裝 yum install nginx –y (若不能安裝，執行命令yum install epel-release) 2. 啟動、停止和重啟 service nginx start service nginx stop

灰度釋出：灰度很簡單，釋出很複雜&灰度釋出（灰度法則）的6點認識

什麼是灰度釋出，其要點有哪些？   最近跟幾個聊的來的同行來了一次說聚就聚的晚餐，聊了一下最近的工作情況如何以及未來規劃等等，酒足飯飽後我們聊了一個話題“灰度釋出”。 因為筆者所負責的產品還沒有達到他們產品使用者的量級上（最低的都在1千萬+），也就談不上灰度釋出這一環節，所以只有聽的

Python中使用PIL快速實現灰度圖

效果 原圖 效果圖 實現 新建資料夾grayImage，在此資料夾下新建gray.py from PIL import Image img=Image.open('1111.jpg') img=img.convert('L') img.save('灰度圖.jpg')