Distribution Kubernetes : Rakuten cible les grands déploiements en Edge
L’équipementier japonais a racheté Robin.io, a installé son Kubernetes dans tous les OpenRAN de ses antennes et le décline maintenant comme un système bâti pour les serveurs urbains ou industriels.
Plus que jamais, la volonté de devenir le VMware des serveurs Edge. Depuis qu’il est passé sous le giron de l’équipementier japonais Rakuten, l’éditeur Robin.io entretemps rebaptisé Rakuten Symphony, peut se targuer d’avoir déployé son système Kubernetes sur plus de 50 000 serveurs ; dont une majorité est des équipements OpenRAN que Rakuten a installés au pied des antennes 5G japonaises. Un coup manqué pour cette startup qui rêvait d’exécuter sur les sites de production des applications en containers au même titre que VMware le fait avec des machines virtuelles dans les datacenters ? Pas vraiment.
De cette expérience, l’éditeur en a tiré des améliorations qui feraient aujourd’hui de son produit la variante de Kubernetes la plus adaptée aux très grands déploiements. C’est-à-dire la mieux conçue pour motoriser les milliers – ou dizaines de milliers – de petits serveurs « Edge » que les industriels internationaux et les villes intelligentes ont vocation à déployer sur leurs sites.
C’est-à-dire là, pour piloter des machines-outils aux quatre coins du monde. Là, pour gérer les équipements urbains qui font la signalisation, l’éclairage ou le chauffage. Ou encore, forcément, là, pour les futurs OpenRAN que les opérateurs télécoms ont du mal à déployer en remplacement des équipements Nokia, Ericsson ou Samsung qui leur coûtent trop cher. Un marché international que la maison-mère Rakuten convoite.
Abstraire le matériel tout en permettant une exploitation à 100 %
« Notre force par rapport aux distributions Kubernetes que vous connaissez, OpenShift de Red Hat et Tanzu de VMware, est que notre système a été conçu très tôt pour les très grands déploiements », explique Partha Seetala, le président de Rakuten Symphony. LeMagIT l’a rencontré à l’occasion d’un événement IT Press Tour organisé fin janvier et consacré aux entreprises de la Silicon Valley qui innovent en matière d’infrastructures Kubernetes.
« L’approche de nos concurrents est de gérer la fluidité des instances applicatives sur un cluster matériellement uniforme, avec un type de processeur, de GPU, de stockage, de carte réseau. La nôtre est d’exposer de manière universelle des matériels complètement différents pour que les applications puissent malgré tout en tirer le maximum de performances, comme si elles avaient été écrites exprès pour eux », argumente-t-il.
« Prenons par exemple un cas d’usage dans les télécoms : un OpenRAN doit valider une communication en moins de 40 microsecondes. C’est tout simplement impossible à faire si votre code logiciel ne prend pas en compte le type de réseau et le type d’accélérateur FPGA que vous avez dans votre équipement. Sauf que, sur votre parc d’antennes, vous allez avoir 800 variantes matérielles. Qu’est-ce que vous faites ? Vous écrivez et mettez régulièrement à jour 800 versions de votre code ? C’est ce que vous devriez faire avec nos concurrents. Nous, nous exposons de manière universelle les capacités du matériel sous-jacent. »
L’offre logicielle de Rakuten Symphony se décline aujourd’hui en trois produits. Symworld CNP (Cloud Native Platform) est le système Kubernetes historique de Robin.io. Symworld Orchestrator est la console d’administration des serveurs Edge à distance ; une sorte de vCenter (la console de VMware), mais capable de gérer plus de 100 000 machines physiques et plus de 10 000 clusters.
Enfin, Symworld CNS (Cloud Native Storage) correspond uniquement à la couche stockage de CNP, qui est dès lors installable par-dessus n’importe quel autre Kubernetes, sous-entendu OpenShift. Selon l’éditeur, le système de stockage Ceph que Red Hat fournit pour Kubernetes ne serait pas totalement adapté aux déploiements en Edge.
CNS, pour aller au-delà des pilotes CSI
« Concernant le stockage, nous enrichissons Kubernetes avec des fonctions de très haut niveau, similaires à celles que vous trouvez sur les baies de stockage pour les machines virtuelles. En Edge, vous allez ainsi typiquement déployer des applications qui ont besoin d’une base de données MongoDB pour enregistrer leurs relevés ou diffuser des informations. La première chose est d’enrichir Kubernetes avec du stockage persistant. C’est ce que font les fournisseurs de baies de disques avec un pilote CSI. Mais il faut aller au-delà », assure Partha Seetala.
« Notre système […] fait des snapshots locaux, des sauvegardes ailleurs, mais aussi propose un système complet pour restaurer l’activité en cas d’incidents. ».
Partha SeetalaPrésident de Rakuten Symphony
Il vante les caractéristiques de la couche de stockage : elle gère à la volée la bande passante entre différents containers, le tiering éventuel (répartition des données sur différents disques selon leur nature), le chiffrement, la compression. « Surtout, notre système protège ces données : il fait des snapshots locaux, des sauvegardes ailleurs, mais aussi propose un système complet pour restaurer l’activité en cas d’incidents, y compris via un dispositif de synchronisation des contenus entre serveurs ou entre clusters ».
Et tout cela en prenant toujours en compte les caractéristiques, les bandes passantes, les IOPS et les capacités des disques de chaque serveur, assure-t-il.
À propos de la sauvegarde et des snapshots, il précise qu’il ne suffit pas de mettre sur disque une copie de secours des données MongoDB. Pour restaurer une instance fonctionnelle, il faut aussi capturer les transactions en cours, la configuration de l’application (notamment les pipelines entre les différents microservices) et ses métadonnées.
CNP, le produit phare
La couche de stockage fonctionne de pair avec un pilote CSI, fourni soit par CNP pour les disques internes, soit par le fabricant d’une baie de disques. De même CNP n’est pas autonome. Il s’installe par-dessus un Linux tiers ; Rakuten Symphony évoque CentOS et RHEL de Red Hat, sans que l’on soit certain s’il s’agit d’une nécessité technique ou juste d’une pique supplémentaire à l’encontre d’OpenShift, que Red Hat installe au-dessus de ses Linux.
L’intérêt principal de CNP repose sur un module appelé Sherlock qui diagnostique le matériel hôte – Rakuten Symphony explique travailler avec les principaux fournisseurs de puces et de serveurs – et produit, dans son propre langage, un pool de capacités. Ces capacités comprennent les performances du processeur et autres puces accélératrices, du réseau et du stockage.
Ce pool de capacités est exposé à Kubernetes, via un module Advanced Scheduler qui doit permettre à l’orchestrateur de dispatcher les ressources selon les besoins des applications. Pour tirer un parti maximal de ce pool de ressources, les applications peuvent être packagées en amont par un outil graphique qui va de pair avec L’Advanced Scheduler et qui sert à préciser les besoins spécifiques des applications : bande passante réseau, puissance CPU ou GPU, etc.
Précisons que l’ensemble Sherlock+Advanced Scheduler fait aussi partie du produit CNS, en étant toutefois limité à la découverte et au partage des ressources de stockage.
Il est notable qu’Advanced Scheduler fonctionne tout autant pour distribuer des ressources à d’éventuelles machines virtuelles. « Nous savons pertinemment que les containers ne remplaceront pas 100 % des machines virtuelles. Donc si votre serveur Edge exécute des VMs depuis l’hyperviseur KVM du Linux hôte, elles seront traitées par CNP comme des containers », indique Partha Seetala.
Précisons que la couche réseau est Calico, le système Open source déjà utilisé par OpenShift. Il ne s’agit pas du réseau mesh qui permet aux applications en containers de s’envoyer des messages, mais bien d’un réseau TCP/IP qui offre des fonctions de firewall et de carte réseau virtuelle par container.
Une console graphique pour superviser et monitorer à distance
Symworld Orchestrator, enfin, apporte les fonctions de déploiement, mises à jour et monitoring à distance que l’on retrouve sur les consoles de gestion des plateformes de virtualisation comme VMware ou Nutanix.
Il gère sa flotte de machines par arborescence fonctionnelle ou géographique, à la souris ou via automatiquement via des règles à personnaliser soi-même. Il permet d’exécuter des scénarios de déploiements qui consistent par exemple à mettre à jour des serveurs de contrôle dans des datacenters de proximité, puis, un à un, les serveurs sur sites qui en dépendent.
C’est aussi depuis Symworld Orchestrator que l’on pilote toutes les opérations liées au stockage et à la protection des données. Toutefois, CNS est lui-même livré avec une version réduite de cette console, afin de définir toutes les règles liées aux sauvegardes et à la récupération d’activité.
Pour approfondir sur Mini serveurs, Edge Computing
