Les conteneurs sont des processus. Point final.
C’est le twist de l’OS que la plupart des ingénieurs traquent dans le bla-bla marketing : un processus, ou un arbre de processus, auquel Linux impose une réalité fictive. Des namespaces morcelés pour son petit monde à lui, des cgroups qui plaquent des plafonds sur les ressources — quotas CPU, limites mémoire. Pas de noyau invité. Pas de surcharge hyperviseur. Juste des astuces malignes qui transforment une machine en dizaines d’apps cloisonnées. Et voilà pourquoi ça domine les ops cloud aujourd’hui : AWS, GCP, Azure — tous bourrent 80 % des charges dans ces bestioles, selon les sondages récents CNCF, parce qu’elles consomment que dalle comparées aux VM.
Regardez, podman run le prouve noir sur blanc. Lancez cette commande — tout droit des tranchées :
podman run -d \
--name my-limited-httpd \
--replace \
--memory=512m \
--memory-swap=512m \
--cpus=1.5 \
--cpu-shares=512 \
--pids-limit=100 \
--blkio-weight=500 \
-p 8081:80 \
registry.access.redhat.com/ubi8/httpd-24
Et hop. Vous avez un conteneur HTTPD bridé à 512 Mo de RAM (pas de swap pour tricher), 1,5 cœur CPU, max 100 PIDs. Jetez un œil à pstree, et tout s’éclaire.
systemd(1)─┬─… ├─conmon(13669)───httpd(13684)─┬─cat(13727) … httpd pond ses petits, tous nichés sous conmon, le baby-sitter des processus.
Podman ne fait pas naître httpd en solo. Il s’appuie sur crun — la réécriture C ultra-rapide de runc, par défaut sur SLES 16 et consort. Crun clone() avec les flags namespace (PID, net, mount, à vous de choisir), grave les limites cgroup dans /sys/fs/cgroup, superpose les couches d’image en rootfs, lance execve() sur votre app. Puis paf — crun s’évapore. Conmon reste en retrait pour le plumbing I/O et les codes de sortie. La chaîne est limpide : podman → crun → noyau → votre httpd qui vit sa vie en isolation.
Le piège du jargon que raffolent les vendeurs
Mais. Les termes s’emmêlent exprès — la valorisation à 9 milliards de Docker a surfé là-dessus, en fusionnant noyau, OS, processus, image dans un “conteneur” flou. Pas clair quand votre app plante en OOM.
Noyau ? L’arbitre hardware : ordonnance les CPU, distribue la mémoire, applique namespaces/cgroups.
OS ? Noyau plus userland (libc, bash, systemd) — RHEL, c’est le plat complet.
Processus ? Tranche de programme avec PID, visible dans /proc.
Image ? Pile de plans — couches en lecture seule + config JSON. Le runtime fait tourner les instances ; une image, dix conteneurs, chacun avec son overlay d’écriture.
« Image = quoi exécuter. Spec runtime = comment l’exécuter. Le conteneur = le processus qui en résulte. »
Une fois pigé, le débogage se fait tout seul.
Image contre conteneur : confusion fatale ?
Les images restent inertes. Les conteneurs tournent. La spec OCI l’impose : dépaqueter les couches, appliquer la spec, lancer le processus. Crun (ou le poids lourd Go de runc) fait le sale boulot. Multiples runs ? Base en lecture seule partagée, écritures privées — sorcellerie du stockage qui économise des téraoctets en prod.
Le mythe s’effondre ici : pas de mini-Linux dedans. PID 1 ? Ruse namespace — l’hôte voit votre PID 42 du conteneur comme PID 1 à l’intérieur. Init global ? Toujours systemd(1) dehors.
Pourquoi les conteneurs écrasent les VM en 2024 ?
Les chiffres hurlent. Les VM virtualisent le hardware — 10-20 % de surcharge, selon les benchmarks Red Hat. Les conteneurs ? Moins de 1 % — même noyau, namespaces taillés sur mesure. Les clusters Kubernetes ronronnent là-dessus ; Datadog signale plus de 70 % des apps monitorées conteneurisées.
Mon avis — tout frais : ça rappelle les jails chroot de 1979, le premier hack d’isolation Unix. Les conteneurs ? Juste namespaces (années 2000) + cgroups (2007) boostés aux stéroïdes. Docker l’a reconditionné pour les VC, mais le noyau a porté le fardeau. Prono : eBPF monte en puissance — il greffera des contrôles plus fins sans swaps runtime, et poussera la part conteneur au-delà de 90 % d’ici 2026. Le baratin v
