Académique Documents
Professionnel Documents
Culture Documents
Istio
Département TIC
3ème Tél Mohamed Escheikh 2021/2022
Pourquoi Istio?
Les services de ces architectures communiquent entre eux via des API. Et la gestion
de cette communication peut rapidement devenir complexe.
L’objectif d’un outil de service mesh est de simplifier cette communication. Il permet
également la découverte de services, l’équilibrage de charge, le chiffrement,
l’authentification et l’autorisation.
Le service mesh permet également de mettre en place un couplage lâche entre les
services. Cela permet de déplacer un microservice d’un nœud ou d’un cluster à un
autre sans avoir à reconfigurer l’application ou à modifier le code.
Le modèle architectural des services mesh est conçu pour fournir des services
d’application avec trois capacités de base : la gestion du trafic, la sécurité et
l’observabilité.
Qu'est-ce qu'un service mesh ?
Il est préférable de disposer d'un système séparé entre les services et le réseau avec lequel
ces services communiquent.
Un tel système assure deux fonctions essentielles :
d'abord, il évite aux services eux-mêmes d'avoir à faire face à la complexité de la
gestion de l'équilibrage du trafic sur le réseau, du routage, des tentatives multiples,
etc. ;
ensuite, il fournit une couche d'abstraction aux administrateurs, ce qui facilite la prise
de décisions de haut niveau sur le trafic réseau dans le cluster - les politiques de
contrôle, les métriques et les logs, la découverte de services, les communications
sécurisées inter-services via TLS, etc.
Trafics Nord/Sud et Est/Ouest
Nord-sud et est-ouest sont deux termes généraux utilisés pour décrire la direction du flux
de circulation du trafic. Dans le cas de la circulation nord-sud, le trafic entre et sort du
cluster.
Contrairement au trafic nord-sud, qui entre et sort du cluster, le trafic est-ouest circule
entre les nœuds du cluster.
Un service mesh doit être capable de gérer les deux types de trafic.
Il convient de noter qu’historiquement, le trafic Nord/Sud était très sécurisé, alors que la
sécurité du trafic Est/Ouest était souvent négligée. Un service mesh améliorera
grandement ce point car les deux types de trafic seront traités de manière équivalente.
De manière générale,
le trafic "est-ouest"
désigne le trafic au sein
d'un centre de données,
c'est-à-dire le trafic de
serveur à serveur.
Le trafic "nord-
sud" est le trafic client-
serveur, entre le centre de
données et le reste du
réseau (tout ce qui se
trouve en dehors du
centre de données
Istio
Istio
Composants du service mesh Istio
Control Plane/Data plane
Istio souhaite former une tour de contrôle pour développer et contrôler des architectures de micro-
services.
Istio fonctionne comme un maillage de services en fournissant deux éléments d'architecture de base
pour le cluster, à savoir : un plan de données et un plan de contrôle.
Le plan de contrôle, regroupant toutes les briques core : configuration, policies, authentification, expositions
des métriques, etc. Coeur d'Istio, IL gère et sécurise le plan de données. Il configure à la fois les proxies Envoy
et les Mixers qui appliquent les politiques réseau pour les services, pour définir par exemple, qui peut
communiquer avec qui et à quel moment. Le plan de contrôle fournit également une couche d'abstraction
programmatique pour le plan de données et tous ses comportements.
Le plan de données , maillage de proxys, qui pourront être présents :
au niveau d’un nœud ; on parle alors de Shared host proxy, déployé par un DaemonSet.
au niveau de chaque pod ; on parle alors de sidecar proxy, déployé par injection auprès
d’un conteneur existant.
gère le trafic réseau entre les services du maillage. Tout ce trafic est intercepté et redirigé par
un système de proxy réseau. En ce qui concerne Istio, le proxy est fourni par un projet open
source appelé Envoy. Un deuxième composant du plan de données, Mixer, rassemble les
données télémétriques et statistiques d'Envoy et le flux du trafic entre services.
Istio
Composants du service mesh Istio
Control Plane/Data plane
Control Plane :
Mixer : prend en charge les contrôles d’accès aux services, les politiques en matière
d’usage ainsi que la collecte des métriques depuis les proxies Envoy.
Pilot : fonctionne de pair avec Envoy pour le contrôle et le routage intelligent (a/b testing,
canary deployment etc.) et résiliant (timeouts, tentatives d’essais etc.) du trafic entre
services, et propose des fonctions de découvertes de services pour Envoy. Il prend les
règles de comportement du trafic fournies par le plan de contrôle et les convertit en
configurations appliquées par Envoy en tenant compte du mode de gestion local. Pilot
permet à Istio de travailler avec d'autres systèmes d'orchestration que Kubernetes, à
condition qu'ils se comportent de manière cohérente entre eux.
Citadel : gère l’authentification inter-services et utilisateur finaux et assure la gestion des
identités pour sécuriser la communication de services à services.
Galley : sorte de meta composant, il s’occupe de la gestion de configuration de tous les
composants d’Istio et notamment la relation avec l’infrastructure sur laquelle il tourne.
prend les configurations spécifiées par l'utilisateur pour Istio et les convertit en
configurations valides pour les autres composants du plan de contrôle. C'est un autre
élément qui permet à Istio d'utiliser différents systèmes d'orchestration de manière
transparente.
Istio
Composants du service mesh Istio
Control Plane/Data plane
Data Plane :
Envoy : proxy, déployé comme sidecar, va permettre de gérer tout le trafic par le
service concerné. Il apporte de nombreuses fonctionnalités (load balancing, TLS,
health checks etc.).
Ceci représente la BASE d’Istio. Nous allons voir que suivant le type d’installation et de
briques ajoutées, d’autres composants peuvent être présents (pour rappel, nous ferons
le focus sur la stack demo).
Istio
Composants du service mesh Istio
Control Plane/Data plane
Envoy et Mixer fonctionnent la main dans la main lorsqu’une requête est envoyée.
Envoy contacte Mixer avant chaque requête pour vérifier si les conditions
d’exécution sont adéquates et après chaque requête pour lui expédier des données
de mesure télémétrique. Le proxy sidecar dispose d’un cache en local de façon à ce
qu’un grand nombre de vérifications post-traitement puisse être effectué à partir du
cache. De plus, le sidecar bufferise les données de mesure afin de limiter les appels
à Mixer – ou les effectue moins fréquemment.
Mixer s’adosse quant à lui à une conception modulaire qui favorise la création de
plug-in (adapters) avec lesquels des éditeurs d’outils de monitoring peuvent se
raccorder. Datadog a par exemple développé son propre plug-in. Mixer s’interface
également aux outils de Sysdig, SolarWinds, ainsi qu’à Google Stackdriver et
Amazon CloudWatch.
Istio a également été conçu pour être déployé sur une architecture existante ou
pour faciliter les déploiements d’architectures de microservices. Mais en créant une
couche d’abstraction en matière de gestion de l’infrastructure, il permet également
de faciliter la mise en place de processus DevOps.
Istio
Composants du service mesh Istio
Control Plane/Data plane1
Istio
Composants du service mesh Istio
Control Plane/Data plane
Ensemble, ces deux éléments vont permettre une administration des services réseau
plus efficace, proposer de nouvelles fonctionnalités et notamment améliorer :
L’équilibrage de charge du trafic réseau de haut niveau (L7) HTTP, mais aussi TCP ou
encore WebSocket
Les ACLs : white/blacklisting, accès à l’API, quotas
La collecte de traces réseau, métriques et logs
Le service-discovery
La sécurité inter-services (support TLS)
Capacités du service mesh Istio
L'abstraction est le premier et le plus précieux des avantages d'Istio, car elle permet de
traiter les complexités d'un maillage de services sans lien de dépendance.
Il est possible d'apporter n'importe quelle modification au maillage par programmation
en commandant Istio.
Les services connectés au maillage n'ont pas besoin d'être reprogrammés de l'intérieur
pour répondre à de nouvelles politiques ou quotas de réseau, et les espaces réseau
entre eux n'ont pas besoin d'être modifiés directement.
De plus, Istio permet d'apporter des modifications non destructives ou provisoires à la
configuration réseau du cluster.
Introduction au maillage de service Istio
Plusieurs solutions existent actuellement pour mettre en œuvre votre Service Mesh. Il s’agira
de choisir en fonction de vos besoins, de votre appétence ou de votre écosystème.
Les leaders:
Istio Issu de la collaboration entre Google, IBM et Lyft. Il s’appuie sur le proxy Envoy.
La plupart des acteurs évoluant autour de Kubernetes travaillent au développement
de solutions basées sur Istio
Linkerd (à prononcer Linker-dee) Premier Service Mesh à avoir vu le jour en 2016, mis
au point par des ingénieurs de Twitter. Ils l’ont développé pour faciliter la résolution
des problématiques d’échelle sur les infrastructures de très grandes tailles.
SuperGloo Très orienté haut niveau, c’est LA solution montante d’orchestration de
services réseau de Solo.io. Il est devenu très populaire ces derniers mois. SuperGloo
offre un Service Mesh beaucoup plus simple et automatisé que ses homologues. Il
prend en charge le trafic ingress (nord-sud) et mesh (est-ouest). Les utilisateurs
peuvent choisir n’importe quelle association ingress/mesh, SuperGloo s’occupe de
tout et gère le fonctionnement de toutes les paires automatiquement.
Les outsiders
Consul
HashiCorp pense que le principe du load-balancing n’est pas optimum : augmentation
des coûts, SPOF, latence. L’idée est donc de miser sur une registry qui va rassembler
toutes les informations sur les différents nœuds, services et composants de la
plateforme. On parle alors de Service Discovery. Depuis sa version 1.2, Consul
propose Connect, son propre Data Plane et sidecar proxy. Cependant, certaines
fonctions (route L7, gateway) sont encore en version Beta. Pour cela, Connect propose
une intégration avec Envoy (et d’autres proxys) afin de palier aux manques (et en
attendant le plein développement de cette solution).
NGINX
On ne présente plus l’entreprise ni le serveur web du même nom. Mais le
développement de son propre Service Mesh est en cours, basé sur… Istio.
Envoy
Le « sidecar proxy », utilisé notamment par la solution Istio, vise à développer son
propre Service Mesh. À suivre de très près.
Istio
Istio reprend en fait plusieurs projets mis en commun par les trois membres fondateurs.
IBM y a contribué avec Amalgam8, un outil de gestion du routage de trafic programmable
qui permet par exemple de tester la résilience des services.
De son côté, Google a apporté sa technologie Service Control qui ajoute un système de
gestion par règles (policies) en matière de sécurité ainsi qu’un système de télémétrie
Mais la pierre angulaire d’Istio a été apportée par Lyft. En contribuant à Envoy, un proxy
maison, la société a fixé une orientation architecturale qui distingue Istio d’autres outils de
Service Mesh, comme par exemple Linkerd, hébergé à la Cloud Native Computing
Foundation (CNCF).
Envoy (également un projet de la CNCF) est en fait un projet open source de proxy,
suffisamment léger pour permettre des déploiements dits « sidecar ». Lorsqu’on déploie
Istio sur une architecture en place, il loge des proxies Envoy, au côté de chaque service
présent au sein d’un pod Kubernetes par exemple. A l’origine, Istio a en effet été développé
pour favoriser l’interconnexion et la gestion des services dans l’orchestrateur
de conteneurs.
Istio
Avec un tel dispositif, chaque service qui doit se connecter à un autre service entre
en contact avec le proxy de ce dernier, précédemment configuré à partir de règles de
routage spécifiques. La base d’Istio est que ce sont les proxies qui interagissent,
facilitant le contrôle et le monitoring du trafic et la collecte de données précises sur
l’état de santé de chaque service.
Istio
Istio génère une télémétrie détaillée pour toutes les communications de service dans un
maillage. Cette télémétrie permet d'observer le comportement du service, permettant ainsi aux
opérateurs de dépanner, de maintenir et d'optimiser leurs applications, sans imposer de charge
supplémentaire aux développeurs de services. Grâce à Istio, les opérateurs acquièrent une
connaissance approfondie de la manière dont les services surveillés interagissent, à la fois avec
d'autres services et avec les composants Istio eux-mêmes.
Istio génère les types de télémétrie suivants afin de fournir une observabilité globale du maillage de
service:
Métriques . Istio génère un ensemble de métriques de service basées sur les quatre «signaux en or»
de la surveillance (latence, trafic, erreurs et saturation). Istio fournit également des métriques
détaillées pour le plan de contrôle du maillage . Un ensemble par défaut de tableaux de bord de
surveillance maillé construits au-dessus de ces métriques est également fourni.
Traces distribuées . Istio génère des plages de trace distribuées pour chaque service, offrant aux
opérateurs une compréhension détaillée des flux d'appels et des dépendances de service au sein d'un
maillage.
Journaux d'accès (access logs) . Lorsque le trafic entre dans un service contenu dans un maillage,
Istio peut générer un enregistrement complet de chaque demande, y compris les métadonnées de
source et de destination. Ces informations permettent aux opérateurs d’auditer le comportement du
service jusqu’au niveau de l’ instance de charge de travail individuelle .
Observabilité Istio
Métrique
Les mesures permettent de surveiller et de comprendre le comportement de
manière globale.
Pour surveiller le comportement du service, Istio génère des métriques pour
tout le trafic de service entrant et sortant et au sein d'un maillage de service
Istio. Ces métriques fournissent des informations sur des comportements tels
que le volume global du trafic, les taux d'erreur au sein du trafic et les temps
de réponse des demandes.
En plus de surveiller le comportement des services au sein d'un maillage, il
est également important de surveiller le comportement du maillage lui-
même. Les composants Istio exportent des métriques sur leurs propres
comportements internes afin de fournir des informations sur la santé et la
fonction du plan de contrôle du maillage.
La collecte de métriques Istio est déterminée par la configuration de
l'opérateur. Les opérateurs sélectionnent comment et quand collecter les
métriques, ainsi que le niveau de détail des métriques elles-mêmes. Cela
permet aux opérateurs d’ajuster de manière flexible la collecte de mesures en
fonction de leurs besoins.
Observabilité Istio
Métrique
Métriques au niveau du proxy
La collecte de mesures Istio commence par les mandataires Sidecar (Envoy). Chaque proxy génère un
riche ensemble de métriques sur tout le trafic transitant par le proxy (entrant et sortant). Les
mandataires fournissent également des statistiques détaillées sur les fonctions administratives du
mandataire lui-même, y compris les informations de configuration et de santé.
Les métriques générées par Envoy permettent de surveiller le maillage en fonction de la granularité
des ressources Envoy (telles que les écouteurs et les clusters). Par conséquent, il est nécessaire de
comprendre la connexion entre les services de maillage et les ressources Envoy pour surveiller les
métriques Envoy.
Istio permet aux opérateurs de sélectionner les métriques Envoy générées et collectées à chaque
instance de charge de travail. Par défaut, Istio n'active qu'un petit sous-ensemble des statistiques
générées par Envoy pour éviter de surcharger les systèmes de métriques et réduire la surcharge de
temps du processeur associée à la collecte de métriques. Toutefois, les opérateurs peuvent facilement
développer l’ensemble de métriques proxy collectées, le cas échéant. Cela permet un débogage ciblé
du comportement du réseau, tout en réduisant le coût global de la surveillance sur le maillage.
Le site de documentation Envoy comprend un aperçu détaillé de la collecte de statistiques Envoy . Le
guide des opérations sur Envoy Statistics fournit des informations supplémentaires sur le contrôle de la
génération de métriques de niveau proxy.
Observabilité Istio
Métrique
Mesures de niveau de service
Outre les métriques de niveau proxy, Istio fournit un ensemble de métriques axées sur le
service permettant de surveiller les communications de service. Ces métriques couvrent
les quatre besoins de surveillance de service de base: latence, trafic, erreurs et
saturation. Istio est livré avec un ensemble de tableaux de bord par défaut permettant de
surveiller les comportements de service en fonction de ces métriques.
Les métriques Istio par défaut sont définies par un ensemble d'artefacts de configuration
fournis avec Istio et sont exportées vers Prometheus par défaut. Les opérateurs sont libres
de modifier la forme et le contenu de ces métriques, ainsi que de modifier leur mécanisme
de collecte, afin de répondre à leurs besoins de surveillance individuels.
La tâche Collecting Metrics fournit des informations supplémentaires sur la
personnalisation de la génération de métriques Istio.
L'utilisation des métriques de niveau de service est entièrement facultative. Les opérateurs
peuvent choisir de désactiver la génération et la collecte de ces métriques pour répondre à
leurs besoins individuels.
Observabilité Istio
Métrique
Exemple de métrique de niveau de service:
Chaque composant Istio (Pilot, Galley, Mixer) fournit également une collection de
métriques d’autosurveillance. Ces métriques permettent de surveiller le
comportement d'Istio lui-même (par opposition à celui des services dans le maillage).
Pour plus d'informations sur les métriques conservées, reportez-vous à la
documentation de référence de chacun des composants:
Pilote
Galère
Mixer
Citadelle
Observabilité Istio
Traces distribuées
SolarWinds est une société américaine qui développe des logiciels professionnels
permettant la gestion centralisée des réseaux, des systèmes et de l'infrastructure
informatique.
Google Stackdriver fournit une surveillance, une journalisation et des diagnostics
puissants. Il vous donne un aperçu de la santé, des performances et de la disponibilité
des applications basées sur le cloud, vous permettant de trouver et de résoudre les
problèmes plus rapidement. Les agents et bibliothèques Stackdriver sont des projets
open source.
Falco , le projet de sécurité d'exécution natif du cloud, est de facto le moteur de
détection des menaces Kubernetes. Falco est le premier projet de sécurité d'exécution
à rejoindre la CNCF en tant que projet de niveau d'incubation. Falco agit comme une
caméra de sécurité détectant les comportements inattendus, les intrusions et le vol de
données en temps réel.
Amazon CloudWatch