Gorodenkoff/stock.adobe.com
Comment Ubisoft a modernisé son infrastructure Kubernetes
Utilisateur de Kubernetes depuis 10 ans, Ubi Soft a souhaité moderniser cette infrastructure pour à la fois pouvoir monter en version, aller vers une infrastructure multicloud et mieux maîtriser les coûts. L’équipe y est parvenue grâce à la solution Open source Capsule.
Une architecture Kubernetes titanesque qu’il a fallu revoir. Derrière sa grosse trentaine de régions Cloud en production, l’éditeur de jeux vidéo Ubisoft a déployé 430 clusters Kubernetes chez Azure, chez AWS et sur le cloud interne OpenStack. Ceux-ci exécutent plusieurs dizaines de milliers de pods applicatifs pour le service informatique, pour l’entité Online Services qui supporte l’infrastructure des jeux en ligne et pour sa division TG (Technology Group) qui offre des services destinés aux développeurs de jeux.
Ubisoft exploite Kubernetes depuis sa version 1.0, parue il y a une dizaine d’années, afin d’aider les développeurs à déployer leurs codes au format container chez l’un ou l’autre des fournisseurs de cloud public. Dans un second temps, en 2019, l’éditeur a déployé Kubernetes sur son cloud interne OpenStack, à l’aide du logiciel Rancher. À cette époque, TG a proposé à ses collaborateurs une offre packagée de type Namespace-as-a-Service baptisée Runway, basée sur un cluster maison dit UKS (pour Ubisoft Kubernetes Services). Une couche d’abstraction lui a ensuite été ajoutée pour que Runway puisse s’exécuter chez plusieurs fournisseurs de cloud public.
La répartition des ressources entre les équipes et les clouds était alors toujours gérée par Rancher.
Cette architecture héberge environ 200 projets, 700 namespaces, et de l’ordre de 10 000 pods applicatifs déployés par les utilisateurs. Corentin Closs, Senior Cloud Administrator chez Ubisoft détaille ces traitements : « Runway est principalement utilisée pour nos outils internes : analyse des logs liés aux crash des jeux en développement, IA, etc. »
Problème, cette infrastructure repose sur une ancienne version de Kubernetes pour conserver la compatibilité avec la version Rancher mise en œuvre. « De fait, toute montée de version sur notre pile d’outils d’Ingress ou d’observabilité était bloquée. C’est pour cette raison que nous avons décidé de repartir d’une feuille blanche. »
Objectif : privilégier les clusters partagés
L’idée est alors de privilégier les clusters partagés plutôt que de devoir gérer énormément de clusters dédiés qui consomment beaucoup de ressources. Vincent Behar, Software Engineer chez Ubisoft, détaille les atouts de cette approche :
« Créer un Namespace est beaucoup plus rapide que de provisionner un cluster complet, notamment chez certains fournisseurs Cloud. Néanmoins, cela vient ajouter beaucoup de contraintes aux utilisateurs. Cela les empêche de recourir aux CRD (Custom Resource Definition) pour étendre l’API Kubernetes et installer les opérateurs qu’ils souhaitent. Notre volonté était de profiter des atouts du cluster partagé, mais sans ses contraintes. »
Pour atteindre cet objectif, un modèle en plusieurs tiers a été mis en place, afin de répondre au plus près aux usages les plus courants : les clusters dédiés restent réservés à quelques utilisateurs, notamment ceux responsables du SRE (Site Reliability Engineering, le service qui s’assure qu’un service en ligne reste disponible), tandis qu’un cluster global partagé baptisé Runway compte de nombreux utilisateurs qui peuvent déployer des packages d’applications bien définis, mais ne peuvent pas installer d’opérateurs.
« L’avantage de l’approche partagée est que cela ne coûte pas cher, mais ses possibilités sont limitées. Face à cela, nous avons souhaité mettre en place un entre-deux à l’échelle des départements. Dans les Department Shared clusters, les SRE peuvent déployer des opérateurs pour leurs équipes et gérer le cluster. Celui-ci comptera moins d’utilisateurs, mais avec plus de possibilités de déploiement et un coût modéré », dit Corentin Closs.
De fait, il y a désormais trois types d’utilisateurs Kubernetes chez Ubisoft : les Fleet Operators qui sont administrateurs de l’ensemble de l’infrastructure Kubernetes, les Cluster Owners qui peuvent demander la création et la configuration de clusters via l’envoi de commandes à l’API, et, enfin, les utilisateurs qui déploient leurs applications sur les clusters.
Corentin Closs milite pour que les frontières entre chaque type d'utilisateur soient le plus claires possible : « Les administrateurs disposent de tous les droits sur les clusters. Pour leur part, les SRE doivent pouvoir installer des opérateurs pour leurs équipes, gérer les permissions et répondre à des demandes pour mettre du logging, du monitoring, toutes ces choses-là. Et enfin, l'utilisateur doit juste pouvoir déployer ses applications. Il n’a pas à se soucier de la manière dont le cluster fonctionne. Il n'a pas non plus forcément besoin d'avoir les droits qui y sont associés, pour éviter de nombreuses erreurs. »
La simplicité de Capsule séduit l’équipe projet
Pour implémenter cette architecture de type multitenant (coexistence de plusieurs configurations avec leurs propres utilisateurs) dans son infrastructure, l’équipe a confronté quatre solutions : une distribution de Kubernetes native, KCP, vCluster et Capsule.
Corentin Closs explique le rôle de ce dernier : « Capsule est un opérateur Kubernetes Open source que l’on installe sur le cluster et qui va prendre en charge l’aspect multitenant. Le code est assez simple à lire, la solution est assez facile à prendre en main et les API sont suffisamment stables pour pouvoir développer par-dessus. La communauté est plutôt réactive, avec des mainteneurs qui sont facilement joignables. »
Pour Ubisoft, Capsule proxy est une fonction clé de la solution : « Il s’agit d’un reverse proxy que vous avez devant le Kubernetes API Server et qui va permettre à vos utilisateurs d'avoir une expérience comme s'ils étaient sur un cluster qui leur a été dédié », ajoute Corentin Closs.
Les utilisateurs peuvent notamment se servir de leurs outils habituels, comme K9s, Freelens et des addons qui peuvent être déployés sur ces clusters. Ubisoft exploite notamment ArgoCD (une solution de type GitOps) et OpenCost pour gérer la facturation par tenant.
Corentin Closs ajoute : « Dans un tenant, nous voulons avoir la capacité de définir un ensemble de règles, des RBAC (contrôle d'accès basé sur les rôles), des quotas, des Network Policies, etc. Quand les utilisateurs créent un nouveau Namespace dans un tenant, un webhook détecte la requête et nous allons répliquer tous ces réglages en amont automatiquement. »
Ce proxy permet à l’utilisateur d’avoir une vision du cluster comme s’il lui était dédié, alors qu’il s’agit d’un cluster partagé.
L’inconvénient de Capsule est de ne pas permettre la création de tenants en mode libre-service, or l’équipe souhaitait que les utilisateurs, qui ont l'habitude de provisionner un nouveau front office ou un nouveau back office en créant un Namespace, puissent continuer à travailler de la même manière :
« Nous avons appelé cet opérateur un Workspace. Celui-ci permet de configurer Capsule et surtout, de récupérer la liste des membres, gérer les RBAC, les capsules, etc. Le setup normal comprend les opérateurs Capsule, le Capsule proxy, le addon pour Argo, ArgoCD, plus nos opérateurs d’observabilité, des gateways, etc. » précise Corentin Closs.
Enfin, Capsule est interfacé à Rome API, la plateforme interne d’Ubisoft pour ses développeurs, sur laquelle ils gèrent leurs projets, ajoutent et suppriment des utilisateurs, etc.
Une conduite du changement à mener auprès des utilisateurs
Si le design et le développement de cette infrastructure sont aujourd’hui achevés, Corentin Closs et Vincent Behar doivent convaincre les utilisateurs de la plateforme Kubernetes historique de rejoindre cette nouvelle itération :
« La montée de version vers 1.35 va nécessiter un accompagnement de nos utilisateurs dans la migration de leurs ressources, les accompagner dans la mise en place de nouvelles bonnes pratiques. Nous regardons les besoins de chaque équipe, pour nous assurer que chacun va exploiter ces ressources au mieux et éviter qu’un cluster complet soit créé lorsqu’il s’agit de simplement déployer une application web. »
D’autres développements doivent être réalisés afin d’intégrer Capsule à la console pour qu'il soit beaucoup plus simple de déployer de nouveaux Workspaces sur un cluster donné. Sur ce plan, Vincent Behar pointe l’importance de l’expérience utilisateur :
« En 10 ans d’expérience sur Kubernetes, nous avons noté l’importance de l’expérience utilisateur. Nous avions déjà créé d'autres plateformes en mode libre-service pour que les utilisateurs soient autonomes, nous avions créé des API, du Terraform... Mais cela ne marche qu’un temps. Cela ne tient pas la durée. Il faut offrir une bonne expérience, un outil simple et facile à utiliser et, surtout, qui s'intègre bien dans l'écosystème. C'est ce nous essayons de faire là aussi pour que tout soit vraiment intégré », conclut-il.
