1

我是 kubernetes 的新手，我无法跟踪我在 Jmeter 负载测试中观察到的响应时间的指数退避信号。我有一个 kubernetes 服务，它在 4-32 个 pod 之间运行，具有水平 pod 自动缩放功能。每个 pod 都运行一个 Gunicorn WSGI，为 django 后端提供服务。所有不同的 k8s 服务都在 nginx 反向代理之后，它将传入的流量直接重定向到服务的 VIP。Nginx 位于暴露于最终用户网络流量的 Amazon ELB 后面。ELB 最终会在 60 秒后超时请求。

每个 gunicorn 服务器运行一个带有 3 个 greenlets 的 worker，并且积压限制为 1。因此它在任何给定时间只能处理 4 个请求，并且对于 nginx 尝试发送的任何额外请求立即返回错误响应。我猜想这些错误请求随后会被捕获并使用指数退避重试，但我无法确定这是在哪里发生的。

据我所知，nginx 不能成为指数重试的来源，因为它只为请求提供一个上游端点。而且我在文档中找不到任何讨论在 kubernetes 路由的任何阶段对错误响应进行指数定时重试的内容。k8s 集群在 1.9 版本上运行。

4

1 回答 1

0

维基百科说：

在各种计算机网络中，二进制指数退避或截断的二进制指数退避是指一种算法，用于间隔同一数据块的重复重传，通常作为网络拥塞避免的一部分。

“截断”只是意味着在增加一定数量后，求幂停止；即重传超时达到上限，此后不再增加。

Kubernetes 组件不具备请求重传能力。它们只是在网络组件之间路由流量，如果一个数据包由于某种原因被丢弃，它就会永远丢失。

Istio有这种特性，所以如果你安装了它，它可能是指数退避的原因。Istio 不是默认 Kubernetes 集群发行版的一部分，因此您必须手动安装它才能使用此功能。

但是，如果您没有安装 istio，则连接级别的数据包重传可以由 TCP 连接的参与者 Jmeter、nginx 和您的应用程序来完成。我假设您的配置中的 nginx 只是将流量重定向到后端 pod，仅此而已。在应用程序级别上重新传输也是可能的，但在这种情况下，它将只有 Jmeter 和后端应用程序。

于 2018-08-06T11:39:12.483 回答