Qu’est-ce que Istio ?

Au moment de la rédaction de cet article, Istio fonctionne uniquement nativement avec Kubernetes, mais sa nature open source permet à quiconque d’écrire des extensions, ce qui fait qu’Istio peut fonctionner sur n’importe quel logiciel de cluster. Aujourd’hui, nous nous concentrons sur l’utilisation d’Istio avec Kubernetes, son cas d’utilisation le plus populaire.

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

Comme il s'agit d'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é dont les administrateurs sont prêts à s'occuper.

Découvrez-en plus sur les bases d’Istio dans la vidéo suivante :

Lorsque les entreprises passent aux microservices, elles doivent prendre en charge des dizaines ou des centaines d’applications spécifiques. La gestion séparée de ces terminaux implique la prise en charge de nombreuses machines virtuelles (VM), y compris à la demande. Un logiciel de cluster comme 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 solides.

Saisir le maillage du service.

Avec l'augmentation du nombre de services, le nombre de moyens de communication potentiels augmente 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. Ainsi, 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 demander d’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 procéder dans un cluster est d’utiliser le modèle sidecar. Un sidecar est un nouveau conteneur, à l’intérieur du pod, qui achemine et observe le trafic de communication entre les services et les conteneurs.

Comme mentionné précédemment, Istio se superpose à Kubernetes, ajoutant des conteneurs qui sont invisibles pour le programmeur et l’administrateur. Appelés conteneurs sidecar, ils font office d’intermédiaires qui dirigent le trafic et surveillent les interactions des composants. Les deux fonctionnent ensemble de trois manières différentes : configuration, surveillance et gestion.

La principale méthode pour définir la configuration avec Kubernetes est la commande kubectl, généralement « kubectl -f <filename> », où le fichier est un fichier YAML. Les utilisateurs d’Istio peuvent soit exécuter de nouveaux et différents types de fichiers YAML avec kubectl, soit utiliser la nouvelle commande facultative ioctl.

Avec Istio, vous pouvez facilement surveiller l’état de vos applications exécutées avec Kubernetes. Cette solution permet de gérer et de visualiser l’état de santé des applications, offrant ainsi une meilleure visibilité que la surveillance générale des clusters et des nœuds qu’offre Kubernetes.

L’interface d’Istio étant essentiellement la même que celle de Kubernetes, sa gestion exige peu de travail supplémentaire. De fait, Istio permet à l’utilisateur de créer des politiques qui affectent et gèrent l’ensemble du cluster Kubernetes, réduisant ainsi le temps de gestion de chaque cluster tout en éliminant le besoin de code de gestion personnalisé.

Parmi les principaux avantages du maillage de services, citons les capacités d’amélioration du débogage, de la surveillance, du routage, de la sécurité et de l’utilisation. Autrement dit, Istio facilite la gestion de multiples services.

Supposons, par exemple, qu’un service ait plusieurs dépendances. Le service pay_claim d’une compagnie d’assurance appelle le service deductible_amt, qui appelle le service is_member_covered, et ainsi de suite. Une chaîne de dépendances complexe peut comporter 10 ou 12 appels de service. Lorsque l’un de ces derniers échoue, il entraîne une série de défaillances en cascade et des erreurs 500, 400, voire pas de réponse.

Pour déboguer cette série d’appels, vous pouvez utiliser une trace de pile. Sur le front-end, les développeurs côté client peuvent déterminer quels éléments sont extraits des serveurs Web, et dans quel ordre, afin de 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 lesquels répondent plus lentement. Nous verrons plus tard comment Istio fournit des outils pour tracer les appels de fonction dans un diagramme comme celui-ci.

Les équipes DevOps et d’administration informatique veulent pouvoir observer le trafic pour connaître la latence, le temps de service, les erreurs en pourcentage du trafic, etc. Il s’agit souvent d’un tableau de bord. Ce dernier fournit une visualisation de la somme, ou de la moyenne, de ces indicateurs au fil du temps, avec parfois la possibilité de descendre jusqu’à un nœud, service ou pod particulier. Kubernetes ne fournit pas ces fonctions de manière native.

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 ensemble. Par exemple, les services ne pourront ainsi appeler que les services qui sont de véritables dépendances. Une autre politique visant à maintenir les services en état de marche est la limitation du débit, qui empêche le trafic excessif d’engorger les services et prévient les attaques par déni de service.

Par défaut, Kubernetes propose un équilibrage de charge round-robin. Si six pods fournissent un microservice, Kubernetes fournira un équilibreur de charge, c’est-à-dire un service qui envoie des requêtes à chaque pod dans l’ordre croissant, avant de recommencer. Cependant, il arrive que l’entreprise déploie différentes versions du même service en production.

L’exemple le plus simple est celui d’un déploiement bleu ou vert. Dans ce cas, le logiciel peut créer une toute nouvelle version de l’application en production, sans y envoyer les utilisateurs de la production. Après la promotion de cette nouvelle version, l’entreprise peut conserver les anciens serveurs afin de permettre un retour rapide en cas de défaillance.

Avec Istio, il suffit d’utiliser le balisage dans un fichier de configuration. Les administrateurs peuvent également utiliser des balises pour indiquer le type de service à connecter et créer des règles basées sur les en-têtes. Par exemple, les utilisateurs bêta peuvent ainsi accéder à un pod Canary disposant de la version la plus récente et la plus performante, tandis que les autres utilisateurs accèdent à la version de production stable.

Si un service est surchargé ou en panne, davantage de requêtes échouent et continuent à surcharger le système. Parce qu’il suit les erreurs et les retards, Istio peut imposer une pause, après le nombre de requêtes défini par la politique, afin de permettre au service de se rétablir. 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.

Istio fournit l’identité, la politique et le chiffrement par défaut, ainsi que l’authentification, l’autorisation et l’audit (AAA). Tous les pods gérés qui communiquent avec d’autres utilisent un trafic chiffré, empêchant toute observation. Le service d’identité, combiné au chiffrement, permet de s’assurer qu’aucun utilisateur non autorisé ne peut falsifier ni « usurper » un appel de service. AAA fournit aux équipes en charge de la sécurité et des opérations les outils nécessaires pour surveiller, et ce à moindre coût.

Les applications traditionnelles requièrent toujours les fonctionnalités de gestion des identités, de politique et de sécurité qu’offre Istio. Dans ce contexte, les programmeurs et les administrateurs travaillent avec un niveau d’abstraction inadapté, réimplémentant les mêmes règles de sécurité encore et encore pour chaque service. Istio leur propose un niveau approprié qui consiste à définir les politiques du cluster par le biais d’un seul et même panneau de commande.