
Bonjour à tous,
Aujourd’hui, pas de tutoriel, mais plutôt un retour d’expérience.
Je vais vous expliquer pourquoi j’ai arrêté d’utiliser les conteneurs LXC sur Proxmox en production.
Cet article ne vise pas à dire que les LXC sont mauvais, mais plutôt à expliquer dans quels cas leur utilisation peut poser problème, notamment dans un environnement de production critique.
Sommaire
Présentation des conteneurs LXC
Les conteneurs LXC (Linux Containers) permettent d’exécuter plusieurs environnements Linux isolés sur un même noyau Linux.
Contrairement aux machines virtuelles classiques, un conteneur LXC :
- ne virtualise pas le matériel
- partage le noyau Linux de l’hôte
- utilise des mécanismes d’isolation comme :
- namespaces
- cgroups
- chroot
Concrètement, un conteneur LXC ressemble beaucoup à une machine virtuelle classique :
- il possède son propre système de fichiers
- ses propres utilisateurs
- ses services
- sa configuration réseau
Mais en réalité, il reste très dépendant du système hôte.
Les avantages sont nombreux :
- déploiement très rapide
- consommation de ressources très faible
- démarrage quasi instantané
- templates prêts à l’emploi dans Proxmox
- redimensionnement du disque très simple
Sur le papier, c’est donc très séduisant.
Différence entre VM et LXC
La principale différence entre une machine virtuelle et un conteneur LXC est le niveau de virtualisation.
Machine virtuelle (VM)
Une VM repose sur un hyperviseur (comme KVM dans Proxmox) qui virtualise complètement le matériel.
Chaque VM possède :
- son propre noyau
- ses pilotes
- son système d’exploitation complet
Avantages :
- isolation forte
- compatibilité maximale
- fonctionnement identique à un serveur physique
- support complet des fonctionnalités hyperviseur
Inconvénients :
- consommation de ressources plus importante
- démarrage plus lent
Conteneur LXC
Un conteneur LXC utilise le noyau de l’hôte.
Avantages :
- très léger
- très rapide à déployer
- peu gourmand en ressources
Inconvénients :
- dépend du noyau de l’hôte
- certaines fonctionnalités Linux ne sont pas disponibles
- compatibilité parfois limitée avec certaines applications
Et c’est précisément là que les problèmes peuvent apparaître.
L’enthousiasme des débuts
Comme beaucoup de personnes découvrant Proxmox, j’ai été très vite emballé par les conteneurs LXC.
Pourquoi ?
Parce que :
- le déploiement est extrêmement rapide
- l’assistant configure automatiquement :
- le mot de passe root
- le réseau
- le stockage
- les templates sont prêts à l’emploi
- le redimensionnement du disque est ultra simple
En quelques clics, on a un serveur prêt à fonctionner.
Pendant longtemps, j’ai donc utilisé les LXC pour héberger :
- des stacks Docker
- des applications web
- des outils internes
- des services d’infrastructure
Les premiers problèmes
Depuis maintenant deux ans, j’exploite plusieurs serveurs Proxmox.
Au départ, ils ne fonctionnaient pas en cluster, donc les LXC fonctionnaient correctement.
Mais avec le temps, certains problèmes sont apparus avec certaines applications.
- Elastic nécessite certaines modifications au niveau du noyau Linux pour fonctionner correctement. Dans un conteneur LXC, ces modifications ne sont pas toujours possibles ou recommandées.
- Avec OpenLiteSpeed, j’ai rencontré un comportement assez étrange : le serveur voyait tous les CPU de l’hôte Proxmox, ce qui perturbait certains réglages de performance.
- Le reverse proxy BunkerWeb fonctionne très mal dans un conteneur LXC.
- Réseau MACVLAN
Pour contourner ces problèmes, plusieurs solutions ont été mises en place :
- déployer certaines applications dans des VM
- créer des LXC supplémentaires pour gérer certaines contraintes réseau
- adapter certaines configurations
Bref… ça fonctionnait, mais cela commençait déjà à devenir un peu bricolé.
Passage en cluster Proxmox
Avec le temps, l’infrastructure Proxmox est devenue de plus en plus critique dans le système d’information.
Nous avons donc décidé de passer sur un cluster Proxmox avec haute disponibilité (HA).
Le stockage a été présenté via NFS depuis une baie SAN.
Et c’est à ce moment que les vrais problèmes ont commencé.
Migration des LXC vers le stockage NFS
Le déplacement des conteneurs LXC vers le stockage NFS doit se faire conteneur éteint.
Pour cette première étape, pas de problème particulier :
on planifie cela le soir et tous les LXC sont déplacés sur la baie.
Mais cette manipulation entraîne déjà une première perte :
plus de snapshots possibles (-1 point)
Le problème des sauvegardes
Autre surprise : le fonctionnement des sauvegardes.
Lors de la sauvegarde d’un conteneur LXC vers un stockage NFS, l’hôte Proxmox utilise rsync pour copier les données.
Le problème est le suivant :
la copie temporaire est réalisée sur le disque local du serveur Proxmox.
Et vous voyez venir le problème…
Certains conteneurs étaient plus volumineux que l’espace disponible sur l’hôte.
Résultat : sauvegarde impossible.
Pour contourner cela, j’ai configuré la copie temporaire sur le NAS de sauvegarde.
Cela fonctionne, mais :
- le temps de sauvegarde augmente fortement
- la solution ne me semble pas très propre
Donc on continue comme ça pour les tests. (-1 point)
Test de la haute disponibilité (HA)
Arrive ensuite le moment de tester la haute disponibilité.
Et là encore, mauvaise surprise.
Lors de la bascule d’un LXC d’un nœud à un autre :
- le conteneur est arrêté
- puis redémarré sur l’autre nœud
Cela provoque donc une interruption des services.
Ce n’est pas vraiment ce que l’on attend d’un système HA.
Résultat :
impossible de faire des maintenances de nœuds en journée. (-1 point)
Autres problèmes
Problème avec une mise à jour Docker
une mise à jour de Docker a cassé le fonctionnement du réseau dans les conteneurs LXC.
Deux solutions :
- rester sur une ancienne version de Docker
- attendre une mise à jour de Proxmox
À l’époque, la correction est arrivée avec le passage de Proxmox 8 vers Proxmox 9.
Encore un point négatif.
Le problème du swap et de la surallocation
Dernier point noir : la gestion des ressources.
Dans la configuration LXC par défaut :
- le swap est lié à la mémoire attribuée au conteneur
- ce swap est partagé entre les conteneurs et l’hôte
Avec le temps, comme les LXC sont très rapides à créer, on se retrouve facilement avec :
- beaucoup de conteneurs
- une surallocation CPU
- une gestion des IP compliquée
- une infrastructure qui devient un peu le bazar
LXC vs VM : quand utiliser l’un ou l’autre ?
Malgré les problèmes rencontrés, les conteneurs LXC ne sont pas inutiles.
Ils restent très intéressants dans certains cas.
Cas où LXC est très adapté
Les conteneurs LXC sont parfaits pour :
- les environnements de test
- les laboratoires
- les services légers
- les environnements de développement
- les services internes non critiques
Leur rapidité de déploiement est un vrai avantage.
Cas où les VM sont préférables
Les machines virtuelles restent la meilleure option pour :
- les applications critiques
- les environnements de production
- les applications nécessitant un accès noyau spécifique
- les infrastructures avec haute disponibilité
- les environnements complexes
Elles offrent :
- une isolation complète
- une meilleure compatibilité
- une gestion plus simple dans le temps.
Conclusion
Les conteneurs LXC sont une excellente technologie et s’intègrent très bien dans Proxmox. Leur légèreté et leur rapidité de déploiement en font un outil particulièrement intéressant pour certains usages.
Cependant, dans mon cas et pour mes besoins en production, les limitations rencontrées ont fini par dépasser les avantages.
Aujourd’hui, j’ai donc fait le choix de revenir à une architecture basée principalement sur des machines virtuelles. Certes, elles consomment un peu plus de ressources, mais elles offrent :
- une meilleure isolation
- une compatibilité maximale avec les applications
- une gestion plus simple et plus prévisible dans le temps
Les conteneurs LXC restent malgré tout présents dans mon infrastructure, mais uniquement pour des tests, du lab ou des environnements temporaires.
Avec la version 9.1 de Proxmox, une nouveauté intéressante arrive : la possibilité d’utiliser directement des images OCI (le format utilisé notamment par Docker). Sur le papier, cela peut sembler très séduisant et simplifier encore le déploiement d’applications conteneurisées.
Mais pour ma part, je reste assez prudent sur cette approche.
Dans un environnement de production, je préfère conserver une machine virtuelle dédiée avec une installation Docker complète, ce qui permet de bénéficier de toutes les fonctionnalités de l’écosystème Docker et d’éviter certaines limitations liées aux conteneurs système.
Comme souvent en informatique, il n’y a pas de solution universelle : tout dépend du contexte, de l’infrastructure et des contraintes de production.
Et vous, utilisez-vous encore des conteneurs LXC en production sur Proxmox ?
Avez-vous rencontré les mêmes problèmes ou au contraire avez-vous une expérience positive avec cette technologie ?
N’hésitez pas à partager votre retour d’expérience dans les commentaires.