Modernisation : Orange préfère exécuter des VM via Kubernetes

L’enjeu : bénéficier de la souplesse des containers

Historiquement, Orange, comme la plupart des télécoms, motorisait ses datacenters opérateur avec le système OpenStack. Né comme une alternative Open source à VMware, OpenStack s’est plus particulièrement imposé chez les télécoms pour virtualiser sur des serveurs génériques des services, en particulier dans la téléphonie mobile, qui étaient auparavant livrés dans des boîtes noires par leurs fournisseurs.

Que ce soit sur VMware comme sur OpenStack, la virtualisation présente le défaut de déployer des applications avec leur système d’exploitation, ce qui oblige les entreprises utilisatrices à des efforts d’administration redondants liés à ces systèmes d’exploitation. Pour chaque nouvelle application déployée, y compris chaque mise à jour, il faut gérer le stockage, la sécurité et l’adressage IP de chaque machine virtuelle. Pire : il faut s’efforcer que les paramètres de l’une n’entrent pas en conflit avec ceux d’une autre.

Les containers, et plus particulièrement leur orchestrateur Kubernetes, ont amplement simplifié le concept. Un container ne contient que le code de l’application qu’il exécute et tous les containers fonctionnent au-dessus d’un système d’exploitation commun. En lieu et place d’adresses IP ou de volumes de stockage, Kubernetes propose aux containers de communiquer entre eux avec uniquement des requêtes sur des URL. Il devient dès lors possible pour les développeurs de mettre eux-mêmes en production des applications, sans passer par les services informatiques.

Et, surtout, il devient très facile d’étendre à l’envi le cluster applicatif : Kubernetes se charge de la cohérence des URL, quel que soit le serveur physique qui exécute à un instant T un container. On parle de scalabilité, ou d’élasticité, à savoir la capacité à augmenter ou réduire en temps réel des copies de containers pour répondre à la demande sans cesse changeante du trafic. Mieux, comme seules certaines fonctions ont parfois besoin de plus de bande passante, il devient possible de fragmenter une application en microservices, chaque microservice ayant ses propres instances de containers.

« Nous parlons en ce qui concerne nos datacenters de POP v2. C’est-à-dire de la faculté de simplifier les opérations pour nos partenaires – c’est par exemple Orange Business qui décide de déployer un SD-WAN pour un client. Partenaires qui pourront proposer plus de services à la carte, du pay-as-you-go. Du point de vue de l’infrastructure, le passage aux containers nous permet aussi de proposer des services qui n’auront que 10 microsecondes de latence », s’enthousiasme Bess Diop.

Pour autant, pas question de ne plus pouvoir exécuter de machines virtuelles. Les éditeurs de services télécoms sont loin d’avoir tous transformé leurs applicatifs au format container. Il faut réécrire tout le code pour qu’il accède à des ressources via des requêtes dans des URL, plus exactement via des APIs, plutôt qu’avec des adresses IP ou des points de montage. Ce n’est pas qu’une question de commandes différentes ; toute la logique est à revoir. On parle d’applicatifs Cloud-Native.

C’est dans ce contexte qu’OINIS lance, dès l’été 2023, un appel d’offres pour moderniser ses infrastructures OpenStack.

L’avantage de Red Hat : mettre des containers et VM au même niveau

Outre la capacité d’exécuter des VM (appelées VNF, pour Virtual Network Functions, dans le jargon des télécoms) et des containers (CNF, Containerized Network Functions, entretemps rebaptisés Cloud-native Networks Functions), OINIS ajoute dans son appel d’offres la faculté de pouvoir réutiliser son équipement existant.

« C’est l’un des objectifs de durabilité que nous nous fixons dans le groupe Orange. Sur 100 serveurs déployés, 15 doivent être du matériel recyclé », précise Bess Diop.

Dix fournisseurs répondent à l’appel d’offres. Quatre correspondent aux critères demandés. Parmi eux, Red Hat a une approche originale. Tous les autres proposent un hyperviseur pour exécuter nativement des machines virtuelles, puis ajoutent dans celles-ci Kubernetes pour orchestrer des containers, lesquels se basent sur l’OS de la machine virtuelle. Red Hat fait plus simple. Il propose OpenShift pour exécuter Kubernetes au plus bas niveau et l’extension OpenShift Virtualization qui permet à Kubernetes d’exécuter des machines virtuelles, comme s’il était lui-même un hyperviseur.

La différence fondamentale est que tous les accès physiques des machines virtuelles sont convertis à la volée par Kubernetes en appel vers des APIs. Cette approche a le mérite de ne pas surcharger l’exploitation informatique : les machines virtuelles sont aussi facilement déployables que des containers.

« Nous nous sommes fixé de tester dans nos propres laboratoires les solutions retenues, à raison de deux semaines de tests intensifs par fournisseur, soit huit semaines en tout. Le bilan est sans appel : la solution de Red Hat nous permet de diviser par quatre les temps de déploiement pour un service », témoigne Bess Diop.

Un autre avantage de Red Hat est l’accompagnement. Et c’est un point qui, de manière surprenante, s’est avéré plus déterminant que prévu :

« Il se trouve que nous utilisions jusqu’à présent une technologie Contrail de l’équipementier Juniper pour relier nos datacenters entre eux. Or, Juniper a arrêté de développer cette fonction BGP (Border Gateway Protocol) justement à ce moment-là. Nous nous sommes donc retrouvés dans la situation de devoir développer nous-mêmes un palliatif », raconte Bess Diop.

« Avec l’aide de Red Hat, cela revenait à développer un pilote CNI (Container Network Interface) pour Kubernetes, », ajoute-t-elle, en précisant qu’il s’agit, selon elle, de l’approche la plus élégante.

Sans surprise, c’est donc avec Red Hat qu’OINIS signe en février 2024.

« Depuis, nous testons et testons encore l’automatisation, les performances obtenues et la solidité de l’isolation, selon différents scénarios. Le premier bilan positif est que la nouvelle architecture nous permet de réduire par deux le nombre de serveurs pour le contrôle du réseau, c’est donc un avantage très significatif dans notre quête d’économie de CO2 », dit Bess Diop.

« Nous déploierons les premiers POP v2 en novembre, dans de nouveaux datacenters, sur de nouvelles régions, pour OBS. Nous continuerons cela tout au long de 2025. Nous travaillerons à la migration des anciens POP vers une architecture POP v2 à partir de 2026 », conclut-elle.