本内容是对知名性能评测博主 Anton Putra VM vs Kubernetes: Performance 内容的翻译与整理, 有适当删减, 相关指标和结论以原作为准
在本视频中，我们将在 Kubernetes 中使用常规的 Deployment 对象以及 ClusterIP 服务部署相同的应用程序，并在虚拟机上使用 systemd 进行部署。此外，我们还将使用一个简单的 DNS进行服务发现。
本次基准测试的目标是探讨 Kubernetes 是否会影响应用程序的性能 。 我们将从客户端侧测量 90% 分位数的延迟（p90），然后通过计算应用程序每秒可以处理的请求数来测量吞吐量。此外，我们还将关注可用性（错误率）、Kubernetes 特有的 CPU 限流情况，以及两种部署方式的 CPU 使用情况。
我在 AWS 上运行所有的基准测试。在 Kubernetes 方面，我使用的是生产环境的 EKS 集群，运行在计算优化型的 Graviton 实例上，该集群不仅用于部署应用程序，还用于运行生成负载的客户端以及 Prometheus 和 Grafana。我为应用程序专门设置了一个独立的实例组，该组仅包含一个 m7a.large 节点，确保不会有其他干扰进程（Noisy Neighbors）。然而，我仍然对 Pod 设置了资源限制，将其设定为与虚拟机相同的 2 个 CPU。
在虚拟机方面，我使用了一台独立的 m7a.large 类型的 EC2 实例，通过 systemd 服务部署相同的应用程序。我已经验证，虚拟机和 Kubernetes 集群中运行的应用程序使用的是完全相同的 Python 版本，即 Python 3.12.3。
应用程序本身是基于 FastAPI 构建的，这是我在之前的基准测试中使用过的框架。你可以在 GitHub 公开仓库中找到该应用程序的源代码。
好了，现在让我们开始运行测试。
延迟测试
延迟（Latency）是最重要的指标之一，我使用 p90 分位数 来测量它。这意味着 90% 的请求会在图表显示的时间范围内完成。
我在同一个 Kubernetes 集群中运行应用程序和客户端，并使用 ClusterIP 进行服务发现，它解析到 Pod 的 IP 地址。然而，即使在 Kubernetes 内部，由于网络路由的原因，延迟仍然高于 直接使用 DNS 记录指向 EC2 实例的方式。我本来没有预料到，即使在没有任何负载的情况下，Kubernetes 的内部网络仍然会对延迟产生显著影响。实际上，ClusterIP 服务仍然依赖 kube-proxy 来处理几乎所有的请求，这可能是导致额外延迟的原因。
吞吐量测试
吞吐量（Throughput）表示每秒可以处理的请求数。测试结束时，我们将看到 Kubernetes 及其用于隔离 Pod 的 cgroups 是否对性能产生了影响。
可用性和错误率
我们还测量了可用性 （Availability）或错误率 （Error Rate）。当客户端开始超时时，可用性会下降。测试结束时，你会发现 Kubernetes 开始对 FastAPI 进行 CPU 限流（throttling）。
CPU 使用情况
为了测量 Pod 的 CPU 使用情况，我使用了 cAdvisor，而对于部署在 EC2 实例上的独立应用程序，我使用了 Node Exporter 。结果显示，Kubernetes 中的 Pod CPU 使用率略高。
让我感到惊讶的是，即使在 Kubernetes 尚未开始限流 FastAPI 之前，相同的应用程序在虚拟机上运行的性能要明显更好 。接下来，我们再运行测试 一分钟 ，然后查看整个测试期间的各项数据图表。整个测试持续了大约 1.5 小时，但我在编辑视频时加快了播放速度。
测试结果
1. 吞吐量（Requests Per Second）
首先，我们来看每秒请求数的图表。
- Kubernetes 部署的应用程序 达到了 10,000 RPS（请求/秒）。
- 虚拟机上的独立应用程序 达到了 12,000 RPS ，比 Kubernetes 高出 20%。
如果你在 Kubernetes 中部署 10 个或 20 个副本 ，这种 20% 的差距 将在计算资源的使用上变得更加明显。
2. 延迟（Latency）
接下来是延迟数据，这部分的差异最大。
- 在 Kubernetes 内部运行的应用程序的延迟几乎是虚拟机上的两倍。
请注意，生成负载的客户端 也运行在 同一个 Kubernetes 集群 内，因此这种额外的延迟主要是由于 kube-proxy 等额外的抽象层造成的。虽然 Kubernetes 提供了便捷的部署方式，但它确实会影响性能。
3. 可用性（Availability）
然后，我们来看可用性。在测试接近尾声时，可用性略有下降。
4. CPU 限流（CPU Throttling）
接下来，我们可以看到 Kubernetes 开始对 FastAPI 进行 CPU 限流。
5. CPU 使用率（CPU Usage）
最后，我们比较了 Kubernetes 和虚拟机上的 CPU 使用情况。可以看出，Kubernetes 的 CPU 使用率更高。
总结
我在生产环境中使用 Kubernetes 已经 6 年 ，它确实极大地提升了 应用程序的部署和升级的便利性 。然而，现在的云服务提供商已经提供了 自动扩展组（Auto Scaling Groups） 和 滚动升级（Rolling Upgrades） 等内置功能，因此如果你的核心需求是 性能优化 或 降低基础设施成本 ，那么在云环境中并不一定需要 Kubernetes。
根据我的经验，Kubernetes 会显著增加基础设施成本。