Comment Uber a migré d'Apache Mesos vers Kubernetes

En 2023, Uber a signé deux contrats de 7 ans avec Oracle et Google pour basculer entièrement vers une infrastructure cloud alors que 95 % de ses infrastructures étaient jusqu'alors on premise. Deux ans plus tard, le spécialiste du transport compte plus de 50 clusters de calcul dans plusieurs régions/zones mondiales, répartis à la fois dans ses centres de données sur site que chez ses deux partenaires cloud. "Chaque cluster compte environ 5 000 à 7 500 hôtes, environ 250 000 cœurs et environ 50 000 pods. Ils alimentent les 4 000 services d'Uber qui utilisent environ 3 millions de cœurs", explique la société dans un bilet de blog. "Ces services sont déployés 100 000 fois par jour, ce qui se traduit par 1,5 million de lancements de pods par jour au rythme de 120-130 pods/seconde dans un seul cluster." Depuis plus de trois ans, la plateforme d'orchestration de containers était basée sur Mesos. À l'origine développé par l'Université de Berkeley (Californie) ce logiciel open source, qui vient se placer entre la couche applicative et le système d'exploitation, facilite le déploiement et la gestion des applications dans les environnements mettant en oeuvre des clusters de grosse capacité. Mais la firme de San Francisco s'est lancée dans un projet de migration vers Kubernetes pour répondre à plusieurs besoins.

"La principale motivation était que Mesos a été déprécié chez Uber en 2021, et que peu de modifications ont été apportées à la base de code depuis. C'était un défi car nous ne recevions pas de corrections de bogues ou de nouvelles fonctionnalités de la part de la communauté", poursuit Uber. A ses yeux, Kubernetes présentait aussi d'autres atouts : outre une communauté active et des mises à jour de correctifs en continu, également un riche écosystème d'opérateurs (operators) pour rationaliser le développement et réduire les redondances. Pour rappel, les operators sont des contrôleurs spécifiques à des applications pour étendre les fonctionnalités de l'API K8s pour créer, configurer et gérer des instances d'applications complexes. "Ces avantages font de Kubernetes un choix sûr et compatible avec l'avenir, garantissant que l'infrastructure d'Uber reste résiliente et adaptable aux futures avancées technologiques. Mais le passage d'Uber de Mesos à Kubernetes a posé d'importants défis en termes d'échelle, de fiabilité et d'intégration", raconte le spécialiste en VTC.

Relever le défi d'un fonctionnement à l'échelle

Trois grands principes ont été établis pour cette migration : des mises à niveau transparentes (pour exécuter les mêmes versions de Kubernetes que les fournisseurs de cloud en s'appuyant sur l'extensibilité native de Kubernetes pour toute personnalisation), des mises à niveau fiables (mise en place des systèmes de validation de versions étendus et tests d'intégration et de performance), ainsi que des migrations automatisées. "Le processus de migration doit être invisible pour les développeurs, ne nécessitant aucun effort ou changement dans leur flux de travail. Il doit s'agir d'un effort centralisé dont la complexité n'est pas répercutée sur l'utilisateur final. Les développeurs ne devraient même pas savoir que leur service s'exécute sur un cluster Mesos ou Kubernetes, et un service devrait coexister en toute sécurité dans les deux clusters", indique Uber.

Les défis relevés ont été nombreux, à commencer par la nécessité d'un fonctionnement à l'échelle, car Uber opère des grands clusters de 5 000 à 7 500 noeuds. "L'exploitation de grands clusters sur Kubernetes a posé des problèmes de gestion de la charge du serveur API pour éviter les goulots d'étranglement, en s'assurant que le planificateur peut gérer l'échelle même avec un taux élevé de renouvellement des pods, et en traitant les problèmes de fragmentation qui surviennent lors de l'exécution de grands clusters avec des charges de travail variées", a fait savoir Uber dans son billet de blog. "Nous avons créé une suite d'analyse comparative de pointe pour Kubernetes chez Uber et nous avons pu évaluer nos clusters à 7 500 nœuds, 200 000 pods et 150 pods planifiés par seconde. Nous avons dû procéder à certaines optimisations et régler certains paramètres pour atteindre ces chiffres. Nous avons réglé les paramètres QPS et la parallélisation dans le gestionnaire de contrôleur et le planificateur pour gérer les charges élevées. Nous avons utilisé la priorité et l'équité de l'API pour limiter les appels d'API coûteux comme list et get. Nous sommes passés de l'encodage JSON à l'encodage Proto pour de meilleures performances. Enfin, nous avons modifié le plug-in du planificateur de répartition de la topologie des pods pour un traitement plus rapide."

La migration d'Apache Mesos vers Kubernetes affecte de nombreux composants de l'environnement applicatif de développement d'Uber (crédit : Uber)

Autre défi de taille à affronter : l'intégration avec l'écosystème de composants de la plateforme de développement Uber pour garantir une expérience cohérente aux développeurs. "Ces intégrations comprenaient nos systèmes CI/CD, la découverte de services, la sécurité, le cycle de vie des hôtes et les piles d'observabilité. Mesos et Kubernetes étant fondamentalement différents dans leur architecture, nous avons dû tout reconstruire à partir de zéro", indique le spécialiste VTC. Pour automatiser les mécanismes de migration de plus de 3 millions de cœurs, la société s'est appuyée sur sa couche de fédération globale stateless, Up. Un autre enjeu a été de garantir la parité des fonctionnalités entre Mesos et Kubernetes pour faciliter une migration sans heurts auprès des utilisateurs pour apporter une expérience semblable en matière de développement, de sécurité, de déploiement et de rapidité opérationnelle.

Des personnalisations spécifiques nécessaires

Dans le cadre de sa migration, Uber a cependant dû concevoir et adopter des composants personnalisés dans son environnement Kubernetes. "Sur Mesos, les développeurs pouvaient accéder aux artefacts [ressources mises à jour dans le cadre de processus de déploiement et de livraison de conteneur, ndlr] des vidages de noyau, des profils de tas et les journaux, même après la sortie de leur conteneur. Cette fonctionnalité aidait les développeurs à déboguer les crashs de leurs conteneurs, les sorties de mémoire, et plus encore. Ces artefacts étaient écrits sur des volumes locaux et exposés à l'interface utilisateur Up via un point de terminaison Mesos. Dans Kubernetes, cependant, les volumes locaux sont nettoyés par défaut lors de la suppression des pods. L'interface utilisateur de Kubernetes ne donne pas de visibilité sur les artefacts des conteneurs. Pour y remédier, nous avons introduit un conteneur sidecar [conteneur secondaire s'exécutant en même temps que le conteneur d'application principal au sein du même Pod, ndlr] et un daemon qui télécharge les artefacts dans un blob store à la sortie du conteneur", précise Uber.

Un contrôleur personnalisé a aussi été conçu pour gérer le rythme des mises à jour des opérations de mise à l'échelle, tout comme un daemon de préemption d'images pour améliorer la vitesse de déploiement des plus grands containers. "L'interface native de Kubernetes ne fonctionnait pas bien à l'échelle d'Uber. Elle se bloquait ou ne répondait plus lorsque nous la dirigions vers un grand cluster. Nous avons optimisé l'interface Kubernetes pour améliorer les performances et la convivialité. Nos améliorations [dont la mise en cache à plusieurs endroits dans le code ] garantissent que l'interface utilisateur reste réactive et fonctionnelle même avec des clusters de grande taille", fait savoir la société dans son billet de blog.

Un long fleuve pas si tranquille

Au cours de sa migration, Uber a découvert des comportements inattendus du système et dénombré certaines "bizarreries". En particulier une lacune dans les outils de surveillance holistique pour les grands clusters Kubernetes, un processus de réconciliation des informers [un composant côté client dans Kubernetes qui surveille les changements apportés aux ressources au sein de votre cluster, ndlr] Kubernetes pas adapté. Pour pallier ce souci, un mécanisme personnalisé forçant la réconciliation des objets de haut niveau toutes les 15 minutes pour garantir un temps de traitement adéquat des événements de déploiement a été mis en place. Et une méthode plus fiable pour détecter et annuler les mauvais déploiements a aussi été implémentée comme l'explique Uber : "Certains services avaient également des contrôles de santé désactivés, ce qui faisait que les pods semblaient prêts alors qu'ils étaient en train de se bloquer, et que de longs délais initiaux des contrôles de santé conduisaient à des indicateurs de progrès trompeurs. Pour résoudre ce problème, nous avons mis en place une heuristique basée sur les redémarrages de conteneurs. Par exemple, si plus de 10 % des pods redémarrent 5 fois ou plus au cours d'un déploiement, nous signalons à Up de déclencher automatiquement un retour en arrière."

Depuis juillet 2024, la migration des services partagés stateless vers Kubernetes a été achevée, non sans avoir rencontré parfois quelques surprises. "Nous avons identifié et corrigé plusieurs problèmes de fiabilité qui sont apparus au fur et à mesure que nous faisions évoluer nos clusters Kubernetes. Par exemple, nous avons découvert des cas limites dans nos contrôleurs et opérateurs personnalisés qui nécessitaient un réglage fin pour garantir des performances et une stabilité constantes. En réglant ces problèmes rapidement, nous avons évité des perturbations potentielles et garanti une expérience fluide pour les développeurs", explique Uber. Pour les prochains mois, le groupe compte aussi faire converger toutes ses technologies de gestion de clusters sur Kubernetes, notamment Apache Hadoop YARN pour les charges de travail par lots et Odin pour les workloads stateful pour simplifier les opérations et améliore l'efficacité opérationnelle.