1.16. Performance et évolutivité
Les paramètres par défaut de ServiceMeshControlPlane ne sont pas destinés à une utilisation en production ; ils sont conçus pour une installation réussie sur une installation par défaut d'OpenShift Container Platform, qui est un environnement aux ressources limitées. Après avoir vérifié que l'installation du SMCP a réussi, vous devez modifier les paramètres définis dans le SMCP pour les adapter à votre environnement.
1.16.1. Limiter les ressources informatiques
Par défaut, spec.proxy a les paramètres cpu: 10m et memory: 128M. Si vous utilisez Pilot, spec.runtime.components.pilot a les mêmes valeurs par défaut.
Les paramètres de l'exemple suivant sont basés sur 1 000 services et 1 000 requêtes par seconde. Vous pouvez modifier les valeurs de cpu et memory dans la page ServiceMeshControlPlane.
Procédure
-
Dans la console web d'OpenShift Container Platform, cliquez sur Operators
Installed Operators. - Cliquez sur le menu Project et sélectionnez le projet dans lequel vous avez installé le plan de contrôle Service Mesh, par exemple istio-system.
-
Cliquez sur l'opérateur Red Hat OpenShift Service Mesh. Dans la colonne Istio Service Mesh Control Plane, cliquez sur le nom de votre
ServiceMeshControlPlane, par exemplebasic. Ajoutez le nom de votre instance Jaeger autonome à l'adresse
ServiceMeshControlPlane.- Cliquez sur l'onglet YAML.
Définissez les valeurs pour
spec.proxy.runtime.container.resources.requests.cpuetspec.proxy.runtime.container.resources.requests.memorydans votre ressourceServiceMeshControlPlane.Exemple version 2.3 ServiceMeshControlPlane
apiVersion: maistra.io/v2 kind: ServiceMeshControlPlane metadata: name: basic namespace: istio-system spec: version: v2.3 proxy: runtime: container: resources: requests: cpu: 600m memory: 50Mi limits: {} runtime: components: pilot: container: resources: requests: cpu: 1000m memory: 1.6Gi limits: {}- Cliquez sur Save.
-
Cliquez sur Reload pour vérifier que la ressource
ServiceMeshControlPlanea été configurée correctement.
1.16.2. Résultats de l'essai de charge
Le maillage des tests de charge de la communauté Istio en amont se compose de 1000 services et de 2000 sidecars avec 70 000 requêtes par seconde à l'échelle du maillage. L'exécution des tests avec Istio 1.12.3 a généré les résultats suivants :
- Le proxy Envoy utilise 0.35 vCPU et 40 MB memory pour 1000 requêtes par seconde passant par le proxy.
- Istiod utilise 1 vCPU et 1.5 GB de mémoire.
- Le proxy Envoy ajoute 2.65 ms à la latence du 90e percentile.
-
L'ancien service
istio-telemetry(désactivé par défaut dans Service Mesh 2.0) utilise 0.6 vCPU pour 1000 requêtes par seconde à l'échelle de la maille pour les déploiements qui utilisent Mixer. Les composants du plan de données, les proxys Envoy, gèrent les données qui circulent dans le système. Le composant du plan de contrôle du Service Mesh, Istiod, configure le plan de données. Le plan de données et le plan de contrôle ont des préoccupations distinctes en matière de performances.
1.16.2.1. Service Mesh Performance du plan de contrôle
Istiod configure les proxies sidecar en fonction des fichiers de configuration rédigés par l'utilisateur et de l'état actuel du système. Dans un environnement Kubernetes, les définitions de ressources personnalisées (CRD) et les déploiements constituent la configuration et l'état du système. Les objets de configuration Istio, tels que les passerelles et les services virtuels, fournissent la configuration créée par l'utilisateur. Pour produire la configuration des proxies, Istiod traite la configuration et l'état du système combinés de l'environnement Kubernetes et de la configuration créée par l'utilisateur.
Le plan de contrôle du Service Mesh prend en charge des milliers de services, répartis sur des milliers de pods avec un nombre similaire de services virtuels créés par l'utilisateur et d'autres objets de configuration. Les besoins en CPU et en mémoire d'Istiod augmentent avec le nombre de configurations et d'états possibles du système. La consommation de CPU varie en fonction des facteurs suivants :
- Le taux de déploiement change.
- Le taux de changement de configuration.
- Le nombre de proxies se connectant à Istiod.
Toutefois, cette partie est intrinsèquement évolutive sur le plan horizontal.
1.16.2.2. Performance du plan de données
Les performances du plan de données dépendent de nombreux facteurs, par exemple :
- Nombre de connexions de clients
- Taux de demande cible
- Taille de la demande et taille de la réponse
- Nombre de threads de l'agent proxy
- Protocol
- Cœurs de l'unité centrale
- Nombre et types de filtres proxy, en particulier les filtres liés à la télémétrie v2.
La latence, le débit et la consommation de CPU et de mémoire des proxys sont mesurés en fonction de ces facteurs.
1.16.2.2.1. Consommation de l'unité centrale et de la mémoire
Comme le proxy sidecar effectue un travail supplémentaire sur le chemin des données, il consomme de l'unité centrale et de la mémoire. Depuis Istio 1.12.3, un proxy consomme environ 0,5 vCPU pour 1000 requêtes par seconde.
La consommation de mémoire du proxy dépend de l'ensemble de l'état de configuration qu'il contient. Un grand nombre d'auditeurs, de clusters et d'itinéraires peut augmenter la consommation de mémoire.
Étant donné que le proxy ne met normalement pas en mémoire tampon les données qui transitent, le taux de requêtes n'a pas d'incidence sur la consommation de mémoire.
1.16.2.2.2. Temps de latence supplémentaire
Étant donné qu'Istio injecte un proxy sidecar sur le chemin des données, la latence est une considération importante. Istio ajoute un filtre d'authentification, un filtre de télémétrie et un filtre d'échange de métadonnées au proxy. Chaque filtre supplémentaire augmente la longueur du chemin à l'intérieur du proxy et affecte la latence.
Le proxy Envoy collecte des données télémétriques brutes après l'envoi d'une réponse au client. Le temps passé à collecter les données télémétriques brutes pour une demande ne contribue pas au temps total nécessaire pour traiter cette demande. Cependant, comme le travailleur est occupé à traiter la demande, il ne commencera pas à traiter la demande suivante immédiatement. Ce processus ajoute au temps d'attente dans la file d'attente de la demande suivante et affecte les temps de latence moyens et de queue. La latence de queue réelle dépend du modèle de trafic.
À l'intérieur du maillage, une requête traverse le proxy côté client, puis le proxy côté serveur. Dans la configuration par défaut d'Istio 1.12.3 (c'est-à-dire Istio avec télémétrie v2), les deux proxys ajoutent environ 1,7 ms et 2,7 ms à la latence du 90e et du 99e percentile, respectivement, par rapport à la latence de base du plan de données.
