k8s-服務網格實戰-配置 Mesh（灰度釋出）

crossoverJie發表於2023-11-07

K8S

在上一篇 k8s-服務網格實戰-入門Istio中分享瞭如何安裝部署 Istio，同時可以利用 Istio 實現 gRPC 的負載均衡。

今天我們更進一步，深入瞭解使用 Istio 的功能。

從 Istio 的流量模型中可以看出：Istio 支援管理叢集的出入口請求（gateway），同時也支援管理叢集內的 mesh 流量，也就是叢集內服務之間的請求。

本次先講解叢集內部的請求，配合實現以下兩個功能：

灰度釋出（對指定的請求分別路由到不同的 service 中）
配置 service 的請求權重

灰度釋出

在開始之前會部署兩個 deployment 和一個 service，同時這兩個 deployment 所關聯的 Pod 分別對應了兩個不同的 label，由於在灰度的時候進行分組。

使用這個 yaml 會部署所需要的 deployment 和 service。

kubectl apply -f https://raw.githubusercontent.com/crossoverJie/k8s-combat/main/deployment/istio-mesh.yaml

首先設想下什麼情況下我們需要灰度釋出，一般是某個重大功能的測試，只對部分進入內測的使用者開放入口。

假設我們做的是一個 App，我們可以對拿到了內測包使用者的所有請求頭中加入一個版本號。

比如 version=200 表示新版本，version=100 表示老版本。
同時在服務端會將這個版本號列印出來，用於區分請求是否進入了預期的 Pod。

// Client 
version := r.URL.Query().Get("version")  
name := "world"  
ctx, cancel := context.WithTimeout(context.Background(), time.Second)  
md := metadata.New(map[string]string{  
    "version": version,  
})  
ctx = metadata.NewOutgoingContext(ctx, md)  
defer cancel()  
g, err := c.SayHello(ctx, &pb.HelloRequest{Name: name})

// Server
func (s *server) SayHello(ctx context.Context, in *pb.HelloRequest) (*pb.HelloReply, error) {  
    md, ok := metadata.FromIncomingContext(ctx)  
    var version string  
    if ok {  
       version = md.Get("version")[0]  
    }    log.Printf("Received: %v, version: %s", in.GetName(), version)  
    name, _ := os.Hostname()  
    return &pb.HelloReply{Message: fmt.Sprintf("hostname:%s, in:%s, version:%s", name, in.Name, version)}, nil  
}

對 service 分組

進行灰度測試時往往需要新增部署一個灰度服務，這裡我們稱為 v2（也就是上圖中的 Pod2）。

同時需要將 v1 和 v2 分組：

apiVersion: networking.istio.io/v1alpha3  
kind: DestinationRule  
metadata:  
  name: k8s-combat-service-ds  
spec:  
  host: k8s-combat-service-istio-mesh  
  subsets:  
    - name: v1  
      labels:  
        app: k8s-combat-service-v1  
    - name: v2  
      labels:  
        app: k8s-combat-service-v2

這裡我們使用 Istio 的 DestinationRule 定義 subset，也就是將我們的 service 下的 Pod 分為 v1/v2。

使用標籤 app 進行分組

注意這裡的 host: k8s-combat-service-istio-mesh 通常配置的是 service 名稱。

apiVersion: v1  
kind: Service  
metadata:  
  name: k8s-combat-service-istio-mesh  
spec:  
  selector:  
    appId: "12345"  
  type: ClusterIP  
  ports:  
    - port: 8081  
      targetPort: 8081  
      name: app  
    - name: grpc  
      port: 50051  
      targetPort: 50051

也就是這裡 service 的名稱，同時也支援配置為 host: k8s-combat-service-istio-mesh.default.svc.cluster.local，如果使用的簡寫Istio 會根據當前指定的 namespace 進行解析。

Istio 更推薦使用全限定名替代我們這裡的簡寫，從而避免誤操作。

當然我們也可以在 DestinationRule 中配置負載均衡的策略，這裡我們先略過：

apiVersion: networking.istio.io/v1alpha3  
kind: DestinationRule  
metadata:  
  name: k8s-combat-service-ds  
spec:  
  host: k8s-combat-service-istio-mesh 
  trafficPolicy:
    loadBalancer:
      simple: ROUND_ROBIN

這樣我們就定義好了兩個分組：

v1：app: k8s-combat-service-v1
v2：app: k8s-combat-service-v2

之後就可以配置路由規則將流量分別指定到兩個不同的組中，這裡我們使用 VirtualService 進行配置。

apiVersion: networking.istio.io/v1alpha3  
kind: VirtualService  
metadata:  
  name: k8s-combat-service-vs  
spec:  
  gateways:  
    - mesh  
  hosts:  
    - k8s-combat-service-istio-mesh # match this host
http:  
  - name: v1  
    match:  
      - headers:  
          version:  
            exact: '100'  
    route:  
      - destination:  
          host: k8s-combat-service-istio-mesh  
          subset: v1  
  - name: v2  
    match:  
      - headers:  
          version:  
            exact: '200'  
    route:  
      - destination:  
          host: k8s-combat-service-istio-mesh  
          subset: v2  
  - name: default  
    route:  
      - destination:  
          host: k8s-combat-service-istio-mesh  
          subset: v1

這個規則很簡單，會檢測 http 協議的 header 中的 version 欄位值，如果為 100 這路由到 subset=v1 這個分組的 Pod 中，同理為 200 時則路由到 subset=v2 這個分組的 Pod 中。

當沒有匹配到 header 時則進入預設的 subset:v1

gRPC 也是基於 http 協議，它的 metadata 也就對應了 http 協議中的 header。

header=100

Greeting: hostname:k8s-combat-service-v1-5b998dc8c8-hkb72, in:world, version:100istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=100"
Greeting: hostname:k8s-combat-service-v1-5b998dc8c8-hkb72, in:world, version:100istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=100"
Greeting: hostname:k8s-combat-service-v1-5b998dc8c8-hkb72, in:world, version:100istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=100"
Greeting: hostname:k8s-combat-service-v1-5b998dc8c8-hkb72, in:world, version:100istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=100"

header=200

Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"

根據以上的上面的測試請求來看，只要我們請求頭裡帶上指定的 version 就會被路由到指定的 Pod 中。

利用這個特性我們就可以在灰度驗證的時候單獨發一個灰度版本的 Deployment，同時配合客戶端指定版本就可以實現灰度功能了。

配置權重

同樣基於 VirtualService 我們還可以對不同的 subset 分組進行權重配置。

apiVersion: networking.istio.io/v1alpha3  
kind: VirtualService  
metadata:  
  name: k8s-combat-service-vs  
spec:  
  gateways:  
    - mesh  
  hosts:  
    - k8s-combat-service-istio-mesh # match this host  
  http:  
    - match:  
        - uri:  
            exact: /helloworld.Greeter/SayHello  
      route:  
        - destination:  
            host: k8s-combat-service-istio-mesh  
            subset: v1  
          weight: 10  
        - destination:  
            host: k8s-combat-service-istio-mesh  
            subset: v2  
          weight: 90  
      timeout: 5000ms

這裡演示的是針對 SayHello 介面進行權重配置（當然還有多種匹配規則），90% 的流量會進入 v2 這個 subset，也就是在 k8s-combat-service-istio-mesh service 下的 app: k8s-combat-service-v2 Pod。

Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-**v1**-5b998dc8c8-hkb72, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$ curl "http://127.0.0.1:8081/grpc_client?name=k8s-combat-service-istio-mesh&version=200"
Greeting: hostname:k8s-combat-service-v2-5db566fb76-xj7j6, in:world, version:200istio-proxy@k8s-combat-service-v1-5b998dc8c8-hkb72:/$

經過測試會發現大部分的請求都會按照我們的預期進入 v2 這個分組。

當然除之外之外我們還可以：

超時時間
故障注入
重試
具體的配置可以參考 Istio 官方文件：

當然在一些雲平臺也提供了視覺化的頁面，可以更直觀的使用。

以上是阿里雲的截圖

但他們的管理的資源都偏 kubernetes，一般是由運維或者是 DevOps 來配置，不方便開發使用，所以還需要一個介於雲廠商和開發者之間的管理釋出平臺，可以由開發者以專案維度管理維護這些功能。

本文的所有原始碼在這裡可以訪問：
https://github.com/crossoverJie/k8s-combat

k8s-服務網格實戰-入門Istio
2023-11-01
K8S
服務網格新成員：亞馬遜釋出App Mesh應用網格
2018-11-30
亞馬遜APP
服務網格 Service Mesh
2023-12-27
Istio 1.2服務網格釋出
2019-06-19
服務網格service mesh 之 Linkerd
2021-09-09
Istio最佳實踐：在K8s上透過Istio服務網格進行灰度釋出
2018-09-05
K8S
為什麼要使用服務網格Service Mesh？
2018-11-07
為什麼我們需要服務網格Service mesh？
2018-06-29
服務網格將更安全：VMware收購Mesh7改變服務網格的遊戲規則
2021-03-19
遊戲
快速上手 Linkerd v2 Service Mesh（服務網格）
2021-06-04
服務網格大事：Istio釋出1.0版本
2018-08-01
服務網格定義企業上雲新路徑！ | Forrester X 螞蟻集團釋出服務網格白皮書
2022-01-04
REST
Service Mesh大咖訪談：使用服務網格的微服務通訊與治理
2018-07-27
微服務
服務網格大戰，再見 Istio! - Fossas
2021-06-11
Emoji.voto，Linkerd 服務網格(service mesh)的示例應用程式
2021-07-21
nginx 實現實用的灰度釋出
2019-10-29
Nginx
阿里雲服務網格 ASM 正式釋出商業化版本
2022-04-13
阿里ASM
如何實現灰度釋出輕量化？
2023-01-31
服務網格｜如何使用 Amesh 配置外掛
2023-01-18
Linkerd Service Mesh 服務配置檔案規範
2021-12-12
架構設計：微服務模式下，實現灰度釋出模式
2020-11-19
架構微服務模式
nginx+lua+redis實現灰度釋出
2023-12-18
NginxRedis
Cilium 1.11 釋出，帶來核心級服務網格、拓撲感知路由....
2021-12-15
路由
Kmesh v0.4釋出！邁向大規模 Sidecarless 服務網格
2024-07-24
IDE
使用 Nginx Ingress 實現金絲雀釋出/灰度釋出
2024-11-18
Nginx
裁剪柵格—（偏移、釋出後服務樣式解決）
2022-12-20
使用Istio服務網格實現流量映象
2018-12-31
重磅 | 騰訊雲服務網格開源專案 Aeraki Mesh 加入 CNCF 雲原生全景圖
2022-03-18
乾貨分享｜使用 Istio 實現灰度釋出
2022-09-20
灰度釋出的一種技術實踐
2022-09-19
大規模微服務場景下灰度釋出與流量染色實踐
2022-12-08
微服務
Vue + Webpack 灰度釋出控制
2018-03-11
VueWeb
服務網格Service Mesh、API閘道器和訊息佇列的對比 - Wolfram Hempel
2019-08-26
API佇列
企業級服務網格架構之路解讀——Service Mesh在會話層解耦
2018-08-20
架構會話解耦
Aeraki Mesh正式成為CNCF沙箱專案，騰訊雲攜夥伴加速服務網格成熟商用
2022-06-17
phoenix API服務釋出
2018-06-13
API
01 . OpenResty簡介部署,優缺點,壓測,適用場景及用Lua實現服務灰度釋出
2020-10-09
REST
愛奇藝在服務網格方向的落地實踐
2022-11-28