Docker Swarm ou Kubernetes : simplicité sous charge variable

Pour une petite production aux services prévisibles, Docker Swarm réduit le travail d’orchestration. Quand le trafic devient irrégulier, que plusieurs applications se disputent les ressources ou que les règles de déploiement se multiplient, Kubernetes offre davantage de leviers. La simplicité de Swarm peut alors perdre de son intérêt opérationnel, sans qu’un volume de requêtes rende Kubernetes intrinsèquement plus rapide.

Le choix tient à la taille du cluster, aux pannes qu’il doit supporter et au temps que l’équipe peut consacrer à son exploitation. Une charge élevée mais régulière peut rester compatible avec Swarm si l’application et l’infrastructure la supportent. Des pointes imprévisibles rendent plus précieuses les fonctions de placement, de mise à l’échelle et de contrôle de l’état des services.

Pourquoi Swarm convient à une petite production

Les concepts de Swarm décrivent une orchestration intégrée à Docker Engine : un manager reçoit l’état souhaité d’un service, distribue ses tâches aux workers et les réaffecte si un nœud devient indisponible. Le DNS interne attribue un nom aux services et l’équilibrage répartit leurs requêtes dans le cluster. La même couche sert ainsi à publier et répliquer un service sans installer séparément un plan de contrôle Kubernetes.

Cette économie de configuration est utile si l’équipe exploite déjà Docker et héberge quelques services dont les besoins changent peu. Les réplicas, le réseau et les ports sont décrits dans l’état voulu ; le manager cherche ensuite à maintenir cet état. L’effort reste concentré sur l’application, les images, la surveillance et les dépendances, plutôt que sur la personnalisation de l’orchestrateur.

La réplication a toutefois une limite concrète : relancer un conteneur ne répare ni une base de données indisponible ni des données conservées uniquement sur le nœud perdu. Pour un service avec état, le choix du stockage, des sauvegardes et du chemin réseau compte autant que celui de l’orchestrateur. Une petite équipe peut préférer cette architecture plus simple, à condition de traiter séparément ces dépendances.

Ce que montrent les mesures de CPU et de débit

Les tableaux du mémoire de Ram Prakash comparent une application React déployée sur Docker Swarm et sur Amazon EKS, avec trois instances EC2 t2.micro dans chaque environnement et des requêtes envoyées par Apache Bench. Aux paliers de 1 000, 10 000 et 20 000 requêtes, le CPU affiché atteint respectivement 55 %, 70 % et 85 % pour Swarm, contre 45 %, 55 % et 65 % pour EKS. Au dernier palier, le débit publié est de 41,15 requêtes par seconde côté Swarm et de 45 côté EKS.

Dans ces tableaux, l’utilisation du CPU est inférieure côté EKS dès le premier palier : la différence n’apparaît pas soudainement à forte charge. L’écart de débit se resserre au dernier palier et les résultats changent avec le scénario de concurrence. Dans l’un des essais avec requêtes concurrentes, Swarm affiche même un débit supérieur ; une victoire uniforme d’EKS ne résume donc pas les mesures publiées.

Un total de requêtes envoyées pendant un essai n’est pas un seuil de trafic soutenu. Pour transformer ces paliers en règle d’architecture, il faudrait connaître le profil de charge dans le temps et les exigences de latence de l’application concernée. Les chiffres montrent quelles métriques bougent dans ce montage, mais ne disent pas à quel débit un autre service devrait changer d’orchestrateur.

Pourquoi le résultat ne se transpose pas tel quel

Le protocole porte sur une application web simple et deux déploiements complets. Le montage EKS comprend AWS Elastic Load Balancing, alors que Swarm utilise son équilibrage intégré ; le réseau, les machines, les réglages et le service managé participent donc au résultat observé. L’écart de CPU ou de débit ne peut pas être attribué au seul moteur d’orchestration.

Le résumé présente Swarm comme plus économe en CPU sous forte charge, alors que le tableau de CPU place EKS plus bas à tous les paliers affichés. Une analyse ultérieure décrit EKS comme supérieur en débit dans tous les scénarios, mais le tableau inclut un cas de concurrence favorable à Swarm et un cas d’égalité. Ces discordances invitent à retenir les valeurs pour ce protocole précis, sans en faire un classement général.

Placement, disponibilité et retours arrière

La présentation de Kubernetes décrit la découverte de services, le montage de systèmes de stockage, le placement selon les ressources déclarées, les déploiements avec retour arrière, le remplacement de conteneurs défaillants et la mise à l’échelle horizontale. Ces mécanismes deviennent utiles lorsque les services n’ont pas les mêmes besoins de CPU et de mémoire ou doivent être répartis selon des contraintes différentes. Leur intérêt est la finesse du contrôle, qui demande en contrepartie des choix de configuration et des compétences d’exploitation.

La disponibilité dépend de l’ensemble de l’application. Redémarrer un conteneur qui échoue, retirer une instance non prête du trafic et conserver des données accessibles après une panne répondent à des problèmes distincts. Une plateforme à fort trafic peut nécessiter les trois ; l’orchestrateur fournit des mécanismes, mais la définition des états de santé et l’architecture des données restent du ressort de l’équipe.

Swarm sait également gérer les changements de version : la documentation des services Docker décrit les mises à jour progressives, le retour manuel à la configuration précédente et un retour automatique configurable lorsqu’une mise à jour échoue. Le besoin d’annuler un déploiement, pris isolément, ne suffit donc pas à imposer Kubernetes. La différence se joue plutôt dans l’ensemble des règles à coordonner autour du déploiement : placement, ressources, santé, stockage et variation du nombre de réplicas.

Un choix par nœuds, compétences et charge

Le guide d’administration de Swarm montre qu’un manager unique ne tolère pas sa propre perte, tandis que trois managers gardent le quorum si l’un tombe. Il précise aussi que multiplier les managers réduit les performances d’écriture du plan de gestion, car davantage de participants doivent valider les changements. Compter les nœuds ne mesure donc ni la capacité de l’application à absorber le trafic ni la disponibilité réelle des données.

Sur un seul nœud, Swarm peut simplifier la gestion d’un service conteneurisé si l’équipe connaît déjà Docker. Ce choix n’apporte pas, à lui seul, la continuité de service face à la panne de la machine.
Sur quelques nœuds et avec un trafic régulier, Swarm reste cohérent si les mises à jour, le placement et les dépendances de données demeurent simples. Le coût de formation et de maintenance de Kubernetes peut alors dépasser l’intérêt des fonctions supplémentaires effectivement utilisées.
Pour de nombreux services soumis à des pointes, à des contraintes de placement différentes ou à des exigences de disponibilité plus fines, Kubernetes devient plus pertinent si l’équipe peut l’exploiter correctement. La charge seule ne dispense pas d’évaluer le réseau, le stockage et le comportement de l’application.

Swarm favorise une exploitation légère lorsque l’environnement reste lisible. Kubernetes prend l’avantage fonctionnel quand il faut piloter finement plusieurs charges, leurs variations et leurs pannes. Aucun des paliers du benchmark ne remplace cette distinction.