kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502
2021/10/2 7:14:41
本文主要是介绍kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
之前踩过这个坑,在《使用 nginx 作反向代理,启用 keepalive 时,遇到 502 错误的调查过程》 中了记录调查过程,当时多个案例同时查,记录的比较乱,这里重新整理一下结论。
ingress-nginx 到 upstream 的长连接通过configmap中的 upstream-keepalive-connections 等参数设置,注意与 keep-alive 区分(见文末)。另外 ingress-nginx 0.20 之前的版本有 bug,即使配置了也不生效:ingress-nginx upstream 的 keep-alive 不生效。
1.三个结论
这里主要解释结论 3,这里的结论不仅适用于 ingress-nginx,也适用于其它使用 nginx 的场景。
结论1:nginx 的端口耗尽时,会返回 502 错误(和本文要讨论的内容无关)。
结论2:nginx 向已经被服务端主动断开的连接发送请求,会收到 RST,然后返回 502。
结论3:服务端先于 nginx 断开连接的情况有两种,
1)服务端的连接超时时间小于 nginx 中的配置;
2)服务端配置的单个连接的最大请求数小于 nginx 中配置。
2.为什么服务端有超时时间和最大请求数限制?
服务端应用可能是通过本地的 tomcat 或者其它 web 框架对外暴露的,这种情况非常普遍。 这些 Web 服务或者框架通常都有默认的长连接设置。
譬如 tomcat 的相关配置
另外曾经遇到过的 Gunicorn 超时时间只有 2 秒:
3.nginx 的配置与后端服务的配置不一致时
如果做反向代理的 nginx 中配置的连接断开条件比后端服务设置的条件宽松,那么就容易出现后端服务先断开连接的情况, 这时候 nginx 转发请求到 upstream,upstream 会返回 RST,nginx 打印下面的错误日志,给客户端返回 502:
2019/06/13 04:57:54 [error] 3429#3429: *21983075 upstream prematurely closed connection while reading response header from upstream, client: 10.19.167.120, server: XXXX.com, request: "POST XXXX HTTP/1.0", upstream: "http://11.0.29.4:8080/XXXXXX", host: "XXXX.com" 2019/06/13 04:58:34 [error] 3063#3063: *21989359 recv() failed (104: Connection reset by peer) while reading response header from upstream, client: 10.19.138.139, server: XXXX.com, request: "POST /api/v1/XXXX HTTP/1.1", upstream: "http://11.0.145.9:8080/api/v1/XXXX", host: "XXXX.com"
4.建议设置
可以调整 nginx 的 upstream 中 keepalive_timeout 和 keepalive_requests,确保 nginx 先于 upstream 断开连接。只有 nginx 与 upstream 之间使用长连接的时候需要考虑这种情况,并进行类似的设置。
upstream record_upstream { server 127.0.0.1:9091; keepalive 16; keepalive_timeout 58s; # 默认 60 s,根据实际情况调整,建议小于 60s keepalive_requests 98; # 默认 100 个,根据实际情况调整,建议小于 100 } server { ... location /http/ { proxy_pass http://record_upstream; proxy_http_version 1.1; proxy_set_header Connection ""; ... } }
nginx 的 keepalive_timeout 和 keepalive_requests 参数各有两个:一组属于 ngx_http_core_module,在 http/server/location 中使用,限制的是 client 与 nginx 之间的连接;另一组是上面使用的,属于 ngx_http_upstream_module,限制的是 nginx 与 upstream 之间的连接。
5.默认行为
nginx 的 upstream 中没有明确配置 keepalive,那么无论 client 和 nginx 之间是否长连接,nginx 和 upstream 都是短连接。
用下面的配置观察:
upstream record_upstream { server 127.0.0.1:9091; #keepalive 3; #keepalive_timeout 58s; #keepalive_requests 98; } server { listen 9000; listen [::]:9000; server_name echo.example; keepalive_requests 2000; keepalive_timeout 60s; location / { proxy_pass http://record_upstream; #proxy_http_version 1.1; #proxy_set_header Connection ""; } }
使用长连接访问 nginx :
wrk -c 1 -t 1 -d 2s http://127.0.0.1:9000
http-record 收到的请求是 “Connection: close”:
/go/src/Server/echo.go:46: { "RemoteAddr": "172.17.0.1:34522", "Method": "GET", "Host": "record_upstream", "RequestURI": "/", "Header": { "Connection": [ "close" ] }, "Body": "" }
6.参考
https://www.lijiaocn.com/%E9%97%AE%E9%A2%98/2019/12/04/nginx-keep-alive-problem.html
这篇关于kubernetes ingress-nginx 启用 upstream 长连接,需要注意,否则容易 502的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!
- 2024-11-15在Kubernetes (k8s) 中搭建三台 Nginx 服务器怎么实现?-icode9专业技术文章分享
- 2024-11-05基于Kubernetes的自定义AWS云平台搭建指南
- 2024-11-05基于Kubernetes Gateway API的现代流量管理方案
- 2024-11-05在Kubernetes上部署你的第一个应用:Nginx服务器
- 2024-11-05利用拓扑感知路由控制Kubernetes中的流量
- 2024-11-05Kubernetes中的层次命名空间:更灵活的资源管理方案
- 2024-11-055分钟上手 Kubernetes:精简实用的 Kubectl 命令速查宝典!
- 2024-10-30K8s 容器的定向调度与亲和性
- 2024-10-28云原生周刊:K8s未来三大发展方向 丨2024.10.28
- 2024-10-25亚马逊弹性Kubernetes服务(EKS)实战:轻松搭建Kubernetes平台