La question peut sembler logique : si OpenStack utilise KVM et que Proxmox fait de même, pourquoi ne pas installer Proxmox sur les serveurs et superposer OpenStack pour gérer toute l’infrastructure ? Le problème est que ces deux produits sont tous deux des plateformes de gestion. Chacun souhaite décider comment naissent, se connectent, stockent, migrent et disparaissent les machines virtuelles, donc leur combinaison ne crée pas automatiquement un cloud privé plus complet.

Les clés d’OpenStack et Proxmox en 30 secondes

• OpenStack supporte KVM via Nova et libvirt, mais ne dispose pas d’un contrôleur spécifique pour gérer des clusters Proxmox.
• Proxmox gère déjà machines virtuelles, réseaux, stockage, haute disponibilité, permissions et sauvegardes.
• Superposer deux plans de contrôle sur les mêmes ressources peut entraîner des configurations divergentes et des opérations contradictoires.
• Proxmox s’intègre bien comme plateforme de virtualisation ; OpenStack est plus adapté pour une cloud multi-utilisateur et en auto-service.
• Kubernetes peut fonctionner sur l’un ou l’autre, mais il ne justifie pas à lui seul le déploiement d’OpenStack.

La documentation actuelle de Nova, le composant de calcul d’OpenStack, inclut KVM parmi les hyperviseurs compatibles, gérés via son contrôleur libvirt. Elle mentionne aussi d’autres options telles que VMware vSphere, Virtuozzo, z/VM ou l’approvisionnement de serveurs physiques avec Ironic. Proxmox n’apparaît pas comme un contrôleur ou hyperviseur supporté de premier ordre.

Cela ne signifie pas qu’il soit impossible de créer une intégration, d’appeler l’API de Proxmox ou de construire une couche intermédiaire traduisant des ordres entre les deux systèmes. Mais cette combinaison n’est pas partie du modèle normal d’OpenStack, et une entreprise devrait assumer le développement, les tests, les mises à jour et la gestion des fautes d’un composant intermédiaire que ni l’un ni l’autre ne contrôle conjointement.

KVM est un point commun, mais ne définit pas l’architecture

KVM est une technologie de virtualisation incluse dans Linux permettant d’exécuter des machines virtuelles utilisant les extensions processeur. Proxmox VE l’intègre avec QEMU pour offrir une virtualisation complète de systèmes Windows et Linux. OpenStack peut l’utiliser comme moteur de calcul via Nova et libvirt.

L’unique point de rencontre s’arrête là. Proxmox VE n’est pas une interface web placée au-dessus de KVM, mais une plateforme complète intégrant la gestion de clusters, la haute disponibilité, la migration, le stockage, les réseaux définis par logiciel, les pare-feux, l’authentification, les permissions et les outils de récupération. Elle administre aussi des conteneurs LXC dans le même environnement.

OpenStack construit son propre modèle autour de services séparés. Nova gère la capacité de calcul, Neutron contrôle les réseaux, Cinder fournit le stockage en blocs, Glance stocke les images et Keystone s’occupe de l’authentification. On peut ajouter d’autres composants pour l’équilibrage, l’orchestration, la télémétrie ou la gestion de clusters de conteneurs.

Lorsqu’OpenStack crée une instance, il enregistre son identité, attribue l’hôte, connecte ses interfaces virtuelles, attache les volumes et surveille l’état attendu de la ressource. Proxmox effectue une opération équivalente dans son propre inventaire, avec ses propres définitions de stockage, réseau et haute disponibilité.

Permettre à ces deux plateformes de modifier les mêmes machines introduit deux sources de vérité. OpenStack peut considérer qu’une instance doit tourner sur un nœud, alors que Proxmox tente de la migrer selon une politique de haute disponibilité. Un administrateur peut modifier un disque via l’interface de Proxmox sans que Cinder en ait connaissance. Un réseau peut exister pour Neutron sans correspondre à la configuration appliquée en ponts, VLAN ou réseaux virtuels dans Proxmox.

Ce type de conflit ne apparaît pas forcément lors de la création initiale, mais peut survenir des mois plus tard, lors d’une migration, d’une récupération, d’une extension de disque ou d’une mise à jour. Les opérations manuelles qui fonctionnent en petits tests deviennent souvent incohérentes dans un environnement automatisé, avec plusieurs administrateurs et des centaines de machines.

Installer directement les composants Nova sur des serveurs qui font déjà partie d’un cluster Proxmox ne résout pas le problème. Cela reviendrait à demander à OpenStack de gérer KVM et libvirt, tout en laissant Proxmox utiliser ses propres processus, fichiers de configuration et sa base de données distribuée sur les mêmes ressources.

La solution cohérente consiste à définir clairement quel sera le plan de contrôle : si l’on choisit OpenStack, il faut que chaque nœud de calcul soit intégré selon l’architecture et les contrôleurs d’OpenStack. Si l’on privilégie Proxmox, les machines doivent être administrées via ses outils et sa clusterisation.

Il n’empêche pas qu’une organisation puisse utiliser les deux plateformes, en maintenant un environnement Proxmox pour des charges traditionnelles et un autre OpenStack pour ses services internes d’infrastructure as a service (IaaS). La séparation évite qu’elles tentent de gérer les mêmes objets et permet d’adapter le modèle opérationnel à chaque cas.

Le véritable enjeu : virtualisation ou cloud privé

Ce débat survient souvent lors d’une migration depuis VMware vSphere. La modification des licences pousse de nombreuses entreprises à chercher une alternative, mêlant alors deux enjeux : remplacer la plateforme de virtualisation et construire un cloud privé.

Proxmox peut couvrir de nombreux besoins précédemment assurés par vSphere. Il permet d’agréger des serveurs, exécuter machines virtuelles et conteneurs, configurer la haute disponibilité, intégrer Ceph, ZFS et du stockage partagé, réaliser des migrations et mettre en place une solution de sauvegarde spécifique.

De plus, Proxmox Datacenter Manager étend la gestion centralisée à plusieurs clusters et centres de données. Selon le fournisseur, cela permet de visualiser, opérer et migrer des milliers de charges via une interface unique, tout en centralisant identités, réseaux EVPN et mises à jour. Cette évolution atténue certaines limitations historiques dans les environnements distribués, tout en restant dans l’écosystème Proxmox.

OpenStack vise un objectif différent. Son intérêt apparaît lorsque les utilisateurs internes doivent demander des ressources via API, travailler sur des projets isolés, appliquer des quotas, créer des réseaux à la demande, utiliser des catalogues d’images ou attacher des volumes sans faire appel à un ticket pour l’administration de virtualisation.

Dans un cloud privé, l’infrastructure est perçue comme un service. Les équipes de développement n’ont pas besoin de savoir sur quel serveur tourne chaque machine ou quel stockage est utilisé. Elles demandent une ressource aux caractéristiques spécifiques, et le système décide de son déploiement en fonction de la capacité, des politiques et de la disponibilité.

Ce modèle a un coût opérationnel. OpenStack requiert la maintenance de plusieurs services, bases de données, files de messages, réseaux, stockages et outils de déploiement. Il demande aussi une équipe formée pour mettre à jour, diagnostiquer et automatiser, tout en évitant que les composants ne se brisent mutuellement.

Le logiciel peut être open source et sans coût par processeur, mais son fonctionnement exige du temps, des compétences et des processus. Une entreprise cherchant simplement à remplacer vSphere pourrait finir par construire une plateforme plus complexe que nécessaire.

Proxmox réduit cette charge en intégrant la majeure partie de la gestion de virtualisation dans un produit plus simple. Cette simplicité relative a ses limites : avoir une API, des permissions et une automatisation ne suffit pas à faire d’un cluster de virtualisation une cloud IaaS complet avec le même modèle de projets, quotas et services réseau d’OpenStack.

Le nombre de machines virtuelles ne suffit pas à lui seul. Un environnement avec moins de 2 000 VM peut justifier OpenStack si l’on cible de nombreux utilisateurs, l’auto-service, des réseaux isolés par projet, et une création ou suppression continue de ressources. Pour des charges stables gérées par une équipe centrale, Proxmox peut être plus adapté.

La question n’est pas seulement combien de machines virtuelles existent, mais surtout qui les utilise, à quelle fréquence et quels services sont attendus. Si la majorité des changements passe par des procédures planifiées et des administrateurs, Proxmox peut suffire. Si plusieurs équipes demandent souvent, via API, une infrastructure isolée, alors la complexité d’OpenStack se justifie.

L’indépendance du hyperviseur doit aussi être nuancée. OpenStack peut fonctionner avec plusieurs technologies, et sa documentation indique qu’un seul hyperviseur est généralement déployé. Les différences de fonctionnalités, formats, contrôleurs et réseaux compliquent la gestion interchangeable sans effort supplémentaire.

Choisir OpenStack ne rend pas exempte la dépendance technologique. Elle s’oriente vers ses APIs, ses services, la conception réseau, le stockage et la plateforme choisie pour l’exploitation. Bien que cette dépendance puisse être préférée à celle d’un fournisseur propriétaire, elle reste à prendre en compte dans l’analyse.

Kubernetes ne nécessite pas OpenStack

Kubernetes est souvent présenté comme une raison clé en faveur d’OpenStack, mais ce n’est pas automatique. Kubernetes peut fonctionner sur des machines virtuelles hébergées par vSphere, Proxmox, OpenStack ou d’autres plateformes capable de fournir des serveurs Linux connectés.

Un cluster stable, même avec plusieurs nœuds, peut tourner sur Proxmox. Les machines sont créées via des templates, Terraform, Ansible ou autres outils, et Kubernetes gère ensuite les conteneurs. Pour beaucoup d’environnements, ce niveau suffit.

OpenStack apporte de la valeur lorsque Kubernetes doit consommer dynamiquement des ressources d’infrastructure. Par exemple, Magnum offre des clusters de conteneurs comme ressources d’OpenStack, intégrant Keystone pour l’identité, Neutron pour le réseau multi-utilisateur et Cinder pour le stockage. Octavia fournit aussi la gestion de load balancers intégrés.

Le choix dépend en fait de ce que Kubernetes attend de l’infrastructure. S’il s’agit d’un déploiement longue durée de quelques clusters, la gestion manuelle ou semi-automatisée peut suffire. Mais si l’on souhaite créer, supprimer ou gérer dynamiquement des ressources via API, OpenStack est mieux adapté.

Il est utile de définir précisément ses besoins : provisioning automatique de nœuds, création dynamique de volumes, équilibrage à la demande, réseaux isolés, quotas par équipe, déploiements automatisés, gestion multi-projets. Si ces exigences font partie du plan de l’organisation, OpenStack propose des composants pour cela. Sinon, Proxmox peut fournir des VM stables sans nécessiter une cloud complète.