Nous entamons une série de posts où nous démontrerons certaines des nombreuses fonctionnalités de la grille de services Istio Service Mesh en combinaison avec Red Hat OpenShift et Kubernetes.
Partie une, aujourd'hui :
- Nous expliquerons le concept des conteneurs sidecar de Kubernetes et formulerons le leitmotiv de cette série de posts : « vous n'avez rien à changer dans votre code ».
- Présentons un élément fondamental d'Istio – les règles de routage. Toutes les autres fonctionnalités d'Istio reposent sur ces règles, car ce sont elles qui permettent d'acheminer le trafic vers les microservices en utilisant des fichiers YAML externes au code des services. Nous examinerons également le schéma de déploiement de Canary Deployment. Bonus de fin d'année – 10 sessions interactives sur Istio.
Partie deux, qui sortira bientôt, vous expliquera :
- Comment Istio met en œuvre l'éjection de pool en combinaison avec le Circuit Breaker et démontrera comment Istio permet de retirer du schéma d'équilibrage un pod défaillant ou mal fonctionnant.
- Nous examinerons également le sujet du Circuit Breaker du premier post concernant comment Istio peut être utilisé ici. Nous montrerons comment router le trafic et traiter les erreurs réseau sans le moindre changement dans le code des services, en utilisant des fichiers de configuration YAML et des commandes terminal.
Partie trois :
- Récit sur la traçabilité et la surveillance, qui sont déjà intégrées ou facilement ajoutées à Istio. Nous montrerons comment utiliser des outils comme Prometheus, Jaeger et Grafana en combinaison avec le scaling d'OpenShift pour gérer sans effort l'architecture des microservices.
- Nous passons de la surveillance et du traitement des erreurs à l'injection intentionnelle de celles-ci dans le système. En d'autres termes, nous apprenons à effectuer l'injection de défauts sans modifier le code source, ce qui est très important du point de vue des tests — car si l'on modifie le code pour cela, il y a un risque d'introduire d'autres erreurs.
Enfin, dans le post final sur Istio Service Mesh :
- Nous passerons du côté Obscur. Plus précisément, nous apprendrons à utiliser le schéma de Dark Launch, lorsque le code est déployé et testé directement sur des données de production, sans affecter le fonctionnement du système. Ici, la capacité d'Istio à séparer le trafic est très utile. La possibilité de tester sur de vraies données de production, sans impacter le fonctionnement du système en production, est le moyen le plus convaincant de vérification.
- En partant du Dark Launch, montrons comment utiliser le modèle de Canary Deployment pour réduire les risques et simplifier le déploiement de nouveau code. Le Canary Deployment en soi n'est pas une nouveauté, mais Istio permet de mettre en œuvre ce schéma simplement avec des fichiers YAML peu complexes.
- En conclusion, nous verrons comment donner accès aux services à ceux qui se trouvent en dehors de vos clusters avec Istio Egress, afin de tirer parti des fonctionnalités d'Istio lors de l'utilisation d'Internet.
Alors, c'est parti…
L'outil de surveillance et de gestion d'Istio – tout ce qu'il faut pour coordonner les microservices dans la service mesh. .
Qu'est-ce que la service mesh Istio ?
La service mesh implémente pour un groupe de services des fonctions telles que la surveillance du trafic, le contrôle d'accès, la découverte, la sécurité, la résilience et d'autres fonctionnalités utiles. Istio permet de faire tout cela sans aucune modification du code des services eux-mêmes. Quel est le secret de cette magie ? Istio attache à chaque service son proxy sous la forme d'un conteneur sidecar, après quoi tout le trafic vers ce service passe par le proxy, qui, en suivant les politiques définies, décide comment, quand et si ce trafic doit vraiment atteindre le service. Istio permet également de mettre en œuvre des techniques DevOps avancées, telles que les déploiements canary, les disjoncteurs, l'injection de fautes, et bien d'autres.
Comment Istio fonctionne avec les conteneurs et Kubernetes.
La service mesh Istio est une mise en œuvre sidecar de tout ce qui est nécessaire pour créer et gérer des microservices : surveillance, traçage, disjoncteurs, routage, équilibrage de charge, injection de fautes, répétitions, time-outs, mirroring, contrôle d'accès, limitation de débit et bien plus encore. Et bien qu'il existe aujourd'hui de nombreuses bibliothèques pour mettre en œuvre ces fonctionnalités directement dans le code, avec Istio, vous pouvez obtenir tout cela sans modifier votre code.
Selon le modèle sidecar, Istio s'exécute dans un conteneur Linux qui est situé dans le même -pod que le service contrôlé et injecte (inject) et extrait (extract) des fonctionnalités et des informations selon la configuration définie. Soulignons que c'est votre propre configuration, et elle vit en dehors de votre code. Ainsi, le code devient beaucoup plus simple et plus concis.
Il est également important de noter que l'aspect opérationnel des microservices n'est pas du tout lié au code lui-même, ce qui signifie que leur exploitation peut être tranquillement confiée aux spécialistes IT. En effet, pourquoi un développeur devrait-il être responsable des circuit breakers et de l'injection de pannes ? Réagir – oui, mais les gérer et les créer ? En retirant tout cela du code, les programmeurs pourront se concentrer entièrement sur la fonctionnalité applicative. De plus, le code lui-même deviendra plus court et plus simple.
Maillage de services
Istio, qui implémente des fonctions de gestion des microservices en dehors de leur code – c'est ce qu'on appelle le concept de maillage de services Service Mesh. Autrement dit, c'est un groupe coordonné d'un ou plusieurs binaires qui forment un maillage de fonctions réseau.
Comment Istio fonctionne avec les microservices
Voici à quoi ressemble le fonctionnement des conteneurs sidecar en liaison avec et vues d'ensemble : vous lancez une instance de Minishift, créez un projet pour Istio (appelons-le « istio-system »), installez et démarrez tous les composants associés à Istio. Ensuite, au fur et à mesure que vous créez des projets et des pods, vous ajoutez des informations de configuration à vos déploiements, et vos pods commencent à utiliser Istio. Simplifiée, le diagramme ressemble à ceci :
Vous pouvez maintenant modifier les paramètres d'Istio pour, par exemple, organiser des injections de pannes, le support ou d'autres fonctionnalités d'Istio – et tout cela sans toucher au code des applications elles-mêmes. Supposons que vous souhaitiez rediriger tout le trafic web de votre plus grand client (Foo Corporation) vers une nouvelle version du site. Pour ce faire, il suffit de créer une règle de routage Istio qui recherchera @foocorporation.com dans l'identifiant utilisateur et effectuera la redirection correspondante. Pour tous les autres utilisateurs, rien ne changera. Et pendant ce temps, vous pourrez tranquillement tester la nouvelle version du site. Et notez qu'il n'est pas nécessaire d'impliquer les développeurs pour cela.
Et cela va coûter cher ?
Pas du tout. Istio fonctionne assez rapidement, il est écrit en et crée peu de surcharge. De plus, la perte potentielle en performance en ligne est compensée par l’augmentation de la productivité des développeurs. Du moins en théorie : n’oubliez pas que le temps des développeurs coûte cher. En ce qui concerne les frais de logiciel, Istio est un logiciel open source, vous pouvez donc l'obtenir et l'utiliser gratuitement.
Maîtrisez par vous-même
L'équipe Red Hat Developer Experience a développé une formation pratique approfondie sur Istio (en anglais). Elle fonctionne sur Linux, MacOS et Windows, et le code est disponible en versions Java et Node.js.
10 sessions interactives sur Istio
Bloc 1 — Pour les débutants
Introduction à Istio
30 minutes
Familiarisez-vous avec Service Mesh, apprenez à installer Istio dans un cluster Kubernetes OpenShift.
Déploiement de microservices dans Istio
30 minutes
Utilisons Istio pour déployer trois microservices avec Spring Boot et Vert.x.
Bloc 2 – Niveau intermédiaire
Surveillance et traçage dans Istio
60 minutes
Nous découvrons les outils de surveillance intégrés d'Istio, les métriques configurables, ainsi qu'OpenTracing via Prometheus et Grafana.
Routage simple dans Istio
60 minutes
Apprenons à gérer le routage dans Istio avec des règles simples.
Règles de routage avancées
60 minutes
Familiarisez-vous avec le routage intelligent dans Istio, la gestion d'accès, l'équilibrage de charge et la limitation de débit.
Bloc 3 – Utilisateur avancé
Injection de pannes dans Istio
60 minutes
Nous explorons les scénarios de gestion des pannes dans les applications distribuées, créant des erreurs HTTP et des latences réseau, et apprenons à appliquer le chaos engineering pour restaurer l'environnement.
Circuit Breaker dans Istio
30 minutes
Nous installons Siege pour le test de charge des sites et apprenons à assurer la résilience du backend avec des répétitions, un circuit breaker et l’éjection de pool.
Egress et Istio
10 minutes
Nous utilisons les routes Egress pour créer des règles d'interaction entre les services internes et les API externes.
Istio et Kiali
15 minutes
Apprenons à utiliser Kiali pour obtenir une vue d'ensemble de la service mesh et étudier les flux de requêtes et de données.
Mutual TLS dans Istio
15 minutes
Créons un Istio Gateway et un VirtualService, puis examinons en détail le mutual TLS (mTLS) et ses configurations.
Bloc 3.1 — Plongée approfondie : Istio Service Mesh pour microservices
À propos de quoi porte le livre :
- Qu'est-ce qu'une service mesh.
- Le système Istio et son rôle dans l'architecture microservices.
- L'utilisation d'Istio pour résoudre les problèmes suivants :
- Résilience ;
- Routage ;
- Test de chaos ;
- Sécurité ;
- Collecte de télémétrie à l'aide de traçage, de métriques et de Grafana.
Série d'articles sur les maillages de services et Istio
Essayez par vous-même
Cette série de posts n'a pas pour but d'assurer une immersion profonde dans le monde d'Istio. Nous voulons simplement vous présenter le concept et, peut-être, vous inspirer à essayer Istio par vous-même. Vous pouvez le faire complètement gratuitement, et Red Hat fournit tous les outils nécessaires pour commencer à apprendre OpenShift, Kubernetes, les conteneurs Linux et Istio, à savoir : , et d'autres ressources sur notre . Ne tardez pas, commencez dès aujourd'hui !
Règles de routage d'Istio : diriger les requêtes de service là où il faut
et s'occupent parfaitement de la façon dont les appels aux sont routés vers les bons pods. C'est l'un des objectifs de Kubernetes : le routage et l'équilibrage des charges. Et si vous avez besoin d'un routage plus précis et sophistiqué ? Par exemple, pour utiliser simultanément deux versions d'un microservice. Comment les règles de routage d'Istio peuvent-elles aider ici ?
Les règles de routage sont celles qui définissent le choix du chemin. Quel que soit le niveau de complexité du système, le principe de base de ces règles reste simple : les requêtes sont routées en fonction de paramètres spécifiques et de valeurs d'en-tête HTTP.
Examinons quelques exemples :
Kubernetes par défaut : trivial « 50-50 »
Dans notre exemple, nous allons montrer comment utiliser simultanément deux versions d'un microservice dans OpenShift, que nous appellerons v1 et v2. Chaque version s'exécute dans son propre pod Kubernetes, et par défaut, un routage équilibré uniforme est appliqué. Chaque pod reçoit sa part de requêtes en fonction de son nombre d'instances de microservice, c'est-à-dire de répliques. Istio permet de modifier cet équilibre manuellement.
Supposons que nous avons déployé sur OpenShift deux versions de notre service de recommandation, recommendation-v1 et recommendation-v2.
Comme le montre la figure 1, lorsque chaque service est représenté par une seule instance, les requêtes alternent uniformément entre elles : 1-2-1-2-… C'est ainsi que le routage de Kubernetes fonctionne par défaut :
Répartition pondérée entre les versions
La figure 2 montre ce qui se passe si nous augmentons le nombre de répliques du service v2 d'un à deux (cela se fait avec la commande oc scale —replicas=2 deployment/recommendation-v2). Comme on peut le voir, les requêtes entre v1 et v2 se répartissent désormais dans un rapport de « un à trois » : 1-2-2-1-2-2-… :
Ignorer la version avec Istio
Istio permet de modifier facilement la répartition des requêtes selon nos besoins. Par exemple, envoyer tout le trafic uniquement vers recommendation-v1 avec le fichier yaml Istio suivant :
Il convient de noter ici que les pods sont sélectionnés en fonction des labels. Dans notre exemple, le label v1 est utilisé. Le paramètre « weight: 100 » signifie que 100 % du trafic sera acheminé vers tous les pods du service qui ont le label v1.
Répartition directive entre les versions (Canary Deployment)
Ensuite, en utilisant le paramètre weight, il est possible de 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 90 % du trafic vers v1 et 10 % vers v2 :
Routage séparé des utilisateurs mobiles
Enfin, montrons comment forcer le routage du trafic des utilisateurs mobiles vers le service v2, tandis que tous les autres iront vers v1. Pour ce faire, nous analysons la valeur de l'user-agent dans l'en-tête de la requête à l'aide d'expressions régulières :
Maintenant, c'est votre tour
L'exemple avec les expressions régulières pour analyser les en-têtes devrait vous inciter à rechercher vos propres variantes d'application des règles de routage Istio. D'autant plus que les possibilités offertes sont très vastes, car les valeurs des en-têtes peuvent être formées dans le code source des applications.
Et n'oubliez pas que c'est Ops, et non Dev
Tout ce que nous avons montré dans les exemples ci-dessus se fait sans le moindre changement dans le code source, excepté dans les cas où il est nécessaire de former des en-têtes de requêtes spéciaux. Istio sera utile tant pour les développeurs, qui pourront par exemple l'utiliser lors de la phase de test, que pour les professionnels de l'exploitation des systèmes IT, qui en tireront un grand bénéfice en production.
Donc, rappelons le leitmotiv de cette série de publications : vous n'avez rien à changer dans votre code. Pas besoin de rassembler de nouvelles images ou de lancer de nouveaux conteneurs. Tout cela se fait en dehors du code.
Laissez libre cours à votre imagination
Imaginez seulement les perspectives ouvertes par l'analyse des en-têtes à l'aide d'expressions régulières. Vous voulez rediriger votre plus grand client vers une version spéciale de vos ? Легко! Нужна отдельная версия для браузера Chrome? Не проблема! Вы можете маршрутизировать трафик практически по любой его характеристике.
Essayez par vous-même
Lire sur Istio, Kubernetes et OpenShift, c'est une chose, mais pourquoi ne pas tout toucher vous-même ? L'équipe a préparé un guide détaillé (en anglais) qui vous aidera à maîtriser ces technologies aussi rapidement que possible. Le guide est également 100% open source, il est donc disponible publiquement. Le fichier fonctionne sur macOS, Linux et Windows, et le code source est disponible en versions Java et node.js (d'autres versions arrivent bientôt). Ouvrez simplement le dépôt git correspondant dans votre navigateur. .
Dans le prochain post : nous travaillons sur les problèmes avec élégance
Aujourd'hui, vous avez vu de quoi sont capables les règles de routage d'Istio. Maintenant, imaginez la même chose, mais appliquée à la gestion des erreurs. C'est exactement ce dont nous parlerons dans le prochain post.
Source : habr.com
