Trois clients SaaS sur le même cluster Kubernetes mutualisé chez l'hébergeur. Un conteneur échappe (privileged: true ou faille runc) : voisinage à risque. Même charge en machines virtuelles dédiées sur hyperviseur durci : le rayon d'impact s'arrête à la VM — au prix de mémoire et d'exploitation.
Conteneur = isolation processus. VM = isolation machine. La frontière choisie définit votre modèle de confiance.
Les guides « Docker en production » supposent une équipe qui durcit le démon, scanne les images et segmente le réseau. Sans cela, un conteneur n'est qu'un processus encapsulé — pratique, mais pas magique. Les audits de sécurité demandent souvent une justification écrite : pourquoi conteneur plutôt que VM pour ce workload ? Répondez en termes de confiance entre locataires, pas de mode à la mode.
Conteneurs : densité et vélocité
Docker, containerd — image immuable, déploiement rapide. Forces : densité, intégration continue, microservices, même noyau. Faiblesses : noyau partagé, erreur de configuration (docker.sock monté), image vulnérable propagée. Hébergement : Kubernetes managé, Docker sur VPS, PaaS conteneurs.
VM : frontière matérielle virtuelle
KVM, VMware, Hyper-V — système invité complet. Forces : isolation forte, noyaux différents, conformité, multi-locataire hostile. Faiblesses : surcharge mémoire et processeur, démarrage lent, correctif par machine. Hébergement : VPS, cloud IaaS, nœuds workers Kubernetes.
| Critère | Conteneur | VM |
|---|---|---|
| Isolation | Processus | Machine |
| Densité | Haute | Basse |
| Correctif noyau | Une fois hôte | Par invité + hôte |
| Multi-locataire hostile | Risqué seul | Préféré |
Erreurs de frontière fréquentes
Conteneur root avec réseau hôte. Socket Docker exposé. VM sous-dimensionnée partageant disque sans chiffrement. « Isolation » supposée sans analyse des images.
Kubernetes : le modèle hybride standard
Chez la plupart des hébergeurs cloud, vos conteneurs tournent sur des machines virtuelles workers gérées par la plateforme. Vous n'avez pas à choisir conteneur ou VM — vous héritez des deux. La question devient : combien de locataires partagent l'hyperviseur, et qui administre le noyau hôte. Lisez le contrat d'hébergement mutualisé Kubernetes : certains offrent isolation renforcée par VM dédiée par client, d'autres densifient plusieurs clients sur les mêmes nœuds.
Pour une petite équipe sans expert sécurité conteneur, un VPS KVM avec Docker Compose peut être plus simple qu'un cluster Kubernetes mutualisé mal compris.
Avant de conteneuriser, demandez : ce service partage-t-il le même niveau de sensibilité que les autres ? Si oui, conteneurs sur un VPS que vous contrôlez suffisent souvent. Si non — client A et client B sur même plateforme SaaS — la VM ou l'isolation hyperviseur par tenant n'est pas un luxe, c'est la frontière contractuelle.
Les hébergeurs documentent parfois « isolation conteneurs » sans garantie multi-tenant hostile — lisez le contrat et les SLA sécurité. En cas de doute pour des données sensibles, la VM dédiée ou le nœud worker dédié coûte moins cher qu'un incident de fuite entre clients.
Avant production, listez interdictions explicites : pas de --privileged, pas de montage socket Docker, pas de réseau hôte sauf justification écrite et validée. Ces trois règles évitent la majorité des fuites conteneur observées chez les hébergeurs mutualisés. Revoyez-les à chaque revue de sécurité trimestrielle — une exception « temporaire » devient permanente en production.
Le sommet : la frontière suit le niveau de confiance
Décider et avancer sans angle mort
Classifiez d'abord vos charges : même zone de confiance ou non. Choisissez les conteneurs si Kubernetes est mature dans votre organisation ; les VM si les locataires sont séparés. Interdisez le mode privilégié et le montage docker.sock en production. Comparez enfin Kubernetes managé européen ou VPS KVM selon la criticité via le comparateur et l'annuaire.
Questions fréquentes
Conteneur = isolation VM ?
Non — noyau partagé ; la VM isole au niveau hyperviseur avec un système invité complet.
Quand choisir la VM ?
Multi-locataire hostile, conformité stricte, systèmes d'exploitation hétérogènes ou charges legacy nécessitant isolation matérielle virtuelle.
Docker entre microservices de confiance ?
Oui avec bonnes pratiques — standard Kubernetes interne à une organisation qui maîtrise la sécurité conteneur.
Impact sur l'hébergement ?
VM consomme plus de mémoire ; conteneurs densifient ; Kubernetes combine souvent les deux sur nœuds VM.
La bonne frontière n'est pas la plus légère — c'est celle où un compromis s'arrête avant le voisin.