Nomad : l'alternative à Kubernetes pour les équipes qui veulent rester simples

Pour comprendre ce phénomène, il faut remonter à 2014. Google publie Kubernetes en Open Source, et en quelques années, l'outil devient le standard de facto de l'orchestration de conteneurs. Douze ans plus tard, en 2026, son hégémonie est telle que poser la question « faut-il vraiment utiliser Kubernetes ? » relève presque de l'hérésie dans certains cercles DevOps. Et pourtant, les données racontent une autre histoire.

Kubernetes est un outil remarquable. Il résout des problèmes réels de déploiement, de mise à l'échelle et de résilience pour des organisations qui opèrent à grande échelle. Mais cette puissance a un coût que beaucoup d'équipes sous-estiment au moment de l'adoption.

La complexite n'est pas un bug, c'est une feature

Un cluster Kubernetes de production implique : un control plane (etcd, API server, scheduler, controller manager), des composants réseau (CNI, kube-proxy ou ses alternatives), un ingress controller, un système de stockage (CSI drivers), un gestionnaire de certificats, un système de monitoring, et souvent un service mesh. Chacun de ces composants a son propre cycle de vie, ses propres mises à jour et ses propres modes de défaillance.

Pour une équipe de 50 ingénieurs gérant des centaines de microservices, cette complexité est justifiée. Pour une équipe de 5 personnes avec 10 services, elle devient un fardeau. Nuançons toutefois : le problème n'est pas Kubernetes en soi, mais son adoption dans des contextes où il n'est pas nécessaire.

Le cout reel de K8s

Au-delà de l'infrastructure, le coût principal est humain. La courbe d'apprentissage de Kubernetes est considérable. Un ingénieur compétent sur K8s nécessite des mois de formation et de pratique. Les concepts de Pods, Deployments, StatefulSets, DaemonSets, Ingress, NetworkPolicies, RBAC, ServiceAccounts forment un écosystème dense que chaque membre de l'équipe doit maîtriser à un degré suffisant.

HashiCorp Nomad, lancé en 2015, propose une vision différente de l'orchestration. Là où Kubernetes a choisi l'exhaustivité, Nomad a choisi la simplicité architecturale.

Un binaire, un cluster

L'architecture de Nomad tient en un seul binaire. Les nœuds serveurs et clients exécutent le même programme avec des configurations différentes. Il n'y a pas d'etcd externe à gérer, pas de composants supplémentaires obligatoires. L'installation d'un cluster Nomad de production peut se faire en une heure ; pour Kubernetes, comptez plutôt une journée (ou plusieurs si vous ne passez pas par un service managé).

# Un job Nomad complet pour deployer une application web
job "webapp" {
  datacenters = ["dc1"]
  type        = "service"

  group "web" {
    count = 3

    network {
      port "http" {
        to = 8080
      }
    }

    task "app" {
      driver = "docker"

      config {
        image = "registry.example.com/webapp:v2.1"
        ports = ["http"]
      }

      resources {
        cpu    = 500
        memory = 256
      }
    }
  }
}

Comparez cela avec l'équivalent Kubernetes : un Deployment, un Service, potentiellement un Ingress, un ConfigMap, un HorizontalPodAutoscaler. Chacun dans son propre fichier YAML (ou un fichier multi-documents), avec des références croisées par labels et selectors.

Au-dela des conteneurs

C'est probablement l'avantage le plus significatif de Nomad. Là où Kubernetes est fondamentalement conçu pour des conteneurs (malgré l'ajout tardif de support pour d'autres runtimes), Nomad orchestre nativement :

• Des conteneurs Docker (via le driver docker)
• Des processus isolés (via le driver exec nativement, ou le plugin communautaire exec2)
• Des machines virtuelles (via le driver qemu)
• Des applications Java (via le driver java)
• Des tâches batch avec planification avancée

Pour les organisations qui gèrent un mix d'applications legacy et de services conteneurisés, cette polyvalence évite de maintenir deux systèmes d'orchestration distincts. Un cas fréquent : une entreprise avec des applications Java monolithiques qui cohabitent avec de nouveaux microservices en conteneurs. Avec Kubernetes, il faudrait conteneuriser les applications legacy ou les gérer séparément. Avec Nomad, elles coexistent dans le même scheduler.

Scaling

Nomad affirme pouvoir gérer plus de 10 000 nœuds avec une empreinte minimale. L'équipe HashiCorp a démontré des clusters de cette taille avec seulement 3 à 5 nœuds serveurs. Kubernetes, à cette échelle, nécessite une configuration spécifique d'etcd, potentiellement du sharding, et une attention particulière au nombre de watchers sur l'API server.

Les données racontent une autre histoire que celle du « Kubernetes scale mieux » : les deux outils scalent, mais le coût opérationnel n'est pas le même. Un cluster Nomad de 10 000 nœuds nécessite moins d'expertise pour être maintenu qu'un cluster K8s équivalent.

Integration avec l'ecosysteme HashiCorp

Nomad s'intègre nativement avec Consul pour le service discovery et le service mesh, et avec Vault pour la gestion des secrets. Ces intégrations sont de première classe, pas des add-ons. Pour les équipes déjà investies dans l'écosystème HashiCorp (Terraform, Vault, Consul), l'ajout de Nomad est naturel et la courbe d'apprentissage est réduite.

À l'inverse, Kubernetes a son propre écosystème de service discovery (CoreDNS), de gestion de secrets (Secrets natifs ou solutions externes comme External Secrets Operator), et de service mesh (Istio, Linkerd). Chaque choix implique une évaluation, une intégration et une maintenance.

Configuration

Nomad utilise HCL (HashiCorp Configuration Language), le même langage que Terraform et les autres outils HashiCorp. Si votre équipe gère déjà son infrastructure avec Terraform ou Terragrunt, la syntaxe sera familière.

Kubernetes utilise YAML, un format dont les subtilités (indentation significative, types implicites, ancres) sont une source bien connue de bugs subtils. Nuançons toutefois : des outils comme Helm, Kustomize ou Podman simplifient la génération de manifestes, et l'écosystème YAML de K8s est extrêmement bien outillé.

Haute disponibilite

Les deux outils supportent la haute disponibilité, mais avec des approches différentes. Nomad utilise le protocole Raft pour la réplication du state entre les nœuds serveurs. Kubernetes s'appuie sur etcd, une base de données distribuée séparée qui doit être gérée indépendamment (sauf dans les distributions managées).

Pour une équipe qui gère elle-même ses clusters, la HA Nomad est plus simple à mettre en place et à déboguer. L'état du cluster est dans le binaire Nomad ; il n'y a pas de composant externe dont la panne peut compromettre l'ensemble du control plane.

Workloads batch et periodiques

Le scheduler batch de Nomad est un de ses points forts historiques. Les jobs batch et sysbatch permettent de planifier des tâches ponctuelles ou périodiques avec une granularité fine. Kubernetes a les CronJobs, mais leur comportement en cas d'échec et leur gestion de la concurrence sont notoirement complexes à configurer correctement.

Environnements mixtes

Les entreprises avec des applications hétérogènes (conteneurs, VMs, processus natifs) trouvent dans Nomad un orchestrateur unifié. Pas besoin de forcer la conteneurisation de toutes les applications. C'est une approche pragmatique qui respecte l'existant.

Équipes réduites

Pour comprendre ce phénomène, il faut regarder la réalité du marché : la majorité des équipes d'infrastructure comptent moins de 10 personnes. À cette échelle, la charge opérationnelle de Kubernetes est disproportionnée par rapport aux bénéfices. Nomad offre 80 % des fonctionnalités d'orchestration pour 20 % de la complexité opérationnelle.

Il serait malhonnête de ne pas mentionner les cas où Kubernetes est clairement le meilleur choix :

• Écosystème cloud-native : si vous utilisez intensivement des Operators, des CRDs, et des outils comme ArgoCD ou Flux, l'écosystème K8s est incomparablement plus riche
• Services managés : EKS, GKE, AKS éliminent une grande partie de la charge opérationnelle ; Nomad n'a pas d'équivalent managé aussi mature
• Recrutement : trouver des ingénieurs compétents sur Kubernetes est plus facile que sur Nomad, simplement par effet de volume
• Standards de l'industrie : certains clients ou réglementations imposent Kubernetes comme référence

Pour les équipes qui explorent les runtimes de conteneurs au-delà de Docker, containerd et d'autres solutions s'intègrent nativement avec Kubernetes. C'est un avantage écosystémique difficile à ignorer.

Les données racontent une autre histoire que celle du choix binaire. De plus en plus d'organisations adoptent un pattern où Kubernetes gère les workloads cloud-native et Nomad gère les workloads legacy ou les tâches batch. Ce n'est pas un aveu de faiblesse architecturale ; c'est une reconnaissance pragmatique que les outils ont des forces différentes.

Chez SHPV, nous accompagnons nos clients dans le choix et le déploiement de solutions d'orchestration adaptées à leur contexte. Que ce soit K3s pour des clusters de production légers ou Nomad pour des environnements mixtes, l'objectif est toujours le même : la solution la plus simple qui répond au besoin réel.

Quel que soit l'orchestrateur choisi, la securite des conteneurs reste un sujet transversal. Les bonnes pratiques de profils de securite Docker s'appliquent aussi bien dans un contexte Kubernetes que Nomad. L'isolation des workloads, la gestion des secrets et le controle d'acces sont des preoccupations qui transcendent le choix de l'outil.

Le choix entre Nomad et Kubernetes n'est pas une question de supériorité technique. C'est une question d'adéquation entre un outil et un contexte. Si votre équipe est petite, vos workloads hétérogènes et votre besoin d'orchestration modéré, Nomad mérite sérieusement d'être évalué. Si vous opérez dans un écosystème cloud-native à grande échelle, Kubernetes reste le choix le plus rationnel.

Nuançons toutefois : le pire choix est celui que l'on fait par défaut, sans évaluation. Kubernetes n'est pas « le meilleur » orchestrateur. Nomad non plus. Mais l'un des deux est probablement le meilleur pour votre situation spécifique.

• Nomad vs. Kubernetes: Which Orchestration Tool Is Right for Your Enterprise? : comparaison enterprise détaillée (Pure Storage)
• Nomad, Kubernetes, and a Pragmatic Look at Choosing Orchestrators : perspective officielle HashiCorp
• What is Nomad? : documentation officielle HashiCorp