最近，開源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則提供了一種在虛擬機或裸金屬主機場景下使用服務網格的新思路，雖然當前功能完成度相對太低，不過還是值得大家持續關注，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/65531.html
標籤：其他
上一篇：Docker容器中用戶權限管理
下一篇：一堆 voip開發論文下載