Performances et mise à l’échelle des modules complémentaires du maillage de service Istio

Le module complémentaire de maillage de service basé sur Istio est divisé logiquement en un plan de contrôle (istiod) et un plan de données. Le plan de données est composé de proxys sidecar Envoy à l’intérieur des pods de charge de travail. Istiod gère et configure ces proxys Envoy. Cet article présente les performances des plans de contrôle et de données pour la révision asm-1-19, notamment la consommation des ressources, la capacité sidecar et la surcharge de latence. En outre, il fournit des suggestions pour traiter la pression potentielle sur les ressources pendant des périodes de charge importante. Cet article explique également comment personnaliser la mise à l’échelle pour le plan de contrôle et les passerelles.

Performances du plan de données

Les exigences en matière de processeur et de mémoire d’Istiod sont corrélées aux taux de modifications de déploiement et de configuration et au nombre de proxys connectés. Les scénarios testés étaient les suivants :

• Attrition des pods : examine l’impact de l’attrition des pods sur istiod. Pour réduire les variables, un seul service est utilisé pour tous les sidecars.
• Plusieurs services : examine l’impact de plusieurs services sur le nombtre maximal de sidecar que Istiod peut gérer (capacité sidecar), où chaque service a N sidecars, ce qui totalise le maximum global.

Spécifications de test

• Une instance istiod avec les paramètres par défaut
• Mise à l’échelle automatique des pods horizontaux désactivée
• Testé avec deux plug-ins réseau : superposition Azure CNI (Container Networking Interface) et superposition Azure CNI avec Cilium (plug-ins réseau recommandés pour les clusters à grande échelle)
• Référence SKU de nœud : Standard D16 v3 (16 processeurs virtuels, 64 Go de mémoire)
• Version de Kubernetes : 1.28.5
• Révision Istio : asm-1-19

Attrition des pods

L’infrastructure ClusterLoader2 a été utilisée pour déterminer le nombre maximal de sidecars que Istiod peut gérer lorsqu’il y a une attrition des sidecars. Le pourcentage d’attrition est défini en tant que pourcentage de sidecars réduits/augmentés pendant le test. Par exemple, 50 % d’attrition pour 10 000 sidecars signifient que 5 000 sidecars ont été réduits, puis 5 000 sidecars ont été augmentés. Les pourcentages d’attrition testés ont été déterminés à partir du pourcentage d’attrition classique pendant les lancements de déploiement (maxUnavailable). Le taux d’attrition a été calculé en déterminant le nombre total de sidecars réduits ou augmentés au cours du temps réel nécessaire pour terminer le processus d’attrition.

Capacité sidecar et processeur et mémoire d’Istiod

Superposition Azure CNI

Attrition (%)	Taux d’attrition (sidecars/s)	Capacité sidecar	Mémoire Istiod (Go)	Processeur Istiod
0	--	25000	32,1	15
25	31,2	15000	22.2	15
50	31,2	15000	25,4	15

Superposition Azure CNI avec Cilium

Attrition (%)	Taux d’attrition (sidecars/s)	Capacité sidecar	Mémoire Istiod (Go)	Processeur Istiod
0	--	30000	41.2	15
25	41,7	25000	36.1	16
50	37,9	25000	42,7	16

Plusieurs services.

L’infrastructure ClusterLoader2 a été utilisée pour déterminer le nombre maximal de sidecars que istiod peut gérer avec 1 000 services. Les résultats peuvent être comparés au test d’attrition de 0 % (un service) dans le scénario d’attrition de pod. Chaque service avait N sidecars contribuant au nombre total maximal de sidecars. On a observé que l’utilisation des ressources du serveur d’API déterminait si le module complémentaire subissait un stress significatif.

Capacité sidecar

Superposition Azure CNI	Superposition Azure CNI avec Cilium
20000	20000

Processeur et mémoire

Ressource	Superposition Azure CNI	Superposition Azure CNI avec Cilium
Mémoire du serveur d’API (Go)	38,9	9.7
Processeur du serveur d’API	6.1	4.7
Mémoire Istiod (Go)	40.4	42,6
Processeur Istiod	15	16

Performances du plan de données

Différents facteurs affectent les performances sidecar telles que la taille de la requête, le nombre de threads de travail proxy et le nombre de connexions clientes. En outre, toute requête qui transite par le maillage traverse le proxy côté client, puis le proxy côté serveur. Par conséquent, la latence et la consommation des ressources sont mesurées pour déterminer les performances du plan de données.

Fortio a été utilisé pour créer la charge. Le test a été effectué avec le référentiel de référence Istio modifié pour une utilisation avec le module complémentaire.

Spécifications de test

• Testé avec deux plug-ins réseau : Superposition Azure CNI et Superposition Azure CNI avec Cilium (plug-ins réseau recommandés pour les clusters à grande échelle)
• Référence SKU de nœud : Standard D16 v5 (16 processeurs virtuels, 64 Go de mémoire)
• Version de Kubernetes : 1.28.5
• Deux rôles de travail de proxy
• Charge utile de 1 Ko
• 1,000 RPS (requêtes par seconde) à différentes connexions du client
• Protocole http/1.1 et TLS (Transport Layer Security) mutuel activés
• 26 points de données collectés

Processeur et mémoire

L’utilisation de la mémoire et du processeur des proxys client et serveur pour 16 connexions clientes et 1 000 RPS dans tous les scénarios du plug-in réseau est d’environ 0,4 processeur virtuel et 72 Mo.

Latence

Le proxy Envoy sidecar collecte les données de télémétrie brutes après avoir répondu à un client, ce qui n’affecte pas directement le temps de traitement total de la requête. Toutefois, ce processus retarde le début de la gestion de la requête suivante, contribuant aux temps d’attente de file d’attente et influençant les latences moyennes et de fin. Selon le modèle de trafic, la latence de fin réelle varie.

Les résultats suivants évaluent l’impact de l’ajout de proxys sidecar au chemin de données, en présentant la latence P90 et P99.

Superposition Azure CNI	Superposition Azure CNI avec Cilium

Mise à l'échelle

Autoscaler de pods horizontaux

La mise à l’échelle automatique des pods horizontaux (HPA) est activée pour les pods de passerelle istiod et d’entrée. Les configurations par défaut pour istiod et les passerelles sont les suivantes :

• Nb min. de réplicas : 2
• Nb max. de réplicas : 5
• Utilisation de l’UC : 80 %

Remarque

Pour éviter des conflits avec le PodDisruptionBudget, le module complémentaire n’autorise pas la définition du paramètre minReplicas en dessous de la valeur par défaut initiale de 2.

Voici les ressources HPA de passerelle d’entrée et istiod :

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

La configuration HPA peut être modifiée au moyen de correctifs et de modifications directes. Exemple :

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

Entrée de service

La définition de ressource personnalisée ServiceEntry d’Istio permet d’ajouter d’autres services dans le registre de service interne d’Istio. Une ServiceEntry permet aux services déjà dans le maillage de diriger vers ou d’accéder aux services spécifiés. Toutefois, la configuration de plusieurs ServiceEntries avec le champ resolution défini sur un DNS peut entraîner une charge importante sur les serveurs DNS (Domain Name System). Les suggestions suivantes peuvent aider à réduire la charge :

• Basculez vers resolution: NONE pour éviter entièrement les recherches DNS proxy. Adapté à la plupart des cas d’usage.
• Augmentez la durée de vie (TTL) si vous contrôlez les domaines résolus.
• Limitez l’étendue ServiceEntry avec exportTo.