Les conteneurs partagent le noyau du système d'exploitation de l'hôte, ils démarrent donc en quelques millisecondes et pèsent quelques mégaoctets, contre les minutes et les gigaoctets d'une machine virtuelle exécutant son propre système d'exploitation. Docker a popularisé cet empaquetage en couches à partir de 2013 ; Kubernetes, publié par Google en 2014, est aujourd'hui l'orchestrateur standard pour des milliers de conteneurs en production.
La virtualisation et la conteneurisation résolvent le même problème historique à partir de deux niveaux d'abstraction différents : comment isoler et empaqueter un logiciel pour qu'il s'exécute de façon reproductible, indépendamment du matériel sous-jacent. La machine virtuelle virtualise l'intégralité du matériel et charge un système d'exploitation invité au-dessus d'un hyperviseur (VMware ESXi, KVM, Hyper-V). Le conteneur, en revanche, virtualise le système d'exploitation : il partage le noyau de l'hôte et isole les processus grâce à des primitives du noyau Linux telles que les namespaces (isolation de 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, alors qu'une machine virtuelle prend 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 placé 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écortiquons les deux technologies avec rigueur technique : comment une image est construite, comment Kubernetes orchestre, quelles erreurs coûtent cher en production et quelles réglementations de sécurité s'appliquent.
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) au-dessus d'un système de fichiers union (overlayfs). Un conteneur est une instance en cours d'exécution de cette image, avec une fine couche inscriptible par-dessus. Cette architecture en couches permet de partager des couches communes entre images et d'accélérer les téléchargements, puisque seules les nouvelles couches sont transférées.
La valeur de Docker réside dans la reproductibilité : le classique « ça marche sur ma machine » disparaît, car l'image contient l'application et toutes ses dépendances figées. Les bonnes pratiques de construction incluent :
- Builds multi-étapes : compiler dans une image volumineuse puis ne copier que le binaire résultant dans une image finale minimale, réduisant drastiquement la taille et la surface d'attaque.
- Images de base minimales (Alpine, distroless) pour limiter les dépendances vulnérables.
- Exécution en tant qu'utilisateur non-root avec la directive
USER, empêchant une évasion de conteneur d'hériter des privilèges de l'hôte. - Immutabilité et étiquetage versionné au lieu de
:latest, pour garantir des déploiements déterministes.
Kubernetes : orchestrer les conteneurs à grande échelle
Lorsque l'on passe d'une poignée de conteneurs à des centaines répartis sur des dizaines de serveurs, il faut un orchestrateur qui décide où placer chaque charge de travail, redémarre ce qui échoue, monte en charge selon la demande et route 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 assigne les pods aux nœuds et les controllers qui réconcilient) des nœuds de travail (worker nodes), où le kubelet exécute les conteneurs via un runtime compatible CRI (containerd, CRI-O).
La plus petite unité déployable n'est pas le conteneur mais le pod, qui regroupe un ou plusieurs conteneurs partageant réseau et stockage. Au-dessus des pods, Kubernetes propose des abstractions déclaratives : le Deployment gère les répliques et les déploiements progressifs (rolling updates), le Service fournit une IP stable et une répartition de charge pour 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 corresponde à cet état.
La mise à l'échelle automatique s'articule sur trois niveaux : le Horizontal Pod Autoscaler (HPA) ajoute ou supprime des répliques 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 supprime des nœuds chez le fournisseur cloud selon la demande globale.
Tableau comparatif : machine virtuelle contre 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 grande (noyau propre) | Plus petite (noyau partagé) |
La conclusion pratique n'est pas qu'une technologie remplace l'autre : elles coexistent. Il est courant d'exécuter Kubernetes par-dessus des machines virtuelles, combinant la forte isolation de la VM à la frontière de sécurité avec la densité et l'agilité du conteneur au niveau applicatif.
Microservices et modèle de déploiement
Les conteneurs sont le véhicule naturel de l'architecture microservices, dans laquelle une application monolithique est décomposée en petits services déployables et scalables indépendamment. 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 avec bascule du trafic) ou le canary (un petit pourcentage du trafic est routé vers la nouvelle version et observé avant un déploiement plus large). Ces techniques sont à la base de la livraison continue moderne, intégrée aux pipelines CI/CD et, de plus en plus, au GitOps (Argo CD, Flux), où le dépôt Git est la source de vérité unique de l'état du cluster.
Sécurité et réglementations dans les environnements conteneurisés
La surface d'attaque change par rapport aux machines virtuelles et exige des contrôles spécifiques. NIST SP 800-190, l'Application Container Security Guide, est la référence officielle et traite des risques dans l'image (vulnérabilités, secrets intégrés), le registre, l'orchestrateur et le runtime. L'organisation CIS publie des benchmarks de durcissement pour Docker comme pour Kubernetes, qu'il est recommandé d'appliquer comme référence de base. Mesures concrètes : analyser 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 avec un magasin 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) exige chiffrement et minimisation, et la portabilité des conteneurs entre régions et fournisseurs doit respecter les règles relatives aux transferts internationaux de données.
Erreurs courantes en production
La première est de ne pas définir de limites de ressources (requests et limits) : sans elles, un pod incontrôlé consomme toute la mémoire du nœud et déclenche l'éviction de ses voisins. La deuxième est de traiter les conteneurs comme des animaux de compagnie plutôt que comme du bétail, en conservant l'état à l'intérieur du conteneur au lieu de volumes persistants ou de bases de données externes. La troisième est d'exécuter en 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 se justifie qu'à partir d'une certaine échelle, et pour de petites charges de travail, Docker Compose ou un PaaS managé suffit souvent.
Questions fréquentes
Ai-je besoin de Kubernetes si j'utilise déjà Docker ?
Pas nécessairement. Docker résout l'empaquetage et l'exécution des conteneurs sur un hôte. Kubernetes résout l'orchestration de nombreux conteneurs sur de nombreux hôtes : mise à l'échelle automatique, reprise après incident, déploiements progressifs et répartition de charge. Si vous gérez quelques 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écurisés 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. Cependant, avec des images minimales, une exécution non-root, des politiques réseau, une analyse des vulnérabilités et, lorsqu'une isolation forte est requise, des environnements d'exécution en bac à sable (gVisor, Kata Containers), on atteint un niveau de sécurité adapté à la production. La règle est la défense en profondeur.
Quel environnement d'exécution Kubernetes utilise-t-il maintenant que Docker a été abandonné ?
Kubernetes a supprimé le composant dockershim, mais cela ne signifie pas que les images Docker cessent de fonctionner : elles suivent le standard OCI et s'exécutent avec des runtimes compatibles CRI comme containerd (qui, en réalité, est le socle de Docker) ou CRI-O. Le changement était interne ; les images construites avec Docker restent parfaitement valides.
Comment l'état et les bases de données sont-ils gérés dans les conteneurs ?
L'état est externalisé dans des volumes persistants (PersistentVolume) adossés à un stockage bloc ou réseau. Pour les bases de données dans Kubernetes, on utilise des StatefulSets, qui fournissent une identité réseau stable et un stockage dédié par réplique, bien que 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é, rapidité de démarrage et reproductibilité au niveau applicatif, et l'approche habituelle en 2026 consiste à les combiner en exécutant Kubernetes par-dessus des VM. Docker a résolu l'empaquetage reproductible qui a éliminé le « ça marche sur ma machine », et Kubernetes a résolu l'orchestration déclarative qui permet à des centaines de conteneurs de s'auto-réparer et de monter en charge sans intervention manuelle. Le vrai risque ne réside pas dans la technologie mais dans son adoption sans discipline : des conteneurs root sans limites de ressources, des images non analysées et des clusters sans RBAC transforment une architecture moderne en surface d'attaque. Adopter les conteneurs est rentable quand l'échelle le justifie et quand le durcissement (NIST SP 800-190, benchmarks CIS) est traité comme une exigence plutôt que comme une décoration. Chez Summum Sistemas, nous concevons des architectures de conteneurs reproductibles, des pipelines CI/CD avec analyse d'images et des clusters Kubernetes durcis, dimensionnés selon l'échelle réelle de chaque client plutôt que selon la mode du moment.