Orchestration d'entreprise.
Pas de Kubernetes requis.

Comment ces chiffres et affirmations ont été obtenus

1. La résidence géographique des données est un filtre de placement, et elle est livrée désactivée. Un déploiement porte odysseus.io/data-residency-country — un code ISO 3166-1 alpha-2 tel que CA ou DE — ou odysseus.io/data-residency-region, qui nomme un ensemble défini par l'opérateur de ces codes, ou odysseus.io/blocked-countries. L'ordonnanceur compare chacun aux étiquettes de pays et de région propres au nœud avant de placer quoi que ce soit, et un nœud qui ne satisfait pas l'exigence est retiré de l'ensemble des candidats — de sorte que le déploiement ne peut pas atterrir en dehors de sa géographie autorisée, plutôt que d'y être trouvé ensuite. Elle est activée par installation dans la configuration du plan de contrôle et est désactivée par défaut ; les régions sont les définitions propres de l'opérateur, pas les nôtres. Kubernetes peut exprimer la même contrainte : il fournit topology.kubernetes.io/region et topology.kubernetes.io/zone comme étiquettes de nœud bien connues, et l'affinité de nœud pour sélectionner dessus, mais pas d'étiquette de pays ou de résidence propre — donc la résidence y est assemblée à partir d'étiquettes personnalisées et de règles d'affinité — kubernetes.io. La différence réside dans l'endroit où le concept vit, pas dans la possibilité de le faire. Nomad n'a pas besoin d'un tel assemblage et cette ligne n'est pas un différenciateur par rapport à lui : region et datacenter sont de premier niveau dans son architecture, et un job contraint le placement sur ${node.datacenter}, ${node.region} ou toute valeur ${meta.<key>} définie par l'opérateur. Ce qui diffère là-bas est le vocabulaire plutôt que la puissance — le nôtre est une étiquette de résidence nommée portant des codes pays ISO et l'appartenance à une région, le leur une contrainte à usage général pointant vers ce que l'opérateur a écrit sur le nœud.
2. Les chiffres de mémoire d'Odysseus sont mesurés, pas modélisés. Les deux sont la mémoire résidente (RSS) du processus en cours d'exécution, échantillonnée sur une fenêtre de 14 minutes le 20 août 2026 sur deux installations en direct : production (plan de contrôle 47–51 Mo sur 19 échantillons, agent de nœud 26–28 Mo) et développement (plan de contrôle 49–64 Mo sur 18 échantillons, agent de nœud 26–28 Mo). Le plan de contrôle s'exécute une fois par installation ; l'agent s'exécute une fois par nœud. Le plan de contrôle publie lui-même le chiffre comme process_resident_memory_bytes sur son endpoint /metrics Prometheus, afin qu'il puisse être vérifié directement plutôt que tenu pour acquis. Nous citons la RSS plutôt que docker stats car cette dernière inclut le cache de pages récupérable, qui sur un conteneur récemment démarré affiche un chiffre plusieurs fois plus élevé sans qu'aucun n'appartienne à l'orchestrateur. Le chiffre de Kubernetes est le minimum documenté dans le guide d'installation kubeadm en amont : “2 Go ou plus de RAM par machine” — kubernetes.io.
3. Comparaison par nœud. Kubernetes en amont ne publie aucune réserve par défaut pour ses agents de nœud — kubeReserved et systemReserved sont tous deux livrés vides — il n'y a donc pas de chiffre officiel unique à citer. Le chiffre profilé est le profilage de ressources K3s publié par SUSE, qui place les composants Kubernetes sur un agent (worker) node — ses mots, “le kubelet et l'agent k3s” — à 275 Mo sur un Intel 8375C, à partir de lectures au 95e percentile en régime permanent — docs.k3s.io. K3s est un binaire unique fusionné avec son propre exécution intégré, c'est donc un plancher pour Kubernetes en amont exécutant les mêmes composants en tant que processus séparés, pas un équivalent. Les chiffres réservés sont une capacité que les fournisseurs gérés retiennent de chaque nœud worker avant qu'un conteneur d'application ne soit planifié, calculée à partir de leurs propres formules publiées : AWS EKS réserve (11 × max-pods) + 255 Mio (574 Mio sur un m5.large, qui supporte 29 pods) — docs.aws.amazon.com ; Google GKE réserve 25 % des premiers 4 Gio et 20 % des 4 Gio suivants plus 100 Mio (≈1,9 Gio sur un nœud de 8 Gio) — cloud.google.com. La capacité réservée est une allocation que l'ordonnanceur retient, pas une consommation mesurée ; nous l'étiquetons comme telle car les deux ne sont pas la même chose.
4. Les nombres de conteneurs sont par nœud, et le nôtre est une déclaration d'adéquation, pas une limite. La plage décrit où Odysseus est conçu pour se situer — au-dessus du point où Docker Compose atteint ses limites, en dessous du point où Kubernetes justifie sa complexité. C'est du positionnement, pas un résultat de benchmark, et nous ne le présentons pas comme tel. Un total de plateforme est ce chiffre par nœud sur le nombre de nœuds qu'un plan de contrôle gère — une conséquence architecturale, pas quelque chose que nous avons mesuré à l'échelle de la flotte, nous ne publions donc pas non plus de chiffre de flotte. Le chiffre de Kubernetes est le plafond documenté par ce projet pour un cluster supporté : “Pas plus de 110 pods par nœud”, énoncé à côté de “Pas plus de 5 000 nœuds” et “Pas plus de 300 000 conteneurs au total” — kubernetes.io. Les deux colonnes ne comptent pas la même unité — Kubernetes limite les pods, un pod contient un ou plusieurs conteneurs, et nous comptons les conteneurs — donc lisez-les comme adjacents plutôt que interchangeables. Nous ne convertissons pas entre eux, car le ratio dépend de la façon dont les pods sont construits. Les distributions gérées plafonnent encore plus bas : AWS EKS dérive la limite de pods par nœud à partir des interfaces réseau de la machine plutôt que de ce chiffre documenté, et son propre exemple chiffré est de 29 pods sur une machine à deux vCPU — le document cité dans la note 3. Nomad ne publie aucune limite par nœud, c'est pourquoi sa cellule le dit plutôt que de porter un chiffre. Le plus grand run HashiCorp publie est sa propre démonstration : 2 000 000 de conteneurs sur 6 100 clients — le mot de Nomad pour un nœud exécutant son agent — dans 10 régions AWS, planifiés en 22 minutes par trois serveurs — hashicorp.com — une moyenne d'environ 330 conteneurs par client. C'est une démonstration plutôt qu'une limite supportée, et c'est un nombre plus grand que tout ce que nous avons exécuté.
5. La colonne Nomad est sourcée, et elle remporte plusieurs lignes. Nomad est le pair le plus proche d'Odysseus dans ce tableau — un unique binaire, léger en ressources, et conçu pour s'intégrer avec le même Consul sur lequel cette plateforme fonctionne — donc un cadrage qui fonctionne contre Kubernetes serait injuste ici, et nous n'en avons pas utilisé un. Mises à jour progressives, canaris avec auto_promote, restauration automatique d'un déploiement échoué et retour au dernier job stable sont tous dans le bloc update de la spécification du job dans l'Édition Communauté — developer.hashicorp.com. L'autoscaling est réel, et arrive sous la forme d'un second démon à exécuter : le Nomad Autoscaler est « construit et publié séparément de Nomad », couvre la mise à l'échelle horizontale des applications et du cluster, et lit Prometheus parmi ses sources de métriques — developer.hashicorp.com. La gestion des secrets est au moins notre égale : le répertoire secrets/ d'une tâche est soutenu par un système de fichiers en mémoire et monté noexec — developer.hashicorp.com. Les politiques et rôles ACL sont dans l'Édition Communauté. Ce qui ne l'est pas : la journalisation d'audit, les quotas de ressources et la politique Sentinel sont dans Nomad Enterprise, tout comme le déploiement d'un job sur des régions fédérées — la fédération des régions elles-mêmes ne l'est pas — developer.hashicorp.com. Les espaces de noms sont dans l'Édition Communauté, et ils segmentent les jobs, les allocations, les déploiements et les évaluations ; la documentation est explicite sur le fait que « Nomad ne met pas dans un espace de noms les objets partagés entre plusieurs espaces de noms. Cela inclut les nœuds » — developer.hashicorp.com. Kubernetes trace la même ligne — « les ressources de bas niveau, telles que les Nœuds … ne sont dans aucun espace de noms » — kubernetes.io ; sur cette plateforme, un nœud est inscrit à un locataire, ce que cette ligne enregistre. Le chiffre des serveurs est l'architecture de référence propre à HashiCorp — « Un cluster Nomad comprend typiquement trois ou cinq serveurs », avec 2 à 4 cœurs et 8 à 16 Go de mémoire chacun pour un petit déploiement en production — developer.hashicorp.com. C'est un dimensionnement machine qu'un lecteur devrait traiter de la même manière que nous traitons le chiffre Kubernetes dans la note 2 : une recommandation, pas une mémoire processus mesurée. Nous n'avons trouvé aucun chiffre publié pour l'agent client, donc la colonne indique qu'il n'y en a pas plutôt que d'en deviner un, et la ligne sur la courbe d'apprentissage est notre estimation plutôt que la mesure de quiconque.