kubernetes - 如何使用 client_disconnected_before_any_response 调试失败的请求

Question

我们有一个 HTTP(s) Load Balancer由 kubernetes 入口创建，它指向由运行 nginx 和 Ruby on Rails 的一组 pod 形成的后端。
查看负载均衡器日志，我们发现响应代码为 0 的请求越来越多。和 statusDetails = client_disconnected_before_any_response .
我们试图了解他为什么会发生这种情况，但我们还没有发现任何相关的东西。 nginx 访问或错误日志中没有任何内容。
这发生在多种请求中，从 GET 到 POST。
我们还怀疑有时尽管请求被记录了该错误，但请求实际上被传递到了后端。例如，我们看到 PG::UniqueViolation 错误，因为身份注册请求在我们的注册端点中被发送到后端两次。
任何形式的帮助将不胜感激。谢谢!

更新 1
根据要求 here is the yaml入口资源的文件:

更新 2
我创建了一个基于日志的 Stackdriver 指标，以计算呈现此行为的请求数。这是图表:

大峰值与这些 kubernetes 事件的时间戳大致匹配:

完整错误:Readiness probe failed: Get http://10.48.1.28:80/health_check: net/http: request canceled (Client.Timeout exceeded while awaiting headers)"因此，后端后面的 Pod 的就绪探测有时似乎会失败，但并非总是如此。
这是readinessProbe的定义

readinessProbe:
  failureThreshold: 3
  httpGet:
    httpHeaders:
    - name: X-Forwarded-Proto
      value: https
    - name: Host
      value: [redacted]
    path: /health_check
    port: 80
    scheme: HTTP
  initialDelaySeconds: 1
  periodSeconds: 30
  successThreshold: 1
  timeoutSeconds: 5

Answer 1

响应代码 0 和 statusDetails = client_disconnected_before_any_response 意味着客户端在负载均衡器能够提供响应之前关闭了连接 GCP documentation .

排查为什么没有及时响应，原因之一可能是keepalive timeouts的区别。来自 nginx 和 GCP 负载均衡器，即使这将最像提供由 502 Bad Gateway race condition 引起的 backend_connection_closed_before_data_sent_to_client | .

为了确保后端响应请求并查看是否需要多长时间，您可以重复此过程几次(因为您仍然会得到一些有效的响应):

curl 响应时间

$ curl -w "@curl.txt"-o/dev/null -s IP_HERE

curl.txt 内容(先创建并保存此文件):

   time_namelookup:  %{time_namelookup}\n
      time_connect:  %{time_connect}\n
   time_appconnect:  %{time_appconnect}\n
  time_pretransfer:  %{time_pretransfer}\n
     time_redirect:  %{time_redirect}\n
time_starttransfer:  %{time_starttransfer}\n
                ----------\n
        time_total:  %{time_total}\n

如果是这种情况，请查看任何类型的循环(如您提到的 PG::UniqueViolation 错误)的注册端点代码。