KubeCon : les fournisseurs se mobilisent pour améliorer le réseau
Kubernetes a un défaut : il est mauvais dans le routage du trafic. Cisco, Microsoft, Google, Arista Networks, mais aussi l’étoile montante française Containous proposent d’y remédier.
Kubernetes a besoin que sa couche réseau soit renforcée. Et ceux qui vont s’en charger sont Cisco, Microsoft, Google, Arista Networks, ainsi que… Containous, une startup française dont les logiciels viennent de dépasser le milliard de téléchargements sur le site DockerHub.
Lors de l’édition américaine de KubeCon, qui se tient cette semaine à San Diego, chacun d’entre eux a proposé des axes d’amélioration dans le routage, l’adressage et la supervision. L’objectif ? Que les flux de données soient enfin encadrés par des fonctions aussi complètes que celles des machines virtuelles, la technologie d’infrastructure à laquelle les containers sont censés succéder.
« La communauté a fait un travail fantastique pour doter Kubernetes d’une infrastructure réseau excessivement simple, immédiatement utilisable à l’installation. Néanmoins, elle ne permet plus d’utiliser les concepts de l’infrastructure classique. Dès lors, comment créer un tunnel sécurisé entre une application et sa base de données ? Comment réguler le trafic ? Comment savoir s’il est optimal quand des adresses IP ne cessent d’apparaître et de disparaître ? », a ainsi interrogé sur scène Vijoy Pandey. Il est à la fois directeur technique chez Cisco et membre du directoire de la CNCF, la fondation qui fédère l’écosystème Open source autour de Kubernetes.
De base, les possibilités autour du réseau dans Kubernetes se limitent au strict minimum : si chaque pod – la capsule qui entoure un container – obtient bien une adresse IP lorsqu’il est mis en route, tous communiquent entre eux par leur nom de domaine, stocké dans le DNS que maintient Kubernetes. La vocation d’un cluster de containers étant d’activer ou d’éteindre des instances applicatives selon la quantité de requêtes, Kubernetes répartit les charges de travail en dirigeant les paquets à tour de rôle vers chacun des pods identiques, par défaut dans l’ordre de leur apparition dans le DNS.
Cette fonction de répartition de charge est assurée par un moteur qui se greffe sur la carte réseau virtuelle, la CNI, que Kubernetes ajoute à chacun des serveurs qui exécutent les pods, que ces serveurs soient des nœuds physiques ou des VMs. L’enjeu pour les acteurs du réseau est de proposer un service qui communique avec cette CNI, voire la pilote. Plusieurs acteurs, dont VMware avec NSX-T, proposent leur propre CNI. D’autres optent plutôt pour l’installation dans le cluster d’un serveur virtuel de fonctions réseau, qui communique généralement avec la plus en vogue des CNI Open source : Calico.
Containous Maesh pour apporter du routage applicatif contrôlable
Containous a profité du salon KubeCon de San Diego pour lancer Maesh 1.0. Il s’agit d’un répartiteur de charge applicatif qui agit en temps réel sur le DNS maintenu par Kubernetes pour orienter de manière plus intelligente le trafic entre les pods.
« Une fonction intéressante est par exemple celle dite de Canary Release : lorsqu’un serveur envoie une mise à jour de données à tous les containers, Maesh prend le contrôle pour échelonner cette mise à jour. On peut le régler pour qu’il envoie, mettons, des portions successives de 5 % de ce trafic, de sorte à éviter d’engorger tout le réseau. Sans Maesh, les applications risquent momentanément de ne plus répondre aux utilisateurs », explique au MagIT Emile Vauge, le PDG de Containous.
Maesh présente par ailleurs l’intérêt de se connecter à des outils tiers : Let’s Encrypt pour autoriser simplement les flux chiffrés par TLS entre deux Pods, mais aussi Datadog pour remonter des métriques sur l’activité, ou encore Jaeger pour déboguer les applications.
Le Français Containous doit sa célébrité dans l’écosystème Kubernetes à son logiciel Traefik. Il s’agissait déjà d’un répartiteur de charge applicatif, mais qui fonctionne entre les requêtes venues d’Internet et les pods applicatifs orchestrés par Kubernetes. L’intérêt de Traefik, surtout, est d’être bien plus économe en ressources que ne l’est Nginx, l’outil par défaut. Et bien plus fonctionnel aussi, grâce, là encore, à des connecteurs vers des outils tiers.
« Nos outils ont du succès, car ils ont été conçus pour Kubernetes, alors que ceux proposés par défaut sont des logiciels plus anciens qui ont été écrits pour des infrastructures très différentes. Traefik fait partie aujourd’hui des 10 logiciels Open source les plus téléchargés. Nous commercialisons une version Entreprise qui permet de l’utiliser en cluster. Nos clients sont autant américains qu’européens », se réjouit Emile Vauge.
Techniquement, Traefik n’entre pas dans la catégorie des serveurs sur le réseau interne, mais dans celle des Ingress Controller, comprendre les extensions de Kubernetes qui font le pont avec le trafic extérieur.
CloudEOS pour un SDN complet et véritablement adapté à Kubernetes
Arista Networks a de son côté dévoilé CloudEOS Cloud Native, la dernière implémentation de son SDN, cette fois-ci plus particulièrement adaptée à Kubernetes.
« Contrairement à d’autres SDN […] notre solution en version Cloud Native s’interface avec la CNI Open source Calico […] »
Joe HielscherDirecteur Produits et Technologies Cloud, Arista
« CloudEOS apporte des fonctions de routage, de firewall, de chiffrement des flux et de monitoring. Mais contrairement à d’autres SDN qui ne fonctionnent que dans le cadre d’une suite propriétaire [NSX, N.D.R.], notre solution en version Cloud Native s’interface avec la CNI Open source Calico et se déploie en pod comme le reste des applications dans les distributions Kubernetes, c’est-à-dire avec des outils comme Terraform, Ansible ou Puppet pour lesquels nous fournissons des plug-ins », explique au MagIT Joe Hielscher, directeur Produits et Technologies Cloud chez Arista Networks.
« Plus concrètement, cela signifie que les métiers et les développeurs peuvent désormais déployer des réseaux sécurisés pour leurs applications à la demande, sans avoir besoin de solliciter les gens de la DSI », ajoute-t-il. Et de préciser que, selon lui, le problème fondamental de Kubernetes reste que la simplicité de déploiement d’infrastructures virtuelles par les développeurs est proportionnelle à la complexité qu’ont d’ordinaire les informaticiens et les ingénieurs réseau à préparer en amont ces infrastructures.
« Nous épargnons donc aux ingénieurs réseau les tâches les plus pénibles, sans pour autant faire abstraction de leur importance. Notre solution est pilotée depuis une console graphique Cloud Vision dans laquelle ils définissent les règles de routage et de sécurité, mais supervisent aussi l’état du réseau. »
« Cette fonction de supervision est particulièrement importante dans le cadre de Kubernetes où les adresses IP ne cessent d’apparaître et de disparaître, si bien qu’il est très difficile sur cette plateforme de se figurer si des problèmes existent dans le temps. Pour adresser ce problème, Cloud Vision conserve en mémoire l’évolution des flux applicatifs qu’ils capturent au niveau de la CNI Calico, afin de comprendre les événements liés au trafic des applications, sans tenir compte des faux-positifs du réseau. »
CloudEOS Cloud Native reprend les fonctions de CloudEOS Multi-Cloud, un SDN orienté cloud hybride qui permet à des machines virtuelles sur site et en ligne – chez AWS, Azure ou GCP – de fonctionner ensemble sur le même réseau privé, voire réplique les topologies de part et d’autre afin d’assurer un plan de reprise d’activité. CloudEOS Multi-Cloud descend lui-même d’EOS, le système d’exploitation des switches physiques d’Arista Networks, qui route le trafic de manière la plus optimale possible selon des règles établies par les ingénieurs réseau, chiffre des communications avec des clés IPSEC et fait de la télémétrie.
Pour l’heure, s’il existe bien une machine virtuelle CloudEOS dans la market-place d’AWS et d’Azure (une offre sur Google Cloud Platform devrait arriver sous peu), le système ne permet pas encore d’utiliser directement leurs services Kubernetes, respectivement EKS, AKS et, pour Google, GKE. À terme, la console Cloud Vision pourrait aussi être disponible au format SaaS.
Vers une gestion du trafic au niveau IP pour même servir les telcos
Pour leur part, Cisco, Microsoft et Google prennent à bras le corps des problématiques situées plus bas dans les couches d’infrastructure. Si bas qu’ils adressent d’ailleurs ouvertement les besoins des opérateurs télécoms, un domaine dont s’est emparée la fondation OpenStack et qui, à bien des égards, fait figure de rivale de la CNCF dans le monde Open source.
Cisco chapeaute désormais le projet NSM, ou Network Service Mesh. Il s’agit là aussi d’un serveur qui prend le contrôle des flux réseau, mais il le fait au niveau des paquets IP.
« La fonction première de NSM sera de créer des tunnels privés entre deux pods, ou entre un pod et un serveur externe au cluster Kubernetes, par exemple pour sécuriser les communications entre une base de données et son serveur de stockage. Mais NSM permet d’aller encore plus loin. Il permet d’optimiser le trafic pour des protocoles qui n’ont rien à voir avec du HTTP ; il devient ainsi possible à des telcos, par exemple d’utiliser des containers pour piloter des équipements », explique, sur un stand, Ed Warnicke, ingénieur chez Cisco.
NSM doit à terme servir d’infrastructure pour toutes les VNF (Virtualized Network Functions), à savoir les machines virtuelles qui embarquent des fonctions d’équipement réseau. Il doit aussi permettre à des pods de prendre des rôles de passerelle en accédant à deux cartes réseau virtuelles. Ce domaine, le multiplexage de cartes CNI, est pour l’heure celui du Network Plumbing Working Group, une équipe de développement sous la tutelle de la CNCF qui encadre tant bien que mal des projets qui partent un peu dans tous les sens : Multus-CNI d’Intel, DANM de Nokia, Knitter de ZTE, l’indépendant CNI-Genie…
Microsoft et Cisco mènent de leur côté un nouveau projet intitulé Dual-Stack. Celui-ci a pour objectif d’apporter aux containers la faculté de communiquer simultanément avec des adresses IPv4 et IPv6 ; ils ne savent le faire pour l’heure que d’une façon à la fois. L’enjeu de ce projet est de résoudre le problème des éditeurs de sites et services web qui, quitte à choisir, optent pour IPv4 alors qu’il y aura une pénurie totale d’adresses à ce format d’ici à quelques semaines.
Durant l’événement KubeCon de San Diego, Heather Kirksey, qui fait partie du directoire de l’OPNFV (Open Platform for Network Functions Virtualization), un autre groupe Open source, mais d’ordinaire plus proche d’OpenStack, est montée sur scène accompagnée de représentants de China Mobile pour donner une illustration des projets de Cisco, Microsoft et Google. L’OPNFV chapeaute désormais un projet, E2E 5G (end-to-end 5G), qui consiste à proposer aux opérateurs télécoms une infrastructure 5G entièrement basée sur Kubernetes.
« L’idée consiste à relier des antennes 5G à un cluster Kubernetes dans lequel des VNF sous forme de pods traitent les communications des terminaux, les envoient dans le service cloud de l’opérateur qui les redirige vers un autre cluster Kubernetes aux pieds des antennes proches des destinataires. L’opérateur dispose ainsi d’une infrastructure très simple, peu chère, à partir de laquelle il peut régler ses qualités de service », ont-ils expliqué, avec l’exemple d’une console de supervision très graphique.
