jäv*_*ävi 13 kubernetes google-kubernetes-engine google-cloud-networking kubernetes-ingress
我们有一个由kubernetes ingress创建的HTTP(s)Load Balancer,它指向由运行nginx和Ruby on Rails的pod组成的后端.
看一下负载均衡器日志,我们检测到越来越多的请求,响应代码为0和statusDetails= client_disconnected_before_any_response.
我们试图理解为什么会发生这种情况,但我们没有找到任何相关的东西.nginx访问或错误日志中没有任何内容.
这种情况发生在从GET到POST的多种请求中.
我们还怀疑有时尽管请求记录了该错误,但请求实际上是传递给后端的.例如,我们看到了PG :: UniqueViolation错误,因为在我们的注册终端中,两次发送了令人满意的注册请求到后端.
任何形式的帮助将不胜感激.谢谢!
我已经创建了一个基于日志的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
Run Code Online (Sandbox Code Playgroud)
响应代码为 0 且 statusDetails = client_disconnected_before_any_response 表示客户端在负载均衡器能够根据此GCP 文档提供响应之前关闭了连接。
调查它为什么没有及时响应,原因之一可能是nginx 和 GCP 负载均衡器的keepalive 超时之间的差异,即使这很可能会提供由502 Bad Gateway 竞争条件引起的 backend_connection_filled_before_data_sent_to_client 。
为了确保后端响应请求并查看是否需要多长时间,您可以重复此过程几次(因为您仍然得到一些有效的响应):
卷曲响应时间
$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
Run Code Online (Sandbox Code Playgroud)
如果是这种情况,请检查任何类型循环的注册端点代码,例如您提到的 PG::UniqueViolation 错误。
| 归档时间: |
|
| 查看次数: |
439 次 |
| 最近记录: |