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 contrôle

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 de désabonnement testés ont été déterminés à partir du taux de désabonnement classique pendant le 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

Superposition Azure CNI avec Cilium

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é du side-car

Processeur et mémoire

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 QPS (requêtes par seconde) à des connexions client variées
• 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.

• Chemin du trafic sidecar : client --> client-sidecar --> server-sidecar --> serveur
• Chemin du trafic de référence : client -->serveur

Vous trouverez une comparaison des performances de latence du plan de données entre les versions du module complémentaire Istio et AKS ici.

Superposition Azure CNI	Superposition Azure CNI avec Cilium

Mise à l'échelle

Personnalisation de la mise à l’échelle automatique horizontale des pods

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

• Nombre minimum de réplicas : 2
• Nombre maximum de répliques : 5
• Utilisation de l’UC : 80 %

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. Toutefois, lors de l’utilisation d’une passerelle de sortie de module complémentaire Istio, la résolution ServiceEntry doit être définie sur DNS.
• Augmentez la durée de vie (TTL) si vous contrôlez les domaines résolus.
• Limitez l’étendue ServiceEntry avec exportTo.