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 延遲。
- Sidecar 流量路徑：用戶端 --> client-sidecar --> server-sidecar --> 伺服器
- 基準流量路徑：用戶端 --> 伺服器
您可以在這裡找到跨 Istio 附加元件和 AKS 版本的數據平面延遲效能比較。
| Azure CNI 重疊 | 使用 Cilium 的 Azure CNI Overlay |
|---|---|
 |
 |
 |
 |
調整大小
水準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 範圍。
