Du conteneur à l'orchestrateur
Comprendre pourquoi les conteneurs remplacent progressivement les VM et ce qu'un orchestrateur apporte en plus.
À retenir
- Les conteneurs isolent des processus via namespaces et cgroups, en partageant le noyau hôte.
- Un orchestrateur comme Kubernetes maintient un état désiré via une boucle de réconciliation continue.
- La densité et la rapidité des conteneurs s'accompagnent d'une surface d'attaque partagée à durcir.
- L'adoption de Kubernetes se justifie surtout à partir de plusieurs dizaines de services ou d'un besoin de haute disponibilité.
Isolation de processus vs virtualisation matérielle
Un conteneur n'est pas une machine virtuelle allégée : c'est un processus Linux isolé par des mécanismes noyau (namespaces pour l'isolation des vues réseau/PID/montage, cgroups pour la limitation CPU/mémoire/IO). Il partage le noyau de l'hôte, ce qui explique un démarrage en dizaines de millisecondes contre plusieurs dizaines de secondes pour une VM, et une empreinte mémoire réduite à l'image applicative plus quelques Mo de runtime.
| Caractéristique | VM | Conteneur |
|---|---|---|
| Isolation | Hyperviseur, noyau dédié | Namespaces + cgroups, noyau partagé |
| Démarrage typique | 30-60 s | 50-500 ms |
| Empreinte disque | Go (OS complet) | Mo à quelques centaines de Mo |
| Densité par hôte | Dizaines | Centaines à milliers |
| Surface d'attaque | Noyau isolé | Noyau partagé, durcissement requis |
Point clé
la densité et la vitesse de démarrage des conteneurs viennent du partage du noyau hôte ; c'est aussi leur principal risque de sécurité si l'isolation n'est pas complétée par seccomp, AppArmor/SELinux et des utilisateurs non-root.
Pourquoi un orchestrateur devient nécessaire
Docker seul gère un conteneur sur un hôte. Dès qu'on dépasse quelques dizaines de conteneurs répartis sur plusieurs machines, il faut répondre à des questions que l'humain ne peut plus traiter manuellement : où placer chaque conteneur selon les ressources disponibles, que faire quand un hôte tombe, comment router le trafic vers la bonne instance, comment appliquer une mise à jour sans coupure de service. Kubernetes (projet CNCF) répond à ces besoins via une boucle de réconciliation permanente : l'utilisateur déclare un état désiré (nombre de réplicas, version d'image), et des contrôleurs comparent en continu cet état à l'état réel pour corriger les écarts.
Sur le terrain
un pod qui redémarre en boucle (CrashLoopBackOff) n'est pas un bug de Kubernetes mais le signe que la boucle de réconciliation fait exactement son travail : elle relance ce que l'application n'arrive pas à maintenir stable.
Arbitrage coûts et compétences
Adopter Kubernetes a un coût réel : apprentissage de l'API, exploitation du control plane (ou facturation d'un service managé type EKS/GKE/AKS), observabilité supplémentaire. Pour une poignée de services stables, un simple Docker Compose ou un PaaS managé reste souvent plus rentable. Le seuil de rentabilité se situe généralement autour de plusieurs dizaines de services ou d'un besoin fort d'auto-scaling et de haute disponibilité multi-zone.
Attention
migrer vers Kubernetes sans revoir l'application (gestion de la configuration externalisée, health checks, arrêt propre sur SIGTERM) ne fait que déplacer les incidents, pas les résoudre.
Astuce
avant tout projet de migration, cartographiez les dépendances d'état (sessions, fichiers locaux) : les applications qui écrivent sur le disque local sans volume externe sont les premières causes d'échec en environnement conteneurisé.