Kubernetes比同规格虚拟机性能相差多少？

本内容是对知名性能评测博主 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 会显著增加基础设施成本。