关于ebpf:基于eBPF的云原生可观测性开源项目Kindling之容器环境下的DNS问题排查

问题形容

最近在帮助用户做业务的容器化迁徙时，对业务做压力测试，发现 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 --:--:--     0
time_namelookup: 4.150
time_connect: 0.800
time_appconnect: 0.000
time_redirect: 0.000
time_pretransfer: 0.021
time_starttransfer: 0.000
----------
time_total: 4.981

间接在 pod 中应用 tcpdump 抓包，应用 wireshark 剖析后果如下：

1. app.default.svc.cluster.local 域名解析成 IP 的总共耗时 4.1s。
2. 在 app.default.svc.cluster.local 的根底上，顺次增加 default.svc.cluster.local、svc.cluster.local、cluster.local、openstacklocal 后缀进行域名解析，都失败了。
3. 最初一次应用 app.default.svc.cluster.local 进行解析胜利了。

为啥会有屡次申请 DNS，百度了下发现 K8S 的 DNS 解析机制，和 resolv.conf 文件中 ndots 和 search 两个参数的机制作用有关系。查看容器的 /etc/resolv.conf 配置：

nameserver 10.96.0.10
search default.svc.cluster.local svc.cluster.local cluster.local openstacklocal
options 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 的云原生可观测性开源工具，旨在帮忙用户更好更快的定界云原生零碎问题，并致力于打造云原生全故障域的定界能力。欢送这方面的使用者和爱好者与咱们分割。
退出咱们

关注咱们