最近，開源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 的優勢
- 輕量、輕量、輕量，重要的事情說三遍，幾個可執行程式就能很方面的部署服務網格基礎架構；
- 通過顯而易見的方式支援多個Mesh，提供比較好的隔離性。
未解決的問題
- 不支援TrafficRoute、TrafficTracing等重要的功能，是以基本上Kuma還處于不可用狀态。
- 雙向認證隻支援内建的自簽名證書，且隻能是在Mesh範圍内進行配置。
- 由于不支援類似Istio中的Ingress、Egress等功能，當開啟雙向認證時，無法将服務對外釋出出去，内部服務也無法通路外部的服務。
- 為了支援在Universal模式下同時啟動多個Envoy，不支援Envoy的熱重新開機。不過，由于xDS配置都是熱更新，是以影響并不大。
- 在Universal模式下，不支援服務注冊和發現，使用者需要逐個為服務配置依賴應用的outbound入口，而且由于沒有內建DNS，服務間通路需要指定到IP:Port，而不是像Istio一樣指定Service Name即可。在Kubernetes模式下，則是依賴了Service的機制，可以将Hostname或Service Name解析為ClusterIP，随後發起的HTTP/TCP請求進入到Sidecar中以後再進行轉發。
- 服務啟動的過程中盡量不要通路依賴的服務，此時可能由于Sidecar及資料平面未配置好，導緻服務啟動失敗。
- 檢視Envoy的config_dump可以看到，目前都是以TCP連接配接的模式進行管理，完全沒有發揮出Envoy的強大能力。
- Universal模式下配置資料平面對象、啟動Sidecar服務等方式都是需要管理者手工指令操作，更友善和人性化的包裝也是必須的。
經過這次測試，我們可以看到 Kuma 目前還處于項目的初始階段，但總的來說技術方向還是不錯的。它不像 Istio 一下子就上一套大而全的功能，學習曲線來說比較平緩，可以讓大家很好的了解服務網格技術能給大家帶來的便利，以及其中存在的技術難點。
目前阻礙服務網格技術應用的原因之一是對曆史遺留系統的支援。通常來說，我們需要對老的系統經過兩次改造，第一次是容器化，使之能夠運作在Kubernetes上，第二次則是對RPC架構的拆解或完全替換。
如果服務網格能夠支援非容器場景，則至少工作還能減少一半。我們知道Istio在從v1.3版本開始，開始支援網格擴充，也即将虛拟機或裸金屬主機內建到部署在Kubernetes中的Isito叢集中。目前支援兩種方式，一種是單網絡方式，也即虛拟機或裸金屬主機通過VPN或VPC連接配接至Kubernetes内部，另外一種是多網絡下通過入口網關實作通訊內建。目前來看，由于Istio本身對Kubernetes的依賴比較重，再加上Istio本身的其它功能都已經相對比較完善，要想增加網格擴充的功能，工作量是比較大的，是以這兩種方式都還處于開發狀态。
相對來說，Kuma則提供了一種在虛拟機或裸金屬主機場景下使用服務網格的新思路，雖然目前功能完成度相對太低，不過還是值得大家持續關注。