L'équipe technologique du constructeur automobile allemand Mercedes-Benz a passé les sept dernières années à constituer une flotte de 900 clusters Kubernetes pour soutenir des centaines d'équipes de développeurs autonomes, offrant ainsi à l'entreprise une plateforme d'infrastructure moderne, évolutive et facile à gérer. C’est en 2015 que le constructeur automobile a commencé à utiliser Kubernetes pour le déploiement d'applications, soit un an après la livraison en open source du système d'orchestration de conteneurs par Google.

Depuis, Mercedes-Benz Tech Innovation, la filiale technologique du constructeur automobile, a développé une expertise interne pour soutenir des centaines d'équipes d'application alignées sur les unités métiers, avec leurs propres besoins technologiques. « Nous savions qu'un cluster Kubernetes unique et partagé ne répondrait pas à nos besoins, qu'aucune distribution de fournisseur ne répondait à nos exigences et que nous avions les ingénieurs compétents », a déclaré Jens Erat, ingénieur devops chez Mercedes-Benz Tech Innovation lors de la KubeCon Europe 2022 qui a eu lieu du 16 au 20 mai. « Notre plateforme 100% FOSS (Free open source software) a été conçue et développée par la même équipe devops, sans problème de licence ni demande de support », a-t-il ajouté.

Aujourd'hui, Mercedes-Benz fonctionne sur 900 clusters Kubernetes sur site dans quatre datacenters mondiaux utilisant OpenStack. Tous exécutent la version 1.23 de Kubernetes depuis la fin de l’année 2021. Selon une enquête réalisée en 2019 par la Cloud Native Computing Foundation (CNCF), même si le domaine Kubernetes du constructeur automobile est moins important que celui des fournisseurs de cloud, moins de 10% des entreprises utilisent plus de 50 clusters. Ce domaine est également près de cinq fois plus important que l'environnement Kubernetes du CERN, autre acteur principal de la KubeCon Europe, qui exploitait 210 clusters au moment de la rédaction de cet article.

Quelle limite dans le nombre de clusters ?

« Nous faisons beaucoup d'efforts pour que cet environnement reste gérable », a déclaré Peter Müller, expert principal chez Mercedes-Benz Tech Innovation. « Pour nous, les systèmes environnants fonctionnent bien si nous gérons 500 clusters, ou 1 000, parce que tout est automatisé… Si nous devions ajouter 500 clusters supplémentaires, nous devrions ajouter un seul ingénieur de plus. « C’est essentiellement grâce à Cluster API on OpenStack, un projet Kubernetes qui permet la création, la configuration et la gestion déclaratives des clusters, pour lequel l'entreprise a récemment opté en remplacement de Terraform et de certains outils personnalisés, que nous pouvons relever ce défi de gestion ». Cependant, comme c’est toujours le cas avec la technologie, cette solution n’est pas parfaite. « Le nombre de clusters n'est pas un problème. Le problème, ce sont certains des systèmes environnants et parfois OpenStack », a encore déclaré M. Müller. « Mais Kubernetes fonctionne plutôt bien, il est évolutif ».

Changer la culture

Chacune des centaines d'équipes d'application de Mercedes-Benz a désormais la possibilité de demander son propre cluster Kubernetes via un processus automatisé qui utilise un ensemble d'outils maison, construits et gérés par l'équipe de Peter Müller au sein du Mercedes-Benz Tech Innovation. Généralement, les équipes demandent un cluster de production préprovisionné, et des clusters plus petits de mise en scène et de développement, mis en œuvre en quelques heures, voire en quelques minutes. « D'un point de vue organisationnel, il y a cinq ou six ans, à l’aube du devops, tout le monde parlait de l'approche ‘vous le concevez, vous en êtes responsable’. En tant que fournisseur d'une plateforme partagée, cela signifie que chaque équipe d'application au sein de Mercedes-Benz dispose de son propre cluster Kubernetes », a déclaré Jörg Schüler, chef d'équipe chez Mercedes-Benz Tech Innovation. « Notre objectif est de fournir un écosystème et que nos équipes d'application soient autonomes », a-t-il ajouté. « Cet écosystème est sous-tendu par les principes du libre-service et orienté vers les API ».

Ce patrimoine est géré non pas par une, mais par cinq équipes de plateforme distinctes. Deux d'entre elles forment une équipe combinée d'une douzaine d'ingénieurs qui se concentrent sur la plate-forme de base Kubernetes-as-a-service. Viennent ensuite les équipes chargées de la base de données en tant que service, de la journalisation et de la surveillance en tant que service, ainsi que de la sécurité des conteneurs, y compris l'exécution, le registre et l'analyse des images. Compléter ces équipes s'avère toutefois difficile pour l'entreprise. « Ce n’est pas facile de trouver de bons experts Kubernetes », a déclaré M. Schüler. « Proposer un enseignement, une formation et d'autres offres autour de cette plateforme est vraiment utile. Il faut une approche communautaire pour que les équipes de développeurs s'entraident à travers des Boot camps, des portails de formation et des environnements de bac à sable », a ajouté le chef d'équipe de Mercedes-Benz Tech Innovation.

Des chemins d’or au cloud

Après tous ces efforts pour gérer Kubernetes à l'échelle, Mercedes-Benz Tech Innovation se prépare à déplacer de plus en plus de charges de travail vers le cloud public, où elle pourrait utiliser davantage de services managés comme Azure Kubernetes Service (AKS) de Microsoft et Elastic Kubernetes Service (EKS) d'Amazon, afin d'alléger la charge cognitive sur la plateforme et les équipes devops. « Nous ne savons pas encore si nous opterons pour EKS, mais pour le moment, nous préférons le faire nous-mêmes, car nous disposons de la même architecture sur site et hors site », a encore déclaré Peter Müller. Si ces versions managées de Kubernetes peuvent contribuer à alléger la charge des équipes de la plateforme Mercedes-Benz Tech Innovation, les équipes chargées des applications ont encore besoin d'aide pour passer aux conteneurs et à Kubernetes.

Des « Golden paths », en l’occurrence les diagrammes de Helm, pourraient apporter une solution pour accélérer les progrès dans ce domaine. Ils pourraient être utilisés comme modèles pour certaines fonctionnalités, comme la gestion des identités et des accès, afin de ne pas répéter le même travail dans différentes équipes. « Nous devons fournir des chemins d’or et d'autres éléments en tant que service afin de réduire la charge cognitive et permettre aux équipes d’exceller dans ce qu'elles font le mieux : créer de la valeur commerciale », a déclaré M. Müller. Évidemment, les niveaux de maturité varient d'une équipe d'application à l'autre, et M. Müller considère que son rôle consiste à leur offrir un environnement sûr dans lequel ils peuvent apprendre. « Une fois que ces équipes auront atteint un niveau de maturité suffisant, elles pourront passer au cloud », a-t-il ajouté. À l'aide de techniques de sourcing interne, Mercedes-Benz Tech Innovation gère ensuite certains de ces chemins d'or, tandis que d'autres se trouvent dans ce que M. Müller appelle « un stade communautaire », en attente de validation. Idéalement, ces chemins d'or pourraient être codifiés dans une plateforme semblable à la plateforme Backstage Software Catalog créée par Spotify. M. Müller dit qu'ils travaillent actuellement sur « la preuve de concepts d’un portail central de développeurs intégrant tous les services, mais nous n'en sommes pas encore là ».

« Pour nous, gérer Kubernetes n'est pas difficile »

« Kubernetes reste difficile, c’est pourquoi il ne faut pas que les équipes devops et de développeurs soient livrées à elles-mêmes », a déclaré Sabine Wolz, responsable de produits chez Mercedes-Benz Tech Innovation, lors de son intervention à la KubeCon Europe. Cependant, Perter Müller croit fermement que ce sont surtout les équipes d'application qui vont devoir se confronter à la courbe d'apprentissage et non les équipes de plateforme. « La gestion de Kubernetes est difficile si l’on n’est pas complètement dedans. Donc, si nous choisissons de le gérer, nous devons tout maîtriser en profondeur, si bien que pour nous, au final ce n’est pas difficile de gérer Kubernetes », a encore déclaré l’expert principal de Mercedes-Benz Tech Innovation. « L’utilisation de Kubernetes pour les projets applicatifs reste difficile. Consommer Kubernetes en tant qu'équipe devops est parfois difficile », a-t-il ajouté. M. Müller espère que son équipe de plateforme se distinguera dans l’aide qu’elle pourra apporter aux équipes d'application pour comprendre l'infrastructure sous-jacente sans nécessairement qu’elles aient besoin d’une expertise approfondie. « Certaines équipes travaillent encore sur des machines virtuelles et commencent à passer à un cluster Kubernetes. Elles doivent fractionner leur monolithe, comprendre comment les transactions sont gérées, penser à la communication asynchrone, et comprendre comment Kubernetes fonctionne », a-t-il déclaré. « Cette étape est difficile, c’est pourquoi il faut les aider et ne pas les laisser seuls ».