3 min de lecture
L’essentiel
- Kubernetes est la référence en matière d’orchestration de conteneurs – mais pas toujours le meilleur choix.
- Docker Swarm offre 80 % des fonctionnalités avec seulement 20 % de la complexité, pour les équipes de petite à moyenne taille.
- HashiCorp Nomad orchestre des conteneurs, des machines virtuelles et des travaux batch sur une seule plateforme.
- AWS ECS et Google Cloud Run éliminent totalement la gestion des clusters en tant que services gérés.
- Le choix dépend de la taille de l’équipe, du type de charge de travail et des capacités opérationnelles – pas de la mode.
Kubernetes a remporté le marché de l’orchestration de conteneurs. Mais la domination sur le marché ne signifie pas qu’il constitue toujours la solution adaptée à chaque cas d’usage. Pour une équipe de cinq développeurs gérant une dizaine de services, Kubernetes est souvent une surcapacité – avec une courbe d’apprentissage qui peut prendre des semaines et une complexité opérationnelle nécessitant l’implication d’une demi-équipe dédiée aux opérations. Des alternatives existent.
Le dilemme Kubernetes : puissant, mais complexe
Kubernetes peut pratiquement tout faire : déploiements progressifs, mise à l’échelle automatique, découverte de services, gestion des secrets, politiques réseau, définitions de ressources personnalisées. Cette puissance a un prix : un cluster Kubernetes prêt pour la production exige une compréhension approfondie des réseaux (plugins CNI, Ingress Controller), du stockage (CSI, PersistentVolumes), de la sécurité (RBAC, NetworkPolicies, PodSecurityStandards) et de la supervision (Prometheus, Grafana, Alertmanager).
Pour une équipe plateforme comptant trois ingénieurs ou plus expérimentés sur Kubernetes, cela reste gérable. Pour une petite équipe qui doit, parallèlement, développer de nouvelles fonctionnalités, cela devient un goulot d’étranglement en termes de ressources. La question ne devrait pas être « Sommes-nous capables de mettre en œuvre Kubernetes ? », mais bien « Avons-nous réellement besoin de Kubernetes ? »
Docker Swarm : l’alternative pragmatique
Docker Swarm est intégré nativement à Docker, ne nécessite aucun outil séparé et peut être mis en place en 15 minutes. Un cluster Swarm prend en charge les mises à jour progressives, la découverte de services, l’équilibrage de charge et la gestion des secrets – autant de fonctionnalités dont 80 % des équipes ont réellement besoin.
Ses limites : pas de mise à l’échelle automatique native (nécessite une implémentation manuelle ou via script), pas de Ingress Controller intégré (Traefik ou Nginx peuvent servir de solution de contournement), communauté et écosystème limités. Docker a, de fait, cessé le développement actif de Swarm – il fonctionne toujours, mais n’est plus activement amélioré.
Pour qui : les équipes gérant de 3 à 20 services, qui ont besoin d’une orchestration de conteneurs sans pouvoir justifier la complexité de Kubernetes. Souvent utilisé comme point d’entrée avant une migration éventuelle vers Kubernetes.
HashiCorp Nomad : le généraliste
Nomad orchestre non seulement des conteneurs, mais aussi des machines virtuelles, des applications Java et des travaux batch. Cela en fait la seule alternative capable de supporter nativement des charges de travail hétérogènes. Son architecture est plus simple que celle de Kubernetes : un cluster Nomad se compose uniquement de serveurs et de clients – pas de cluster etcd, pas de configuration du serveur API, pas de plugins CNI.
Nomad s’intègre parfaitement à l’écosystème HashiCorp : Consul pour la découverte de services, Vault pour la gestion des secrets, Terraform pour l’infrastructure. Pour les entreprises utilisant déjà des outils HashiCorp, Nomad constitue donc le choix naturel.
Sa limitation : son écosystème est plus petit que celui de Kubernetes. Moins d’intégrations tierces, moins de support communautaire, et moins d’ingénieurs expérimentés sur Nomad disponibles sur le marché du travail.
Services gérés : pas de cluster, pas de problème
AWS ECS (Elastic Container Service) est l’orchestrateur de conteneurs propre à Amazon – entièrement intégré à l’écosystème AWS et plus simple à utiliser que EKS (Kubernetes sur AWS). Avec Fargate comme couche de calcul, la gestion des clusters disparaît totalement : on définit simplement des tâches et des services, et AWS s’occupe de l’infrastructure.
Google Cloud Run va encore plus loin : déploiement de conteneurs en un seul clic, mise à l’échelle automatique (y compris jusqu’à zéro instance), facturation à l’appel. Pour les charges de travail basées sur HTTP et sans communication complexe entre services, Cloud Run est la solution la plus simple disponible sur le marché.
Azure Container Apps se positionne de manière similaire à Cloud Run : conteneurs serverless avec mise à l’échelle automatique basée sur KEDA et intégration de Dapr pour les modèles de microservices.
Matrice de décision : quel outil pour quel contexte ?
Kubernetes si : plus de 50 services, exigence multi-cloud, équipe plateforme importante, réseau complexe, contrôleurs personnalisés requis.
Docker Swarm si : petite équipe (< 5 développeurs), < 20 services, démarrage rapide, déploiement sur site (on-premise), absence d’expertise Kubernetes.
Nomad si : charges de travail hétérogènes (conteneurs + machines virtuelles + travaux batch), utilisation préalable de la pile HashiCorp, recherche d’une solution simple répondant aux exigences d’entreprise.
ECS/Cloud Run si : environnement natif AWS/GCP, équipe souhaitant se concentrer sur le code plutôt que sur l’infrastructure, services basés sur HTTP, pas de besoin multi-cloud.
Questions fréquentes
Docker Swarm est-il mort ?
Pas mort, mais en mode maintenance. Docker concentre ses efforts sur Docker Desktop et Docker Hub. Swarm fonctionne de façon stable, mais ne reçoit plus de nouvelles fonctionnalités. Pour les configurations existantes, ce n’est pas un problème. Pour les nouveaux projets, il convient toutefois de considérer sa pérennité à long terme.
Peut-on migrer de Docker Swarm vers Kubernetes ?
Oui, et c’est plus simple que depuis des configurations basées sur des machines virtuelles. Les images conteneur sont identiques. Les fichiers Docker Compose peuvent être convertis en manifestes Kubernetes à l’aide de l’outil kompose. La migration concerne principalement le réseau, le stockage et la configuration des déploiements.
ECS est-il moins coûteux qu’EKS ?
ECS lui-même est gratuit – vous ne payez que pour les ressources de calcul (EC2 ou Fargate). EKS applique une redevance de 0,10 USD par heure (~73 USD/mois) en plus des coûts liés au calcul. Pour les petites configurations, ECS est donc moins coûteux. À grande échelle, cette différence s’atténue.
Pourquoi tous les développeurs n’utilisent-ils pas Cloud Run ?
Cloud Run est optimal pour les charges de travail orientées requêtes (API, sites web). Pour les charges de travail impliquant des connexions persistantes (WebSockets, streaming), un maillage de services (service mesh) complexe ou des exigences réseau spécifiques, Kubernetes reste le meilleur choix. Cloud Run abstrait trop de détails pour ces cas d’usage.
Aurons-nous vraiment besoin d’une orchestration de conteneurs ?
Pas nécessairement. Pour quelques services, un simple serveur équipé de Docker Compose et d’un proxy inverse suffit souvent. L’orchestration de conteneurs devient pertinente à partir d’une dizaine de services, lorsque des déploiements progressifs, une mise à l’échelle automatique et une découverte de services sont nécessaires.
Source de l’image : Pexels / Jan van der Wolf
