Nous commençons une série de publications dans lesquelles nous présenterons certaines des nombreuses fonctionnalités du maillage de service Istio Service Mesh en combinaison avec Red Hat OpenShift et Kubernetes.
Première partie, aujourd'hui:
- Expliquons le concept de conteneurs Kubernetes sidecar et formulons le leitmotiv de cette série de messages: "vous n'avez rien à changer dans votre code" .
- Imaginez la chose de base Istio - les règles de routage. Ils construisent toutes les autres fonctionnalités d'Istio, car ce sont les règles qui vous permettent de diriger le trafic vers les microservices, en utilisant pour cela des fichiers YAML externes au code de service. Nous considérons également le schéma de déploiement pour le déploiement des Canaries. Bonus du Nouvel An - 10 leçons interactives Istio
La deuxième partie vous dira:
- Comment Istio implémente l'éjection de pool conjointement avec le disjoncteur et montre comment Istio supprime un module cassé ou fonctionnant mal du schéma d'équilibrage.
- Nous aborderons également le sujet Disjoncteur du premier article sur la façon dont Istio peut être utilisé ici. Nous montrons comment acheminer le trafic et gérer les erreurs réseau à l'aide des fichiers de configuration YAML et des commandes de terminal sans la moindre modification du code de service.
Troisième partie :
- Une histoire sur le traçage et la surveillance qui sont déjà intégrés ou facilement ajoutés à Istio. Nous allons vous montrer comment utiliser des outils tels que Prometheus, Jaeger et Grafana en combinaison avec la mise à l'échelle OpenShift pour gérer facilement votre architecture de microservices.
- Nous passons de la surveillance et du traitement des erreurs à leur introduction intentionnelle dans le système. En d'autres termes, nous apprenons à faire l'injection de défauts sans changer le code source, ce qui est très important du point de vue des tests - car si vous changez le code lui-même pour cela, il y a un risque d'introduire des erreurs supplémentaires.
Enfin,
dans le dernier message sur l'Istio Service Mesh:
- Passons au côté obscur. Plus précisément, nous apprendrons à utiliser le schéma Dark Launch lorsque le code est déployé et testé directement sur les données de production, mais n'affecte pas le fonctionnement du système. C’est là que la capacité d’Istio à partager le trafic est utile. Et la possibilité d'effectuer des tests sur des données de production en direct sans affecter les performances du système de combat est le moyen le plus convaincant de le vérifier.
- À partir de Dark Launch, nous montrerons comment utiliser le modèle Canary Deployment pour réduire les risques et simplifier la mise en service d'un nouveau code. Canary Deployment lui-même est loin d'être une nouveauté, mais Istio vous permet de mettre en œuvre ce schéma avec de simples fichiers YAML.
- En conclusion, nous allons montrer comment utiliser Istio Egress pour donner accès aux services à ceux qui ne font pas partie de vos clusters afin d'utiliser les capacités d'Istio lorsque vous travaillez avec Internet.
Alors, ça a commencé ...
Outils de surveillance et de contrôle Istio - tout ce dont vous avez besoin pour coordonner les microservices dans le maillage de service .Qu'est-ce que la grille de services Istio
Une grille de services implémente des fonctions pour un groupe de services tels que la surveillance du trafic, le contrôle d'accès, la découverte, la sécurité, la tolérance aux pannes et d'autres choses utiles. Istio vous permet de faire tout cela sans la moindre modification du code des services eux-mêmes. Quel est le secret de la magie? Istio accroche à chaque service son proxy sous la forme d'un sidecar-container (sidecar est une poussette de moto), après quoi tout le trafic vers ce service passe par un proxy, qui, guidé par des politiques prédéfinies, décide comment, quand et si ce trafic doit atteindre le service. Istio permet également de mettre en œuvre des techniques DevOps avancées telles que les déploiements canaris, les disjoncteurs, l'injection de pannes et bien d'autres.
Comment Istio fonctionne avec les conteneurs et Kubernetes
La grille de services Istio est une implémentation latérale de tout ce dont vous avez besoin pour créer et gérer des microservices: surveillance, traçage, disjoncteurs, routage, équilibrage de charge, injection de pannes, tentatives, délais d'expiration, mise en miroir, contrôle d'accès, limites de vitesse et bien plus encore un autre. Et bien qu'il existe aujourd'hui de nombreuses bibliothèques pour implémenter ces fonctions directement dans le code, avec Istio vous pouvez obtenir la même chose sans rien changer dans votre code.
Selon le modèle de side-car, Istio s'exécute dans un conteneur Linux, qui est situé dans le même pod
Kubernetes avec un service contrôlé et injecte et extrait des fonctionnalités et des informations selon une configuration donnée. Nous soulignons qu'il s'agit de votre propre configuration et qu'elle vit en dehors de votre code. Par conséquent, le code devient beaucoup plus facile et plus court.
Plus important encore, la composante opérationnelle des microservices dans ce cas n'est en aucun cas liée au code lui-même, ce qui signifie que leur fonctionnement peut être transféré en toute sécurité à des informaticiens. En fait, pourquoi un développeur devrait-il être responsable des disjoncteurs et de l'injection de défauts? Réagir - oui, mais les traiter et les créer? Si vous supprimez tout cela du code, les programmeurs pourront se concentrer complètement sur la fonctionnalité de l'application. Et le code lui-même deviendra plus court et plus facile.
Grille de service
Istio, qui implémente des fonctions de gestion de microservices en dehors de leur code, est le concept de la grille de service Service Mesh. En d'autres termes, il s'agit d'un groupe coordonné d'un ou plusieurs fichiers binaires qui forment un réseau de fonctions réseau.
Comment Istio fonctionne avec les microservices
Voici comment les conteneurs side-car fonctionnent en conjonction avec
Kubernetes et
Minishift à
vol d'oiseau: lancez une instance de Minishift, créez un projet pour Istio (appelons-le «istio-system»), installez et exécutez tous les composants liés à Istio. Ensuite, lorsque des projets et des pods sont créés, ajoutez des informations de configuration à vos déploiements et vos pods commencent à utiliser Istio. Un diagramme simplifié ressemble à ceci:
Vous pouvez maintenant modifier les paramètres d'Istio pour, par exemple, organiser l'injection de pannes, la prise en charge de
Canary Deployment ou d'autres fonctionnalités d'Istio - tout cela sans toucher au code des applications elles-mêmes. Supposons que vous souhaitiez rediriger tout le trafic Web des utilisateurs de votre plus gros client (Foo Corporation) vers une nouvelle version du site. Pour ce faire, créez simplement une règle de routage Istio qui recherchera @ foocorporation.com dans l'ID utilisateur et effectuera la redirection appropriée. Pour tous les autres utilisateurs, rien ne changera. En attendant, vous testerez sereinement la nouvelle version du site. Et notez que vous n'avez pas besoin d'attirer les développeurs pour cela.
Et vous devez payer cher pour cela?
Pas du tout. Istio fonctionne assez rapidement, il est écrit en
Go et crée une très petite surcharge. De plus, une éventuelle perte de productivité en ligne est compensée par une augmentation de la productivité des développeurs. Du moins en théorie: n'oubliez pas que le temps de développement coûte cher. Quant au coût du logiciel, Istio est un logiciel open source, vous pouvez donc l'obtenir et l'utiliser gratuitement.
Apprenez par vous-même
L'équipe Red Hat Developer Experience a développé un
guide pratique détaillé d'Istio (en anglais). Il fonctionne sur Linux, MacOS et Windows, et le code est présenté en Java et Node.js.
10 leçons interactives sur Istio
Bloc 1 - Pour les débutants
Introduction à Istio30 minutes
Nous nous familiarisons avec Service Mesh, apprenons comment installer Istio dans le cluster Kubernetes OpenShift.
CommencezDéploiement de microservices dans Istio30 minutes
Nous utilisons Istio pour déployer trois microservices avec Spring Boot et Vert.x.
CommencezBloc 2 - Intermédiaire
Surveillance et traçage à Istio60 minutes
Nous explorons les outils de surveillance intégrés d'Istio, les mesures personnalisées et OpenTracing via Prometheus et Grafana.
CommencezRoutage facile à Istio60 minutes
Apprenez à gérer le routage dans Istio avec des règles simples.
CommencezRègles de routage avancées60 minutes
Présentation du routage intelligent Istio, du contrôle d'accès, de l'équilibrage de charge et de la limitation de vitesse.
CommencezBloc 3 - Utilisateur avancé
Injection de fautes à Istio60 minutes
Nous étudions des scénarios de basculement dans des applications distribuées, créant des erreurs HTTP et des retards réseau, et apprenons comment utiliser l'ingénierie du chaos pour restaurer l'environnement.
CommencezDisjoncteur à Istio30 minutes
Installez Siege pour les sites de test de stress et apprenez à fournir une résilience d'arrière-plan avec les répétitions, les disjoncteurs et l'éjection de pool.
CommencezSortie et Istio10 minutes
Nous utilisons les routes Egress pour créer des règles d'interaction des services internes avec les API et services externes.
CommencezIstio et Kiali15 minutes
Nous apprenons à utiliser Kiali pour obtenir une image générale du réseau de services et étudier le flux des demandes et des données.
CommencezTLS mutuel à Istio
15 minutes
Nous créons Istio Gateway et VirtualService, puis nous étudions en détail le TLS mutuel (mTLS) et ses paramètres.
CommencezBloc 3.1 - Immersion profonde: maillage de service Istio pour microservices
À propos de ce que le livre:
- Qu'est-ce qu'un maillage de service?
- Système Istio et son rôle dans l'architecture des microservices.
- Utiliser Istio pour résoudre les problèmes suivants:
- Tolérance aux pannes;
- Acheminement
- Test du chaos;
- La sécurité;
- Collection de télémétrie utilisant le traçage, les métriques et Grafana.
Télécharger le livreSérie d'articles sur les grilles de services et Istio
Essayez-le vous-même
Cette série de messages n'est pas destinée à fournir une immersion profonde dans le monde d'Istio. Nous voulons juste vous présenter le concept lui-même et peut-être vous inspirer pour essayer Istio par vous-même. Cela peut être entièrement gratuit et Red Hat fournit tous les outils nécessaires pour commencer à explorer OpenShift, Kubernetes, les conteneurs Linux et Istio, à savoir:
Red Hat Developer OpenShift Container Platform ,
notre guide Istio et d'autres ressources sur notre
micro site sur Maillage de service . Ne tardez pas, commencez dès aujourd'hui!
Règles de routage Istio: nous orientons les demandes de service là où nous en avons besoin
OpenShift et
Kubernetes font un excellent travail de routage des appels de
microservices vers les pods appropriés. C'est l'un des objectifs de Kubernetes - routage et équilibrage de charge. Mais que faire si vous avez besoin d'un routage plus fin et plus sophistiqué? Par exemple, pour utiliser deux versions d'un microservice en même temps. Comment les règles de route d'Istio aident-elles ici?
Les règles de routage sont des règles qui, en fait, déterminent le choix de l'itinéraire. À tout niveau de complexité du système, le principe général de fonctionnement de ces règles reste simple: les requêtes sont acheminées en fonction de certains paramètres et valeurs d'en-tête HTTP.
Regardons des exemples:
Valeur par défaut de Kubernetes: trivial "50 to 50"
Dans notre exemple, nous allons montrer comment utiliser simultanément deux versions du microservice dans OpenShift, appelons-les v1 et v2. Chaque version s'exécute dans son propre module Kubernetes et, par défaut, elle fonctionne de manière équilibrée avec un routage à tour de rôle. Chaque pod reçoit sa part de requêtes par le nombre de ses instances de microservices, c'est-à-dire de répliques. Istio vous permet également de modifier cet équilibre manuellement.
Supposons que nous ayons déployé deux versions de notre service de recommandation sur OpenShift, recommendation-v1 et recommendation-v2.
Dans la fig. La figure 1 montre que lorsque chaque service est présenté dans une instance, les demandes sont alternées de manière égale entre eux: 1-2-1-2- ... Voici comment le routage Kubernetes fonctionne par défaut:
Répartition pondérée entre les versions
Dans la fig. La figure 2 montre ce qui se passe si vous augmentez le nombre de réplicas de service v2 de un à deux (cela se fait avec la commande oc scale --replicas = 2 deployment / recommendation-v2). Comme vous pouvez le voir, les requêtes entre v1 et v2 sont désormais divisées en une relation un à trois: 1-2-2-1-2-2-2- ...:
Ignorer la version à l'aide d'Istio
Istio facilite la modification de la distribution des requêtes de la manière dont nous avons besoin. Par exemple, envoyez tout le trafic uniquement à recommendation-v1 à l'aide du fichier Istio yaml suivant:
Ici, il faut faire attention à cela: les pods sont sélectionnés en fonction des étiquettes. Dans notre exemple, l'étiquette v1 est utilisée. Le paramètre «weight: 100» signifie que 100% du trafic sera acheminé vers tous les pods du service qui ont le label v1.
Distribution d'annuaire entre les versions (déploiement Canary)
De plus, en utilisant le paramètre de poids, vous pouvez diriger le trafic vers les deux pods, en ignorant le nombre d'instances de microservices en cours d'exécution dans chacun d'eux. Par exemple, ici, nous dirigeons directement 90% du trafic vers v1 et 10% vers v2:
Acheminement séparé des utilisateurs mobiles
En conclusion, nous allons montrer comment forcer le trafic des utilisateurs mobiles vers le service v2, et tout le reste vers la v1. Pour ce faire, à l'aide d'expressions régulières, nous analysons la valeur de user-agent dans l'en-tête de demande:
Maintenant c'est ton tour
Un exemple avec des expressions régulières pour analyser les en-têtes devrait vous motiver à rechercher vos propres options pour appliquer les règles de routage Istio. De plus, les possibilités ici sont très étendues, car les valeurs des en-têtes peuvent être formées dans le code source des applications.
Et rappelez-vous que Ops, pas Dev
Tout ce que nous avons montré dans les exemples ci-dessus se fait sans la moindre modification du code source, sauf pour les cas où il est nécessaire de former des en-têtes de demande spéciaux. Istio sera utile à la fois aux développeurs qui, par exemple, pourront l'utiliser au stade des tests, et aux spécialistes de l'exploitation des systèmes informatiques, qu'il aidera grandement à la production.
Répétons donc le leitmotiv de cette série de posts:
vous n'avez rien à changer dans votre code . Pas besoin de collecter de nouvelles images ou de lancer de nouveaux conteneurs. Tout cela est implémenté en dehors du code.
Allumez l'imagination
Imaginez simplement les perspectives de l'analyse des titres avec des expressions régulières. Vous souhaitez rediriger votre plus gros client vers une version spéciale de vos
microservices ? C'est facile! Besoin d'une version distincte pour le navigateur Chrome? Pas de problème! Vous pouvez acheminer le trafic par presque toutes ses caractéristiques.
Essayez-le vous-même
Lire sur Istio, Kubernetes et OpenShift est une chose, mais pourquoi ne pas le toucher de vos propres mains? L'équipe du
programme pour développeurs Red Hat a préparé un manuel détaillé (en anglais) qui vous aidera à maîtriser rapidement ces technologies. Le manuel est également 100% open source, il est donc accessible au public. Le fichier fonctionne sur macOS, Linux et Windows, et le code source est dans les versions en Java et node.js (les versions dans d'autres langues seront bientôt). Il vous suffit d'ouvrir le référentiel git
Red Hat Developer Demo approprié dans votre navigateur.
Dans le prochain article: nous résolvons magnifiquement les problèmes
Aujourd'hui, vous avez vu de quelles capacités les règles de routage d'Istio sont capables. Imaginez maintenant la même chose, mais uniquement en relation avec la gestion des erreurs. C'est ce dont nous parlerons dans le prochain post.