我是kubernetes的新手，在追踪Jmeter负载测试中观察到的指数退避信号以获取响应时间时遇到了问题。我有一个kubernetes服务，它在4-32个pod之间运行，具有水平pod自动缩放功能。每个pod都运行一个Gunicorn WSGI，为django后端提供服务。所有不同的k8s服务都在nginx反向代理后面，它将传入的流量直接重定向到服务的VIP。Nginx位于暴露于最终用户网络流量的亚马逊ELB之后。ELB最终会在60秒后超时一个请求。
每个gunicorn服务器运行一个具有3个greenlet的worker，并且有1个backlog限制。因此，它在任何给定的时间只能服务器4个请求，并立即为nginx试图发送的任何额外请求返回错误响应。我猜这些错误请求随后会被捕获并以指数后退的方式重试，但我不太清楚这是在哪里发生的。
据我所知，nginx不可能是指数重试的来源，因为它只为一个请求的一个上游端点提供服务。我在文档中找不到任何讨论kubernetes路由中任何阶段错误响应时的指数定时重试的内容。k8s集群正在1.9版本上运行。
维基百科说：
在各种计算机网络中，二进制指数后退或截断二进制指数后退是指一种用于间隔同一数据块的重复重传的算法，通常作为避免网络拥塞的一部分。
"截断"只是指在增加一定数量后，幂运算停止；即重传超时达到上限并且此后不再增加。
Kubernetes组件不具有请求重传功能。它们只是在网络组件之间路由流量，如果数据包由于某种原因丢失，它就会永远丢失。
Istio有这种功能，所以如果你安装了它，这可能是指数后退的原因。Istio不是默认Kubernetes集群分发的一部分，因此您必须手动安装它才能使用此功能。
然而，如果您没有安装istio，那么TCP连接的参与者Jmeter、nginx和您的应用程序可以在连接级别上重新传输数据包。我假设您的配置中的nginx只是将流量重定向到后端pod，仅此而已。在应用程序级别的重传也是可能的，但在这种情况下，它将只是Jmeter和后端应用程序。