Prestaties en schaalaanpassing van Istio service mesh add-ons

De Istio-gebaseerde service mesh add-on wordt logisch gesplitst in een controlevlak (istiod) en een gegevensvlak. Het gegevensvlak bestaat uit sidecar proxies van Envoy binnen workload pods. Istiod beheert en configureert deze Envoy-proxy's. Dit artikel bevat de prestaties van zowel het besturingsvlak als het gegevensvlak voor revisie asm-1-19, waaronder resourceverbruik, sidecarcapaciteit en latentieoverhead. Daarnaast biedt het suggesties voor het aanpakken van mogelijke belasting van resources tijdens perioden van zware belasting. Dit artikel bevat ook informatie over het aanpassen van schalen voor het besturingsvlak en de gateways.

Prestaties van het controlevlak

De CPU- en geheugenvereisten van Istiod correleren met de snelheid van implementatie- en configuratiewijzigingen en het aantal verbonden proxy's. De geteste scenario's zijn:

• Podverloop: onderzoekt de effecten van podverloop op istiod. Om variabelen te reduceren, wordt voor alle sidecars slechts één service gebruikt.
• Meerdere services: onderzoekt de impact van meerdere services op het maximale aantal sidecars dat Istiod kan beheren (sidecarcapaciteit), waarbij elke service N sidecars heeft, wat resulteert in het totale maximum.

Testspecificaties

• Eén istiod exemplaar met standaardinstellingen
• Horizontaal automatisch schalen van pods uitgeschakeld
• Getest met twee netwerkinvoegtoepassingen: Azure Container Networking Interface (CNI) Overlay en Azure CNI-overlay met Cilium (aanbevolen netwerkinvoegtoepassingen voor grootschalige clusters)
• Knooppunt-SKU: Standard D16 v3 (16 vCPU, 64 GB geheugen)
• Kubernetes-versie: 1.28.5
• Istio revisie: asm-1-19

Podverloop

Het ClusterLoader2-framework is gebruikt om te bepalen hoeveel sidecars Istiod maximaal kan beheren wanneer er sidecarverloop is. Het churnpercentage wordt gedefinieerd als het percentage sidecars dat tijdens de test omlaag/omhoog worden gezet. 50% omzetting voor 10.000 sidecars betekent bijvoorbeeld dat 5.000 sidecars zijn verwijderd en dat 5.000 sidecars zijn toegevoegd. De geteste verlooppercentages zijn bepaald op basis van het typische verlooppercentage tijdens implementaties (maxUnavailable). Het verlooppercentage werd berekend door het totale aantal sidecars te bepalen dat zowel omhoog als omlaag is gegaan gedurende de werkelijke tijd die nodig was om het verloopproces te voltooien.

Sidecar-capaciteit en Istiod-CPU en geheugen

Azure CNI-overlay

Verloop (%)	Verloopsnelheid (sidecars/sec)	Sidecar-capaciteit	Istiod-geheugen (GB)	Istiod CPU
0	--	25000	32.1	15
vijfentwintig	31.2	15000	22.2	15
50	31.2	15000	25.4	15

Azure CNI-overlay met Cilium

Verloop (%)	Verloopsnelheid (sidecars/sec)	Sidecar-capaciteit	Istiod-geheugen (Gigabyte)	Istiod CPU
0	--	30.000	41.2	15
vijfentwintig	41.7	25000	36.1	16
50	37.9	25000	42.7	16

Meerdere services

Het ClusterLoader2-framework is gebruikt om te bepalen hoeveel sidecars istiod maximaal kunnen worden beheerd met 1000 services. De resultaten kunnen worden vergeleken met de 0% verlooptest (één service) in het pod-verloopscenario. Elke service had N sidecars die bijdroegen aan het totale maximum aantal sidecars. Het resourcegebruik van de API Server is waargenomen om te bepalen of er sprake is van aanzienlijke stress van de invoegtoepassing.

Sidecar-capaciteit

Azure CNI-Overlay	Azure CNI-overlay met Cilium
20000	20000

CPU en geheugen

Hulpbron	Azure CNI-Overlay	Azure CNI-overlay met Cilium
Geheugen van API-server (GB)	38.9	9.7
CPU van API-server	6.1	4.7
Istiod geheugen (GB)	40,4	42.6
Istiod CPU	15	16

Prestaties van gegevensvlak

Verschillende factoren zijn van invloed op sidecarprestaties, zoals de verzoekgrootte, het aantal proxywerkerthreads en het aantal clientverbindingen. Bovendien doorloopt elke aanvraag die via de mesh stroomt de proxy aan de clientzijde en vervolgens de proxy aan de serverzijde. Daarom worden latentie en resourceverbruik gemeten om de prestaties van het gegevensvlak te bepalen.

Fortio is gebruikt om de lading te creëren. De test is uitgevoerd met de Istio-benchmarkopslagplaats die is gewijzigd voor gebruik met de invoegtoepassing.

Testspecificaties

• Getest met twee netwerkinvoegtoepassingen: Azure CNI Overlay en Azure CNI-overlay met Cilium (aanbevolen netwerkinvoegtoepassingen voor grootschalige clusters)
• Knooppunt-SKU: Standard D16 v5 (16 vCPU, 64 GB geheugen)
• Kubernetes-versie: 1.28.5
• Twee proxymedewerkers
• 1 kB datapakket
• 1000 query's per seconde (QPS) bij verschillende clientverbindingen
• http/1.1 protocol en wederzijdse TLS (Transport Layer Security) ingeschakeld
• 26 verzamelde gegevenspunten

CPU en geheugen

Het geheugen- en CPU-gebruik voor zowel de client- als serverproxy voor 16 clientverbindingen en 1000 QPS in alle scenario's met netwerkinvoegtoepassingen is ongeveer 0,4 vCPU en 72 MB.

Wachttijd

De Sidecar Envoy-proxy verzamelt onbewerkte telemetriegegevens na het reageren op een client, wat niet rechtstreeks van invloed is op de totale verwerkingstijd van de aanvraag. Dit proces vertraagt echter het begin van de verwerking van de volgende aanvraag, wat bijdraagt aan wachttijden in de wachtrij en het beïnvloeden van gemiddelde en staartlatenties. Afhankelijk van het verkeerspatroon varieert de werkelijke tail-latentie.

De volgende resultaten evalueren de impact van het toevoegen van sidecar proxies aan het gegevenspad en tonen daarmee de latentiepercentielen P90 en P99.

• Sidecar-verkeerspad: client-sidecar> --> server-sidecar --> server
• Basislijnverkeerspad: client --> server

Hier vindt u een vergelijking van de prestaties van gegevensvlaklatentie in istio-invoegtoepassing en AKS-versies.

Azure CNI-Overlay	Azure CNI-overlay met Cilium

Opschalen

Aanpassing van horizontale pod-autoscaling

Automatische schaalaanpassing van pods (HPA) is ingeschakeld voor de implementaties van gateways istiod voor inkomend/uitgaand verkeer. De standaardconfiguraties voor istiod en de gateways zijn:

• Minimale replicas: 2
• Maximum aantal replica's: 5
• CPU-gebruik: 80%

Opmerking

Om conflicten met de PodDisruptionBudget te voorkomen, staat de invoegtoepassing niet toe dat de minReplicas wordt ingesteld onder de oorspronkelijke standaardwaarde van 2.

De volgende zijn de istiod- en ingress-gateway-HPA-resources:

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

De HPA-configuratie kan worden gewijzigd via patches en directe bewerkingen. Voorbeeld:

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

Opmerking

Zie de documentatie voor de upgrade van de Istio-invoegtoepassing voor meer informatie over hoe HPA-instellingen worden toegepast op beide revisies tijdens een canary-upgrade.

Servicevermelding

Met de aangepaste resourcedefinitie van Istio serviceEntry kunnen andere services worden toegevoegd aan het interne serviceregister van Istio. Met een ServiceEntry kunnen services die al in de mesh aanwezig zijn, de opgegeven services verzenden of toegang krijgen tot. De configuratie van meerdere ServiceEntries met het resolution veld dat is ingesteld op DNS kan echter een zware belasting veroorzaken op DNS-servers (Domain Name System). Met de volgende suggesties kunt u de belasting verminderen:

• Schakel over naar resolution: NONE om DNS-proxyzoekacties volledig te voorkomen. Geschikt voor de meeste gebruiksvoorbeelden. Wanneer u echter een Istio-add-on egress gateway gebruikt, moet het oplossingstype van de ServiceEntry worden ingesteld op DNS.
• Verhoog TTL (Time To Live) als u de beheerder van de op te lossen domeinen bent.
• Beperk het bereik ServiceEntry met exportTo.