使用Bookinfo應用測試Kuma服務網格

最近，開源API管理平臺Kong服務供應商近日放出了新的開源項目Kuma。本文嘗試將 bookinfo 應用部署在 Kuma 網格中，以便幫助大家更好的理解 Kuma 項目。

Kuma是能用于管理服務網絡（Service Mesh）的通用控制平臺，通過無縫管理4-7層的網絡流量、微服務與API，來解決第一代服務網絡的技術限制。

Kuma 強調其易用性，能確保底層網絡的安全性與可觀察性，而且即便其提供高級簡單的控制界面，但是使用者仍然可以進行更高級的配置。Kuma 集合了快速數據平臺與進階控制平臺，讓使用者可用簡單的指令，就能設置權限、公開指標以及配置路由規則。

另外，Kuma 采用軟件定義安全性，為所有4層流量啟用 mTLS，并提供高精細度的流量控制功能，強化4層路由功能，而 Kuma 也能夠快速實現追蹤與日志記錄功能，讓用戶分析指標進行錯誤排查。Kuma 可在任意的平臺上執行，包括 Kubernetes、虛擬機器、容器、裸機和傳統環境，使整個企業組織都能實踐原生云端應用。

Kuma 利用開源項目 Envoy 開發而成，而 Envoy 則是為原生云端應用程序設計的代理，官方提到，Envoy 目前已經是邊緣代理的標準，與服務網絡一起，成為原生云端系統的重要實現方法，因為對于越大規模的微服務應用來說，監控、安全性和可靠性就更顯得重要。

• 本文中使用的代碼可以在 Github 找到（https://github.com/waret/kuma-tutorial）。
  

首先使用如下命令配置控制平面，這里是在控制平面中創建了一個新的名為 bookinfo的Mesh。

下圖為 Bookinfo 應用的架構圖，其中包含 productpage、reviews、details、ratings 等4個服務，另外 reviews 服務提供了三個版本。在這次測試中，我們為每個版本部署一個實例。

在數據平面，為了能在一個服務器中部署所有6個實例，這里為了避免沖突，需要考慮為各個實例合理分配 inbound 和 outbound 的端口，如下所示。

需要注意的一點，kuma-v0.1.2 版本中不支持在同一宿主機上部署多個 Sidecar，但是最新的 master 分支上已經做了修改，因此本文后面使用的 kuma 相關命令行程序都是從 master 分支全新編譯出來的。

執行如下命令配置 ratings-v1 服務。

執行如下命令配置 details-v1 服務。

這里對 Istio 項目中的 bookinfo 代碼進行了修改，以支持配置 RATINGS_PORT 參數，包括下面的 productpage 服務。執行如下命令配置 reviews-v1 服務。

執行如下命令配置 reviews-v2 服務。

執行如下命令配置 reviews-v3 服務。

執行如下命令配置 productpage-v1 服務。

打開瀏覽器，輸入 http://$IP:10501/productpage，可以看到如下結果，也即bookinfo應用發布成功。刷新頁面，可以看到review評分的變化。

為了測試數據平面可以動態更新配置，如下更新 bookinfo/reviews 服務的本地端口，并執行。

查看對應數據平面服務的日志，可以看到新的配置更新生效。但是這里的問題在于 productpage 實例本身仍然訪問的是之前的 10504 端口，而 Sidecar 此時已無法實現該端口的轉發，會導致服務本身的異常。所以總的來說，在 Kuma 的 Universal 模式下，一種比較好的實踐是事先做好應用、服務、實例、端口等的規劃，升級更新會導致服務的短暫中斷。

總結

Kuma 的優勢

1. 輕量、輕量、輕量，重要的事情說三遍，幾個可執行程序就能很方面的部署服務網格基礎架構；

2. 通過顯而易見的方式支持多個Mesh，提供比較好的隔離性。

未解決的問題

1. 不支持TrafficRoute、TrafficTracing等重要的功能，所以基本上Kuma還處于不可用狀態。

   
   

2. 雙向認證只支持內建的自簽名證書，且只能是在Mesh范圍內進行配置。

   
   

3. 由于不支持類似Istio中的Ingress、Egress等功能，當開啟雙向認證時，無法將服務對外發布出去，內部服務也無法訪問外部的服務。

   
   

4. 為了支持在Universal模式下同時啟動多個Envoy，不支持Envoy的熱重啟。不過，由于xDS配置都是熱更新，所以影響并不大。

   
   

5. 在Universal模式下，不支持服務注冊和發現，用戶需要逐個為服務配置依賴應用的outbound入口，而且由于沒有集成DNS，服務間訪問需要指定到IP:Port，而不是像Istio一樣指定Service Name即可。在Kubernetes模式下，則是依賴了Service的機制，可以將Hostname或Service Name解析為ClusterIP，隨后發起的HTTP/TCP請求進入到Sidecar中以后再進行轉發。

   
   

6. 服務啟動的過程中盡量不要訪問依賴的服務，此時可能由于Sidecar及數據平面未配置好，導致服務啟動失敗。

   
   

7. 查看Envoy的config_dump可以看到，當前都是以TCP連接的模式進行管理，完全沒有發揮出Envoy的強大能力。

   
   

8. Universal模式下配置數據平面對象、啟動Sidecar服務等方式都是需要管理員手工命令操作，更方便和人性化的包裝也是必須的。

經過這次測試，我們可以看到 Kuma 當前還處于項目的初始階段，但總的來說技術方向還是不錯的。它不像 Istio 一下子就上一套大而全的功能，學習曲線來說比較平緩，可以讓大家很好的理解服務網格技術能給大家帶來的便利，以及其中存在的技術難點。

當前阻礙服務網格技術應用的原因之一是對歷史遺留系統的支持。通常來說，我們需要對老的系統經過兩次改造，第一次是容器化，使之能夠運行在Kubernetes上，第二次則是對RPC框架的拆解或完全替換。

如果服務網格能夠支持非容器場景，則至少工作還能減少一半。我們知道Istio在從v1.3版本開始，開始支持網格擴展，也即將虛擬機或裸金屬主機集成到部署在Kubernetes中的Isito集群中。當前支持兩種方式，一種是單網絡方式，也即虛擬機或裸金屬主機通過***或VPC連接至Kubernetes內部，另外一種是多網絡下通過入口網關實現通訊集成。目前來看，由于Istio本身對Kubernetes的依賴比較重，再加上Istio本身的其它功能都已經相對比較完善，要想增加網格擴展的功能，工作量是比較大的，所以這兩種方式都還處于開發狀態。

相對來說，Kuma則提供了一種在虛擬機或裸金屬主機場景下使用服務網格的新思路，雖然當前功能完成度相對太低，不過還是值得大家持續關注。