出口閘道效能調查

驗證加入出口閘道對效能的影響。

2019 年 1 月 31 日 | 作者：Jose Nativio，IBM

本次調查的主要目的是確定在服務網格中加入出口閘道以存取外部服務（在此案例中為 MongoDB）時，對效能和資源利用率的影響。在部落格文章使用外部 MongoDB 服務中，描述了如何為外部 MongoDB 設定出口閘道的步驟。

本次調查使用的應用程式是 Java 版本的 Acmeair，它模擬一個航空公司訂位系統。這個應用程式用於 Istio 每日建置的效能回歸巡邏中，但在該設定中，微服務直接透過其 Sidecar 存取外部 MongoDB，而沒有使用出口閘道。

下圖說明了回歸巡邏目前如何使用 Acmeair 和 Istio 執行

Acmeair benchmark in the Istio performance regression patrol environment — Istio 效能回歸巡邏環境中的 Acmeair 基準測試

另一個差異是應用程式使用純 MongoDB 通訊協定與外部資料庫通訊。本次研究的第一個變更是建立 MongoDB 與應用程式內執行的用戶端之間的 TLS 通訊，因為這是一個更實際的場景。

測試了從網格存取外部資料庫的幾個案例，並在接下來進行說明。

出口流量案例

案例 1：繞過 Sidecar

在此案例中，Sidecar 不會攔截應用程式與外部資料庫之間的通訊。這是透過使用 MongoDB 的 CIDR 設定 init 容器參數 -x 來完成的，這使得 Sidecar 忽略傳送至/來自此 IP 位址的訊息。例如

    - -x
    - "169.47.232.211/32"

Traffic to external MongoDB by-passing the sidecar — 繞過 Sidecar 的外部 MongoDB 流量

案例 2：透過 Sidecar，使用服務條目

這是將 Sidecar 注入到應用程式 Pod 時的預設組態。所有訊息都會被 Sidecar 攔截並根據設定的規則路由到目的地，包括與外部服務的通訊。MongoDB 被定義為一個 ServiceEntry。

Sidecar intercepting traffic to external MongoDB — Sidecar 攔截到外部 MongoDB 的流量

案例 3：出口閘道

定義了用於存取 MongoDB 的出口閘道以及相應的目的地規則和虛擬服務資源。所有傳送到和來自外部資料庫的流量都會經過出口閘道 (envoy)。

Introduction of the egress gateway to access MongoDB — 引入出口閘道以存取 MongoDB

案例 4：Sidecar 與出口閘道之間的相互 TLS

在此案例中，Sidecar 和閘道之間有一個額外的安全層，因此預期會對效能產生一些影響。

Enabling mutual TLS between sidecars and the egress gateway — 在 Sidecar 和出口閘道之間啟用相互 TLS

案例 5：使用 SNI Proxy 的出口閘道

此案例用於評估需要額外 Proxy 才能存取萬用字元網域的情況。這可能是由於 envoy 目前的限制所致。在出口閘道 Pod 中建立了一個 nginx Proxy 作為 Sidecar。

Egress gateway with additional SNI Proxy — 使用額外 SNI Proxy 的出口閘道

環境

Istio 版本：1.0.2
K8s 版本：1.10.5_1517
Acmeair 應用程式：4 個服務（每個服務 1 個副本）、服務間交易、外部 Mongo DB，平均有效載荷：620 個位元組。

結果

使用 Jmeter 產生工作負載，其中包含一系列 5 分鐘的執行，每次執行都使用不斷增長的用戶端數量發出 HTTP 請求。使用的用戶端數量為 1、5、10、20、30、40、50 和 60。

輸送量

下圖顯示了不同案例的輸送量

Throughput obtained for the different cases — 不同案例的輸送量

如您所見，在應用程式和外部 MongoDB 之間存在 Sidecar 和出口閘道並不會產生重大影響，但是啟用相互 TLS，然後加入 SNI Proxy 分別導致輸送量下降約 10% 和 24%。

回應時間

當使用 20 個用戶端驅動流量時，會收集不同請求的平均回應時間。下圖顯示了每個案例的平均值、中位數、90%、95% 和 99% 的平均值

Response times obtained for the different configurations — 不同組態的回應時間

同樣地，前 3 個案例的回應時間沒有太大差異，但是相互 TLS 和額外的 Proxy 會增加明顯的延遲。

CPU 使用率

在執行期間，會收集所有 Istio 元件以及 Sidecar 的 CPU 使用率。為了進行公平的比較，Istio 使用的 CPU 會依據給定執行的輸送量進行標準化。結果顯示在下圖中

CPU usage normalized by TPS — 依據 TPS 標準化的 CPU 使用量

就每個交易的 CPU 消耗而言，僅在出口閘道 + SNI Proxy 案例中，Istio 使用的 CPU 明顯較多。

結論

在本次調查中，我們嘗試了不同的選項來存取啟用了 TLS 的外部 MongoDB，以比較它們的效能。引入出口閘道對效能沒有顯著影響，也沒有顯著增加 CPU 消耗。只有在啟用 Sidecar 和出口閘道之間的相互 TLS 或使用額外的 SNI Proxy 來處理萬用字元網域時，我們才能觀察到一些效能下降。