Kubernetes 副本数量与性能答案

【问题标题】：Kubernetes number of replicas vs performanceKubernetes 副本数量与性能
【发布时间】：2020-04-17 08:11:07
【问题描述】：

我刚接触 Kubernetes，非常喜欢它编排容器的能力。我假设当应用程序开始增长时，我可以简单地增加副本来处理需求。然而，现在我已经运行了一些基准测试，结果让我感到困惑。

我在 GKE 上运行 Laravel 6.2 w/ Apache，并使用单个 g1-small 机器作为节点。我只使用NodePort 服务来公开应用程序，因为LoadBalancer 似乎很昂贵。

使用的基准测试工具是wrk 和ab。当副本增加到 2 时，请求/秒以某种方式下降。我预计请求/秒会增加，因为有 2 个 pod 可用于服务请求。某处是否存在瓶颈，或者我的理解存在缺陷。希望有人能指出我所缺少的。

【问题讨论】：

你的瓶颈是哪一部分？
@Jonas 这也是我想知道的，我的问题是：node 中的额外pod 不应该能够满足更多请求吗？
使用 10 个 pod 会得到什么结果？
我在 4 个 Pod 之后遇到了 CPU 不足错误，因为我只在一台 g1 小型机器中生成它们，但即使有 3 个 Pod，来自基准工具的请求数也会下降
是的，但您提供的信息仍然太少，无法回答问题

标签： laravel apache docker kubernetes google-cloud-platform

【解决方案1】：

g1-small instance 非常小：您可以获得 50% 的单核利用率和 1.7 GB 的 RAM。您没有描述您的应用程序做了什么或如何分析它，但如果它受 CPU 限制，那么添加更多的进程副本对您毫无帮助；您仍然受到 GCP 为您提供的 CPU 数量的限制。如果您达到将显着降低性能的实例的内存限制，那么无论是交换副本还是其中一个副本都会被 OOM 杀死。

可能会影响此基准测试的另一件事是，有时，您可以在有限的时间内将 CPU 利用率提高到 100%。因此，如果您有一个实例并运行了第一个基准测试，它可能使用了一个突发周期并看到了更高的性能，但是在同一实例上重新运行第二个基准测试可能无法做到这一点。

简而言之，您不能只增加 Deployment 的副本数并期望获得更好的性能。您需要确定系统中实际瓶颈的位置。像 Prometheus 这样可以报告每个 pod CPU 利用率的高级统计数据的监控工具会有所帮助。在典型的由数据库支持的 Web 应用程序中，数据库本身就是瓶颈，在 Kubernetes 级别您无能为力。

【讨论】：

感谢您的回答。那么如果不超过 CPU/内存，我可以假设更多的 pod 通常应该产生更高的吞吐量吗？我显然需要更深入地挖掘真正的原因。有趣的是，您应该提出可能导致不规则结果的突发 CPU 利用率，用户对Laravel hello world project 进行了基准测试，发现后续测试的结果更差。不过，感谢您的意见！
没有特别的理由假设更多的 pod 会产生更高的吞吐量；这取决于您的瓶颈到底在哪里。如果是网络 I/O，或者一些共享资源，比如 CPU 内核，或者共享数据库，更多的 pod 不会让事情变得更快，而且可能会让事情变得更慢。