3 min de lecture<\/p>\n
Kubernetes a remport\u00e9 le march\u00e9 de l\u2019orchestration de conteneurs. Mais la domination sur le march\u00e9 ne signifie pas qu\u2019il constitue toujours la solution adapt\u00e9e \u00e0 chaque cas d\u2019usage. Pour une \u00e9quipe de cinq d\u00e9veloppeurs g\u00e9rant une dizaine de services, Kubernetes est souvent une surcapacit\u00e9 – avec une courbe d\u2019apprentissage qui peut prendre des semaines et une complexit\u00e9 op\u00e9rationnelle n\u00e9cessitant l\u2019implication d\u2019une demi-\u00e9quipe d\u00e9di\u00e9e aux op\u00e9rations. Des alternatives existent.<\/strong><\/p>\n Kubernetes peut pratiquement tout faire : d\u00e9ploiements progressifs, mise \u00e0 l\u2019\u00e9chelle automatique, d\u00e9couverte de services, gestion des secrets, politiques r\u00e9seau, d\u00e9finitions de ressources personnalis\u00e9es. Cette puissance a un prix : un cluster Kubernetes pr\u00eat pour la production exige une compr\u00e9hension approfondie des r\u00e9seaux (plugins CNI, Ingress Controller<\/em>), du stockage (CSI, PersistentVolumes<\/em>), de la s\u00e9curit\u00e9 (RBAC, NetworkPolicies<\/em>, PodSecurityStandards<\/em>) et de la supervision (Prometheus<\/em>, Grafana<\/em>, Alertmanager<\/em>).<\/p>\n Pour une \u00e9quipe plateforme comptant trois ing\u00e9nieurs ou plus exp\u00e9riment\u00e9s sur Kubernetes, cela reste g\u00e9rable. Pour une petite \u00e9quipe qui doit, parall\u00e8lement, d\u00e9velopper de nouvelles fonctionnalit\u00e9s, cela devient un goulot d\u2019\u00e9tranglement en termes de ressources. La question ne devrait pas \u00eatre \u00ab Sommes-nous capables de mettre en \u0153uvre Kubernetes ? \u00bb, mais bien \u00ab Avons-nous r\u00e9ellement besoin de Kubernetes ? \u00bb<\/p>\n Docker Swarm est int\u00e9gr\u00e9 nativement \u00e0 Docker, ne n\u00e9cessite aucun outil s\u00e9par\u00e9 et peut \u00eatre mis en place en 15 minutes. Un cluster Swarm prend en charge les mises \u00e0 jour progressives, la d\u00e9couverte de services, l\u2019\u00e9quilibrage de charge et la gestion des secrets – autant de fonctionnalit\u00e9s dont 80 % des \u00e9quipes ont r\u00e9ellement besoin.<\/p>\n Ses limites : pas de mise \u00e0 l\u2019\u00e9chelle automatique native (n\u00e9cessite une impl\u00e9mentation manuelle ou via script), pas de Ingress Controller<\/em> int\u00e9gr\u00e9 (Traefik<\/em> ou Nginx<\/em> peuvent servir de solution de contournement), communaut\u00e9 et \u00e9cosyst\u00e8me limit\u00e9s. Docker a, de fait, cess\u00e9 le d\u00e9veloppement actif de Swarm – il fonctionne toujours, mais n\u2019est plus activement am\u00e9lior\u00e9.<\/p>\n Pour qui : les \u00e9quipes g\u00e9rant de 3 \u00e0 20 services, qui ont besoin d\u2019une orchestration de conteneurs sans pouvoir justifier la complexit\u00e9 de Kubernetes. Souvent utilis\u00e9 comme point d\u2019entr\u00e9e avant une migration \u00e9ventuelle vers Kubernetes.<\/p>\n 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\u00e9t\u00e9rog\u00e8nes. Son architecture est plus simple que celle de Kubernetes : un cluster Nomad se compose uniquement de serveurs et de clients – pas de cluster etcd<\/em>, pas de configuration du serveur API, pas de plugins CNI.<\/p>\n Nomad s\u2019int\u00e8gre parfaitement \u00e0 l\u2019\u00e9cosyst\u00e8me HashiCorp : Consul<\/em> pour la d\u00e9couverte de services, Vault<\/em> pour la gestion des secrets, Terraform<\/em> pour l\u2019infrastructure. Pour les entreprises utilisant d\u00e9j\u00e0 des outils HashiCorp, Nomad constitue donc le choix naturel.<\/p>\n Sa limitation : son \u00e9cosyst\u00e8me est plus petit que celui de Kubernetes. Moins d\u2019int\u00e9grations tierces, moins de support communautaire, et moins d\u2019ing\u00e9nieurs exp\u00e9riment\u00e9s sur Nomad disponibles sur le march\u00e9 du travail.<\/p>\n AWS ECS (Elastic Container Service)<\/strong> est l\u2019orchestrateur de conteneurs propre \u00e0 Amazon – enti\u00e8rement int\u00e9gr\u00e9 \u00e0 l\u2019\u00e9cosyst\u00e8me AWS et plus simple \u00e0 utiliser que EKS (Kubernetes sur AWS). Avec Fargate<\/em> comme couche de calcul, la gestion des clusters dispara\u00eet totalement : on d\u00e9finit simplement des t\u00e2ches et des services, et AWS s\u2019occupe de l\u2019infrastructure.<\/p>\n Google Cloud Run<\/strong> va encore plus loin : d\u00e9ploiement de conteneurs en un seul clic, mise \u00e0 l\u2019\u00e9chelle automatique (y compris jusqu\u2019\u00e0 z\u00e9ro instance), facturation \u00e0 l\u2019appel. Pour les charges de travail bas\u00e9es sur HTTP et sans communication complexe entre services, Cloud Run est la solution la plus simple disponible sur le march\u00e9.<\/p>\n Azure Container Apps<\/strong> se positionne de mani\u00e8re similaire \u00e0 Cloud Run : conteneurs serverless avec mise \u00e0 l\u2019\u00e9chelle automatique bas\u00e9e sur KEDA<\/em> et int\u00e9gration de Dapr<\/em> pour les mod\u00e8les de microservices.<\/p>\n Kubernetes<\/strong> si : plus de 50 services, exigence multi-cloud, \u00e9quipe plateforme importante, r\u00e9seau complexe, contr\u00f4leurs personnalis\u00e9s requis.<\/p>\n Docker Swarm<\/strong> si : petite \u00e9quipe (< 5 d\u00e9veloppeurs), < 20 services, d\u00e9marrage rapide, d\u00e9ploiement sur site (on-premise<\/em>), absence d\u2019expertise Kubernetes.<\/p>\n Nomad<\/strong> si : charges de travail h\u00e9t\u00e9rog\u00e8nes (conteneurs + machines virtuelles + travaux batch), utilisation pr\u00e9alable de la pile HashiCorp, recherche d\u2019une solution simple r\u00e9pondant aux exigences d\u2019entreprise.<\/p>\n ECS\/Cloud Run<\/strong> si : environnement natif AWS\/GCP, \u00e9quipe souhaitant se concentrer sur le code plut\u00f4t que sur l\u2019infrastructure, services bas\u00e9s sur HTTP, pas de besoin multi-cloud.<\/p>\n Pas mort, mais en mode maintenance. Docker concentre ses efforts sur Docker Desktop et Docker Hub. Swarm fonctionne de fa\u00e7on stable, mais ne re\u00e7oit plus de nouvelles fonctionnalit\u00e9s. Pour les configurations existantes, ce n\u2019est pas un probl\u00e8me. Pour les nouveaux projets, il convient toutefois de consid\u00e9rer sa p\u00e9rennit\u00e9 \u00e0 long terme.<\/p>\n<\/details>\n Oui, et c\u2019est plus simple que depuis des configurations bas\u00e9es sur des machines virtuelles. Les images conteneur sont identiques. Les fichiers Docker Compose peuvent \u00eatre convertis en manifestes Kubernetes \u00e0 l\u2019aide de l\u2019outil kompose<\/em>. La migration concerne principalement le r\u00e9seau, le stockage et la configuration des d\u00e9ploiements.<\/p>\n<\/details>\nLe dilemme Kubernetes : puissant, mais complexe<\/h2>\n
Docker Swarm : l\u2019alternative pragmatique<\/h2>\n
HashiCorp Nomad : le g\u00e9n\u00e9raliste<\/h2>\n
Services g\u00e9r\u00e9s : pas de cluster, pas de probl\u00e8me<\/h2>\n
Matrice de d\u00e9cision : quel outil pour quel contexte ?<\/h2>\n
Questions fr\u00e9quentes<\/h2>\n
Docker Swarm est-il mort ?<\/strong><\/summary>\n
Peut-on migrer de Docker Swarm vers Kubernetes ?<\/strong><\/summary>\n