Istio est une couche de maillage de service open source configurable qui se connecte, surveille et sécurise les conteneurs dans un cluster Kubernetes. À ce jour, Istio ne fonctionne en mode natif qu'avec Kubernetes, mais sa nature open source permet à quiconque d'écrire des extensions permettant à Istio de fonctionner sur n'importe quel logiciel de cluster. Aujourd'hui, nous allons nous concentrer sur l'utilisation d'Istio avec Kubernetes, son cas d'utilisation le plus populaire.

Kubernetes est un outil d'orchestration de conteneurs, et une unité centrale de Kubernetes est un nœud. Un nœud est constitué d'un ou de plusieurs conteneurs, ainsi que de systèmes de fichiers ou d'autres composants. Une architecture de microservices peut comporter une dizaine de nœuds différents, chacun représentant des microservices différents. Kubernetes gère la disponibilité et la consommation de ressources des nœuds, en ajoutant des pods à mesure que la demande augmente grâce au pod autoscaler. Istio injecte des conteneurs supplémentaires dans le pod pour renforcer la sécurité, la gestion et la surveillance.

Étant un logiciel open source, Istio peut fonctionner sur n'importe quel fournisseur de cloud public qui le prend en charge et sur n'importe quel cloud privé si les administrateurs y consentent.

La vidéo suivante explique plus en détail les concepts de base d'Istio :

Lorsque des entreprises passent aux microservices, elles doivent prendre en charge des dizaines, voire des centaines d'applications spécifiques. La gestion séparée de ces points d'extrémité implique de prendre en charge un grand nombre de machines virtuelles ou VM, y compris la demande. Un logiciel de cluster tel que Kubernetes peut créer des pods et les faire évoluer, mais Kubernetes ne fournit pas de routage, de règles de trafic, ni d'outils de surveillance ou de débogage puissants.

C'est ici qu'intervient le maillage de services.

À mesure que le nombre de services augmente, le nombre de moyens de communication potentiels progresse de manière exponentielle. Deux services n'ont que deux voies de communication. Trois services en ont six, tandis que 10 services en ont 90. Un maillage de services offre un moyen unique de configurer ces voies de communication en créant une politique pour la communication.

Un maillage de services instrumente les services et dirige le trafic de communication selon une configuration prédéfinie. Cela signifie qu'au lieu de configurer un conteneur en cours d'exécution (ou d'écrire du code pour le faire), un administrateur peut fournir une configuration au maillage de services et lui faire effectuer ce travail. Auparavant, cela devait toujours se faire avec les serveurs web et la communication de service à service.

La façon la plus courante de faire cela dans un cluster est d'utiliser le modèle side-car. Un side-car est un nouveau conteneur, à l'intérieur du pod, qui achemine et observe le trafic de communication entre les services et les conteneurs.

Comme nous l'avons mentionné précédemment, Istio se superpose à Kubernetes, en ajoutant des conteneurs qui sont pratiquement invisibles pour le programmeur et l'administrateur. Appelés conteneurs side-car, ils agissent comme une personne intermédiaire qui dirige le trafic et surveille les interactions entre les composants. La combinaison des deux fonctionne de trois manières : configuration, surveillance et gestion.

Configuration

La principale méthode pour définir la configuration avec Kubernetes est la commande kubectl, communément appelée "kubectl -f", où le fichier est un fichier YAML. Les utilisateurs d'Istio peuvent exécuter des types de fichiers YAML nouveaux et différents avec kubectl, ou utiliser la nouvelle commande ioctl, facultative.

Surveillance

Avec Istio, vous pouvez facilement surveiller l'état de vos applications qui fonctionnent avec Kubernetes. Les outils d'Istio peuvent gérer et visualiser l'état de santé des applications et vous fournir plus d'informations que la simple surveillance générale des clusters et des nœuds fournie par Kubernetes.

Gestion

Étant donné que l'interface d'Istio est pratiquement identique à celle de Kubernetes, sa gestion ne nécessite quasiment aucun travail supplémentaire. Par ailleurs, Istio permet à l'utilisateur de créer des politiques qui ont un impact sur l'ensemble du cluster Kubernetes et le gèrent, ce qui réduit le temps de gestion de chaque cluster tout en évitant d'avoir recours à un code de gestion personnalisé.

Le maillage de services présente de nombreux avantages, notamment l'amélioration du débogage, de la surveillance, du routage, de la sécurité et des possibilités d'exploitation. Autrement dit, avec Istio, il faudra moins d'efforts pour gérer un groupe plus large de services.

Amélioration du débogage

Supposons qu'un service possède plusieurs dépendances. Le service pay_claim d'une compagnie d'assurances appelle le service deductible_amt, qui appelle le service is_member_covered, et ainsi de suite. Une chaîne de dépendances complexe peut avoir 10 ou 12 appels de service. Lorsque l'un de ces 12 appels de service est défectueux, une série de défaillances en cascade se produit, entraînant une erreur 500, une erreur 400, voire l'absence totale de réponse.

Pour déboguer cet ensemble d'appels, vous pouvez utiliser quelque chose comme une trace de pile. Sur le front-end, les développeurs côté client peuvent voir quels éléments sont récupérés des serveurs Web, dans quel ordre, et les examiner. Les programmeurs front-end peuvent obtenir un diagramme en cascade pour faciliter le débogage.

Ce que l'exemple ne montre pas, c'est ce qui se passe à l'intérieur du centre de données : comment callback=parselLotamaAudiences appelle quatre autres services web et quels sont ceux qui répondent le plus lentement. Nous verrons plus loin comment Istio fournit des outils pour tracer des appels de fonction dans un diagramme très similaire à celui-ci.

Surveillance et observabilité

Les équipes DevOps et les administrateurs informatiques peuvent vouloir observer le trafic pour voir la latence, le temps de service, les erreurs en pourcentage du trafic, etc. Souvent, ils veulent voir un tableau de bord. Un tableau de bord fournit une visualisation de la somme, ou de la moyenne, de ces paramètres au fil du temps, et permet peut-être d'accéder à un nœud, un service ou un pod spécifique. Kubernetes ne fournit pas cette fonctionnalité en natif.

Politique

Par défaut, Kubernetes permet à chaque pod d'envoyer du trafic à tous les autres pods. Istio permet aux administrateurs de créer une politique pour restreindre les services qui peuvent fonctionner les uns avec les autres. Ainsi, certains services peuvent uniquement appeler d'autres services qui sont de vraies dépendances. Pour assurer le bon fonctionnement des services, une autre politique consiste à limiter le débit, ce qui empêchera le trafic excessif de saturer un service et préviendra les attaques par déni de service.

Routage et équilibrage de charge

Par défaut, Kubernetes fournit un équilibrage de charge de type circulaire. Si six pods fournissent un microservice, Kubernetes fournit un équilibreur de charge, ou « service », qui envoie les requêtes à chaque pod dans un ordre croissant, puis recommence. Cependant, il arrive qu'une entreprise déploie différentes versions d'un même service en production.

L'exemple le plus simple peut être un déploiement bleu/vert. Dans ce cas, le logiciel peut construire une version entièrement nouvelle de l'application en production sans y envoyer les utilisateurs. Après avoir lancé la nouvelle version, l'entreprise peut conserver les anciens serveurs afin de rétablir rapidement la situation en cas de panne.

Avec Istio, c'est aussi simple que d'utiliser le balisage dans un fichier de configuration. Les administrateurs peuvent également utiliser des étiquettes pour indiquer le type de service auquel se connecter et élaborer des règles basées sur les en-têtes. Ainsi, par exemple, les utilisateurs de la version bêta peuvent accéder à un pod Canary contenant la dernière et meilleure version, tandis que les utilisateurs réguliers accèdent à la version stable de production.

Coupure de circuit

Si un service est surchargé ou hors service, les nouvelles demandes échoueront tout en continuant à surcharger le système. Comme Istio surveille les erreurs et les retards, il peut imposer une pause (pour permettre à un service de se rétablir) après un nombre spécifique de demandes défini par la politique. Vous pouvez appliquer cette politique à l'ensemble du cluster en créant un petit fichier texte et en demandant à Istio de l'utiliser comme nouvelle politique.

Sécurité

Istio fournit l'identité, la règle et le chiffrement par défaut, ainsi que l'authentification, l'autorisation et l'audit (AAA). Les pods gérés qui communiquent avec d'autres utiliseront le trafic chiffré, empêchant toute observation. Le service d'identité, associé au chiffrement, garantit qu'aucun utilisateur non autorisé ne puisse falsifier ou usurper un appel de service. L'AAA fournit aux professionnels de la sécurité et des opérations les outils dont ils ont besoin pour surveiller, avec moins de contraintes.

Simplification de l'administration

Les applications traditionnelles continuent d'avoir besoin des fonctions d'identification, de politique et de sécurité offertes par Istio. Les programmeurs et les administrateurs travaillent donc à un niveau d'abstraction inadéquat en réimplantant sans cesse les mêmes règles de sécurité pour chaque service. Istio leur permet de travailler au bon niveau, en définissant la politique du cluster à l'aide d'un panneau de contrôle unique.