共用方式為

Istio 服務網格附加元件的效能和調整

  • 發行項

Istio 型服務網格附加元件在邏輯上分為控制平面 (istiod) 和資料平面。 資料平面由工作負載 Pod 內的 Envoy 側車 Proxy 組成。 Istiod 管理和設定這些 Envoy Proxy。 本文介紹了 asm-1-19 版本的控制和資料平面之效能，包括資源使用量、側車容量和延遲額外負荷。 此外，它還提供解决重負載時期資源潜在壓力的建議。 本文還介紹了如何自訂控制平面和閘道的調整。

控制平面效能

Istiod 的 CPU 和記憶體需求與部署和設定變更之速率以及連線之 Proxy 數量相關。 測試的案例包括：

  • Pod 流失：檢查 Pod 流失對 istiod 的影響。 為了减少變數，所有側車只使用一個服務。
  • 多個服務：檢查多個服務對 Istiod 可以管理的最大測車 (測車容量) 之影響，其中每個服務都有 N 個測車，總計最大值。

測試規格

  • 一個具有預設設定的 istiod 執行個體
  • 已停用水平 Pod 自動調整
  • 使用兩個網路外掛程式進行測試：Azure 容器網路介面 (CNI) 重疊和使用 Cilium 的 Azure CNI 重疊 (建議用於大型叢集的網路外掛程式)
  • 節點 SKU：標準 D16 v3 (16 vCPU，64-GB 記憶體)
  • Kubernetes 版本：1.28.5
  • Istio 修訂：asm-1-19

Pod 流失

ClusterLoader2 架構用於確定 Istiod 在側車流失時可以管理的最大側車數。 流失百分比是指在測試期間中向下/上流失的側車的百分比。 例如，10,000 個側車的 50% 流失表示 5,000 個側車大量向下流失，然後 5,000 個側車大量向上流失。 測試的流失百分比是根據部署推出期間的一般流失百分比確定的 (maxUnavailable)。 透過確定在完成流失過程所需的實際時間內流失 (上及下) 的側車總數來計算流失。

測車容量和 Istiod CPU 和記憶體

Azure CNI 重疊

流失 (%) 流失 (測車/秒) 測車容量 Istiod 記憶體 (GB) Istiod CPU
0 -- 25000 32.1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

使用 Cilium 的 Azure CNI 重疊

流失 (%) 流失 (測車/秒) 測車容量 Istiod 記憶體 (GB) Istiod CPU
0 -- 30000 41.2 15
25 41.7 25000 36.1 16
50 37.9 25000 42.7 16

多服務

ClusterLoader2 架構用於確定 1,000 個服務可以管理的測車 istiod 的最大數。 結果可以與 Pod 客戶流失案例中的 0% 客戶流失測試 (一個服務) 進行比較。 每項服務都有 N 個側車，這對側車總數的最大值有貢獻。 觀察 API 伺服器資源使用狀況，以確定是否存在來自附加元件的任何重大壓力。

測車容量

Azure CNI 重疊 使用 Cilium 的 Azure CNI Overlay
20000 20000

CPU 和記憶體

資源 Azure CNI 重疊 使用 Cilium 的 Azure CNI Overlay
API 伺服器記憶體(GB) 38.9 9.7
API 伺服器 CPU 6.1 4.7
Istiod 記憶體 (GB) 40.4 42.6
Istiod CPU 15 16

資料平面效能

各種要素影響測車效能，如要求大小、Proxy 背景工作角色執行緒數和用戶端連線數。 此外，流經網格的任何要求都會周遊用戶端 Proxy，然後周遊伺服器端 Proxy。 因此，度測延遲和資源使用量以確定資料平面效能。

Fortio 用於建立負載。 測試是使用 Istio 效能評定存放庫進行的，其經過修改後可與附加元件一起使用。

測試規格

  • 使用兩個網路外掛程式進行測試：Azure CNI 重疊和使用 Cilium 的 Azure CNI 重疊 (建議用於大規模叢集的網路外掛程式)
  • 節點 SKU：標準 D16 v5 (16 vCPU，64-GB 記憶體)
  • Kubernetes 版本：1.28.5
  • 2 個 Proxy 背景工作角色
  • 1-KB 承載
  • 在不同的用戶端連線上每秒 1,000 次査詢 (QPS)
  • 已啟用 http/1.1 通訊協定和相互傳輸層安全性 (TLS)
  • 收集了 26 個資料點

CPU 和記憶體

在所有網路外掛程式案例中，16 個用戶端連線和 1,000 個 QPS 的用戶端和伺服器 Proxy 之記憶體和 CPU 使用量約為 0.4 vCPU 和 72 MB。

延遲

測車 Envoy Proxy 在回應用戶端後收集原始遙測資料，這不會直接影響要求的總處理時間。 但是，此流程會延遲開始處理下一個要求，導致佇列等待時間增長，並影響平均延遲和結尾延遲。 根據流量模式的不同，實際的結尾延遲會有所不同。

以下結果評估了將測車 Proxy 新增至資料路徑的影響，顯示了 P90 和 P99 延遲。

Azure CNI 重疊 使用 Cilium 的 Azure CNI Overlay
比較 Azure CNI 重疊的 P99 延遲之圖表。 比較使用 Cilium 的 Azure CNI 重疊的 P99 延遲之圖表。
比較 Azure CNI 重疊的 P90 延遲之圖表。 比較使用 Cilium 的 Azure CNI 重疊的 P90 延遲之圖表。

調整大小

水平 Pod 自動調整

已為 istiod 和輸入閘道 Pod 啟用水平 Pod 自動調整 (HPA)。 istiod 和閘道的預設設定為：

  • 最小複本：2
  • 最大複本：5
  • CPU 使用率：80%

注意

為了防止與 PodDisruptionBudget 發生衝突，附加元件不允許將 minReplicas 設定為低於初始預設值 2。

以下是 istiod 和輸入閘道 HPA 資源：

NAMESPACE           NAME                                         REFERENCE
aks-istio-ingress   aks-istio-ingressgateway-external-asm-1-19   Deployment/aks-istio-ingressgateway-external-asm-1-19

aks-istio-ingress   aks-istio-ingressgateway-internal-asm-1-19   Deployment/aks-istio-ingressgateway-internal-asm-1-19

aks-istio-system    istiod-asm-1-19                              Deployment/istiod-asm-1-19

HPA 設定可以透過修正程式和直接編輯進行修改。 範例：

kubectl patch hpa aks-istio-ingressgateway-external-asm-1-19 -n aks-istio-ingress --type merge --patch '{"spec": {"minReplicas": 3, "maxReplicas": 6}}'

服務項目

Istio 的 ServiceEntry 自訂資源定義允許將其他服務新增至 Istio 內部服務登錄中。 ServiceEntry 允許已經在網格中的服務路由或存取指定服務。 但是，將 resolution 欄位設定為 DNS 的多個 ServiceEntries 之設定可能會導致網域名稱系統 (DNS) 伺服器負載過重。 以下建議有助於减少負載：

  • 切換至 resolution: NONE 以完全避免 Proxy DNS 查詢。 適用於大多數使用案例。
  • 如果您控制要解析的網域，請新增 TTL (存留時間)。
  • 使用 exportTo 限制 ServiceEntry 範圍。