1
Architectures de services avancées
Istio
Département TIC
3ème Tél
Mohamed Escheikh 2021/2022
Pourquoi Istio?
plate-forme ouverte permettant de gérer la complexité de la connexion et de la
sécurisation des microservices. Il offre un moyen simple de créer un réseau de services
déployés avec équilibrage de charge, authentification de service à service, surveillance,
etc. sans nécessiter de modification du code de service.
Istio fournit des informations comportementales et un contrôle opérationnel sur le maillage
de service dans son ensemble, offrant une solution complète répondant aux diverses
exigences des applications de microservice.
Certaines fonctionnalités clés sont disponibles de manière uniforme sur un réseau de
services:
Gestion du trafic: contrôle le flux de trafic et les appels d'API entre les services, améliore la fiabilité des
appels et renforce le réseau, ce qui lui permet de faire face aux conditions défavorables.
Observabilité: Comprend les dépendances entre les services, ainsi que la nature et la circulation du trafic
entre eux, pour identifier rapidement les problèmes.
Application des stratégies : applique une stratégie organisationnelle aux interactions entre les services, en
veillant à ce que les stratégies d'accès soient appliquées et que les ressources soient équitablement
réparties entre les utilisateurs. Il vous permet de modifier la stratégie en configurant le maillage au lieu de
modifier le code de l'application.
Identité de service et sécurité: fournit des services dans le maillage avec une identité vérifiable et vous
permet de protéger le trafic de services lorsqu'il circule sur des réseaux avec différents niveaux de fiabilité.
Comment fonctionne Istio?
Un maillage de service Istio comprend un plan de données et un plan de
contrôle.
Le plan de données comprend un ensemble de proxys intelligents (Envoy) de
haute performance, indépendants de la plate-forme, basés sur C ++, de
couche 7. Ils sont déployés en tant que side-cars dans votre environnement
pour assurer la médiation et le contrôle de toutes les communications réseau
entre microservices.
Le plan de contrôle gère et configure les mandataires pour router le trafic,
applique les règles au moment de l'exécution et gère la découverte de
services. Il fournit également une forte authentification de service à service et
d’utilisateur final à l’aide du protocole TLS (Transport Layer Security) mutuel,
avec gestion intégrée des identités et des identifiants.
Architecture Istio
Istio
service mesh Kubernetes
Comment le projet open source Istio de Google surmonte les complexités de la
gestion des réseaux utilisés pour connecter les microservices.?
Si les architectures de micro-services résolvent certains problèmes, elles en ajoutent
aussi de nouveaux. La division des applications en services indépendants simplifie le
développement, les mises à jour et la mise à l'échelle. Mais cela oblige d'un autre côté à
connecter et à sécuriser beaucoup plus de composants mobiles. Au point que la gestion
de tous les services réseau - équilibrage de charge, gestion du trafic, authentification et
autorisation, etc. - peut devenir incroyablement complexe. Cet espace réseau entre les
services d'un cluster Kubernetes porte un nom générique : le maillage de services, ou
services mesh. Le projet Istio de Google apporte une solution pour gérer le maillage de
services du cluster avant de se retrouver avec une pelote inextricable.
Qu'est-ce qu'un service mesh ?
Le service mesh permet de mettre en place un couplage lâche dans une
architecture microservices.
Une architecture micro-service isole les fonctionnalités logicielles en de multiples
services indépendants. Ceci fournit une plate-forme facilement déployable,
maintenable et testable. Une architecture micro-service permet également de créer
des équipes plus petites et plus agiles pour faire avancer une plate-forme : les
feature teams.
Les architectures de micro-services simplifient le déploiement continu de platesformes traitant de sujets complexes. Elles aident les entreprises à être plus réactives
et agiles et à s’adapter à un marché en évolution.
Qu'est-ce qu'un service mesh ?
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 "nordsud" est le trafic clientserveur, 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 microservices.
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
« Un Service Mesh s’apparente à une plateforme de contrôle et de gestion,
sécurisée et performante de l’interconnexion entre tous les (micro) services
d’une application »
Un maillage de services assure la surveillance du trafic, le contrôle d'accès, la
découverte, la sécurité, la résilience et d'autres éléments utiles à un groupe de
services. Istio fait tout cela, mais ne nécessite aucune modification du code de
ces services.
Istio déploie un proxy (appelé sidecar) à côté de chaque service. Tout le trafic
destiné à un service est envoyé au proxy, qui utilise des règles pour décider
comment, quand et si ce trafic doit être acheminé vers le service.
Istio permet également l'utilisation de techniques DevOps sophistiquées telles
que les déploiements de canaris, les disjoncteurs, l'injection de fautes, etc.
Solutions de services mesh
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
Très présent dans la communauté, notamment Kubernetes.
Reçoit le soutien de grands acteurs du domaine, comme RedHat (pour sa solution
OpenShift).
S’appuie sur une référence en terme de sidecar proxy, à savoir Envoy.
Produit déjà orienté et pensé pour la production et l’exploitation, sûrement le plus
abouti actuellement.
Observabilité 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 luimê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:
istio_requests_total{ connection_security_policy="mutual_tls", destination_app="details",
destination_principal="cluster.local/ns/default/sa/default", destination_service="details.default.svc.cluster.local",
destination_service_name="details", destination_service_namespace="default", destination_version="v1",
destination_workload="details-v1", destination_workload_namespace="default", reporter="destination",
request_protocol="http", response_code="200", response_flags="-", source_app="productpage",
source_principal="cluster.local/ns/default/sa/default", source_version="v1", source_workload="productpage-v1",
source_workload_namespace="default" } 214
Observabilité Istio
Métrique
Métriques du plan de contrôle
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
Le traçage distribué fournit un moyen de surveiller et de comprendre le
comportement en surveillant les demandes individuelles au fur et à mesure qu'elles
passent dans un maillage. Les traces permettent aux opérateurs de maillage de
comprendre les dépendances de service et les sources de latence au sein de leur
maillage de service.
Istio prend en charge le traçage distribué via les serveurs proxy Envoy. Les
mandataires génèrent automatiquement des étendues de trace pour le compte des
applications qu'ils proxy, ce qui oblige uniquement les applications à transmettre le
contexte de requête approprié.
Istio prend en charge un certain nombre de moteurs de suivi, notamment Zipkin ,
Jaeger , LightStep et Datadog . Les opérateurs contrôlent le taux d'échantillonnage
pour la génération de traces (c'est-à-dire le taux auquel les données de suivi sont
générées par demande). Cela permet aux opérateurs de contrôler la quantité et le
taux de données de traçage produites pour leur maillage.
Observabilité Istio
Traces distribuées
Trace distribuée pour une requête unique
Vous trouverez plus d'informations sur le traçage distribué avec Istio dans
notre FAQ sur le traçage distribué .
Exemple de trace distribuée générée par Istio pour une requête unique:
Observabilité Istio
Journaux d'accès
Les journaux d'accès offrent un moyen de surveiller et de comprendre le
comportement du point de vue d'une instance de charge de travail individuelle.
Istio peut générer des journaux d’accès pour le trafic de services dans un ensemble
configurable de formats, offrant ainsi aux opérateurs un contrôle total sur la
manière, le type, le moment et le lieu de la journalisation. Istio expose un ensemble
complet de métadonnées source et de destination aux mécanismes de
journalisation des accès, permettant ainsi un audit détaillé des transactions du
réseau.
Les journaux d'accès peuvent être générés localement ou exportés vers des
systèmes personnalisés, y compris Fluentd .
Pour plus d'informations sur la journalisation des accès, reportez-vous
aux tâches Collecte des journaux et Obtention des journaux d'accès de Envoy .
Observabilité Istio
Journaux d'accès
Exemple de journal d’accès Istio (formaté en JSON)
Limitations des Services Mesh
La technologie Service Mesh est une technologie ambitieuse, qui vise à
résoudre tous les problèmes de communication posés par l’architecture
micro-services. Cela ne va pas sans apporter quelques critiques :
Complexité : L’introduction de proxies et autres composants, dans un environnement
déjà sophistiqué, augmente la complexité globale de toute la chaîne de production de
logiciels : du développement au déploiement en passant par la maintenance et le suivi.
Expertise : L’ajout d’un service mesh dans un cluster Kubernetes nécessite que les
développeurs connaissent les deux technologies.
Latence : Le service mesh est un intermédiaire, son utilisation peut entraîner des
latences.
Invasion : Le choix d’un service mesh est très structurant, il a un côté invasif.
Malgré ces limitations, et les freins des équipes DevOps, la technologie
Service Mesh est populaire auprès des développeurs qui sont attirés
par les promesses d’observabilité, de sécurité et de couplage lâche.
Sysdig
approche unifiée de la sécurité des conteneurs, de la surveillance des microservices et de la
criminalistique, avec le support Kubernetes, Prometheus et Falco.
Plate-forme DevOps conçue pour offrir la sécurité pour exécuter des conteneurs et des services
cloud. La plate-forme fonctionne pour sécuriser le pipeline de build, détecte et répond aux menaces
d'exécution, valide la conformité et surveille et dépanne l'infrastructure et les services cloud. La
plate-forme de SysDig est construite sur une pile open source qui comprend Falco et Sysdig OSS, les
normes ouvertes pour la détection et la réponse aux menaces d'exécution.
criminalistique ensemble des techniques de police scientifique destinées à l'identification
de l'auteur d'un crime? La science capable d'interpréter, de guider et d'identifier les cyberenquêtes est la criminalistique informatique qui, grâce à des techniques, des stratégies et des
outils, permettra de connaître avec certitude les indices, les auteurs, les modus operandi et les
instruments des crimes informatiques.
SolarWinds, Google Stackdriver et Falco
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
Observabilité de vos ressources et applications AWS sur AWS et sur site
Amazon CloudWatch est un service de surveillance et d'observabilité conçu pour les
ingénieurs DevOps, les développeurs, les ingénieurs en fiabilité de sites (SRE) et les
responsables informatiques. CloudWatch vous fournit des données et informations
exploitables dont vous avez besoin pour surveiller vos applications, réagir aux variations
de performance sur l’ensemble du système, optimiser l’utilisation des ressources et
avoir une appréciation unifiée de la santé opérationnelle. CloudWatch collecte les
données opérationnelles et de surveillance sous forme de journaux, de métriques et
d’événements pour vous permettre d’avoir une appréciation unifiée des ressources,
des applications et des services AWS exécutés sur AWS et sur des serveurs sur site.
Vous pouvez utiliser CloudWatch pour déceler des comportements anormaux dans vos
environnements, définir des alarmes, visualiser les journaux et les métriques côte à
côte, agir automatiquement, faire des dépannages et trouver les informations utiles au
bon fonctionnement de vos applications.