Istio在Rainbond Service Mesh體系下的落地實踐

兩年前Service Mesh（服務網格）一出來就受到追捧，很多人認爲它是微服務架構的最終形態，因爲它可以讓業務代碼和微服務架構解耦，也就是說業務代碼不需要修改就能實現微服務架構，但解耦還不夠徹底，使用還是不方便，雖然架構解耦了，但部署還沒有解耦。

• 無法根據不同環境或客戶需要選擇合適的Service Mesh框架。
• 無法做到在開發環境不用學習和使用Service Mesh，生產環境按需開啓。

插件式 Service Mesh架構實現思路

目前成熟的ServiceMesh框架也有許多，但是對於用戶而言。並不存在萬能的ServiceMesh框架，可以解決各種場景的問題。因此我們希望對於用戶而言，他只需要關心自己的業務代碼。而應用的治理能力，則可以通過不同的ServiceMesh框架進行拓展。用戶的業務代碼與ServiceMesh框架完全解耦。如下圖所示。用戶可以隨時替換某個應用所使用的ServiceMesh架構。選擇與業務最匹配的解決方案。

基於以上思路，我們可以將istio、linkerd、dapr等微服務架構做成插件，開發過程中完全不需要知道Service Mesh框架的存在，只需要處理好業務的依賴關係，當交付到生產環境或客戶環境，有些需要性能高、有些需要功能全、有些客戶已經指定等各種差異化需求，根據環境和客戶需要按需開啓不同類型的插件即可，當Service Mesh框架有問題，隨時切換。這樣Service Mesh框架就變成賦能的工具，老的業務系統重新部署馬上就能開啓服務治理能力。

Rainbond就是基於上述思路實現的，當前版本已經實現了三個服務治理插件。

• kubernetes 原生Service 模式
• 基於envoy的Service Mesh模式
• Istio服務治理模式

後面我們詳細講解Istio服務治理模式的使用過程。

使用Istio治理模式的實踐

有了以上概念，我們可以來看看Rainbond如何與Istio結合。在Rainbond中，用戶可以對不同的應用設置不同的治理模式，即用戶可以通過切換應用的治理模式，來按需治理應用。這樣帶來的好處便是用戶可以不被某一個ServiceMesh框架所綁定，且可以快速試錯，能快速找到最適合當前業務的ServiceMesh框架。

安裝Istio 控制面（control plane）

首先在切換到Istio治理模式時，如果未安裝Istio的控制面，則會提示需要安裝對應的控制面。因此我們需要安裝Istio的控制面，控制面在一個集羣中只需安裝一次，它提供了統一的管理入口，用來管理工作在Istio治理模式下的服務。完成配置下發等功能。結合Rainbond現有的helm安裝方式，我們可以便捷的安裝好對應的組件。

1. 創建團隊

在5.5.0版本中，我們支持了用戶在創建團隊時指定命名空間。由於默認helm安裝的命名空間爲 istio-system ，所以爲了減少用戶配置。我們首先需要創建出對應的團隊。如下圖所示。團隊英文名對應的則是該團隊在集羣中的命名空間。此處填寫 istio-system 。

2. 對接商店

Rainbond支持基於helm直接部署應用，所以接下來對接Rainbond官方helm倉庫，後續基於Helm商店部署Istio即可， 在應用市場頁面，點擊添加商店，選擇helm商店，輸入相關信息即可完成對接。

商店地址：https://openchart.goodrain.com/goodrain/rainbond

3. 安裝 Istio 控制面

商店創建完成後，即可看到對應的 helm 應用，目前Rainbond提供了 istio 1.11.4 版本的helm包，根據 Istio官方文檔，該版本對Kubernetes集羣的版本支持爲 1.19, 1.20, 1.21, 1.22。

• 安裝 base 應用

  選擇helm商店中的base應用進行部署，團隊選擇之前創建的命名空間爲 istio-system 的團隊。該應用包主要部署了Istio相關的集羣資源和 CRD 資源。

• 安裝 istio-discovery 應用**

  同上述base應用一樣，選擇正確的團隊。安裝 istio-discovery 應用。有了這兩個應用，就可以擁有 Istio 基礎的治理能力了。

示例應用開啓Istio治理模式

1. 切換治理模式

我們以SpringBoot後臺管理系統 若依 爲例，如下圖所示，用戶可以先從開源應用商店安裝一個 若依SpringBoot 應用，版本選擇3.6.0，點擊治理模式切換，選擇Istio治理模式。

在點擊切換爲Istio治理模式後，會需要用戶手動設置內部域名，此處的內部域名將會是該組件在Kubernetes集羣中的service名稱，在同一個團隊下唯一。這裏我們修改爲可讀性較高的內部域名。

2. 修改配置文件

在這一步完成後，我們還需要進入 ruoyi-ui 掛載一個新的配置文件。這主要是因爲默認情況下，ruoyi-ui 的配置文件 web.conf 中後端服務地址爲 127.0.0.1，在之前使用 Rainbond 內置 ServiceMesh 模式時，由於 Rainbond 會獲取到後端服務的地址，注入到 ruoyi-ui 內部, 賦予 ruoyi-ui 一個本地訪問地址（127.0.0.1）訪問後端服務。所以無需修改就能使用。

但使用 Istio 治理模式時，組件間通過內部域名進行通信，因此需要通過掛載配置文件的方式修改對應的代理地址，ruoyi-ui 的配置文件可以通過右上方的 Web終端 訪問到容器中，複製 /app/nginx/conf.d/web.conf 這個文件的內容。修改代理地址後保存，如下圖所示。之前我們設置了控制檯的內部域名爲 ruoyi-admin，所以這裏替換爲 ruoyi-admin。

3. 重啓應用

在完成以上兩步後，我們需要重啓整個應用。在啓動應用後，進入組件頁面查看，應該可以看到每個組件都有一個類似的 Sidecar 容器，這就是Istio的數據面 (data plane)，在應用切換爲Istio治理模式以後，該應用下的所有組件都會自動注入對應的 Sidecar 容器，不需要用戶額外設置。

至此，該應用已納入Istio治理範圍。用戶如果需要對該應用有更多的配置，則可以參考 Istio官方文檔 進行擴展。

通過Kiali監控和管理Istio

在之前的步驟中，我們使用 Istio 治理模式納管了 若依 。接下來則帶大家一起看看如何使用 Kiali 觀測應用間的通信鏈路。在這一步中，用戶需要有 kubectl 命令。

1. 安裝 prometheus

在Istio中，各個組件通過暴露HTTP接口的方式讓Prometheus定時抓取數據（採用了Exporters的方式）。所以Istio控制平面安裝完成後，需要在istio-system的命名空間中部署Prometheus，將Istio組件的各相關指標的數據源默認配置在Prometheus中。

同上述base應用一樣，選擇正確的團隊，安裝 Prometheus應用。

2. 安裝kiali

kiali提供可視化界面監控和管理Istio，能夠展示服務拓撲關係，進行服務配置。

安裝 kiali-operator 應用，同上述base應用一樣，選擇正確的團隊。

安裝過程將自動創建Service，通過Rainbond平臺第三方組件的形式可將 kiali 的訪問端口暴露出來。如下圖所示：

在端口界面添加訪問端口，添加以後打開對外服務使用生成的網關策略即可進行訪問。

kiali登錄時需要身份認證token，使用以下命令獲取token：

kubectl describe secret $(kubectl get secret -n istio-system | grep istiod-token |awk '{print $1}') -n istio-system

訪問到kiali以後，在Applications一欄，選中應用所在的命名空間，就可以看到我們剛剛創建的應用。點擊進入，可以看到如下的流量路線。

在 Graph 一欄，也可以看到對應的應用內的流量請求。更多的配置及相關功能參考 Kiali官方文檔

總結

本文簡單介紹了在Rainbond中使用Istio治理模式的操作。以及Rainbond與Istio治理模式的結合。Rainbond爲用戶提供了一個可選的插件體系，使用戶可以根據自己的需求選擇不同的Service Mesh框架。在與Istio的結合上，我們主要爲用戶完成了指定應用數據平面的注入。用戶也可以通過該機制擴展自己所需的ServiceMesh框架。後續文章我們將詳細講解如何製作插件，盡請關注。

---

Rainbond是一個開源的雲原生應用管理平臺，使用簡單，不需要懂容器和Kubernetes，支持管理多個Kubernetes集羣，提供企業級應用的全生命週期管理，功能包括應用開發環境、應用市場、微服務架構、應用持續交付、應用運維、應用級多雲管理等。

Github：https://github.com/goodrain/rainbond

官網：https://www.rainbond.com?channel=oschina

微信羣：請搜索添加羣助手微信號 wylhzmyj

釘釘羣：請搜索羣號 31096419