Nous commençons une série d'articles présentant certaines des nombreuses fonctionnalités d'Istio Service Mesh lorsqu'elles sont combinées avec Red Hat OpenShift et Kubernetes.
Première partie, aujourd'hui :
- Expliquons le concept des conteneurs side-car Kubernetes et formulons le leitmotiv de cette série d'articles : "vous n'avez rien à changer dans votre code".
- Présentons l'élément fondamental d'Istio : les règles de routage. Toutes les autres fonctionnalités d'Istio reposent sur celles-ci, puisque ce sont les règles qui permettent de diriger le trafic vers les microservices, à l'aide de fichiers YAML externes au code du service. Nous envisageons également le schéma de déploiement Canary Deployment. Bonus du Nouvel An – 10 cours interactifs sur Istio
La deuxième partie, à venir, vous dira :
- Comment Istio implémente Pool Ejection en combinaison avec Circuit Breaker et démontrera comment Istio vous permet de supprimer un pod mort ou peu performant du circuit d'équilibrage.
- Nous examinerons également le sujet Circuit Breaker du premier article pour voir comment Istio peut être utilisé ici. Nous vous montrerons 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.
Partie trois:
- Une histoire sur le traçage et la surveillance, qui sont déjà intégrés ou facilement ajoutés à Istio. Nous vous montrerons comment utiliser des outils tels que Prometheus, Jaeger et Grafana en combinaison avec la mise à l'échelle OpenShift pour gérer sans effort les architectures 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 à effectuer une injection de fautes sans modifier le code source, ce qui est très important du point de vue des tests - car si vous modifiez le code lui-même pour cela, il y a un risque d'introduire des erreurs supplémentaires.
Enfin, dans le dernier article sur 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 en rien le fonctionnement du système. C’est là que la capacité d’Istio à diviser le trafic s’avère utile. Et la possibilité de tester des données de production en direct sans affecter en aucune façon le fonctionnement du système de combat constitue la méthode de vérification la plus convaincante.
- En nous appuyant sur Dark Launch, nous vous montrerons comment utiliser le modèle de déploiement Canary pour réduire les risques et faciliter la mise en production de nouveau code. Canary Deployment lui-même est loin d'être nouveau, mais Istio vous permet de mettre en œuvre ce schéma avec de simples fichiers YAML.
- Enfin, nous vous montrerons comment utiliser Istio Egress pour donner accès aux services à ceux qui se trouvent en dehors de vos clusters afin d'utiliser les capacités d'Istio lorsque vous travaillez avec Internet.
Alors, c'est parti...
Outils de surveillance et de gestion Istio : tout ce dont vous avez besoin pour orchestrer des microservices dans un maillage de services .
Qu'est-ce qu'Istio Service Mesh ?
Un maillage de services implémente des fonctions telles 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 éléments utiles pour un groupe de services. 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 attache son propre proxy à chaque service sous la forme d'un conteneur side-car (le side-car est un side-car de moto), après quoi tout le trafic vers ce service passe par le proxy, qui, guidé par des politiques spécifiées, décide comment, quand et si ce trafic devrait atteindre le service du tout. 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
Le maillage de services Istio est une implémentation side-car 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, tentatives, délais d'attente, mise en miroir, contrôle d'accès, limitation de débit et bien plus encore. Et bien qu'il existe aujourd'hui une tonne de bibliothèques pour implémenter ces fonctions directement dans le code, avec Istio vous pouvez obtenir les mêmes choses sans rien changer dans votre code.
Selon le modèle side-car, Istio s'exécute dans un conteneur Linux, situé dans un -pod avec un service contrôlé et injecte et extrait des fonctionnalités et des informations selon la configuration donnée. Nous soulignons qu’il s’agit de votre propre configuration et qu’elle réside en dehors de votre code. Le code devient donc beaucoup plus simple et plus court.
Il est également important que la composante opérationnelle des microservices n'ait aucun lien avec le code lui-même, ce qui signifie que leur fonctionnement peut être transféré en toute sécurité à des spécialistes informatiques. En effet, pourquoi le 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 pleinement sur les fonctionnalités de l'application. Et 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, est le concept d'un Service Mesh. En d’autres termes, il s’agit d’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 travail des conteneurs side-car en conjonction avec и vue d'ensemble : 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, 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. Un schéma simplifié ressemble à ceci :
Vous pouvez désormais modifier les paramètres d'Istio afin, par exemple, d'organiser l'injection 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 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 redirigera en conséquence. 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 du tout besoin d’impliquer des développeurs pour cela.
Et faudra-t-il le payer cher ?
Pas du tout. Istio est assez rapide et est écrit en et crée très peu de frais généraux. De plus, la perte possible de productivité en ligne est compensée par une augmentation de la productivité des développeurs. Au moins en théorie : n'oubliez pas que le temps des développeurs est précieux. En ce qui concerne les coûts des logiciels, Istio est un logiciel open source, vous pouvez donc l'obtenir et l'utiliser gratuitement.
Maîtrisez-le vous-même
L'équipe Red Hat Developer Experience a développé un programme pratique approfondi par Istio (en anglais). Il fonctionne sous Linux, MacOS et Windows, et le code est disponible en Java et Node.js.
10 cours interactifs sur Istio
Bloc 1 - Pour les débutants
Présentation d'Istio
30 minutes
Faisons connaissance avec Service Mesh, apprenons à installer Istio dans un cluster OpenShift Kubernetes.
Déployer des microservices dans Istio
30 minutes
Nous 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 explorerons les outils de surveillance intégrés d'Istio, les métriques personnalisées et OpenTracing via Prometheus et Grafana.
Routage simple dans Istio
60 minutes
Découvrez comment gérer le routage dans Istio à l'aide de règles simples.
Règles de routage avancées
60 minutes
Jetons un coup d'œil au routage intelligent, au contrôle d'accès, à l'équilibrage de charge et à la limitation de débit d'Istio.
Bloc 3 – utilisateur avancé
Injection de défauts dans Istio
60 minutes
Nous étudions les scénarios de gestion des pannes dans les applications distribuées, créant des erreurs HTTP et des retards réseau, et apprenons à utiliser l'ingénierie du chaos pour restaurer l'environnement.
Disjoncteur à Istio
30 minutes
Nous installons Siege pour les sites de tests de résistance et apprenons à garantir la tolérance aux pannes du backend à l'aide de rediffusions, de disjoncteurs et d'éjection de pool.
Sortie et Istio
10 minutes
Nous utilisons les routes de sortie pour créer des règles pour l'interaction des services internes avec les API et services externes.
Istio et Kiali
15 minutes
Apprenez à utiliser Kiali pour obtenir une vue d'ensemble du maillage de services et explorer les flux de requêtes et de données.
TLS mutuel dans Istio
15 minutes
Nous créons Istio Gateway et VirtualService, puis nous étudions en détail le TLS mutuel (mTLS) et ses paramètres.
Bloc 3.1 – Analyse approfondie : Istio Service Mesh pour les microservices
De quoi parle le livre:
- Qu’est-ce qu’un maillage de services ?
- Le 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 ;
- Routage ;
- Tests de chaos ;
- La sécurité;
- Collecte de télémétrie à l'aide de traces, de métriques et de Grafana.
Série d'articles sur les maillages de services et Istio
Essayez vous-même
Cette série d'articles n'a pas pour but de fournir une plongée approfondie dans le monde d'Istio. Nous souhaitons simplement vous présenter le concept et peut-être vous inciter à essayer Istio par vous-même. C'est entièrement gratuit et Red Hat fournit tous les outils dont vous avez besoin pour démarrer avec OpenShift, Kubernetes, les conteneurs Linux et Istio, notamment : , et d'autres ressources sur notre . Ne tardez pas, commencez dès aujourd'hui !
Règles de routage Istio : diriger les demandes de service là où elles doivent aller
и faire un excellent travail pour répondre acheminés vers les pods requis. C'est l'une des raisons de l'existence de Kubernetes : le routage et l'équilibrage de charge. Mais que se passe-t-il si vous avez besoin d’un routage plus subtil et sophistiqué ? Par exemple, pour utiliser simultanément deux versions d’un microservice. Comment les règles de routage Istio peuvent-elles vous aider ?
Les règles de routage sont les règles qui déterminent réellement le choix de l'itinéraire. Quel que soit le 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 :
Kubernetes par défaut : trivial "50/50"
Dans notre exemple, nous allons montrer comment utiliser simultanément deux versions d'un microservice dans OpenShift, appelons-les v1 et v2. Chaque version s'exécute dans son propre pod Kubernetes et, par défaut, elle exécute un routage round robin uniformément équilibré. Chaque pod reçoit sa part de requêtes en fonction du nombre de ses instances de microservice, autrement dit de réplicas. Istio vous permet de modifier ce solde manuellement.
Disons que nous avons déployé deux versions de notre service de recommandation sur OpenShift, recommendation-v1 et recommendation-v2.
En figue. La figure 1 montre que lorsque chaque service est représenté dans une instance, les requêtes alternent de manière égale entre elles : 1-2-1-2-... Voici comment fonctionne le routage Kubernetes par défaut :
Répartition pondérée entre les versions
En figue. 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 déployer/recommendation-v2). Comme vous pouvez le constater, les requêtes entre la v1 et la v2 sont désormais divisées selon 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, envoyez tout le trafic uniquement à recommendation-v1 à l'aide du fichier yaml Istio suivant :
Ici, il faut faire attention à ceci : les dosettes sont sélectionnées en fonction des étiquettes. Notre exemple utilise l'étiquette v1. Le paramètre « poids : 100 » signifie que 100 % du trafic sera acheminé vers tous les pods de service portant le label v1.
Répartition des directives entre les versions (déploiement Canary)
Ensuite, à l'aide du paramètre de poids, vous pouvez diriger le trafic vers les deux pods, en ignorant le nombre d'instances de microservice exécutées dans chacun d'eux. Par exemple, ici nous dirigeons 90 % du trafic vers la v1 et 10 % vers la v2 :
Routage séparé pour les utilisateurs mobiles
En conclusion, nous montrerons comment forcer le trafic des utilisateurs mobiles à être acheminé vers le service v2 et tous les autres vers le service v1. Pour ce faire, nous utilisons des expressions régulières pour analyser la valeur de l'agent utilisateur dans l'en-tête de la requête :
Maintenant, c'est à votre tour
L'exemple avec des expressions régulières pour analyser les en-têtes devrait vous motiver à trouver vos propres utilisations des règles de routage Istio. De plus, les possibilités ici sont assez étendues, puisque les valeurs d'en-tête peuvent être formées dans le code source de l'application.
Et rappelez-vous que Ops, pas Dev
Tout ce que nous avons montré dans les exemples ci-dessus est réalisé sans la moindre modification du code source, enfin, sauf dans les cas où il est nécessaire de générer des en-têtes de requêtes spéciales. Istio sera utile aussi bien aux développeurs, qui pourront par exemple l'utiliser au stade des tests, qu'aux spécialistes de l'exploitation des systèmes informatiques, pour qui il aidera grandement en production.
Reprenons donc le leitmotiv de cette série de posts : vous n'avez rien à changer dans votre code. Il n'est pas nécessaire de créer de nouvelles images ou de lancer de nouveaux conteneurs. Tout cela est implémenté en dehors du code.
Utilise ton imagination
Imaginez simplement les possibilités d'analyse d'en-tête à l'aide d'expressions régulières. Vous souhaitez rediriger votre plus gros client vers une version spéciale de votre ? Facilement! Besoin d'une version distincte pour le navigateur Chrome ? Aucun problème! Vous pouvez acheminer le trafic selon presque toutes les caractéristiques.
Essayez vous-même
Lire sur Istio, Kubernetes et OpenShift est une chose, mais pourquoi ne pas toucher à tout vous-même ? Équipe a préparé un guide détaillé (en anglais) qui vous aidera à maîtriser ces technologies le plus rapidement possible. Le manuel est également 100 % open source, il est donc publié dans le domaine public. Le fichier fonctionne sur macOS, Linux et Windows, et le code source est disponible en versions Java et node.js (des versions dans d'autres langues seront bientôt disponibles). Ouvrez simplement le référentiel git correspondant dans votre navigateur .
Dans le prochain article : nous résolvons les problèmes à merveille
Aujourd'hui, vous avez vu ce que les règles de routage Istio peuvent faire. Imaginez maintenant la même chose, mais uniquement en ce qui concerne la gestion des erreurs. C’est exactement ce dont nous parlerons dans le prochain article.
Source: habr.com