我是kubernetes的新手，我无法跟踪我在Jmeter负载测试中观察到的指数退避信号的响应时间。我有一个Kubernetes服务，它在4-32个Pod之间运行，具有水平Pod自动缩放功能。每个Pod都运行一个为django后端服务的Gunicorn WSGI。所有不同的k8s服务都位于nginx反向代理后面，该代理将传入的流量直接重定向到服务的VIP。 Nginx位于Amazon ELB的后面，后者会受到最终用户Web流量的影响。 ELB最终在60秒后使请求超时。
每个gunicorn服务器正在运行一个带有3个greenlet的工作程序，并且积压限制为1。因此，它在任何给定时间只能处理4个请求，并且对于nginx尝试发送其方式的任何其他请求都立即返回错误响应。我猜想这些错误请求随后会被捕获并以指数补偿的方式重试，但是我无法完全确定发生这种情况的地方。
据我所知，nginx不能作为指数重试的来源，因为它仅为一个请求提供上游端点。而且，我在文档中找不到任何内容来讨论在kubernetes路由的任何阶段对错误响应进行指数定时重试。 k8s集群在1.9版上运行。
答案 0 :(得分：0)
在各种计算机网络中，二进制指数退避或截断的二进制指数退避是指一种算法，用于间隔同一数据块的重复重传，通常作为避免网络拥塞的一部分。
“截断”仅表示经过一定数量的增加后，幂运算停止；即重传超时达到上限，此后不再增加。
Kubernetes components不具有请求重传功能。它们只是在网络组件之间路由流量，如果数据包由于某种原因被丢弃，它将永远丢失。
Istio具有这种feature，因此，如果安装了它，则可能是指数退避的reason。 Istio不是默认的Kubernetes群集发行版的一部分，因此您必须手动安装它才能使用此功能。
但是，如果未安装istio，则连接级别的数据包重传可以由TCP连接的参与者（即Jmeter，nginx和您的应用程序）完成。我认为您配置中的nginx只是将流量重定向到后端Pod，仅此而已。 在应用程序级别上也可以重传，但是在这种情况下，只能是Jmeter和后端应用程序。