最佳實務：服務網格效能基準測試
評估 Istio 資料平面效能的工具和指南。
服務網格為應用程式部署添加了許多功能，包括流量策略、可觀察性和安全通訊。但是，在您的環境中添加服務網格會產生代價，無論是時間（增加的延遲）還是資源（CPU 週期）。為了在服務網格是否適合您的使用案例上做出明智的決定，評估您的應用程式在部署服務網格時的效能至關重要。
今年初，我們發布了一篇關於 Istio 1.1 版本效能改進的部落格文章。在Istio 1.2發布後，我們希望提供指導和工具，以幫助您在生產就緒的 Kubernetes 環境中基準測試 Istio 的資料平面效能。
總體而言，我們發現 Istio 的邊車代理延遲會隨著並行連線數量的增加而擴展。在每秒 1000 個請求 (RPS) 的情況下，跨 16 個連線，Istio 在第 50 個百分位數為每個請求增加 3 毫秒，在第 99 個百分位數增加 10 毫秒。
在Istio 工具儲存庫中，您會找到測量 Istio 資料平面效能的腳本和說明，以及關於如何使用另一個服務網格實作Linkerd執行腳本的其他說明。當我們詳細介紹效能測試框架的每個步驟的最佳實務時，請跟隨我們。
1. 使用生產就緒的 Istio 安裝
為了準確測量大規模服務網格的效能，使用足夠大小的 Kubernetes 叢集非常重要。我們使用三個工作節點進行測試，每個節點至少有 4 個 vCPU 和 15 GB 的記憶體。
然後，在該叢集上使用生產就緒的 Istio 安裝設定檔非常重要。這讓我們可以實現以效能為導向的設定，例如控制平面 pod 自動擴展，並確保資源限制適用於高流量負載。預設 Istio 安裝適用於大多數基準測試使用案例。對於廣泛的效能基準測試，具有數千個代理注入服務，我們還提供了調整的 Istio 安裝，它將額外的記憶體和 CPU 分配給 Istio 控制平面。
Istio 的示範安裝不適用於效能測試，因為它旨在部署在小型試用叢集上，並且啟用完整追蹤和存取日誌以展示 Istio 的功能。
2. 專注於資料平面
我們的基準測試腳本專注於評估 Istio 資料平面：在應用程式容器之間仲介流量的Envoy代理。為什麼要專注於資料平面？因為在大規模情況下，有很多應用程式容器，資料平面的記憶體和 CPU 使用量很快就會超過 Istio 控制平面的使用量。讓我們看一個例子，了解這種情況如何發生。
假設您執行 2,000 個 Envoy 注入的 pod，每個 pod 每秒處理 1,000 個請求。每個代理使用 50 MB 的記憶體，並且為了配置所有這些代理，Pilot 使用 1 個 vCPU 和 1.5 GB 的記憶體。總而言之，Istio 資料平面（所有 Envoy 代理的總和）使用 100 GB 的記憶體，而 Pilot 使用 1.5 GB。
出於延遲原因，專注於資料平面效能也很重要。這是因為大多數應用程式請求都會流經 Istio 資料平面，而不是控制平面。有兩個例外情況
- 遙測報告：每個代理都會將原始遙測資料發送到 Mixer，Mixer 會將這些資料處理成度量、追蹤和其他遙測資料。原始遙測資料與存取日誌類似，因此會產生代價。存取日誌處理會消耗 CPU，並阻止工作執行緒接收下一個工作單元。在較高的輸送量下，下一個工作單元更有可能在佇列中等待工作執行緒接收。這可能會導致 Envoy 的長尾（第 99 個百分位數）延遲。
- 自訂策略檢查：當使用自訂 Istio 策略轉接器時，策略檢查會在請求路徑上。這表示資料路徑上的請求標頭和中繼資料將會傳送到控制平面 (Mixer)，導致更高的請求延遲。注意：這些策略檢查預設為停用，因為最常見的策略使用案例 (RBAC) 完全由 Envoy 代理執行。
當 Mixer V2 將所有策略和遙測功能直接移入代理時，這兩個例外情況將在未來的 Istio 版本中消失。
接下來，當大規模測試 Istio 的資料平面效能時，不僅要測試每秒增加的請求數，還要針對增加數量的並行連線進行測試。這是因為真實世界中的高輸送量流量來自多個用戶端。提供的腳本可讓您在增加 RPS 的情況下，使用任意數量的並行連線執行相同的負載測試。
最後，我們的測試環境會測量兩個 pod 之間的請求，而不是多個。用戶端 pod 是Fortio，它會將流量傳送到伺服器 pod。
為什麼只使用兩個 pod 進行測試？因為擴展輸送量 (RPS) 和連線數（執行緒數）對 Envoy 效能的影響大於增加服務登錄檔的總大小 — 或 Kubernetes 叢集中 pod 和服務的總數。當服務登錄檔的大小增加時，Envoy 必須追蹤更多端點，並且每個請求的查閱時間確實會增加，但幅度很小。如果您有很多服務，而且這個常數會造成延遲問題，Istio 會提供Sidecar 資源，可讓您限制每個 Envoy 了解哪些服務。
3. 測量有和沒有代理的情況
雖然許多 Istio 功能（例如相互 TLS 驗證）依賴於應用程式 pod 旁邊的 Envoy 代理，但您可以選擇性地停用某些網格服務的邊車代理注入。在您為生產環境擴展 Istio 時，您可能需要逐步將邊車代理新增至您的工作負載。
為此，測試腳本提供了三種不同的模式。這些模式會分析當請求通過用戶端和伺服器代理（both）、僅通過伺服器代理（serveronly）以及沒有代理（baseline）時 Istio 的效能。
您也可以停用Mixer以在效能測試期間停止 Istio 的遙測，這會提供符合我們預期在 Mixer V2 工作完成時的效能結果。Istio 也支援Envoy 原生遙測，其效能與停用 Istio 遙測類似。
Istio 1.2 效能
讓我們看看如何使用此測試環境來分析 Istio 1.2 的資料平面效能。我們還提供了執行 Linkerd 資料平面相同效能測試的說明。目前，Linkerd 僅支援延遲基準測試。
為了測量 Istio 的邊車代理延遲，我們觀察並行連線數增加時第 50、90 和 99 個百分位數，同時保持請求輸送量 (RPS) 恆定。
我們發現，當請求同時通過用戶端和伺服器代理時，在 16 個並行連線和 1000 RPS 的情況下，Istio 在基準線 (P50) 上增加了 3 毫秒。（從綠線 both 中減去粉紅線 base。）在 64 個並行連線的情況下，Istio 在基準線上增加了 12 毫秒，但停用 Mixer (nomixer_both) 時，Istio 僅增加了 7 毫秒。
在第 90 個百分位數中，使用 16 個並行連線時，Istio 增加了 6 毫秒；使用 64 個連線時，Istio 增加了 20 毫秒。
最後，在第 99 個百分位數中，使用 16 個連線時，Istio 在基準線上增加了 10 毫秒。在 64 個連線的情況下，Istio 在有 Mixer 的情況下增加了 25 毫秒，在沒有 Mixer 的情況下增加了 10 毫秒。
在 CPU 使用率方面，我們測量了在請求吞吐量（RPS）增加，且並行連線數保持不變的情況下之效能。我們發現啟用 Mixer 時，Envoy 在 3000 RPS 下的最大 CPU 使用率為 1.2 個虛擬 CPU (vCPU)。在 1000 RPS 下，一個 Envoy 大約使用半個 CPU。
總結
在對 Istio 的效能進行基準測試的過程中，我們學到了幾個關鍵的經驗教訓
- 使用模擬生產環境的環境。
- 專注於資料平面的流量。
- 以基準為依據進行測量。
- 增加並行連線數以及總吞吐量。
對於一個在 16 個連線中具有 1000 RPS 的網格，Istio 1.2 在第 50 百分位數上，僅比基準增加了 3 毫秒 的延遲。
另請查看 Istio 效能與可擴展性指南，以獲取最新的效能數據。
感謝您的閱讀，祝您基準測試愉快！
