在我们的一个页面请求中，在 chrome 浏览器中查看只是发出了一个请求，但在我们的服务日志上发现了多次请求，而且每次间隔 60s 。 最终，页面会显示 504 错误，服务端并没有返回任何数据。
服务端的日志如下
由于服务前面是有 nginx 通过反向代理请求的。这块很容易想到 proxy 的超时设置。 所以设置如下
|
1 2 3 |
proxy_read_timeout 3000s; proxy_send_timeout 3000s; proxy_next_upstream off; |
但是设置完，问题并没有解决，还是会出现多条请求，而且请求间隔还是 60s 。 我们把目标转向了 nginx access log 。我们可以设想，如果是服务的 nginx 的配置问题， 那么 acess log 应该只有一条数据，后面的请求会有多条数据。但是查看 access log ， 和我们的设想不一样，也是出现了多条请求日志。
也就是说服务所在的 nginx 也是被动的收到了多条请求，从而请求了服务。从 access log 上看返回码是 499， 也就是说上游客户端主动断开了连接。
我们重新梳理了服务的整体架构，发现问题可能出在 nginx ingress 上。 Ingress 本质上也是由 nginx 控制，通过 nginx 转发到后端服务上，又是一个反向代理。
登录到 k8s 上查看 ingress 的相关配置。
|
1 2 3 |
kubectl -n kube-system get pods kubectl -n kube-system exec -it nginx-ingress-controller-7bbb9944f8-htzft -- bash cat /etc/nginx/nginx.conf |
发现 proxy 的超时设置的是 60s , 而且会重试 3次， 和我们看到的现象是完全一致。 我们需要做的就是调整 ingress 的配置。
我们通过 这里 可以看到调整 ingress nginx 的几种方式。 我们调整了全局配置。 通过设置 config map ， 然后配置会自动更新。 再次进行服务请求，问题解决。