Pourquoi orchestrer des conteneurs : ce qu'un moteur ne fait pas

25 min
Quiz · 6 questions

Par Stéphane Robert mis à jour le 13 octobre 2026

Améliorer cette page

Que voulez-vous signaler ?

L’issue s’ouvre déjà remplie avec le titre et l’adresse de cette page.

Un orchestrateur de conteneurs pilote un parc de machines comme une seule : vous lui décrivez ce qui doit tourner, il décide où, vérifie en permanence et corrige seul. Docker sait lancer et relancer un conteneur sur une machine ; il ne sait pas choisir une autre machine quand la première tombe. Cette leçon s'adresse à celles et ceux qui sortent de la formation Docker et abordent Kubernetes. Elle montre les six besoins qu'un moteur seul ne couvre pas, la notion d'état désiré sur laquelle tout repose, et pourquoi Kubernetes s'est imposé, avant d'apprendre son vocabulaire.

Ce que vous allez apprendre

Distinguer ce que Docker fait déjà sur une machine de ce qu'il ne fait pas sur plusieurs.
Nommer les six besoins qu'un orchestrateur couvre : placement, redémarrage, mise à l'échelle, réseau entre hôtes, mises à jour progressives, état désiré.
Expliquer la boucle qui compare l'état désiré à l'état réel.
Situer Kubernetes face à Docker Swarm et Nomad, et savoir quand aucun orchestrateur n'est nécessaire.

Prérequis

Vous savez lancer un conteneur avec docker run, publier un port et lire docker ps, comme dans la formation Docker. Les politiques de redémarrage (--restart) y sont présentées dans Exécuter et dépanner des conteneurs. Aucune connaissance de Kubernetes n'est requise : la leçon n'utilise aucune commande Kubernetes que vous deviez taper vous-même.

Qu'est-ce qu'un orchestrateur de conteneurs ?

Un orchestrateur est un logiciel qui gère des conteneurs sur plusieurs machines à partir d'une description de ce qui doit tourner. Il n'exécute aucun conteneur lui-même : sur chaque machine, appelée nœud, il confie l'exécution au moteur local (containerd, CRI-O). Son travail est de décider et de surveiller : quel conteneur sur quel nœud, combien de copies, et que faire quand l'une disparaît.

La place exacte de chaque couche, runtime, moteur et orchestrateur, est démontrée dans Runtime, moteur, orchestrateur : qui fait quoi ?. Cette leçon part de là et pose une seule question : qu'est-ce qui manque quand on n'a qu'un moteur et plusieurs serveurs ?

Que sait déjà faire Docker sur une seule machine ?

Sur une machine, Docker relance déjà un conteneur qui s'arrête, grâce à sa politique de redémarrage. C'est souvent ce qui fait croire qu'un orchestrateur est superflu. L'essai suivant lance nginx avec --restart unless-stopped, arrête le processus principal depuis l'intérieur du conteneur, puis relit le compteur de redémarrages.

docker run -d --name orch-web --restart unless-stopped \
  nginx:1.31.3-alpine3.24@sha256:4a73073bd557c65b759505da037898b61f1be6cbcc3c2c3aeac22d2a470c1752
docker exec orch-web nginx -s stop
docker inspect -f '{{.RestartCount}} {{.State.Status}}' orch-web

1 running

Le démon Docker a vu le conteneur s'arrêter et l'a relancé : le compteur RestartCount passe de 0 à 1. Retenez la limite : ce démon ne voit que sa machine. Si le serveur lui-même s'éteint, plus personne ne relance quoi que ce soit, et aucun autre serveur ne prend le relais. Nettoyez avec docker rm -f orch-web.

Que manque-t-il dès qu'on passe à plusieurs machines ?

Avec trois serveurs et un moteur sur chacun, six tâches retombent sur vous : placer, relancer ailleurs, multiplier, relier, mettre à jour et surveiller. Le tableau ci-dessous les met en regard de ce que fait un orchestrateur. Lisez la colonne du milieu comme votre journée sans orchestrateur : chaque ligne est un script ou une intervention manuelle.

Besoin	Avec un moteur seul, sur chaque serveur	Avec un orchestrateur
Placement	Vous choisissez le serveur à la main	Il choisit un nœud qui a la place
Redémarrage	Relance locale, rien si le serveur tombe	Il recrée le conteneur sur un autre nœud
Mise à l'échelle	Un `docker run` par copie, sur chaque serveur	Vous changez un nombre, il ajuste
Réseau entre hôtes	Adresses à suivre, répartiteur à configurer	Un nom stable qui joint toutes les copies
Mise à jour progressive	Arrêt, mise à jour, relance, serveur par serveur	Remplacement copie par copie, retour arrière
État désiré	La vérité est dans votre tête ou vos scripts	Elle est écrite, et vérifiée en continu

Placement : qui choisit la machine ?

Le placement consiste à choisir sur quel nœud lancer chaque conteneur. Sans orchestrateur, c'est vous qui regardez la mémoire et le CPU libres de chaque serveur. Un orchestrateur confie ce choix à un composant appelé scheduler (ordonnanceur), qui tient compte des ressources demandées et des contraintes que vous posez.

Redémarrage : que se passe-t-il quand un serveur tombe ?

Le redémarrage local de Docker couvre un processus qui plante, pas une machine perdue. Un orchestrateur détecte qu'un nœud ne répond plus et recrée ses conteneurs sur les nœuds restants. C'est ce qu'on appelle l'auto-réparation, et c'est la différence la plus visible avec un moteur seul.

Mise à l'échelle : combien de copies ?

La mise à l'échelle fait passer une application de 2 à 10 copies (appelées réplicas) pour encaisser la charge, puis la redescendre. Avec un orchestrateur, vous modifiez un nombre dans la description et il lance ou arrête les copies nécessaires, réparties sur les nœuds. Certains savent même ajuster ce nombre selon la charge mesurée.

Réseau entre hôtes : comment joindre une copie qui change de place ?

Le réseau entre hôtes est le problème que l'on sous-estime le plus. Une copie recréée sur un autre nœud change d'adresse IP. Un orchestrateur fournit un nom stable et une adresse qui ne bouge pas, derrière lesquels il répartit le trafic entre toutes les copies, où qu'elles tournent.

Mise à jour progressive : comment changer de version sans coupure ?

La mise à jour progressive (en anglais rolling update) remplace les copies une par une : une nouvelle version démarre, prouve qu'elle répond, puis une ancienne s'arrête. Si la nouvelle version échoue, l'orchestrateur s'arrête et permet un retour arrière. À la main, la même opération demande un script fragile et une fenêtre de maintenance.

Qu'est-ce que l'état désiré, et pourquoi tout repose dessus ?

L'état désiré est la description de ce qui doit tourner, que l'orchestrateur compare sans arrêt à ce qui tourne réellement. Vous n'écrivez plus « lance trois conteneurs », vous écrivez « il doit y avoir trois copies de cette image ». La différence paraît mince ; elle change tout. Une commande s'exécute une fois et s'oublie, une déclaration reste vraie et se vérifie en permanence.

Le schéma montre cette boucle de réconciliation. Suivez le chemin en gras : vous déclarez une fois, puis l'orchestrateur observe, compare et agit, indéfiniment. Les cinq besoins précédents en découlent : un nœud perdu, une copie en trop ou une version à changer ne sont que des écarts entre l'état réel et l'état désiré.

Source · SVG

C'est aussi ce qui rend un orchestrateur prévisible : la description vit dans un fichier, se relit, se versionne dans Git et se rejoue à l'identique sur un autre cluster. Cette approche porte un nom, la gestion déclarative, que les leçons Kubernetes emploient en permanence.

À quoi ressemble l'orchestration sur un vrai cluster ?

Sur un cluster Kubernetes de trois nœuds, supprimer une copie ou éteindre un nœud ne demande aucune intervention : l'orchestrateur recrée ce qui manque. Les sorties ci-dessous viennent d'un cluster local kind en Kubernetes 1.37 (un nœud de pilotage, dit plan de contrôle, et deux nœuds d'exécution). Vous n'avez rien à taper ici : vous créerez ce cluster vous-même deux leçons plus loin. Regardez seulement la colonne NODE et les noms de copies.

Trois copies de nginx ont été déclarées. Le scheduler les a réparties sur les deux nœuds d'exécution :

NAME                   READY   STATUS    NODE
web-79cb948dbf-cwqcr   1/1     Running   orchestration-worker2
web-79cb948dbf-nz26m   1/1     Running   orchestration-worker
web-79cb948dbf-whq2s   1/1     Running   orchestration-worker

La copie cwqcr est ensuite supprimée à la main. Trois secondes après, une copie neuve, 428jc, l'a remplacée : l'état désiré dit trois, l'état réel disait deux, l'écart a été corrigé.

NAME                   READY   STATUS    NODE
web-79cb948dbf-428jc   1/1     Running   orchestration-worker2
web-79cb948dbf-nz26m   1/1     Running   orchestration-worker
web-79cb948dbf-whq2s   1/1     Running   orchestration-worker

Dernier essai, celui qu'un moteur seul ne sait pas faire : le nœud orchestration-worker, qui portait deux copies, est éteint (docker stop, puisque les nœuds kind sont des conteneurs). Son état passe à Unknown en moins d'une minute. L'orchestrateur attend ensuite un délai de grâce de cinq minutes par défaut, au cas où le nœud reviendrait, puis recrée les deux copies sur le nœud survivant.

NAME                   READY   STATUS        NODE
web-79cb948dbf-428jc   1/1     Running       orchestration-worker2
web-79cb948dbf-6hh9h   1/1     Running       orchestration-worker2
web-79cb948dbf-b6sj9   1/1     Running       orchestration-worker2
web-79cb948dbf-nz26m   1/1     Terminating   orchestration-worker
web-79cb948dbf-whq2s   1/1     Terminating   orchestration-worker

Les deux copies du nœud perdu sont marquées Terminating et deux copies neuves tournent sur orchestration-worker2 : le compte de trois est rétabli sans qu'aucune commande n'ait été tapée. Ce délai de cinq minutes se règle ; son réglage relève des leçons sur le placement, plus loin dans la formation.

Pourquoi Kubernetes s'est-il imposé ?

Kubernetes s'est imposé parce qu'il a réuni l'expérience de Google, une gouvernance neutre et une API que tout l'écosystème peut étendre. Google l'a publié en open source en 2014, en s'inspirant de Borg, son orchestrateur interne. La version 1.0 est sortie en 2015, et le projet a été confié à la CNCF (Cloud Native Computing Foundation, rattachée à la Linux Foundation), dont il est devenu le premier projet diplômé le 6 mars 2018.

Trois raisons expliquent l'écart avec les autres outils, et elles comptent plus que les fonctionnalités prises une à une :

Une gouvernance neutre : aucun éditeur ne possède Kubernetes, ce qui a permis à tous les fournisseurs cloud de proposer une offre managée (EKS chez AWS, GKE chez Google, AKS chez Microsoft, et chez des acteurs européens).
Une API extensible : on peut y ajouter ses propres types d'objets. Les outils de réseau, de stockage ou de sécurité se branchent dessus au lieu de réinventer un orchestrateur.
Un modèle unique : la même description fonctionne sur un poste, dans un datacenter ou chez un fournisseur cloud, ce qui en fait le socle commun des équipes et des certifications.

Les autres orchestrateurs n'ont pas disparu. Le mode Swarm est intégré à Docker et reste le plus simple à prendre en main sur quelques machines ; il est décrit dans Docker Swarm. Nomad, de HashiCorp, orchestre aussi des charges qui ne sont pas des conteneurs, voir Nomad. Enfin OpenShift, de Red Hat, n'est pas un concurrent mais une distribution de Kubernetes enrichie, présentée dans OpenShift.

Faut-il toujours un orchestrateur ?

Non : sur une seule machine, un orchestrateur coûte plus qu'il ne rapporte. Kubernetes demande un plan de contrôle, les composants qui pilotent le cluster, à faire tourner, à mettre à jour et à sécuriser. Pour une application sur un seul serveur, Docker Compose décrit plusieurs conteneurs dans un fichier et suffit, voir Docker Compose. Compose n'est pas un orchestrateur : il ne choisit pas de machine et ne replace rien si l'hôte tombe.

Le besoin d'orchestrer naît avec la deuxième machine et avec l'exigence de disponibilité : dès qu'une panne de serveur ne doit plus couper le service, il faut quelqu'un pour relancer ailleurs. Le tableau de choix selon la taille du parc est dans Runtime, moteur, orchestrateur. Pour un parc réduit ou un homelab, K3s est une distribution allégée de Kubernetes.

À retenir

Un orchestrateur pilote des conteneurs sur plusieurs machines ; sur chaque nœud, il confie l'exécution au moteur local.
La politique --restart de Docker relance un conteneur sur sa machine, jamais sur une autre quand le serveur tombe.
Six besoins justifient un orchestrateur : placement, redémarrage ailleurs, mise à l'échelle, réseau entre hôtes, mises à jour progressives et état désiré.
L'état désiré est une description que l'orchestrateur compare en continu à l'état réel : chaque écart déclenche une action.
Kubernetes s'est imposé par sa gouvernance neutre (CNCF), son API extensible et son modèle unique du poste au cloud.
Swarm et Nomad restent utilisables ; Compose n'est pas un orchestrateur et suffit sur une seule machine.

Testez vos connaissances

Six questions vérifient que vous savez ce qu'un moteur seul ne fait pas, ce que recouvre l'état désiré, et quand un orchestrateur devient nécessaire.

Contrôle de connaissances

Validez vos connaissances avec ce quiz interactif

6 questions

5 min.

80% requis

Informations

Le chronomètre démarre au clic sur Démarrer
Questions à choix multiples, vrai/faux et réponses courtes
Vous pouvez naviguer entre les questions
Les résultats détaillés sont affichés à la fin