Dela via

Prestanda och skalning för Istio Service Mesh-tillägg

  • Artikel

Det Istio-baserade tjänstnättillägget är logiskt uppdelat i ett kontrollplan (istiod) och ett dataplan. Dataplanet består av Envoy-proxyservrar i arbetsbelastningspoddar. Istiod hanterar och konfigurerar dessa Envoy-proxyservrar. I den här artikeln beskrivs prestanda för både kontroll- och dataplanet för revision asm-1-19, inklusive resursförbrukning, sidovagnskapacitet och svarstid. Dessutom innehåller den förslag på hur du kan hantera potentiella belastningar på resurser under perioder med hög belastning. Den här artikeln beskriver också hur du anpassar skalning för kontrollplanet och gatewayerna.

Kontrollplansprestanda

Istiods processor- och minneskrav korrelerar med distributionstakten och konfigurationsändringarna och antalet anslutna proxyservrar. De scenarier som testades var:

  • Poddomsättning: undersöker effekten av poddomsättning på istiod. För att minska variabler används endast en tjänst för alla sidovagnar.
  • Flera tjänster: undersöker effekten av flera tjänster på den maximala sidovagn som Istiod kan hantera (sidovagnskapacitet), där varje tjänst har N sidovagn, totalt det totala maximala.

Testspecifikationer

  • En istiod instans med standardinställningar
  • Vågrät autoskalning av poddar inaktiverad
  • Testad med två plugin-program för nätverk: Överlägg för Azure Container Networking Interface (CNI) och Azure CNI Overlay med Cilium (rekommenderade nätverksinsticksprogram för storskaliga kluster)
  • Node SKU: Standard D16 v3 (16 vCPU, 64 GB minne)
  • Kubernetes-version: 1.28.5
  • Istio-revision: asm-1-19

Poddomsättning

Ramverket ClusterLoader2 användes för att fastställa det maximala antalet sidovagnar som Istiod kan hantera när det finns sidovagnsomsättning. Omsättningsprocenten definieras som procent av sidovagnen som tappas ned/upp under testet. Till exempel skulle 50 % omsättning för 10 000 sidobilar innebära att 5 000 sidovagnar minskade, sedan omsväxlades 5 000 sidobilar. De procentomsättningar som testades fastställdes utifrån den typiska omsättningsprocenten under distributionsdistributionen (maxUnavailable). Omsättningsfrekvensen beräknades genom att fastställa det totala antalet sidvagnsomsättningar (upp och ned) under den faktiska tid det tog att slutföra omsättningsprocessen.

Sidecar-kapacitet och Istiod-processor och minne

Azure CNI-överlägg

Omsättning (%) Omsättningshastighet (sidovagnar/sek) Sidovagnskapacitet Istiod-minne (GB) Istiod CPU
0 -- 25000 32,1 15
25 31,2 15000 22.2 15
50 31,2 15000 25,4 15

Azure CNI-överlägg med Cilium

Omsättning (%) Omsättningshastighet (sidovagnar/sek) Sidovagnskapacitet Istiod-minne (GB) Istiod CPU
0 -- 30000 41.2 15
25 41.7 25000 36.1 16
50 37.9 25000 42.7 16

Flera tjänster

Ramverket ClusterLoader2 användes för att fastställa det maximala antalet sidovagnar istiod som kan hanteras med 1 000 tjänster. Resultaten kan jämföras med 0 % churn-testet (en tjänst) i poddomsättningsscenariot. Varje tjänst hade N sidovagnar som bidrog till det totala maximala antalet sidovagnar. Api Server-resursanvändningen observerades för att avgöra om det fanns någon betydande stress från tillägget.

Sidovagnskapacitet

Azure CNI-överlägg Azure CNI-överlägg med Cilium
20000 20000

CPU och minne

Resurs Azure CNI-överlägg Azure CNI-överlägg med Cilium
API Server-minne (GB) 38.9 9,7
API Server CPU 6.1 4.7
Istiod-minne (GB) 40.4 42.6
Istiod CPU 15 16

Prestanda för dataplan

Olika faktorer påverkar prestanda för sidovagn, till exempel begärandestorlek, antal proxyarbetstrådar och antal klientanslutningar. Dessutom passerar alla begäranden som flödar genom nätet proxyn på klientsidan och sedan proxyn på serversidan. Därför mäts svarstid och resursförbrukning för att fastställa dataplanets prestanda.

Fortio användes för att skapa belastningen. Testet utfördes med Istio benchmark-lagringsplatsen som ändrades för användning med tillägget.

Testspecifikationer

  • Testad med två nätverksinsticksprogram: Azure CNI Overlay och Azure CNI Overlay med Cilium (rekommenderade nätverksinsticksprogram för storskaliga kluster)
  • Node SKU: Standard D16 v5 (16 vCPU, 64 GB minne)
  • Kubernetes-version: 1.28.5
  • Två proxyarbetare
  • Nyttolast på 1 KB
  • 1 000 frågor per sekund (QPS) vid varierande klientanslutningar
  • http/1.1 protokoll och ömsesidig TLS (Transport Layer Security) aktiverat
  • 26 insamlade datapunkter

CPU och minne

Minnes- och CPU-användningen för både klient- och serverproxyn för 16 klientanslutningar och 1 000 QPS i alla scenarier för nätverksinsticksprogram är ungefär 0,4 vCPU och 72 MB.

Svarstid

Proxyn för sidecar Envoy samlar in rådata efter att ha svarat på en klient, vilket inte direkt påverkar begärans totala bearbetningstid. Den här processen fördröjer dock starten av hanteringen av nästa begäran, vilket bidrar till köväntetider och påverkar genomsnittliga och avslutande svarstider. Beroende på trafikmönstret varierar den faktiska svarstiden för svansen.

Följande resultat utvärderar effekten av att lägga till sidovagnsproxy i datasökvägen, vilket visar P90- och P99-svarstiden.

  • Sidovagnstrafiksökväg: klient --> klient-sidovagn --> server-sidovagn --> server
  • Trafiksökväg för baslinje: klient –> server

En jämförelse av prestanda för dataplanets svarstid mellan Istio-tillägget och AKS-versioner finns här.

Azure CNI-överlägg Azure CNI-överlägg med Cilium
Diagram som jämför P99-svarstid för Azure CNI-överlägg. Diagram som jämför P99-svarstid för Azure CNI-överlägg med Cilium.
Diagram som jämför P90-svarstid för Azure CNI-överlägg. Diagram som jämför P90-svarstid för Azure CNI-överlägg med Cilium.

Skalning

Anpassning av horisontell autoskalning av poddar

Horisontell autoskalning av poddar (HPA) är aktiverat för gateway-poddarna istiod och ingressen. Standardkonfigurationerna för istiod och gatewayerna är:

  • Minsta repliker: 2
  • Maximalt antal repliker: 5
  • CPU-användning: 80 %

Kommentar

För att förhindra konflikter med PodDisruptionBudgettillåter tillägget inte inställningen minReplicas under den ursprungliga standardinställningen för 2.

Följande är istiod hpa-resurserna och ingressgatewayen:

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-konfigurationen kan ändras genom korrigeringar och direktredigeringar. Exempel:

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

Kommentar

Mer information om hur HPA-inställningar tillämpas för båda revisionerna under en kanarieuppgradering finns i dokumentationen om istio-tilläggsuppgradering.

Tjänstpost

Istios anpassade resursdefinition ServiceEntry gör det möjligt att lägga till andra tjänster i Istios interna tjänstregister. Med ServiceEntry kan tjänster som redan finns i nätet dirigera eller komma åt de angivna tjänsterna. Konfigurationen av flera ServiceEntries med resolution fältet inställt på DNS kan dock orsaka en stor belastning på DNS-servrar (Domain Name System). Följande förslag kan bidra till att minska belastningen:

  • Växla till resolution: NONE för att undvika proxy-DNS-sökningar helt och hållet. Lämplig för de flesta användningsfall.
  • Öka TTL (Time To Live) om du kontrollerar de domäner som löses.
  • Begränsa ServiceEntry-omfånget med exportTo.