Kubernetes : Michelin réinternalise après 3 ans chez VMware

Des "choix en désaccord", une "différence de philosophie", des "stratégies pas parfaitement alignées"... Entre VMware et Michelin, les choses n'ont pas tenu sur la partie Kubernetes.

L'entreprise française avait commencé à investir dans cette technologie en 2018. Soucieuse d'éviter tout lock-in, elle avait décidé de construire sa flotte à partir de briques dont elle avait la maîtrise (Ansible, Python, GitLab CI...). Il s'agissait aussi de développer des compétences en interne. Ainsi les déploiements se faisaient-ils sur Azure, mais pas sur l'offre managée AKS. La décision de s'engager avec un partenaire pourrait intervenir plus tard, une fois la maturité acquise. La volatilité du marché (acquisition de Pivotal par VMware, de Red Hat par IBM, de Rancher par SUSE, de Docker par Mirantis...) faisait d'autant plus craindre de choisir le "mauvais cheval".

Au printemps 2021, Michelin avait fait un point sur ses démarches, alors portées par une équipe de 7 personnes. Le parc comprenait 9 clusters de 3 à 30 noeuds, hébergés en cinq emplacements - certains sur Azure, d'autres sur vSphere - et couvrant 45 applications pour environ 2000 pods. L'ensemble suivait le cycle de vie de Kubernetes (mise à niveau tous les 3-4 mois). En son centre se trouvait l'installeur Kubespray, au-dessus duquel un projet avait été créé pour gérer les opérations J+1/J+2.

Tanzu : de l'IaC au support, un usage pas concluant

La question du déploiement de clusters sur site avait fini par se poser. Chacune des 70 usines de production était effectivement censée avoir le sien à terme. En y ajoutant les déploiements cloud, Michelin avait le sentiment que son outillage ne suffirait pas à passer à l'échelle. Il s'était assez rapidement tourné vers Tanzu.

Dès le début, certains aspects de l'intégration ont présagé de problèmes qui s'accentueraient avec le temps, affirme aujourd'hui l'entreprise. À l'en croire, le produit reflète les "idées arrêtées" de VMware. Certains des choix de l'éditeur sont en tout cas allés à l'encontre de la stratégie de Michelin, qui en est arrivé à s'abstenir d'utiliser certaines composantes.

Entre autres écueils, on nous mentionne la quasi-impossibilité de mettre en place une approche IaC, Tanzu Kubernetes Grid et son plan de contrôle n'étant scriptables qu'en mode impératif. Michelin déplore également des inefficacités dans la gestion du cycle de vie, confiée en partie à VMware. Et, dans le même esprit de délégation, une frustration chez les ingés, cantonnés à ouvrir des tickets alors qu'ils auraient souvent pu corriger des problèmes.

Une migration synchronisée avec l'échéance du contrat VMware

Fin 2023, il fut décidé d'un retour vers l'open source. En toile de fond, la fin du contrat avec VMware à l'été 2024. Michelin était alors convaincu d'avoir les ressources pour se passer de l'assistance d'un tiers.

Plusieurs PoC ont prouvé qu'il était possible d'exploiter la Cluster API en combinaison avec ArgoCD pour gérer la flotte en mode IaC / GitOps. Surtout, un basculement sans interruption s'est révélée faisable - alors que dans le même temps, VMware s'apprêtait à livrer des breaking changes.

La migration en elle-même fut enclenchée début juin 2024. Totalement automatisée, elle fut bouclée le mois suivant. Le deuxième semestre fut consacré à rattraper le retard pris sur les versions de Kubernetes, jusqu'au point où tous les éléments bénéficiaient d'un niveau de support communautaire satisfaisant.

À fin mars 2025, le parc Kubernetes de Michelin regroupait environ 440 applications métier sur une soixantaine de clusters. Il était géré par une équipe de 11 personnes.

Illustration © Dmitry Kovalchuk - Adobe Stock