Ce qu’il faut prendre en compte avant d’installer ISTIO en Production

Un service mesh offre la possibilité de connecter, manager et sécuriser des microservices. Lorsqu’il s’agit  d’un fonctionnement en production, il faut s’assurer que le service mesh soit suffisamment performant afin qu’il ne rajoute pas trop de latence aux communications entre microservices et qu’il puisse supporter une charge assez importante. Plusieurs entreprises ont eu des problèmes en production parce qu’elles n’ont pas pris en compte les pré-requis.

Istio vient avec des  profils préconfigurés pour  une installation facile et rapide. Pour une mise en place en production, il permet de personnaliser l’installation pour s’adapter à l’environnement et répondre à  plusieurs problématiques telles que:

  • La performance du control plane et les ressources CPU et RAM consommées
  • La montée en charge
  • La résilience des composants du mesh
  • La sécurité de l’infrastructure  et des communications entre les services 
  • Le monitoring et tracing des différents composants et des communications entre microservices. 

Ces problématiques sont très complexes et varient selon les besoins et les environnements. Dans cet article, nous allons voir comment Istio permet de répondre à ces problématiques.

Performance et Scaling

Istio facilite la création d’un réseau de services avec le routage, le load balancing, l’authentification inter-services, le monitoring etc… Le tout  sans changer le code applicatif. Il fournit tous ces bénéfices tout en minimisant la consommation de ressources et la latence ajoutée aux traitements. 

Les Envoy proxies gèrent tous les flux qui transitent sur le système. Tandis que le control plane s’assure de configurer  le data plane.  

Ces composants ont des caractéristiques distinctes en terme de performance.

Control plane 

Pilot est le composant Istio qui configure les sidecars proxies selon la configuration fournie par l’utilisateur et l’état  du système. Dans un environnement Kubernetes, les Custom Resource Definitions (CRDs) et deployments constituent la configuration et l’état du système. Pilot va traiter les objets Istio tels que les gateways et les virtual services créés par l’utilisateur, et va produire la configuration à envoyer aux envoy proxies.

Le control plane supporte des milliers de services. La consommation en terme de CPU et mémoire de Pilot augmente avec le nombre de configurations et le nombre de proxies à gérer ainsi que l’état du système. 

En quelques chiffres:

Avec l’isolation des namespaces activée, une instance Pilot peut supporter 1000 services, 2000 sidecars avec 1 vCPU et 1.5 GB de mémoire. 

Il est possible de répartir cette charge en augmentant le nombre d’instances  Pilot.

Data plane 

Les performances du Data plane dépendent de plusieurs facteurs, par exemple:

  • Le nombre de connexions clientes 
  • le taux de requêtes
  • La taille des requêtes et des réponses
  • Le nombre de threads
  • Le protocole
  • La CPU etc….

La  latence, le débit et la consommation CPU  et RAM dépendent de tous ces facteurs.

La latence est un facteur important parce  que Istio rajoute un sidecar qui intercepte le flux allant vers les applications. Ce qui rajoute une étape supplémentaire au traitement des requêtes et  par conséquent de la latence. Istio rajoute aussi de l’authentification et des filtres mixer au proxy. Et chaque filtre affecte la latence.

L’Envoy proxy collecte des données de télémétrie après qu’une réponse soit envoyée au client. Ce temps de collecte n’est pas compris dans le traitement de la requête mais affecte le début de traitement de la requête suivante.

Dans un mesh, une requête traverse deux proxies,  celui du service source et celui du service destination.  Chaque proxy rajoute une petite latence.

Cas de la version 1.4.5 d’Istio:

Un test de performance réalisé sur un mesh de 1000 services avec 2000 sidecars et 70,000 requêtes par secondes a donné les résultats suivants:

  • Les Envoy proxies utilisent 0.5 vCPU et 50 MB de mémoire pour 1000 requêtes par seconde qui transitent.
  • Istio-telemetry utilise 0.6 vCPU pour 1000 requêtes par seconde au niveau du mesh.
  • Pilot utilise 1 vCPU et 1.5 GB de mémoire.
  • Les Envoy proxies ajoutent autour de 6-7 ms de latence.

Scaling

Les principaux composants du control plane d’Istio sont configurés pour scaler horizontalement en fonction de la charge à l’aide d’un objet kubernetes appelé HPA horizontal pod autoscaling.

Pour un déploiement en production des composants  Istio sur kubernetes, nous allons donc nous assurer d’allouer des ressources suffisantes et de configurer un autoscaling pour répondre à la charge. Le tableau suivant représente un exemple de configuration des ressources attribuées aux composants du control plane d’Istio avec ou sans autoscaling:

 

 

Sécurité

Istio permet de répondre aux problématiques de sécurité à travers le chiffrement des communications entre les microservices, l’authentification mutuelle TLS ainsi que les access policies. Tout ceci est fait via son  composant citadel qui gère les clés et certificats.

https://istio.io/docs/concepts/security/architecture.svg

Istio fournit aussi un node agent qui peut gérer les certificats au niveau du noeud sur lequel tournent les microservices.

Il est possible d’activer ces fonctionnalités à l’installation ou plus tard.

Pour une installation en prod, nous allons nous assurer d’activer le tls, la sécurité du control plane et le node agent Istio.

PSP et Istio cni

Istio injecte un init Container, appelé istio-init, dans les pods déployés dans le mesh. C’est grâce à  ce conteneur que Istio va configurer la redirection du trafic du pod vers le sidecar proxy. Cette action nécessite que  le user ou le service account du pod ait les permissions RBAC nécessaires dans Kubernetes pour déployer des conteneurs NET_ADMIN. 

Pour une installation en prod, il faut soit:

  • Créer une PSP qui permettra aux conteneurs d’istio de s’exécuter en  NET_ADMIN.
  • Utiliser le CNI plugin d’Istio qui évite de donner le droit NET_ADMIN

Le CNI plugin d’Istio évite d’utiliser un init container avec les droits NET_ADMIN et du coup  est une alternative qui évite de donner des droits élevés aux utilisateurs. Il permet ainsi de mieux répondre aux exigences de sécurité pour un cluster kubernetes.  

Monitoring and tracing

Grafana et Prometheus

Istio permet d’installer un Grafana préconfiguré avec des dashboards pour le monitoring du mesh. Grafana étant un outil indépendant et ne faisant pas parti de composants principaux d’Istio, l’installation  via la configuration d’Istio est assez limitée et n’offre pas la flexibilité nécessaire. Pour une installation en production, il est préférable de l’installer indépendamment via les outils adaptés.

Istio permet l’intégration avec  un Grafana externe, et fournit des dashboards qu’on peut intégrer facilement.

Istio permet aussi l’installation d’un Prometheus préconfiguré. Mais pour avoir plus de flexibilité il est mieux d’installer un prometheus  et l’intégrer à Istio. Pour des informations sur la mise en place d’un prometheus et d’un grafana sur un environnement Kubernetes en production: https://github.com/coreos/kube-prometheus

Kiali

Kiali est un add-on d’Istio qui permet de visualiser le mesh et d’avoir le graphe des services du mesh ainsi que les objets de  configuration d’Istio. Il possède une API pour générer des graphes au format json.

Istio permet de l’installer directement avec ses autres composants. Pour  une installation en production on peut se contenter de l’installation fournie par  Istio.

Tracing 

Istio permet aussi d’installer une solution de tracing comme  Jaeger en mode All-In-One. Mais pour un fonctionnement en production il est nécessaire d’installer ce composant séparément et l’intégrer à Istio. 

Le lien suivant contient des informations pour une  mise en place de Jaeger en production: https://www.jaegertracing.io/docs/1.17/operator/

 

Conclusion

Cet article fait état d’un ensemble de points importants à considérer lorsqu’on veut  mettre en place Istio en production. Il est important de mentionner que les exigences en terme de production varient selon les entreprises et du coup les points traités dans cet article ne sont pas exhaustifs. Mais ils constituent une bonne base d’éléments important pour un environnement de production Kubernetes. Nous verrons plus tard, plus en détails comment configurer Istio  dans une installation pour prendre en compte ces points.

 

 


 

Cissé ABDELHAFIZ
Cissé ABDELHAFIZIngénieur Cloud DevOps