Teilen über

Leistung und Skalierung des Istio-Dienstnetz-Add-Ons

  • Artikel

Das Istio-basierte Service Mesh-Add-On ist logisch in eine Steuerungsebene (istiod) und in eine Datenebene unterteilt. Die Datenebene besteht aus Envoy-Sidecar-Proxys innerhalb von Workload-Pods. Diese Envoy-Proxys werden von Istiod verwaltet und konfiguriert. Dieser Artikel enthält Informationen zur Leistung der Steuerungs- und Datenebene für die Revision „asm-1-19“ (einschließlich Ressourcenverbrauch, Sidecarkapazität und zusätzlicher Wartezeit). Darüber hinaus finden Sie hier Empfehlungen für die Behandlung potenzieller Ressourcenbelastungen bei hoher Auslastung. In diesem Artikel wird auch beschrieben, wie Sie die Skalierung für die Steuerungsebene und Gateways anpassen.

Leistung der Steuerungsebene

Die CPU- und Arbeitsspeicheranforderungen von Istiod korrelieren mit der Rate der Bereitstellungs- und Konfigurationsänderungen und der Anzahl verbundener Proxys. Folgende Szenarien wurden getestet:

  • Pod-Churn: Untersucht die Auswirkungen von Pod-Churning auf istiod. Zur Reduzierung von Variablen wird für alle Sidecars nur ein einzelner Dienst verwendet.
  • Mehrere Dienste: Untersucht die Auswirkungen mehrerer Dienste auf die maximale Anzahl von Sidecars, die Istiod verwalten kann (Sidecarkapazität). Hierbei hat jeder Dienst N Sidecars, woraus sich der gesamte Maximalwert ergibt.

Testspezifikationen

  • Eine einzelne istiod-Instanz mit Standardeinstellungen
  • Horizontale automatische Podskalierung deaktiviert
  • Getestet mit zwei Netzwerk-Plug-Ins: Azure Container Networking Interface (CNI) Overlay und Azure CNI Overlay mit Cilium (empfohlene Netzwerk-Plug-Ins für große Cluster)
  • Knoten-SKU: Standard D16 v3 (16 vCPUs, 64 GB Arbeitsspeicher)
  • Kubernetes-Version: 1.28.5
  • Istio-Revision: asm-1-19

Pod-Churn

Das ClusterLoader2-Framework wurde verwendet, um die maximale Anzahl von Sidecars zu bestimmen, die Istiod bei Auftreten von Sidecar-Churning verwalten kann. Der Churn-Prozentsatz wird als prozentualer Anteil der Sidecars definiert, die während des Tests weggefallen oder hinzugekommen sind. Ein Churn von 50 Prozent für 10.000 Sidecars bedeutet beispielsweise, dass 5.000 Sidecars weggefallen und anschließend 5.000 Sidecars hinzugekommen sind. Die getesteten Churn-Prozentsätze wurden auf der Grundlage des typischen Churn-Prozentsatzes während des Bereitstellungsrollouts (maxUnavailable) ermittelt. Zur Berechnung des Churn wurde die Gesamtanzahl von Sidecars mit Churn (unabhängig von der Art des Churn) für die tatsächliche Zeit bis zum Abschluss des Churning-Prozesses ermittelt.

Sidecarkapazität und sowie CPU und Arbeitsspeicher von Istiod

Azure CNI Overlay

Churn (Prozent) Churn (Sidecars/Sek.) Sidecarkapazität Istiod-Arbeitsspeicher (GB) Istiod-CPU
0 -- 25000 32,1 15
25 31.2 15000 22.2 15
50 31.2 15000 25.4 15

Azure CNI Overlay mit Cilium

Churn (Prozent) Churn (Sidecars/Sek.) Sidecarkapazität Istiod-Arbeitsspeicher (GB) Istiod-CPU
0 -- 30.000 41,2 15
25 41,7 25000 36,1 16
50 37,9 25000 42,7 16

Mehrere Dienste

Das ClusterLoader2-Framework wurde verwendet, um die maximale Anzahl von Sidecars zu bestimmen, die istiod mit 1.000 Diensten verwalten kann. Die Ergebnisse können mit dem Null-Prozent-Churn-Test (einzelner Dienst) im Pod-Churn-Szenario verglichen werden. Jeder Dienst verfügte über N Sidecars, die zur gesamten maximalen Anzahl von Sidecars beitragen. Die API Server-Ressourcenauslastung wurde beobachtet, um festzustellen, ob das Add-On zu einer erheblichen Belastung führt.

Sidecarkapazität

Azure CNI Overlay Azure CNI Overlay mit Cilium
20000 20000

CPU und Arbeitsspeicher

Resource Azure CNI Overlay Azure CNI Overlay mit Cilium
API-Serverarbeitsspeicher (GB) 38,9 9.7
API-Server-CPU 6.1 4.7
Istiod-Arbeitsspeicher (GB) 40,4 42,6
Istiod-CPU 15 16

Leistung der Datenebene

Die Sidecarleistung wird durch verschiedene Faktoren beeinflusst. Hierzu zählen beispielsweise die Anforderungsgröße, die Anzahl von Proxyarbeitsthreads und die Anzahl von Clientverbindungen. Darüber hinaus durchläuft jede Anforderung auf ihrem Weg durch das Mesh den clientseitigen Proxy und dann den serverseitigen Proxy. Daher werden Wartezeit und Ressourcenverbrauch gemessen, um die Leistung der Datenebene zu ermitteln.

Fortio wurde zum Erstellen der Last verwendet. Der Test wurde mit dem Istio-Benchmarkrepository durchgeführt, das für die Verwendung mit dem Add-On angepasst wurde.

Testspezifikationen

  • Getestet mit zwei Netzwerk-Plug-Ins: Azure CNI Overlay und Azure CNI Overlay mit Cilium (empfohlene Netzwerk-Plug-Ins für große Cluster)
  • Knoten-SKU: Standard D16 v5 (16 vCPUs, 64 GB Arbeitsspeicher)
  • Kubernetes-Version: 1.28.5
  • Zwei Proxyworker
  • Nutzdaten mit einer Größe von 1 KB
  • 1.000 QPS (Queries per Second, Abfragen pro Sekunde) bei variierenden Clientverbindungen
  • Aktivierung des http/1.1-Protokolls und von Mutual Transport Layer Security (TLS)
  • 26 gesammelte Datenpunkte

CPU und Arbeitsspeicher

Die Arbeitsspeicher- bzw. CPU-Auslastung für den Client- und den Serverproxy für 16 Clientverbindungen und 1.000 QPS in allen Netzwerk-Plug-In-Szenarien liegt bei etwa 0,4 virtuellen CPUs bzw. bei 72 MB.

Latency

Der Sidecar-Envoy-Proxy sammelt unformatierte Telemetriedaten nach der Antwort an einen Client, was sich nicht direkt auf die Gesamtverarbeitungszeit der Anforderung auswirkt. Dieser Prozess verzögert jedoch den Beginn der Behandlung der nächsten Anforderung. Somit trägt er zu Wartezeiten in der Warteschlange bei und beeinflusst die durchschnittliche Wartezeit sowie die Wartezeit am Ende. Die tatsächliche Wartezeit am Ende variiert je nach Datenverkehrsmuster.

In den folgenden Ergebnissen werden die Auswirkungen des Hinzufügens von Sidecarproxys zum Datenpfad ausgewertet und die P90- und die P99-Wartezeit dargestellt.

  • Sidecar-Datenverkehrspfad: Client --> Client-Sidecar --> Server-Sidecar --> Server
  • Baseline-Datenverkehrspfad: Client --> Server

Hier finden Sie einen Vergleich der Latenzleistung auf Datenebene über das Istio-Add-On und die AKS-Versionen hinweg.

Azure CNI Overlay Azure CNI Overlay mit Cilium
Diagramm: Vergleich der P99-Wartezeit für Azure CNI Overlay Diagramm: Vergleich der P99-Wartezeit für Azure CNI Overlay mit Cilium
Diagramm: Vergleich der P90-Wartezeit für Azure CNI Overlay Diagramm: Vergleich der P90-Wartezeit für Azure CNI Overlay mit Cilium

Skalierung

Automatische Anpassung des horizontalen Pods

Horizontale automatische Podskalierung (Horizontal Pod Autoscaling, HPA) ist für die istiod- und Eingangsgatewaypods aktiviert. Standardkonfigurationen für istiod und die Gateways:

  • Mindestanzahl Replikate: 2
  • Maximale Anzahl Replikate: 5
  • CPU-Auslastung: 80 %

Hinweis

Um Konflikte mit PodDisruptionBudget zu verhindern, lässt das Add-On das Festlegen von minReplicas auf einen niedrigeren Wert als die anfängliche Standardeinstellung 2 nicht zu.

Im Folgenden sind die HPA-Ressourcen für istiod und das Eingangsgateway aufgeführt:

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

Die HPA-Konfiguration kann über Patches und direkte Bearbeitungen geändert werden. Beispiel:

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

Hinweis

In der Dokumentation zum Istio-Add-On-Upgrade finden Sie Einzelheiten dazu, wie HPA-Einstellungen während eines Canary-Upgrades auf beide Revisionen angewendet werden.

Diensteintrag

Die benutzerdefinierte Ressourcendefinition „ServiceEntry“ von Istio ermöglicht das Hinzufügen anderer Dienste zur internen Dienstregistrierung von Istio. Ein Diensteintrag (ServiceEntry) ermöglicht es Diensten, die sich bereits im Mesh befindet, die angegebenen Dienste weiterzuleiten oder auf sie zuzugreifen. Die Konfiguration mehrerer Diensteinträge (ServiceEntries), bei denen das Feld resolution auf „DNS“ festgelegt ist, kann jedoch zu einer hohen Last für DNS-Server (Domain Name System) führen. Die folgenden Empfehlungen können zur Verringerung der Last beitragen:

  • Wechseln Sie zu resolution: NONE, um Proxy-DNS-Lookups vollständig zu vermeiden. Geeignet für die meisten Anwendungsfälle.
  • Erhöhen Sie die Gültigkeitsdauer (Time To Live, TTL), wenn Sie die aufzulösenden Domänen steuern.
  • Beschränken Sie den ServiceEntry-Bereich mit exportTo.