企业级编排。
无需 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 代理程序”——在 Intel 8375C 上的内存占用定为 275 MB，基于稳态下的第 95 百分位读数—— 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 个核心和 8 到 16 GB 内存—— developer.hashicorp.com。这是读者应像我们对待注释 2 中 Kubernetes 数据那样看待的机器规格建议：是推荐值，而非实测的进程内存。我们未找到客户端代理程序的公开数据，因此该列说明无此数据，而非猜测；关于学习曲线的行是我们的估计，而非任何人的实测值。
6. Athena 工具计数是调用点的计数，而非整数。 它在 server.registerTool( 中有 athena-mcp/src/tools/*.ts 个调用点 ——截至撰写时为 80 个——并应用了两项修正： cronjob_suspend/cronjob_resume 对是从循环内的单个调用点注册的（一个点，两个工具，因此 +1），而三个发现 辅助程序（search_tools、describe_tool、request_tool） 是由 makeDiscoveryTools() 在 server.ts 中单独注册的 而非通过匹配该模式的调用注册（+3）。80 − 1 + 2 + 3 = 84。任何人都可以 通过针对标记的 版本运行 grep -rc "server.registerTool(" athena-mcp/src/tools/*.ts 来复现基础数字，并根据上述两项修正重新推导出相同的总数。