5.1Swarm vs Kubernetes : quand passer à l'orchestration ?
L'essentiel en 30 secondes
- Compose = une machine : il ne répartit pas sur plusieurs hôtes, ne remplace pas un nœud mort, n'équilibre pas finement la charge — dès qu'il faut multi-machine, zéro-downtime ou auto-réparation, il faut orchestrer.
- Swarm = multi-hôte simple : intégré à Docker, proche de Compose, idéal pour 2 à 5 machines (réplicas, mise à jour sans coupure).
- Kubernetes = parc exigeant : le standard à grande échelle (déploiements, services, autoscaling, secrets) mais un apprentissage sérieux — règle : Compose → Swarm → Kubernetes, par besoin prouvé, jamais par mode.
Mini-cas filé — Idir, devops junior à Alger
Idir, devops junior à Alger, fait tourner l'appli de sa petite structure sur un seul serveur avec Compose : ça marche. Un jour, on lui demande « pourquoi pas Kubernetes ? ». Au lieu de foncer, il audite : une machine, des mises à jour simples, aucune exigence multi-hôte. Verdict : Compose bien outillé (CI, sauvegardes, healthchecks) suffit. Il note quand même la marche suivante : si l'équipe passe à 2 ou 3 machines avec besoin de réplicas, ce sera Swarm ; Kubernetes seulement si le parc et les équipes l'exigent. Ce cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 5.2, 5.3 et 5.4.
Ce même cas revient dans le cours, le schéma, le script et le défi 48h — et continue en 5.2, 5.3 et 5.4.
1. Ce que Compose ne fait pas
Compose excelle sur une machine : il lance, relie et rejoue un stack de façon fiable. Mais il ne répartit pas les conteneurs sur plusieurs hôtes, ne remplace pas automatiquement un nœud mort, et n'équilibre pas finement la charge entre réplicas. Idir le vérifie sur son serveur à Alger : tant qu'il n'a qu'un hôte et des mises à jour simples, ces limites ne le gênent pas.
Dès qu'on veut du zéro-downtime sur plusieurs machines, du multi-hôte ou de l'auto-réparation, il faut un orchestrateur : un pilote multi-machines qui place les réplicas, surveille et répare. La question n'est donc pas « quel outil est à la mode ? » mais « quelle douleur réelle dois-je traiter ? ».
2. Swarm : le grand frère de Compose
Swarm est intégré à Docker et parle presque Compose (docker stack deploy -c compose.yml). On l'apprend vite : un manager, des workers, des réplicas, des mises à jour réplica par réplica. Idir y voit l'étape naturelle si sa structure passe à 2 ou 3 machines : mêmes réflexes Compose, plus la répartition et la mise à jour sans coupure.
Idéal pour 2 à 5 machines et des besoins simples. Sa limite : un écosystème et une finesse moindres que Kubernetes (pas d'autoscaling natif aussi poussé, moins d'extensions). Pour du multi-hôte simple, c'est un excellent rapport effort/bénéfice.
3. Kubernetes : le standard exigeant
Kubernetes orchestre à grande échelle : déploiements, services à adresse stable, autoscaling, secrets, exposition avancée. Mais il exige un apprentissage sérieux et un cluster à opérer — ou un cluster managé opéré par un fournisseur. Idir retient la règle d'escalade : Compose → Swarm → Kubernetes, un cran à la fois, par besoin prouvé.
Un Kubernetes sans besoin, c'est de la complexité sans bénéfice : plus de pièces à surveiller, sauvegarder et mettre à jour, pour aucun gain si une machine suffisait. On monte d'un cran quand la douleur l'exige — jamais pour apprendre en production.
Le saviez-vous ?
Un Kubernetes sans besoin, c'est de la complexité sans bénéfice.
🔎 Exemple concret — La grille de décision d'Idir
Chaque cran répond à une douleur réelle.
1 machine, deploiements simples -> Compose + CI + sauvegardes
2-5 machines, replicas, MAJ sans coupure -> Swarm (stack deploy)
Parc, autoscaling, multi-equipes -> Kubernetes (manage)
Question piege : on veut du K8s
-> Quel besoin precis ? Sinon : Compose.Lecture : Idir place son besoin réel sur l'échelle avant de choisir.
Leçon : un orchestrateur sans besoin = complexité sans bénéfice.
Vocabulaire de la section
- Orchestrateur
- Le pilote multi-machines : il place les réplicas, surveille et répare.
Exemple simple : Idir compare Compose (un hôte) à un orchestrateur dès qu'il faut plusieurs machines.
Ce que ce n'est pas : un simple fichier Compose sur une seule machine.
Réflexe : ai-je besoin de répartir sur plusieurs hôtes ?
- Réplica
- Un exemplaire d'un service, réparti par l'orchestrateur.
Exemple simple : Idir prévoit 3 réplicas de son appli web sur son futur cluster.
Ce que ce n'est pas : un conteneur unique lancé à la main.
Réflexe : combien d'exemplaires mon service exige-t-il ?
- Rolling update
- La mise à jour sans coupure, réplica par réplica.
Exemple simple : Idir met à jour son appli un réplica à la fois, le service répond toujours.
Ce que ce n'est pas : tout arrêter puis relancer en pleine journée.
Réflexe : ma mise à jour coupe-t-elle le service ?
- Nœud
- Une machine membre du cluster (manager ou worker).
Exemple simple : Idir compte ses machines réelles avant de choisir son échelle.
Ce que ce n'est pas : un conteneur isolé.
Réflexe : combien de machines ai-je vraiment ?
- Managé
- Un cluster opéré par un fournisseur au lieu d'être opéré à la main.
Exemple simple : Idir vise un cluster managé si Kubernetes devient nécessaire.
Ce que ce n'est pas : un cluster bricolé sans équipe pour l'opérer.
Réflexe : qui opère le cluster si je choisis Kubernetes ?
En pratique — Auditer votre besoin
- Listez vos machines et vos services réels (comme Idir : une machine, une appli web).
- Notez vos exigences : coupure acceptable ? multi-hôte ? autoscaling ?
- Placez-vous sur l'échelle Compose / Swarm / Kubernetes.
- Écrivez la prochaine étape SEULEMENT si le besoin l'exige.
Script prêt à dire — justifier le choix d'échelle
« Aujourd'hui à Alger, notre appli tourne sur une machine avec des mises à jour simples : Compose avec CI, sauvegardes et healthchecks suffit. Si on passe à plusieurs machines avec besoin de réplicas, je propose Swarm ; Kubernetes seulement si le parc et les équipes l'exigent. On monte d'un cran par besoin prouvé, pas par mode. »
À dire à l'équipe pour cadrer le choix avant tout changement d'outil.
Modèle copier-coller — fiche choix d'échelle
FICHE CHOIX D'ECHELLE — date : ___
MACHINES REELLES : ___ · SERVICES : ___
EXIGENCES : coupure OK ? OUI / NON · multi-hote ? OUI / NON · autoscaling ? OUI / NON
ECHELLE : Compose / Swarm / Kubernetes (entourer)
PREUVE DU BESOIN : ___
PROCHAINE ETAPE : ___ (seulement si besoin prouve)Solo / petit budget
Idir seul : Compose + CI + sauvegardes suffit — noter la marche Swarm au cas où.
TPE / équipe réduite
Une fiche d'audit affichée : chacun voit pourquoi on reste sur Compose pour l'instant.
PME à Alger
Idir cale à Alger une revue avec son référent : machines, exigences et prochaine étape écrite.
Équipe qui démarre
Binôme : l'un liste les machines, l'autre les exigences — décision commune, écrite.
✓ Bonnes pratiques
- Épuisez Compose + CI avant de monter d'un cran.
- Swarm pour le multi-hôte simple (2 à 5 machines).
- Kubernetes de préférence en managé si Kubernetes il faut.
✗ Pièges fréquents
- Passer à Kubernetes « pour apprendre » en production.
- Croire que l'orchestrateur sauvegarde vos données.
- Multiplier les outils avant que les besoins existent.
Points clés à retenir
- Compose = 1 hôte, simple et robuste — ne répartit ni ne répare sur plusieurs machines.
- Swarm = multi-hôte simple (2 à 5 machines), proche de Compose, idéal pour débuter l'orchestration.
- Kubernetes = parc exigeant, standard à grande échelle, apprentissage sérieux.
- On monte par besoin prouvé : Compose → Swarm → Kubernetes, jamais par mode.
Défi 48h — appliquez demain
Remplissez la fiche choix d'échelle (modèle ci-dessus) pour votre appli réelle : vos machines et vos exigences justifient-elles votre échelle ?
- Je peux placer mon besoin sur l'échelle Compose / Swarm / Kubernetes.
- Ma fiche d'audit est écrite et justifiée.
- Je sais pourquoi un orchestrateur sans besoin coûte plus qu'il rapporte.
Questions fréquentes
Swarm est-il dépassé face à Kubernetes ?
Non : intégré à Docker et maintenu, Swarm reste redoutable à son échelle — le multi-hôte simple (quelques machines, réplicas, mises à jour sans coupure). Moins à la mode que Kubernetes, mais bien plus simple à apprendre et à opérer. Choisissez par besoin : Swarm pour quelques machines, Kubernetes pour un parc avec des exigences avancées.
Peut-on rester en Compose en production ?
Oui, dans beaucoup de cas (une ou deux machines) avec CI, healthchecks, sauvegardes testées et reverse proxy. L'orchestration n'est pas un passage obligé : Compose bien outillé bat un orchestrateur surdimensionné. On ne monte vers Swarm ou Kubernetes que sur besoin prouvé (multi-hôte, zéro-downtime, autoscaling).
Une appli sur 1 serveur, mises à jour simples. Que choisir ?