Kubernetes 作為基礎平臺，提供了強大的容器編排能力。但是在其上部署業務和服務治理上，仍然會面對一些復雜性和局限性。在服務治理上，已經有許多成熟的 ServiceMesh 框架用于擴充其能力，如 Istio、Linkerd、Dapr 等。本文將主要介紹如何使用 Istio 擴充 Kubernetes 灰度發布的能力。

而在部署上，則會利用開源項目 Rainbond 作為基礎平臺來進行實踐。Rainbond 是一個云原生應用管理平臺，它使用「以應用為中心」的設計模式。基于這一設計模式抽象出了標準化的應用模型。從使用的體驗上不需要學習和編寫YAML，即可實現業務應用的全生命周期管理。因此使用它簡化業務的部署和管理。同時 Rainbond 支持 ServiceMesh 框架的替換，使我們可以按需選擇與業務最匹配的 ServiceMesh 框架進行服務治理。

Kubernetes 中如何實現灰度發布

當你在 Kubernetes 集群中部署業務時，可以利用 Kubernetes 原生提供的灰度發布^[1]的方式去上線業務。這種方式是通過在舊版本和新版本的服務之間，定義一個差異化的 Label，根據不同版本之間的公共 Label 負載流量到后端 Pod，最終實現根據 Pod 的副本數控制流量的百分比。

如下圖所示：用戶定義了兩個 Deployment 對象，其中舊版本名為 frontend-stable，有3個副本。新版本為 frontend-canary，有1個副本。此時定義了一個 Service 對象，使用它們之間公共的 Label 進行選擇。這就使得用戶訪問 frontend 這個 Service 時，能以 3:1 的比例同時訪問到兩個版本。并且還可以通過調整副本數持續控制流量比例，最終達到完整上線。

Kubernetes 默認的實現方式在簡單的部署場景下很有效，但是在一些復雜場景中，仍然會有較大的局限，如：

1. 業務配置自動伸縮后，會直接影響灰度發布的流量比例
2. 低百分比的流量控制占用資源高，如 1 % 的流量到達新版本，則至少需要 100 個副本
3. 精確的流量分發控制，使訪問到新版本中的用戶一直是同一批，而不是某個用戶訪問時隨機切換

Istio 灰度發布簡述

由于 Kubernetes 提供的灰度發布方式的局限性，在一些復雜場景下，我們就需要使用 Istio 來實現更精細的灰度發布策略。在使用 Istio 進行灰度發布時，我們需要了解兩個重要概念：

1. Virtual services^[2]: 虛擬服務定義了請求到服務的路徑。可以包含一組路由規則，使匹配到對應規則的請求能到達指定目標。

2. Destination rules^[3]: 目標規則可以管理到達該目標的流量，如對服務后端所對應的實例池進行分組，再結合 Virtual services 定義的路由規則，最終將流量轉發到正確的實例上。

如下圖所示，以 istio 官網提供的 Bookinfo 示例程序為例，給出了 virtual services 和 destination rules 的主要定義。其中 virtual services 主要分為兩塊，主機名和路由規則。主機名是客戶端向服務發送請求時使用的一個或多個地址。當請求到達 virtual services 時，則會根據其定義的路由規則匹配。圖中就定義了郵箱以 gmail.com 結尾的用戶流量只會到達 v3 版本的實例上。而其他用戶則以 1:9 的比例分別訪問到 v1 和 v2 版本的服務。這種方式實現了精確的流量分發控制。

當用戶流量來到 reviews.demo.svc.cluster.local 這個 Service 上時，可以看到 destination rules 的規則定義中根據 version 這個 label 定義了不同的實例集，實現了流量比例與副本數的解耦。不管 reviews-v1 有多少實例。始終只有 10% 的流量到達 destination rules 的 v1 子集中。這就解決了業務副本數與流量比例的沖突問題，也使得資源使用更加合理。

Istio 灰度發布在 Rainbond 上的實踐

基于以上理解，我們接下來以 BookInfo 為例來體驗 Istio 的灰度發布。

1. 準備工作：

在開始之前，我們需要提前安裝好所需要的環境。

「安裝 Rainbond」

參考 Rainbond 官方文檔^[4] 快速安裝，安裝完成后可以通過對接 Helm 商店一鍵安裝 Istio 以及相應組件。

「安裝 Istio 以及 Kiali」

登錄到 Rainbond 控制臺后，先創建一個團隊，團隊英文名對應 Kubernetes 中的命名空間，Istio 默認安裝的命名空間為 istio-system ，因此團隊英文名填寫istio-system，名稱可以填寫為 istio項目。接下來對接 Helm 商店，通過 應用市場 -> 點擊號 -> Helm 商店 對接。商店名稱隨意填寫，地址填寫 https://openchart.goodrain.com/goodrain/rainbond。商店對接完成后，我們即可點擊安裝 istio、kiali 等應用。詳細可參考 Istio 安裝^[5]。

2. 部署 BookInfo 應用

在部署 BookInfo 之前，我們需要在 Rainbond 中創建一個團隊和應用，并將應用的治理模式切換為 Istio 治理模式。在 Rainbond 中應用治理模式切換是指可以無侵入地變更應用下組件間通信治理模式。

如下圖所示，一個完整應用會包含多個微服務模塊，而 ServiceMesh 框架則是對所有業務容器注入 Proxy，根據注入Proxy的差異可以支持多種類型的 ServiceMesh 實現，比如：Istio、Linkerd、Dapr，應用可以按需開啟 ServiceMesh 能力，或更換實現框架。為了讓 BookInfo 這個應用使用到 Istio 的治理能力，所以需要切換到 Istio 治理模式。

「2.1 準備鏡像」

BookInfo^[6] 這個應用程序由 6 個微服務組成，它們之間的依賴如下圖所示。其中 Productpage 這個服務提供了訪問頁面，從 Details 這個服務中獲得書籍詳細信息。從 Reviews 服務中獲得書籍評價。其中 Reviews-v2 和 Reviews-v3 會從 Ratings 這個服務中獲得書籍的評級信息。這六個微服務的鏡像如下：

docker.io/istio/examples-bookinfo-productpage-v1:1.17.0
docker.io/istio/examples-bookinfo-details-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v2:1.17.0
docker.io/istio/examples-bookinfo-reviews-v3:1.17.0
docker.io/istio/examples-bookinfo-ratings-v1:1.17.0

「2.2 部署組件」

我們在應用下，選擇添加組件 -> 指定鏡像 -> 填寫鏡像地址 -> 新建組件 -> 確認創建，即可依次創建出這 5 個微服務對應的組件。

「2.3 生成可用的 Service」

剛剛我們僅完成了所有服務的部署，還未定義這些微服務的訪問策略。以 Productpage 為例，我們通過點擊拓撲圖中 Productpage 這個組件，即可進入這個服務的管理頁面。找到 端口 -> 添加端口 -> 端口號填寫9080 -> 打開對外服務 -> 點擊生成的路由，即可訪問成功。此時會發現 Productpage 這個組件的頁面還無法拉取到書籍評價信息。這是由于它默認使用 details 和 reviews 這兩個 Service 名稱連接到它依賴的組件。此時我們部署的 Reviews-v1 等組件還沒有正確的 Service 名稱。因此還是進入組件管理頁面，組件端口 -> 添加端口 -> 端口號填寫9080 -> 修改使用別名 -> 內部域名填寫為 reviews-v1 -> 打開對內服務。details、reviews-v2、ratings 等組件都是如此，填寫其對應的 Service 名稱后，打開對內服務即可。

最后在應用的 K8s 資源下，我們還需要創建一個如下的 Service，用來在 Reviews 的三個版本之間負載流量。

apiVersion:v1
kind:Service
metadata:
labels:
app:reviews
service:reviews
name:reviews
spec:
ports:
-name:http
port:9080
protocol:TCP
targetPort:9080
selector:
component:reviews#需要在Reviews三個版本中，均添加Kubernetes屬性，設置上該Label，才能正確生效
sessionAffinity:None
type:ClusterIP

「2.4 編排依賴關系」

完成以上操作后，訪問 Productpage 應用，可以看到書籍評論能正確在三個版本中切換了。此時，可以在應用視圖下，切換到編排模式，根據上述 BookInfo 應用的架構圖進行連線，實現拓撲圖的編排。如下圖所示，這樣編排的好處是后期可以將這個應用整體發布出去，其他用戶直接安裝下來即可得到一樣的拓撲關系，再也不用擔心找不到各個服務依賴的組件。

3. 灰度發布

在完成以上部署操作后，我們得到了一個完整的 BookInfo 程序，但此時還未定義 Istio 相關配置，所以還需要通過 Kiali 去定義流量規則。實現灰度發布。

「3.1 配置路由規則」

訪問 Kiali 管理頁面，即可看到該應用。在左側邊欄選擇 Services，找到 reviews 這個 Service，點擊進入，右上角 Actions 選擇 Traffic Shifting，即可看到如下配置：拖動滑塊選擇流量比例。下圖中 30% 的流量將會訪問到 reviews-v1 上，70% 的流量訪問到 reviews-v2上。點擊創建后，即可看見頁面左下角，Kiali 自動為你生成了 virtual services 和 destination rules 資源。你可以點擊進去根據自己需求再次編輯。

「3.2 驗證路由規則是否生效」

找到最開始部署的組件 Productpage，進入組件管理頁面，點擊右上角訪問入口，可以看到書籍詳情和評級，反復刷新頁面，可以看到不帶星級的評價信息(reviews-v1)與黑色星級評價信息(reviews-v2)出現的比例大概是 3:7。紅色星級評價信息(reviews-v3)從未出現。

「3.3 驗證組件擴容對流量的影響」

找到部署的組件 reviews-v1 ，進入組件管理頁面 -> 伸縮 -> 實例數量設置為4，此時再次訪問 Productpage 頁面，反復刷新頁面，可以看到 reviews-v1 擴容后，訪問到 reviews-v1 與 reviews-v2 的比例仍為 3:7，組件實例數的多少對流量分發策略沒有影響。

Reference Link

[1]

灰度發布: https://kubernetes.io/docs/concepts/cluster-administration/manage-deployment/#canary-deployments

[2]

Virtual services: https://istio.io/latest/docs/concepts/traffic-management/#virtual-services

[3]

Destination rules: https://istio.io/latest/docs/concepts/traffic-management/#destination-rules

[4]

快速安裝 Rainbond: https://www.rainbond.com/docs/quick-start/quick-install/

[5]

Istio 安裝: https://www.rainbond.com/docs/use-manual/app-manage/overview/model/deploy-istio/

[6]

BookInfo: https://istio.io/latest/docs/examples/bookinfo/