在混合云基础设施领域，数据是最有价值的货币。但要让数据既有效又有价值，必须在正确的上下文中获取。基准测试作为评估技术方案性能的核心手段，其结果直接影响技术选型决策。然而，正如 Red Hat 在一篇技术博客中所揭示的，一场看似惊人的性能对比背后，可能隐藏着架构设计层面的系统性偏差。
架构差异：从 300 到 4 的拓扑鸿沟
任何实验中最关键的要素是控制变量。在这场由 Principled Technologies 执行的 Pod 密度对比测试中，两个平台被分配了相同的物理硬件 —— 四台 Dell PowerEdge 服务器。然而，配置却存在显著差异：VMware Cloud Foundation 9.0 with vSphere Kubernetes Service（VKS）运行了 300 个虚拟工作节点，分布在 4 台物理主机上，相当于每台服务器承载 75 个虚拟机，每个虚拟机配置为「best-effort-medium」级别（2 个 vCPU、8GB 内存、无资源预留）。相比之下，Red Hat OpenShift 被配置为裸金属集群，仅有 4 个工作节点，每台物理服务器一个。
测试结果呈现出极具迷惑性的数字：VKS 在 300 个工作节点上达到了 42000 个 Pod，平均每个节点 140 个 Pod；而 OpenShift 在 4 个工作节点上达到了 7400 个 Pod，平均每个节点 1850 个 Pod。表面上看，VKS 的总 Pod 数量是 OpenShift 的 5.6 倍，这正是原始报告中宣称的「5.6 倍 Pod 密度优势」。但如果我们审视每个节点的效率，OpenShift 的单节点密度实际上是 VKS 的 13 倍以上。问题在于：5.6 倍这个数字反映的并非平台运行 Pod 的效率差异，而是测试环境的拓扑结构 ——300 个节点对 4 个节点 —— 这本质上是一个关于节点数量的比较，而非关于平台性能的较量。
更值得关注的是配置层面的不对称性。方法论文档中的 YAML 配置将 VKS 的 maxPods 设置为 200（值得注意的是，同一文档的正文声称「每个节点最多 300 个 Pod」，这是内部不一致），而 OpenShift 的 maxPods 被设置为 5000，远超默认的 250。这反而给了 OpenShift 一个优势。然而，拓扑结构已经决定了结果：VKS 的理论上限是 60000 个 Pod（300 节点 ×200），而 OpenShift 的理论上限是 20000 个 Pod（4 节点 ×5000）。测试比较的是两种根本不同的架构，却只汇报了聚合总数。
排队理论：节点数量而非平台速度
报告中另一个被强调的指标是 VKS 的「Pod 就绪速度更快」。对于观察者而言，这首先是排队理论的基本原理，而非软件工程上的突破。用一个形象的比喻：让 1000 人登上 4 辆巴士会产生长队，而让这些人同时登上 300 辆小型货车则队列消失。通过使用 300 个虚拟节点，VKS 最小化了调度争用。相反，通过将 4 个裸金属节点推向绝对稳定极限，测试创造了一个瓶颈 —— 在架构合理的生产环境中，这种瓶颈根本不存在。
需要指出的是，该测试使用的 Pod（通过 kube-burner 生成）相对于实际工作负载消耗极少的 CPU 和内存。与真实工作负载不同，在启动过程中节点级别不存在资源争用或排队。300 个节点相对于 4 个节点的优势是真实的，但它仅适用于空的调度槽，而非实际消耗资源的 Pod。
合成工作负载的盲区
kube-burner 测试旨在压测 Kubernetes 控制平面（系统的大脑），而非数据平面（实际计算）。方法论文档显示，具体使用的变体是 kubelet-density-heavy，它在每次迭代中创建一个基本的 PostgreSQL Pod 和一个客户端应用 Pod。这些 Pod 比空的「pause」容器更重，但仍然是合成探测，而非真实业务应用。它们旨在查看编排器在停止响应或节点失去心跳之前可以填充多少个「槽」。
在真实业务场景中，Pod 不仅仅是需要填充的槽。生产环境中交付业务价值的 Pod（如 Java 微服务或 Python 驱动的推理引擎）承载着显著的「有效载荷」。首先，真实应用通常需要 512MB 到 4GB 的内存和大量的 CPU 切片。将 1800 个这样的 Pod 塞进单个物理节点会立即耗尽物理资源。其次，业务工作负载产生大量的磁盘 I/O 和复杂的网络流量。kube-burner 的「sleep」 Pod 不产生内部流量，意味着测试忽略了在真实世界中通常会导致高密度集群崩溃的「嘈杂邻居」效应。第三，真实应用有初始化序列、数据库迁移和健康检查依赖。kube-burner 测量的是一个「空心」容器被标记为「就绪」的速度，这类似于测量在停车场停放空车的速度，而非装载和调度满载巴士所需的时间。
虽然 OpenShift 能够在一个节点上产生 1850 个 Pod 值得自豪，但我们认识到这不反映真实客户工作负载 —— 实际工作负载会在低得多的 Pod 数量下就会使工作节点（物理或虚拟）饱和。诚实的答案是，测试两边的头条数字都与生产现实脱节。
虚拟化税的现实考量
运行 300 个独立的虚拟机引入了值得考虑的开销。每个虚拟机运行自己的客户操作系统内核、自己的 kubelet 和自己的容器运行时。聚合的 vCPU 需求（600）超过了所有 4 台主机的物理核心总数（192），意味着虚拟机被过度承诺，而 best-effort-medium 虚拟机级别没有资源预留。这种组合对几乎空闲的合成 Pod 有效，但如果这些 Pod 做真实工作，则无法维持。
虚拟化工作节点是一种生产模式，Red Hat 推荐将这种拓扑用于托管控制平面托管场景。使用默认的 maxPods 限制 500 和每个托管控制平面约 70 个 Pod，客户很快就会达到每个裸金属工作节点约 6 个托管控制平面的上限。超越该上限的推荐方式是在裸金属主机上运行虚拟机工作节点，并将托管控制平面 Pod 放置在这些虚拟机中 —— 这正是测试中的拓扑。
同样，当客户需要在 Pod 之间进行内核级隔离（而非命名空间级隔离）时，也使用此模式，我们的 OpenShift Virtualization 方法使用相同的模型。问题不在于虚拟化工作节点作为架构，而在于此特定配置过度承诺了主机，且工作负载足够轻以掩盖了这一问题。
工程实践：基准测试的避坑指南
透过这场基准测试争议，我们可以提炼出工程实践中评估性能测试结果的关键原则。首先，比较必须在等效的架构之间进行 —— 虚拟化对虚拟化，裸金属对裸金属。当一方使用 300 个虚拟节点而另一方使用 4 个裸金属节点时，总数比较毫无意义。其次，必须关注每个节点的指标而非仅看聚合总数。单节点密度往往更能反映平台的实际效率。第三，工作负载必须具有代表性。合成探测可以找到平台的「断点」，但它们不是容量规划的依据。最后，需要审视 maxPods 等配置参数的设置，确保比较是在公平的前提下进行。
基准测试应该是帮助客户做出明智决策的工具，通过在同等条件下比较等价配置。当评估 Pod 密度声明时，我们鼓励超越聚合总数，询问在具有代表性生产负载的等价架构上获得的每个节点结果。