Prestanda och skalning för Istio Service Mesh-tillägg
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.
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.
- 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
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.
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 |
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 |
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.
- 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
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.
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.
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 %
Anteckning
För att förhindra konflikter med PodDisruptionBudget
tillå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}}'
Anteckning
Mer information om hur HPA-inställningar tillämpas för båda revisionerna under en kanarieuppgradering finns i dokumentationen om istio-tilläggsuppgradering.
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
.
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: