为什么 1 个 pod 副本比其他 5 个慢？

Question

我有一个多节点 kubernetes 集群，其中有 6 个 Pod（副本、8Gi、4 个 CPU 核心）在 Auto Scaling 组中的不同节点上运行。这些 Pod 包含一个提供 REST API 的应用程序，并连接到 Redis。

对于通过入口配置的 ALB 的所有请求，某些请求比其他请求慢得多。

当我在 Pod-IP 级别发送请求时，我发现 1 个 pod 比其他 5 个 pod 慢得多（几乎慢 5 倍），从而大大缩短了总响应时间。

我尝试杀死该 Pod，以便部署启动一个运行良好的新 Pod。问题是，其他一些 pod 也因此变慢了。快：慢的比例维持在5：1。

Pod 的 CPU 利用率低于 30%，并且拥有充足的可用资源。

我无法弄清楚原因。请帮忙。

Answer 1

我不是提问者，但奇怪的是遇到了类似的问题，该问题本身不能归因于任何明显的问题。

经过大量调试和转动每一块石头后，我们最终通过删除所需的注释来禁用 Prometheus Operator 刮擦我们的 Pod。“1 pod 性能问题”神奇地消失了。

我们 kubectl 转发了其中一个 Pod 并检查了我们的指标端点：它正在生成 6 MB（！）的指标数据，这是相当多的，并且在没有负载时需要大约 700-1000 毫秒才能生成。事实证明，我们的自定义指标存在回归，并为特定指标创建了许多标签变体，这归因于生成的指标近 3 MB。下一个问题是 Kafka Streams，它生成许多非常详细的指标（甚至在每个 Kafka Stream 节点操作的基础上或针对连接的 Kafka 集群中的每个节点进行标记）。我们没有简单的方法来禁用这些指标的收集，但我们只是将它们从普罗米修斯端点中排除。

这给我们留下了区区 32kb 的指标。重新激活 Prometheus Operator 抓取并没有重新引入观察到的问题。

但为什么只有一个吊舱呢？我们基本上有两个 Prometheus Operator 实例每 30 秒抓取一次所有注册的端点，这导致平均抓取间隔约为 15 秒。我们检查了 http 指标，然后它让我们震惊：与任何其他 pod 相比，一个 pod 的抓取频率高出 8-10 倍！考虑到高负载场景，prometheus 端点响应时间超过 1.5 秒的情况并非不可能，这意味着在前一个抓取尚未完成时会启动另一个抓取过程。所有这些都增加了越来越多的 CPU 使用率，导致 Pod 受到更多限制，因为它达到了 CPU 限制，这反过来又增加了指标端点响应时间，导致更多并发抓取生成 6 MB 数据。

至于为什么一个 Pod 被如此频繁地刮擦：我们目前还没有明确的答案，因为我们的系统团队仍在调查。遗憾的是，在我们减少指标端点响应大小后，8-10 倍的抓取量消失了。

我们基本上是通过指标抓取来获得 DDOSd 的，这种情况在一个 Pod 上发生得太频繁（原因未知）。这一定是我调试过的最复杂的事情了。我们基本上删除了应用程序的每个部分（数据库层、跟踪、普罗米修斯、自定义指标），直到找到罪魁祸首。我们甚至考虑了特定的 Kubernetes 节点是否是罪魁祸首，甚至检查了诸如熵之类的东西是否因某种原因而耗尽。

祝你的问题好运，我希望这可以帮助一些可怜的灵魂不要浪费超过一个星期的大海捞针！