全流量分析发现问题解决问题案例

本文通过网络关键路径性能传导视图发现k8s集群中TCP连接失败率高,深入分析Linux内核,揭示容器内优化与宿主机内核优化的不同,最终通过实验证明容器内需单独优化,并提出全流量分析在运维中的重要性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

一、网络关键路径性能传导视图

在NetInside可观测性模块中,我们基于k8s集群的业务逻辑结构,自定义的建立了以用户体验为中心的网络性能模型,如下图:

在这个流量模型中,浅绿色为体验传递与消减情况,因为用户的一个服务请求,在内部有多个处理逻辑,前一个逻辑的体验时间,依赖后一个逻辑的处理时间,所以其体验时间,会在多个处理逻辑进行传导,我们称之为性能传导视图,浅蓝色部分为处理逻辑向外请求的数据,浅红色则为处理逻辑中影响性能的关键指标。

二、发现问题

视图构建完成之后,竟然出现了橙色体验告警色块,这与我们的想象中的预期不符。在此之前,k8s集群一直是稳定运行,服务器接入也是全千M,基于我们对比业务和流量的了解,纯千的接入完全够用,且传统意义上的监控,也没有出现任何异常,所以出现个近40MS的服务器响应延迟,让我们有点惊讶。

继续看视图,我们发现这个橙色体验告警色块到数据库集时就没有了,可以初步判断问题的关键在于k8s集群。而k8s存在SDN网络,所以是SDN网络问题,还是物理网络问题,我们得区分出来,所以我们把k8s物理网络的性能指标也构建出来做为比较,结果问题还是指向k8s的SDN网络上,结合k8s集群SDN网络里面的关键性能指标,发现TCP的连接失败率还挺高的,由此其实已经可以判断,问题点,应该还是在k8s集群里面。

基于现有分析,我们决定先解决连接失败问题,因为这个问题与响应延迟是同一类型的问题,只是问题表现的程度不同。但面对这个问题的时候,让我们不得不面对一个让我们有点无语的问题。我们知道,TCP连接的建立是由linux内核完成的,而无论是容器也好,k8s的SDN也好,服务器的物理网络也好,对于k8s集群而言,其实都是在同一个内核上!也就是说,同一个人,干的同样的活,为什么表现的情况是不一样的?<

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值