企业级编排。
无需 Kubernetes。

这些数字和声明是如何得出的

1. 地理数据驻留是一种放置过滤器，默认处于关闭状态。 部署携带 odysseus.io/data-residency-country — 一个 ISO 3166-1 alpha-2 代码，例如 CA 或 DE — 或 odysseus.io/data-residency-region，它命名了一个由操作员定义的此类代码集合，或 odysseus.io/blocked-countries。调度器在放置任何内容之前，会将每个代码与节点自身的国家和地区标签 进行比较， 不满足要求的节点将从候选集中移除 — 因此 部署不能落在其允许的地理区域之外，而不是事后才被发现。它在控制平面的配置中按安装启用， 默认关闭；区域是操作员自己的定义，不是我们的。 Kubernetes 可以表达相同的约束：它提供了 topology.kubernetes.io/region 和 topology.kubernetes.io/zone 作为 节点标签，以及节点亲和性来基于它们进行选择，但它没有自己的国家或驻留标签 — 因此那里的驻留是通过自定义标签和亲和性规则组装的 — kubernetes.io。 区别在于概念存在于何处，而不是能否实现。 Nomad 不需要这样的组装，这一行并不是与它相比的差异化因素： region 和 datacenter 在其架构中是一等公民，作业 可以基于 ${node.datacenter}、${node.region} 或 任何操作员设置的 ${meta.<key>} 值来约束放置。那里不同的只是词汇， 而非能力 — 我们的驻留标签是携带 ISO 国家代码和区域成员资格的命名标签， 而他们的是指向操作员在节点上写入的任何内容的通用约束。
2. Odysseus 内存数据是实测的，而非建模的。 两者都是运行进程的常驻内存（RSS），在 2026 年 8 月 20 日的 14 分钟窗口内，在两个实时安装实例上采样：生产环境（控制平面 47–51 MB，19 个样本；节点代理程序 26–28 MB）和开发环境（控制平面 49–64 MB，18 个样本；节点代理程序 26–28 MB）。控制平面每个安装实例运行一次；代理程序每个节点运行一次。控制平面自身通过其 Prometheus /metrics 端点发布该数据为 process_resident_memory_bytes，因此可以直接验证，无需依赖信任。我们引用 RSS 而非 docker stats，因为后者包含可回收的页面缓存，在刚启动的容器上，这部分缓存会高出数倍，且不属于编排器。Kubernetes 的数据是上游 kubeadm 安装指南中记录的最低要求： “每台机器 2 GB 或更多 RAM” — kubernetes.io。
3. 逐节点比较。上游 Kubernetes 未为其节点代理程序发布默认预留资源——kubeReserved和systemReserved均为空——因此没有单一的官方数字可供引用。此处分析的数字是 SUSE 发布的 K3s 资源分析，该分析将代理程序（工作）节点上的 Kubernetes 组件——其原文为“kubelet 和 k3s agent”——在 Intel 8375C 上的稳态第 95 百分位读数定为 275 MB——docs.k3s.io。K3s 是一个单一合并的二进制文件，拥有自己的嵌入式运行时，因此这是上游 Kubernetes 以独立进程运行相同组件时的下限，并非等效值。预留数字是托管服务提供商在调度任何应用容器之前，从每个工作节点中扣除的容量，根据其自身发布的公式计算得出：AWS EKS 预留 (11 × max-pods) + 255 MiB（在 m5.large 上为 574 MiB，该实例支持 29 个 Pod）——docs.aws.amazon.com；Google GKE 预留前 4 GiB 的 25% 和接下来 4 GiB 的 20%，外加 100 MiB（在 8 GiB 节点上约为 1.9 GiB）——cloud.google.com。预留容量是调度程序扣除的配额，而非实测消耗；我们如此标注是因为两者并非同一回事。
4. 容器数量是按节点计算的，我们的表述是关于适用性的说明，而非上限。该范围描述了 Odysseus 设计定位的区间——高于 Docker Compose 力所不及的起点，低于 Kubernetes 复杂性开始显现的终点。这是定位说明，而非基准测试结果，我们也不将其作为基准测试结果呈现。平台总数是该按节点数字乘以控制平面管理的节点数量——这是架构上的推论，并非我们在大规模集群上实测的结果，因此我们也不发布集群规模的数字。Kubernetes 的数字是该项目自身文档中记录的受支持集群上限：“每个节点不超过 110 个 Pod”，同时声明“不超过 5,000 个节点”和“不超过 300,000 个容器”——kubernetes.io。这两列统计的单位不同——Kubernetes 限制的是 Pod，一个 Pod 包含一个或多个容器，而我们统计的是容器——因此请将它们视为相邻而非可互换的指标。我们不在两者之间进行换算，因为比例取决于 Pod 的构建方式。托管发行版的上限更低：AWS EKS 根据机器的网络接口而非该文档中的数字推导出每个节点的 Pod 上限，其自身示例为双 vCPU 机器上的 29 个 Pod——即注释 3 中引用的文档。Nomad 根本不发布任何按节点上限，因此其单元格如此说明而非提供数字。HashiCorp发布的最大运行规模是其自身的演示：在 10 个 AWS 区域中，跨 6,100 个客户端（Nomad 对运行其代理程序的节点的称呼）运行 2,000,000 个容器，由三个服务器在 22 分钟内完成调度——hashicorp.com——平均每个客户端约 330 个容器。这是演示而非受支持的上限，且该数字大于我们运行过的任何规模。
5. Nomad列已标注来源，且在多行中胜出。Nomad是本表中与Odysseus最接近的同类——单一二进制文件，资源占用轻，且设计为与本平台运行的同一Consul集成——因此在此使用针对Kubernetes的对比框架并不公平，我们并未采用。 滚动更新、带auto_promote的金丝雀发布、失败部署的自动回滚以及回退到上一个稳定作业，这些功能均包含在社区版作业规范的update块中—— developer.hashicorp.com。 自动扩缩容是真实存在的，它作为第二个守护进程运行：Nomad Autoscaler是“独立于Nomad构建和发布的”，覆盖水平应用和集群扩缩容，并在其指标源中读取Prometheus—— developer.hashicorp.com。 密钥处理至少与我们持平：任务的secrets/目录由内存文件系统支持并以noexec方式挂载—— developer.hashicorp.com。 ACL策略和角色属于社区版。 不属于社区版的功能包括：审计日志、资源配额和Sentinel策略属于Nomad企业版，将单个作业跨联邦区域部署也是如此——而联邦化区域本身则不是—— developer.hashicorp.com。 命名空间属于社区版，它们对作业、分配、部署和评估进行分段；文档明确说明“Nomad不会对跨多个命名空间共享的对象进行命名空间划分。这包括节点”—— developer.hashicorp.com。 Kubernetes划定了相同的界限——“低级资源，例如节点……不属于任何命名空间”—— kubernetes.io； 在本平台上，节点被注册到一个租户，这正是该行所记录的内容。 服务器数量是HashiCorp自身的参考架构——“一个Nomad集群通常由三到五台服务器组成”，对于小型生产部署，每台服务器配置2-4核CPU和8-16 GB内存—— developer.hashicorp.com。 读者应像我们对待注释2中的Kubernetes数据那样看待此机器规格：这是建议值，而非实测的进程内存。我们未找到客户端代理程序的公开数据，因此该列标注为无，而非猜测，而关于学习曲线的行是我们基于估计而非任何实测数据得出的。