Infrastructures Kubernetes : Solo.io enrichit le routage des containers
L’éditeur spécialiste du répartiteur de charge Open source Istio décline sa version commerciale en une plateforme complète pour supporter les déploiements les plus complexes.
Du réseau Mesh durci. Solo.io, l’éditeur de Gloo Mesh – une version commerciale du routeur d’APIs Istio – fait évoluer son offre en une plateforme complète, Gloo Platform. À ses fonctions commerciales qui contrôlent le trafic entre modules Open source, l’éditeur en ajoute d’autres qui servent à mieux préparer ces contrôles en amont.
« L’écosystème Kubernetes vous permet de mettre en ligne des applications qui multiplient toutes seules leurs instances selon le trafic. Ce que nous apportons avec Gloo Platform, c’est la possibilité de changer régulièrement toute votre architecture », entonne Brian Gracely, le directeur marketing de Solo.io. LeMagIT l’a rencontré à l’occasion d’un événement IT Press consacré aux startups de la Silicon Valley qui innovent en matière d’infrastructures Kubernetes.
« Nos clients sont par exemple des commerces qui, du jour au lendemain, passent de la vente en boutiques à la livraison chez leurs clients, puis qui ouvrent un drive-in avec des files de voitures à gérer, puis qui décident de créer une nouvelle activité basée sur leurs données utilisateurs. Ces gens ont autant besoin que les autres que leurs applications soient sécurisées. Mais elles changent si souvent qu’il faut les sécuriser à 100 % dès le premier jour de leur mise en production. »
« Notre solution a vocation à rajouter tout ce qu’il faut pour que la croissance de trafic se déroule sans aucune entrave, pour que la circulation des données entre chaque fonction applicative soit sécurisée dès le point de départ », ajoute-t-il.
Gloo Platform comprend un gestionnaire de carte réseau CNI pour Kubernetes (Gloo Network), un moteur Ambient Mesh qui permet à présent au routeur Gloo Mesh de se passer des proxys accolés à chaque container, la couche proxy – quelle que soit sa forme (Gloo Gateway) – avec la capacité de dialoguer en GraphQL (moteur Gloo GraphQL), et une console d’administration pour configurer et monitorer l’ensemble (Gloo Portal).
Réduire les coûts informatiques et la complexité de la maintenance
En réseau traditionnel, un serveur applicatif dispose d’une adresse IP et propose ses services au travers de numéros de port. Dans le monde Kubernetes, les services sont incarnés par des containers et, pour soutenir la charge variable des requêtes, un nombre variable de containers proposent le même service, chacun avec un numéro de port aléatoire (couche TCP, dite L4, dans le modèle OSI).
Chaque service étant surtout interrogeable par une API (couche applicative, dite L7, en l’occurrence tout ce qui a trait aux requêtes HTTP), l’orchestrateur Kubernetes doit disposer d’un routeur qui dresse une cartographie des APIs disponibles parmi ses numéros de ports internes, afin d’assurer la répartition de charges. Cette fonction est souvent assurée par le logiciel Open source Istio. Dans la version commerciale Gloo Mesh, Istio est enrichi par des fonctions d’observabilité qui utilisent le protocole eBPF.
« Comprenez que nous ne sommes pas un éditeur qui se contente de repackager des codes Open source pour en faire des solutions commerciales. Nous sommes les principaux contributeurs de code Open source au projet Istio », précise Brian Gracely.
Pour dire à Istio quelle API il expose, chaque container applicatif s’accompagne d’un container qui n’a qu’une fonction de proxy. Cette fonction de proxy est généralement incarnée par le logiciel Open source Envoy. Le container qui exécute la fonction de proxy est appelé un « side-car » et chaque couple container applicatif + container proxy forme un pod. Initialement, Solo.io proposait Gloo Edge, une version d’Envoy elle aussi enrichie avec des fonctions d’observabilité.
En tant que proxy, le side-car s’occupe de la gestion du protocole HTTP (réponses aux requêtes, quotas, délais, validation des échanges via authentification, cookies et autres métadonnées). De fait, la charge de chaque side-car est susceptible de consommer beaucoup de ressources de calcul, d’autant que les side-cars des pods similaires font tous les mêmes vérifications.
« En pratique, nous dissocions les rouages réseau des applications, ce qui vous permet de remplacer rapidement les applications par d’autres, totalement différente. »
Brian GracelyDirecteur marketing, Solo.io
Pour pallier ce problème, Google et Solo.io ont développé fin 2022 le logiciel Open source Ambiant Mesh qui centralise les fonctions des side-cars au niveau du répartiteur de charge Istio. Outre consommer moins de ressource, Ambiant Mesh présente l’intérêt de pouvoir modifier les règles de routage dans Istio sans redémarrer les pods. En l’occurrence, le pod ne contient plus qu’un embryon de side-car : un container avec un agent ztunnel qui établit une communication via un certificat mTLS avec l’agent ztunnel du routeur Istio.
« Nous réduisons ainsi les coûts de l’informatique, mais aussi la complexité de maintenance de votre cluster. En pratique, nous dissocions les rouages réseau des applications, ce qui vous permet de remplacer rapidement les applications par d’autres, totalement différentes, sans avoir besoin d’y intégrer une ingénierie réseau », poursuit notre interlocuteur.
Des fonctions en plus pour mieux préparer l’infrastructure en amont
Cette construction, plus légère, autorise même le remplacement du protocole RESTful – qui sert à envoyer les ordres aux API au sein des requêtes HTTP – par le langage de requêtes GraphQL, qui réduit lui aussi le trafic dans les échanges de données. L’ensemble Ambiant Mesh et moteur GraphQL est commercialisé par Solo.io sous la forme du module Gloo Gateway.
Chaque cluster de containers est exécuté sur un serveur, lequel communique avec d’autres serveurs exécutant eux aussi un cluster de containers et tout ce monde est conçu pour travailler ensemble, soit essentiellement se répartir la charge des requêtes entrantes. Pour maintenir certaines règles de trafic, de bande passante et de routage entre tous ces serveurs, les cartes réseau de chaque serveur (présentées à Kubernetes sous la forme d’un pilote CNI) sont contrôlées par le logiciel Gloo Network.
L’ensemble des règles et des métriques de chacun de ses composants est enfin pilotable au travers du module graphique Gloo Portal. L’intérêt de Gloo Portal est de pouvoir définir en amont les APIs qui seront disponibles dans le ou les clusters, leur routage au sein d’un nom de domaine et leurs droits d’accès, avec la possibilité de lier les utilisateurs avec un service d’authentification.
« Encore une fois, nous ciblons des déploiements très complexes, où des applicatifs d’inventaires côtoient des applicatifs de recommandation et des applicatifs de fidélisation et où, selon l’usage excessivement variable des clients d’une enseigne, tel applicatif peut se retrouver en un clin d’œil exécuté à la place d’un autre. Sans nos fonctions qui permettent de préparer le terrain en amont, par une équipe sécurité ou DSI plutôt que par les développeurs, ce serait bien trop complexe et lent à gérer », assure Brian Gracely.
Le responsable de Solo.io consent à dire que des offres Kubernetes de premier plan, comme OpenShift de RedHat et Tanzu de VMware, proposent des outils de gestion des APIs en amont. « En revanche, Tanzu n’offre pas de répartition de charge ou de firewall au niveau des APIs. Quant à OpenShift, il met ces fonctions dans NGINX, un produit obsolète conçu pour faire de la répartition de charge entre plusieurs instances d’un site web. Nous sommes les seuls à sécuriser cette répartition au niveau d’Istio », conclut-il.
