问题形容
最近在帮助用户做业务的容器化迁徙时,对业务做压力测试,发现ui服务的/homepage接口呈现了偶发性的响应申请超时。给大家分享下排查问题过程。
问题定位
先通过skywalking看看相干ui的/homepagetrace,通过下图能够看到总耗时超过5828ms。
发现延时呈现在ui/homepage的self上,共耗时4005ms。其余依赖调用的工夫只用了1823ms。能够确认从ui/homepage调用app/homepage的申请产生到申请数据传输实现耗时太多。当初没有更好的办法进一步排查具体的耗时状况,进入ui容器内,只能应用curl拜访app/homepage看看。
$curl -4 -w "@curl-format.txt" -o /dev/null -l "http://app.default.svc.cluster.local:8091/homepage" % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 0 0 0 0 0 0 0 0 --:--:-- 0:00:03 --:--:-- 0time_namelookup: 4.150time_connect: 0.800time_appconnect: 0.000time_redirect: 0.000time_pretransfer: 0.021time_starttransfer: 0.000----------time_total: 4.981
间接在pod中应用tcpdump抓包,应用wireshark剖析后果如下:
- app.default.svc.cluster.local 域名解析成IP的总共耗时4.1s。
- 在app.default.svc.cluster.local 的根底上,顺次增加default.svc.cluster.local、svc.cluster.local、cluster.local、openstacklocal 后缀进行域名解析,都失败了。
- 最初一次应用app.default.svc.cluster.local 进行解析胜利了。
为啥会有屡次申请DNS,百度了下发现K8S的DNS解析机制,和resolv.conf文件中ndots和search两个参数的机制作用有关系。查看容器的/etc/resolv.conf配置:
nameserver 10.96.0.10search default.svc.cluster.local svc.cluster.local cluster.local openstacklocaloptions ndots:5 single-request-reopen
援用ndots: 5 示意如果域名蕴含的 "." 少于5个,则先增加 search 后缀,再应用相对域名;如果域名蕴含的 "." 大于等于5个,则先应用相对域名,再增加 search 后缀。
起因是app.default.svc.cluster.local少于5个点,所以先加search后缀。最初再应用app.default.svc.cluster.local进行解析。
解决方案
应用简短域名,app.default.svc.cluster.local改成app
批改/etc/resolv.conf配置,将ndots: 5 批改为 ndots: 4
问题复盘
DNS是Kubernetes集群中至关重要的根底服务之一,因为K8S的机制,造成DNS域名解析申请是Kubernetes最高频的网络行为之一。如果DNS有问题,很容易呈现性能问题。但DNS很难通过apm等监控工具的trace定位问题,只能通过登录容器进行抓包剖析,这种除了耗时耗力外,很可能相干的POD都曾经沦亡了。
能够实时监控DNS吗?
Kindling的eBPF探针能够实时获取到被监控POD间的所有申请,包含DNS申请。部署实现后,通过Kindling来排查DNS问题就很不便了。DNS Request Detiail 面板显示了单个K8S集群下DNS申请的监控数据。能够在此面板中剖析网络的DNS性能。面板显示了DNS的要害KPI指标,例如:申请量、延时、谬误数等。通过面板能够清晰理解DNS的运行状态,像后面介绍的场景能够间接看到发动了4次状态为NXDomain的DNS解析。上面通过一段视频简略介绍一下Kindling轻量版的DNS面板性能。
https://www.bilibili.com/vide...
Kindling是一款基于eBPF的云原生可观测性开源工具,旨在帮忙用户更好更快的定界云原生零碎问题,并致力于打造云原生全故障域的定界能力。欢送这方面的使用者和爱好者与咱们分割。
退出咱们
关注咱们