性能文章>记一次线上 K8s Ingress 访问故障排查和优化>

记一次线上 K8s Ingress 访问故障排查和优化转载

2月前
167510

导语

本篇是应用迁移至我们的paas平台后发生的502问题,本篇是K8s一次较为简单的排查和优化,希望大家能有所收获!

正文

具体现象

应用迁移至我们的PaaS平台后会出现偶发性的502问题,错误见图片:

记一次线上 K8s Ingress 访问故障排查和优化数据图表-heapdump性能社区

相比于程序的请求量,错误肯定是比较少的,但是错误一直在发生,会影响调用方的代码,需要检查下问题原因。

为啥我们只看到了POST请求

读者肯定会说,你们 ELK 过滤字段里面写的是POST,所以肯定只有POST请求,hah。其实不是这样的,GET请求也会有502,只是Nginx会对GET请求进行重试,产生类似如下的日志:

记一次线上 K8s Ingress 访问故障排查和优化数据图表-heapdump性能社区
重试机制是Nginx默认的: proxynextupstream

http://nginx.org/en/docs/http/ngxhttpproxymodule.html#proxynext_upstream

因为GET方法会被认为是幂等的,所以当一个upstream出现502的时候,nginx会再次尝试. 对于我们的问题,主要想确认为什么有502,只看POST请求就足够了,两者的原因应该是一致的.

网络拓扑结构

网络请求流入集群时,对于我们集群的结构:

用户请求=>
Nginx=>Ingress=>uwsgi


不要问为什么有了 Ingress 还有 Nginx。这是历史原因,有些工作暂时需要由 Nginx 承担。

统计排查

基于我们对于Nginx和Ingress的错误请求统计,发现两者中的502错误是想等的,说明问题一定是出现在 Ingress<=>uwsgi 之中。

抓包

这个并不是最先想到的方案,因为我们用了很多统计方法也没总结出来规律,最后只能寄希望于抓包了…

该请求日志如下:

记一次线上 K8s Ingress 访问故障排查和优化数据图表-heapdump性能社区

抓包结果如下:


从抓包情况来看,当前的 TCP 连接被复用了,由于Ingress中使用了HTTP1.1协议,会在一次tcp连接中尝试发送第二个HTTP请求,但是uwsgi没有支持http1.1,所以在第二个请求根本不会被处理,直接拒绝了。所以在Ingress看来,这个请求失败了,因此返回了502. 由于GET请求会重试,但POST请求无法重试,所以访问统计中出现了POST请求502的问题。

Ingress配置学习

Ingress中, 默认对upstream使用的http版本为1.1, 但是我们的uwsgi使用的是http-socket, 而非http11-socket, 我们Ingress中使用了与后端不同的协议, 出现了意料之外的502错误。

记一次线上 K8s Ingress 访问故障排查和优化数据图表-heapdump性能社区
https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/annotations/#proxy-http-version
因为 Nginx 默认是1.0, 但是切换到Ingress中默认变成了1.1, 而我们没有统一, 解决方案是强制指定Ingress中使用的http协议版本。

{% if keepalive_enable is sameas true %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.1"
{% else %}
nginx.ingress.kubernetes.io/proxy-http-version: "1.0"
{% endif %}

如果有大佬看到了,可以简单讲讲 Ingress 会在什么时候复用 http1.1 的连接, 以及为什么 Ingress 不复用每一个连接,这样问题会尽快的暴露,这些问题我没有继续深究了。毕竟你换个语言比如 Golang 就没有这个问题了, 这个是 uwsgi 专属错误。

总结

有关这个502问题的排查,我个人觉得,最后抓包一次性解决问题其实没什么特别的,抓了就能发现问题,不抓就发现不了。

我是希望给大家一个启发,对于一整条链路,如何来排查故障:我们这里既使用了Nginx,又使用了 Ingress,在排查时,需要首先检查两者的错误数量, 如果确认错误基本一致,那就说明错误与 Nginx 没有关系,需要检查 Ingress 上的错误,对于多个中转的请求,这样的排查能比较快的确定链路的错误位置。

分类:标签:
请先登录,查看1条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

关于内存溢出,咱再聊点有意思的?
概述 上篇文章讲了JVM在GC上的一个设计缺陷,揪出一个导致GC慢慢变长的JVM设计缺陷,可能有不少人还是没怎么看明白的,今天准备讲的大家应该都很容易看明白 本文其实很犹豫写不写,因为感觉没有
一次百万长连接压测 Nginx OOM 的问题排查分析
在最近的一次百万长连接压测中,32C 128G 的四台 Nginx 频繁出现 OOM,出现问题时的内存监控如下所示。排查的过程记录如下。 现象描述这是一个 websocket 百万长连接收发消息的压测
Nginx 502 Bad Gateway
前言事实证明,读过Linux内核源码确实有很大的好处,尤其在处理问题的时刻。当你看到报错的那一瞬间,就能把现象/原因/以及解决方案一股脑的在脑中闪现。甚至一些边边角角的现象都能很快的反应过来是为何。笔
通过调试 Nginx 源码来定位有趣 Nginx 转发合并斜杠和编码问题
背景前段时间出现了一个请求在测试环境签名成功,在线上环境签名失败的情况,排查原因是线上url中有双斜杠会被合并成一个传给后端,在测试环境中不会出现。这个就比较神奇了,Nginx 版本完全一样。确认问题
彻底弄懂 Nginx location 匹配
Nginx 的 location 实现了对请求的细分处理,有些 URI 返回静态内容,有些分发到后端服务器等,今天来彻底弄懂它的匹配规则一个最简单的 location 的例子如下```server {
优化 Nginx HTTPS 延迟让Nginx提速 30%!
导言Nginx 常作为最常见的服务器,常被用作负载均衡 (Load Balancer)、反向代理 (Reverse Proxy),以及网关 (Gateway) 等等。一个配置得当的 Nginx 服务器单机应该可以期望承受住 50K 到 80K 左右[1]每秒的请求,同时将 CPU 负载在可控范围内
记一次线上 K8s Ingress 访问故障排查和优化
导语本篇是应用迁移至我们的paas平台后发生的502问题,本篇是K8s一次较为简单的排查和优化,希望大家能有所收获!正文具体现象应用迁移至我们的PaaS平台后会出现偶发性的502问题,错误见图片:相比于程序的请求量,错误肯定是比较少的,但是错误一直在发生,会影响调用方的代码,需要检查下问
关于我在某安科技中nginx多层代理静态资源遇到的问题
nginx多层代理性能对性能的影响竟然此大,并且会带来严重的网络问题