Sortir de VMware en migrant vers Kubernetes

Depuis le rachat de VMware par Broadcom, beaucoup d’entreprises ont remis la virtualisation sur la table. Dans la plupart des cas, le déclencheur n’est pas un problème de performance : c’est un sujet de coûts, de packaging, de prévisibilité budgétaire et de dépendance.

La question devient alors : faut-il remplacer VMware par une autre virtualisation “VM classique”... ou profiter de la décision pour rationaliser et éviter d’avoir à rechanger dans quelques années ?

Chez Skalio, nous défendons souvent une trajectoire cloud-native : construire un socle Kubernetes solide, et y opérer des VMs sur Kubernetes quand c’est nécessaire (legacy, contraintes éditeurs), tout en préparant la modernisation applicative. Nous avons davantage de retours terrain côté SUSE, tout en intervenant aussi sur des environnements Red Hat selon le contexte.

Ce billet assume une idée simple : VMs sur Kubernetes, c’est exigeant, mais c’est aussi une manière de transformer une sortie VMware en investissement durable (gouvernance, automatisation, supervision, sécurité), plutôt qu’en remplacement temporaire.

Le vrai choix : “remplacer un hyperviseur” ou “rationaliser l’exploitation”

Remplacer VMware “à l’identique” peut être un bon choix quand l’urgence est de stabiliser rapidement. Mais cela laisse souvent intactes les causes qui rendent les changements coûteux :

• une exploitation très centrée sur une console et des gestes manuels
• des pratiques de sauvegarde/PRA pas assez testées
• des droits et des audits difficiles à unifier
• des outils et procédures différentes selon les équipes

À l’inverse, opérer des VMs sur Kubernetes cherche à résoudre un problème plus large : bâtir un socle d’exploitation commun pour plusieurs types de charges de travail.

L’objectif n’est pas de “mettre des VMs dans des conteneurs”. L’objectif est d’avoir une plateforme où l’on peut :

• gérer les accès et la traçabilité de manière cohérente
• automatiser ce qui doit l’être (provisionnement, configuration)
• superviser et dépanner avec des outils standard
• préparer la réduction progressive du parc VM, sans big bang

Pourquoi les VMs sur Kubernetes peuvent être un bon investissement “long terme”

La promesse d’une trajectoire cloud-native n’est pas magique. Elle repose sur un pari : investir dans une plateforme et des pratiques d’exploitation qui serviront au-delà de la seule virtualisation.

Unifier les règles du jeu

Kubernetes force (dans le bon sens du terme) à expliciter des sujets qui, sinon, restent implicites :

• qui a le droit de faire quoi
• comment on trace les changements
• comment on déploie de manière reproductible
• comment on supervise et comment on réagit en incident

C’est un effort au départ, mais c’est aussi une forme de rationalisation : on évite de multiplier des outils et des procédures selon les “silos” (VM d’un côté, conteneurs de l’autre).

Éviter le scénario “on rechange encore dans 3 ans”

Beaucoup d’organisations remplacent VMware par une autre virtualisation, puis découvrent qu’elles doivent quand même construire une plateforme Kubernetes pour les nouveaux usages. Résultat : deux mondes à opérer, deux ensembles de compétences, deux stratégies de supervision et de sécurité.

Une approche VMs sur Kubernetes vise au contraire à converger : la VM devient une charge de travail parmi d’autres, et la plateforme (et ses pratiques) devient l’investissement principal.

Conserver du legacy sans bloquer la modernisation

Dans la vraie vie, tout ne se modernise pas en 6 mois :

• certains éditeurs imposent un support précis
• certaines applications sont trop risquées à transformer
• certaines équipes applicatives n’ont pas la bande passante

Les VMs sur Kubernetes permettent de garder ces contraintes “sous contrôle”, tout en avançant sur le reste.

SUSE Virtualization et Red Hat : où ils se placent dans cette approche

Quand on parle de VMs sur Kubernetes, deux familles reviennent souvent.

Côté SUSE : gestion multi-clusters et transition opérationnelle

Dans beaucoup de projets, la difficulté n’est pas “installer un cluster”, mais de réussir la transition de l’exploitation : inventaire, droits, supervision, procédures, mises à jour.

L’écosystème SUSE est souvent regardé pour :

• une approche orientée gestion et exploitation au quotidien
• une console qui aide la conduite du changement
• la capacité à faire cohabiter les usages Kubernetes et la virtualisation

Côté Red Hat : plateforme Kubernetes enterprise et virtualisation sur le même socle

Red Hat est fréquemment retenu quand l’organisation est déjà très engagée dans un Kubernetes “entreprise” bien cadré, avec des attentes fortes sur les processus et la sécurité.

Le point commun (et l’important) : dans ces approches, l’objectif est d’opérer des VMs dans le même cadre que le reste (droits, politiques, supervision), plutôt que de maintenir deux mondes totalement séparés.

Le message honnête : VMs sur Kubernetes, c’est un investissement (pas une recette miracle)

Mettre des VMs sur Kubernetes peut vous éviter de reconstruire un nouveau silo... mais seulement si vous acceptez l’investissement qui va avec.

Le premier point, c’est que l’exploitation compte plus que l’installation. Installer une plateforme et démarrer quelques VMs ne prouve pas qu’elle tiendra sur la durée. Ce qui fait la différence, c’est la capacité à enchaîner proprement : mises à jour, incidents, changement d’échelle, et demandes internes.

Concrètement, une trajectoire VMs sur Kubernetes exige de mettre au clair, dès le départ, des sujets que VMware rend parfois “faciles” grâce à son historique et à sa centralisation :

• Les mises à jour : qui décide, quand, comment on prépare, et comment on revient en arrière en cas de problème.
• La supervision : quelles alertes sont réellement actionnables, qui les reçoit, et quelles actions suivre.
• Les procédures d’incident : pas un classeur de 50 pages, mais quelques scénarios typiques (nœud indisponible, stockage dégradé, VM qui ne redémarre pas) et une réponse standard.
• Les droits et la traçabilité : qui peut créer, modifier, restaurer, comment on prouve une action, comment on évite les opérations “dans un coin”.

Le deuxième point, c’est la conduite du changement. VMware est très “interface graphique” : inventaire, actions rapides, dépannage visuel. Si vous basculez vers une nouvelle plateforme sans préserver une interface claire et des gestes simples, l’exploitation devient plus dure... et les équipes reviennent vite à des pratiques manuelles non tracées.

Une méthode simple marche bien : choisir une console de référence (une seule), et lister les 10 gestes du quotidien que tout le monde doit retrouver facilement : créer une VM depuis un modèle, ajuster CPU/RAM, ajouter un disque, mettre un nœud en maintenance, vérifier la haute disponibilité, restaurer, gérer les droits, etc. Ensuite, on applique une règle pratique : la console sert à investiguer et traiter l’exceptionnel ; l’automatisation sert à répéter sans erreur.

Le troisième point, souvent sous-estimé, ce sont les compatibilités. Sur une plateforme Kubernetes, tout évolue : version du cluster, couche de gestion, stockage, sauvegarde, extensions réseau. Sans une discipline minimale sur les versions “validées”, on peut dégrader un point critique (snapshots, restauration) avec une mise à jour pourtant banale.

Le bon réflexe est de maintenir un tableau très simple (une page) : vos briques et leurs versions validées.

Enfin, il y a le sujet qui fait déraper les plannings : stockage et PRA. Si vous aviez SAN ou une forte intégration VMware, le stockage n’est pas un détail. Sur Kubernetes, c’est une chaîne complète : volumes, snapshots, sauvegarde, réplication, PRA. C’est aussi l’endroit où l’on voit vite si une plateforme est réellement “production-ready” pour vos objectifs.

Une approche réaliste : converger sans big bang

Dans la majorité des cas, la trajectoire la plus saine n’est ni “tout VM classique”, ni “tout cloud-native en une fois”.

C’est plutôt :

1. Construire un socle Kubernetes propre (gouvernance, supervision, mises à jour)
2. Y opérer des VMs quand c’est utile (legacy, contraintes)
3. Réduire progressivement le parc VM en modernisant ce qui peut l’être

Le but est de ne pas reconstruire un nouveau silo, mais de converger vers une exploitation unique.

Sécuriser votre sortie VMware avec un pilote “production” en 30 jours

Si vous envisagez une trajectoire VMs sur Kubernetes (SUSE ou Red Hat), le meilleur moyen d’éviter les mauvaises surprises est de valider l’exploitation dès le départ.

Chez Skalio, nous proposons un pilote en 30 jours orienté “production” (pas une simple démo). L’objectif : produire des faits et des livrables utiles, pour décider sereinement entre continuité VM, transition hybride, ou cloud-native.

Ce que le pilote valide (8 tests très révélateurs)

1. Restauration : une restauration complète + une restauration ciblée (et on chronomètre)
2. PRA minimal : un scénario simple avec un objectif de temps réaliste
3. Mise à jour : au moins une mise à jour de la plateforme ou d’un composant critique
4. Performance : test sur un workload sensible (pas seulement CPU/RAM)
5. Réseau : règles, MTU, services, supervision réseau
6. Droits et traçabilité : qui peut faire quoi, et comment on le prouve
7. Supervision : alertes exploitables pour l’équipe
8. Procédure incident : un exercice court (30–45 min)

Ce que vous récupérez de concret

• un tableau de compatibilités simple (vos versions validées)
• 2–3 procédures courtes (mise à jour, restauration, incident)
• un avis factuel sur la trajectoire (continuité VM, transition hybride, cloud-native)

Conclusion

Sortir de VMware est souvent vécu comme une contrainte budgétaire. C’est aussi une occasion rare de simplifier et rationaliser l’exploitation pour plusieurs années, au lieu de faire un remplacement “à court terme”.

Pour les équipes infrastructures et exploitation, la trajectoire VMs sur Kubernetes apporte surtout :

• une exploitation plus cohérente (mêmes règles d’accès, mêmes méthodes de supervision, mêmes procédures)
• moins de bricolage et d’actions non tracées, donc moins d’incidents “surprise”
• une transition plus progressive : garder du legacy quand il le faut, moderniser quand c’est possible

Pour la DSI, le bénéfice est d’abord la maîtrise :

• une plateforme qui sert à la fois la VM et le cloud-native, donc moins de silos
• une meilleure auditabilité (droits, traçabilité) et une gouvernance plus simple
• une stratégie qui limite le risque de devoir “rechanger” rapidement parce que l’organisation a continué à empiler des outils

Cette approche n’est pas une recette miracle. Elle réussit si, et seulement si, vous posez quelques conditions de réussite dès le départ :

1. Investir dans l’exploitation (mises à jour, supervision utile, procédures courtes)
2. Préserver l’efficacité opérationnelle avec une console de référence et des gestes simples (conduite du changement)
3. Maîtriser les compatibilités via un tableau de versions validées, surtout autour du stockage et de la sauvegarde
4. Traiter le stockage et le PRA comme des sujets majeurs, testés en conditions réelles
5. Gérer les exceptions éditeurs : identifier tôt les workloads “non négociables”

Si ces conditions sont réunies, les VMs sur Kubernetes transforment une sortie VMware en investissement durable : une plateforme unique, une exploitation plus robuste, et une trajectoire de modernisation sans dépendance récurrente.