此前我们部门已经完成了业务上云的目标,而随着业务请求量的激增,上云应用系统也面临着一些复杂的故障和挑战。
下文我就结合最近的容器排障工作,跟大家一起探讨如何优化系统的性能、扩展性和容错能力,为读者提供参考和借鉴,以确保系统的高效运行和可靠交付。
用户反馈出现了一个异常任务,它长时间出于“进行中”的状态;用户上传的源物料大小是568MB左右,预期能够半小时出结果,实际过了6个小时都没有结束任务。
最终我们通过上面的排障思路和定位行动,将根本原因定位出来了:排查发现是容器集群资源吃紧,结合云原生组件kubeproxy反向代理机制,两者结合引发所导致。
下面具体列出分析思路和大致流程,一起讨论下。
既然目前是任务一直执行,说明问题是出在了(3)~(7)步骤上了,那么聚焦于APP2和APP3。
基于他们的请求响应关系,下文将APP2定位成客户端,将APP3定位成服务端。
正常的预期现象是:两边容器都有业务进程,并且两边进程频繁进行HTTP通信;当任务执行结束之后,两边进程都将退出被系统销毁。
那么我们首先需要分析两侧容器进程。
通过ps -ef,分别在客户端APP2和服务端APP3,打印进程状态。
客户端APP2的任务进程:有一个进程存活,说明客户端进程卡住了。
服务端APP3的任务进程:没有执行中的任务进程了。
定位是客户端APP2的进程卡死,而服务端APP3的进程正常结束了。
分析进程卡死的原因,首先是想到日志,然后是网络。
在云容器的日志看,发现并没有打印相关的ERROR级别日志,说明业务是整体成功的状态,所以我们更加怀疑是环境问题(网络/IO等资源)导致。
通过netstat -ntp| grep PID,分别在APP2和APP3进程关联的网络端口状态。
由于不存在工作进程,所以也查不出关联的网络端口了。
通过网络排查,发现了客户端APP2的进程,存在4个TCP端口一直在监听状态,并没有正常关闭。
分别从客户端和服务端角度出发,去定位TCP连接异常监听。
由于容器集群是已经部署上云,并且在K8S部署架构下运行,和技术运营的同学一起梳理出以下的请求链路:
这里与HTTP普通请求响应的区别:由于service的“从中作梗”,kube-proxy其实是一个代理层负责实现service。
通过kube-proxy的ipvs机制,实现了从 service-ip 到 容器ip的映射,完成一个网络转发代理,最终实现容器之间的通信。
请求链路最终经过了以下3个步骤:
上面在3.3.3步骤 也分析到了,客户端的连接(客户端APP2→APP3-service)是一直建立的,而服务端的连接(APP3-service→APP3-容器)是关闭了的。
那么我们判断问题是在了kube-proxy代理这个环节上。
因为恢复业务使用一直是当务之急,所以基于请求链路的理解,我们大胆测试了一下:改为通过pod-ip/port直连通信的方式,客户端进程能否正常结束呢?
随后验证:该方案是可行的,此时的客户端和服务端进程都正常结束了。
通过pod-ip/port直连的方式,同时技术运营同学也辅助了pod重启之后的pod-ip动态刷新的工作,确保临时方案的可用性。
至此,我们优先恢复了业务的正常使用。
但kube-proxy的流量代理问题,仍旧没定位清晰;未来容器服务,如果要继续做高可用部署,依旧是离不开这个组件的,所以继续盘它。
通过3.4.3步骤 分析,最终定位到问题出在了kube-proxy代理这个环节上,所以决定在客户端和服务端两侧进行抓包。
通过tcpdump,我们分别在客户端和服务端里,实现了流量抓包(虽然日志非常大,幸好容器分配到的磁盘空间足够,事后也有清理),随后是下载出来用wireshark分析网络情况。
期间过程有点繁琐,因为要顺序性的启动抓包进程、客户端服务端进程复现、以及文件权限申请等细节,这里不对抓包过程展开。
最终是复现了问题,并对残留的几个TCP连接进行了抓包分析,这里针对其中一个异常的TCP连接(客户端的进程残留一个TCP连接port=40422)分析。
客户端
客户端目标是service-ip,三次握手完成,连接建立是在12:03:06。
经过kube-proxy代理到具体的pod实例,服务端跟客户端,三次握手完成,连接建立是在12:03:09。
客户端
客户端最后一次跟service-ip连接通信,在12:04:51。
通过网络抓包分析得到:
目前摸到的线索是:服务端回了一个包给客户端,并造成了“案发现场”。于是我们找了云同学协助查看问题,最终判断是kube-proxy的代理会话超时机制作用导致。
kube-proxy存在会话保活机制:会记录客户端与服务端的连接,有效时间是15分钟。
当ipvs会话保持超时后,连接记录就没了。
梳理请求链路,我们得到以下的“客户端-Service-服务端”三方通信流程图:
针对“服务端回了一个包给客户端,并造成了“案发现场”,从上面关注两个时间点:
至此,我们已经找到了故障的根本原因:
调整kube-proxy的会话超时时间是不实际的,因为基础组件改动是一个全局的影响;
所以自然引出最后一个问题:为什么服务端会来不及处理请求,以至于不能及时保活。
对于为什么服务端会来不及处理请求,以至于不能及时保活;我们想到的是两个原因:
基于对服务端计算能力的评估,只能是跟容器资源限制有关系,于是查看了服务端APP3的CPU/内存/网络/IO的相关监控。
只关注APP3,因为计算量集中在这个服务。
监控显示:CPU整体负载很低,在任务进行中时,CPU使用量才略微升高,而后下去了(约等于不工作,说明APP2的确完成了计算量的工作了)。
监控显示:APP3在数据分析过程里,内存一直飙高,但经过一段时间后,量就降下去了。
监控显示:APP3在数据分析过程里,IO带宽一直打满,达到了280MBps,但经过一段时间后,监控就降下去了。
因为我们用的是云存储规格是SSD,也算是到了性能瓶颈了。
从资源监控看资源吃紧是客观存在的:
结合公司的降本增效大背景,通过无限制的投入资源去优化体验,片面去追求更大的内存和更快的磁盘IO是不现实的。
这次独特的Bug排查,也是由于业务流量徒增而导致,所以我们决定利用好已有的条件去克服困难:
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。