La virtualisation et la conteneurisation résolvent le même problème historique depuis deux niveaux d'abstraction distincts : comment isoler et empaqueter un logiciel pour qu'il s'exécute de manière reproductible, indépendamment du matériel sous-jacent. La machine virtuelle virtualise le matériel complet et charge un système d'exploitation invité au-dessus d'un hyperviseur (VMware ESXi, KVM, Hyper-V). Le conteneur, lui, virtualise le système d'exploitation : il partage le noyau de l'hôte et isole les processus au moyen de primitives du noyau Linux comme les namespaces (isolation de la visibilité) et les cgroups (contrôle des ressources). Cette différence explique pourquoi un conteneur démarre en quelques millisecondes et pèse quelques mégaoctets, tandis qu'une machine virtuelle met des secondes ou des minutes et occupe des gigaoctets.
Docker a popularisé les conteneurs en 2013 en offrant une expérience d'empaquetage simple, et Kubernetes — publié par Google en 2014 et aujourd'hui sous l'égide de la Cloud Native Computing Foundation — est devenu l'orchestrateur standard pour exécuter des conteneurs à grande échelle. Dans cet article, nous décomposons les deux technologies avec rigueur technique : comment se construit une image, comment Kubernetes orchestre, quelles erreurs coûtent cher en production et quel cadre normatif de sécurité s'applique.
Docker : images, couches et modèle d'empaquetage
Une image Docker est un modèle immuable en lecture seule, construit en couches empilées (chaque instruction du Dockerfile génère une couche) sur un système de fichiers union (overlayfs). Un conteneur est une instance en exécution de cette image, dotée d'une fine couche d'écriture par-dessus. Cette architecture en couches permet de partager les couches communes entre images et d'accélérer les téléchargements, puisque seules les couches nouvelles sont transférées.
La valeur de Docker réside dans la reproductibilité : le classique « ça marche sur ma machine » disparaît parce que l'image contient l'application et toutes ses dépendances figées. Les bonnes pratiques de construction comprennent :
- Les multi-stage builds : compiler dans une image volumineuse et copier uniquement le binaire résultant vers une image finale minimale, réduisant drastiquement la taille et la surface d'attaque.
- Les images de base minimales (Alpine, distroless) pour limiter les dépendances vulnérables.
- L'exécution en tant qu'utilisateur non root avec la directive
USER, afin d'éviter qu'une évasion de conteneur n'hérite des privilèges de l'hôte. - L'immuabilité et l'étiquetage par version au lieu de
:latest, pour garantir des déploiements déterministes.
Kubernetes : l'orchestration de conteneurs à grande échelle
Lorsqu'on passe de quelques conteneurs à des centaines répartis sur des dizaines de serveurs, il faut un orchestrateur capable de décider où placer chaque charge, de relancer ce qui tombe en panne, de mettre à l'échelle selon la demande et de router le trafic. C'est Kubernetes. Son architecture sépare le control plane (le kube-apiserver comme point d'entrée, etcd comme magasin d'état, le scheduler qui affecte les pods aux nœuds et les controllers qui réconcilient) des worker nodes, où le kubelet exécute les conteneurs via un runtime compatible CRI (containerd, CRI-O).
L'unité déployable minimale n'est pas le conteneur mais le pod, qui regroupe un ou plusieurs conteneurs partageant le réseau et le stockage. Au-dessus des pods, Kubernetes offre des abstractions déclaratives : le Deployment gère les réplicas et les déploiements progressifs (rolling updates), le Service fournit une IP stable et un équilibrage vers un ensemble de pods, l'Ingress expose le HTTP/S vers l'extérieur, et le ConfigMap et le Secret externalisent la configuration et les identifiants. Le modèle est déclaratif : l'utilisateur décrit l'état souhaité en YAML et la boucle de réconciliation de Kubernetes travaille sans relâche pour que l'état réel coïncide avec lui.
La mise à l'échelle automatique s'articule sur trois niveaux : le Horizontal Pod Autoscaler (HPA) ajoute ou retire des réplicas selon le CPU, la mémoire ou des métriques personnalisées ; le Vertical Pod Autoscaler ajuste les ressources par pod ; et le Cluster Autoscaler ajoute ou retire des nœuds chez le fournisseur cloud selon la demande agrégée.
Tableau comparatif : machine virtuelle et conteneur
| Dimension | Machine virtuelle | Conteneur |
|---|---|---|
| Isolation | Matériel complet (hyperviseur) | Processus (namespaces + cgroups) |
| Système d'exploitation | OS invité complet par VM | Partage le noyau de l'hôte |
| Temps de démarrage | Secondes à minutes | Millisecondes |
| Taille typique | Gigaoctets | Mégaoctets |
| Densité par hôte | Dizaines | Centaines ou milliers |
| Surface d'isolation | Plus forte (noyau propre) | Plus faible (noyau partagé) |
La conclusion pratique n'est pas qu'une technologie remplace l'autre : elles coexistent. Il est courant d'exécuter Kubernetes sur des machines virtuelles, en combinant la forte isolation de la VM à la frontière de sécurité avec la densité et l'agilité du conteneur dans la couche applicative.
Microservices et modèle de déploiement
Les conteneurs sont le véhicule naturel de l'architecture en microservices, où une application monolithique se décompose en services petits, déployables et scalables de façon indépendante. Cela permet des déploiements sans interruption grâce à des stratégies comme le rolling update (Kubernetes remplace les pods progressivement), le blue-green (deux environnements parallèles et bascule du trafic) ou le canary (on route un petit pourcentage de trafic vers la nouvelle version et on l'observe avant de généraliser). Ces techniques sont le fondement de la livraison continue moderne, intégrées à des pipelines de CI/CD et, de plus en plus, à GitOps (Argo CD, Flux), où le dépôt Git est la source unique de vérité de l'état du cluster.
Sécurité et cadre normatif des environnements de conteneurs
La surface d'attaque change par rapport aux machines virtuelles et exige des contrôles spécifiques. Le NIST SP 800-190, Application Container Security Guide, est la référence officielle et traite des risques liés à l'image (vulnérabilités, secrets embarqués), au registre, à l'orchestrateur et au runtime. L'organisation CIS publie des benchmarks de durcissement tant pour Docker que pour Kubernetes, qu'il convient d'appliquer comme ligne de base. Mesures concrètes : scanner les images dans le pipeline (Trivy, Clair), signer les images (Cosign/Sigstore), appliquer des Network Policies pour microsegmenter le trafic est-ouest, utiliser le RBAC avec le moindre privilège et gérer les secrets via un coffre externe (Vault) plutôt que de les laisser dans des variables d'environnement.
Sur le plan de la conformité, lorsque les conteneurs traitent des données personnelles, le RGPD s'applique : le principe de sécurité du traitement (article 32) impose le chiffrement et la minimisation, et la portabilité des conteneurs entre régions et fournisseurs doit respecter les règles de transfert international de données.
Erreurs fréquentes en production
La première est de ne pas définir de limites de ressources (requests et limits) : sans elles, un pod emballé consomme toute la mémoire du nœud et provoque l'éviction de ses voisins. La deuxième est de traiter les conteneurs comme des animaux de compagnie et non comme du bétail, en stockant l'état à l'intérieur du conteneur plutôt que dans des volumes persistants ou des bases de données externes. La troisième est d'exécuter en tant que root et de monter le socket Docker à l'intérieur du conteneur, ce qui revient à offrir l'hôte. La quatrième est d'ignorer les health checks (liveness et readiness probes), sans lesquels Kubernetes ne sait pas si un pod est réellement prêt à recevoir du trafic. La cinquième, très fréquente, est d'adopter Kubernetes pour trois services : sa complexité opérationnelle ne s'amortit qu'à une certaine échelle, et pour de petites charges Docker Compose ou un PaaS managé suffisent souvent.
Foire aux questions
Ai-je besoin de Kubernetes si j'utilise déjà Docker ?
Pas nécessairement. Docker résout l'empaquetage et l'exécution de conteneurs sur un hôte. Kubernetes résout l'orchestration de nombreux conteneurs sur de nombreux hôtes : autoscaling, reprise après panne, déploiements progressifs et équilibrage. Si vous gérez peu de services sur un seul serveur, Docker Compose peut suffire ; Kubernetes apporte de la valeur lorsque l'échelle et la haute disponibilité le justifient.
Les conteneurs sont-ils moins sûrs que les machines virtuelles ?
L'isolation du conteneur est plus faible car il partage le noyau de l'hôte, si bien qu'une évasion compromet potentiellement toute la machine. Toutefois, avec des images minimales, une exécution sans root, des politiques réseau, le scan de vulnérabilités et, si une forte isolation est requise, des runtimes sandbox (gVisor, Kata Containers), on atteint un niveau de sécurité apte à la production. La règle est la défense en profondeur.
Quel runtime Kubernetes utilise-t-il maintenant que Docker a été déprécié ?
Kubernetes a retiré le composant dockershim, mais cela ne signifie pas que les images Docker cessent de fonctionner : elles respectent le standard OCI et s'exécutent avec des runtimes compatibles CRI comme containerd (qui sous-tend d'ailleurs Docker) ou CRI-O. Le changement était interne ; les images construites avec Docker restent pleinement valables.
Comment gère-t-on l'état et les bases de données dans les conteneurs ?
L'état est externalisé dans des volumes persistants (PersistentVolume) adossés à du stockage bloc ou réseau. Pour les bases de données sur Kubernetes, on utilise des StatefulSets, qui fournissent une identité réseau stable et un stockage dédié par réplica, même si de nombreuses organisations préfèrent déléguer la base de données à un service managé du fournisseur cloud en raison de sa criticité.
Conclusion
Le choix entre machines virtuelles et conteneurs n'est pas un duel, mais une décision de couches : la VM apporte une forte isolation à la frontière de sécurité et les conteneurs apportent densité, vitesse de démarrage et reproductibilité dans la couche applicative, et l'usage courant en 2026 consiste à les combiner en exécutant Kubernetes sur des VM. Docker a résolu l'empaquetage reproductible qui a fait disparaître le « ça marche sur ma machine », et Kubernetes a résolu l'orchestration déclarative qui permet à des centaines de conteneurs de s'autoréparer et de monter en charge sans intervention manuelle. Le risque réel ne tient pas à la technologie mais à son adoption sans discipline : des conteneurs root sans limites de ressources, des images non scannées et des clusters sans RBAC transforment une architecture moderne en surface d'attaque. Adopter les conteneurs est rentable lorsque l'échelle le justifie et lorsque le durcissement (NIST SP 800-190, benchmarks CIS) est traité comme une exigence et non comme un ornement. Chez Summum Sistemas, nous concevons des architectures de conteneurs reproductibles, des pipelines de CI/CD avec scan d'images et des clusters Kubernetes durcis, dimensionnés à l'échelle réelle de chaque client et non à la mode du moment.