1. Toy模板网首页
  2. > Toy博客

【容器】K8s容器内部dns解析慢解决方案

10月前 作者：bee_yyy 分类：Toy博客 阅读(43) 违法举报

这篇具有很好参考价值的文章主要介绍了【容器】K8s容器内部dns解析慢解决方案。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

需求&背景

K8s内，要对做内部域名解析的劫持，解析 *.lol.com 至 172.34.18.12。
通过在coredns的配置文件配置 *.lol.com 的泛域名解析（如下所示），能够解析成功。但是在容器内部解析公网/内部地址慢。正常的http请求花费5-6秒。

template IN A lol.com {
  match .*\.lol\.com
  answer "{{ .Name }} 60 IN A 172.34.18.12"
  fallthrough
}

coredns 10.42.137.95:36945->114.114.114.114:53: i/o timeout,ops,k8s,容器,kubernetes,容器,云原生

问题解决

DNS解析慢可能出现的问题在解析链路的各个环节。我们按照解析的路径逐步排查。在K8s内部从发起解析的设备，到K8s的DNS服务（coredns）。

1）在需要解析域名的容器抓包

首先在需要解析域名的容器内抓包，在容器所在宿主机执行以下步骤。
通过describe命令获取到Pod内的container-id

kubectl describe [po]

获取进程pid

docker inspect -f {{.State.Pid}} [container-id]

使用nsenter进入pid命名空间

nsenter -n -t [pid]

抓包53（dns解析使用）端口的流量，并记录timestamp

tcpdump -n -tt -i eth0 port 53

1654670942.436773 IP 11.5.0.87.59372 > 11.6.0.10.domain: 54304+ A? myfoo.lol.com.my-services.svc.cluster.local. (62)
1654670942.439162 IP 11.6.0.10.domain > 11.5.0.87.59372: 54304 NXDomain*- 0/1/0 (155)
1654670942.439269 IP 11.5.0.87.35180 > 11.6.0.10.domain: 1677+ A? myfoo.lol.com.svc.cluster.local. (50)
1654670942.439900 IP 11.6.0.10.domain > 11.5.0.87.35180: 1677 NXDomain*- 0/1/0 (143)
1654670942.440105 IP 11.5.0.87.40185 > 11.6.0.10.domain: 56859+ A? myfoo.lol.com.cluster.local. (46)
1654670942.441976 IP 11.6.0.10.domain > 11.5.0.87.40185: 56859 NXDomain*- 0/1/0 (139)
1654670942.442056 IP 11.5.0.87.43673 > 11.6.0.10.domain: 52888+ A? myfoo.lol.com.localdomain. (44)
1654670944.443202 IP 11.6.0.10.domain > 11.5.0.87.43673: 52888 ServFail- 0/0/0 (44)
1654670944.443329 IP 11.5.0.87.58234 > 11.6.0.10.domain: 52888+ A? myfoo.lol.com.localdomain. (44)
1654670946.444789 IP 11.6.0.10.domain > 11.5.0.87.58234: 52888 ServFail- 0/0/0 (44)
1654670946.444929 IP 11.5.0.87.59003 > 11.6.0.10.domain: 46828+ A? myfoo.lol.com. (32)
1654670946.445715 IP 11.6.0.10.domain > 11.5.0.87.59003: 46828*- 1/0/0 A 172.34.18.12 (62)
1654670946.448576 IP 11.5.0.87.52708 > 11.6.0.10.domain: 58584+ PTR? 12.18.34.172.in-addr.arpa. (43)
1654670948.449842 IP 11.6.0.10.domain > 11.5.0.87.52708: 58584 ServFail- 0/0/0 (43)
1654670948.450019 IP 11.5.0.87.52435 > 11.6.0.10.domain: 58584+ PTR? 12.18.34.172.in-addr.arpa. (43)
1654670950.451448 IP 11.6.0.10.domain > 11.5.0.87.52435: 58584 ServFail- 0/0/0 (43)

以上 11.5.0.87 是业务pod本身ip，11.6.0.10 是coredns svc 的ip。
以上的抓包结果显示 从11.5.0.87 发起dns解析请求至11.6.0.10。11.6.0.10 返回解析后的dns记录
最左边的timestamp显示1654670942 - 1654670946 相差有8秒
从日志看经历了 myfoo.lol.com.my-services.svc.cluster.local. 到 myfoo.lol.com. 最终解析出172.34.18.12的解析过程。
以上日志表明两点：
1.解析过程带了不同的域。
2.从容器内发起的解析请求指向11.6.0.10

coredns 日志

[ERROR] plugin/errors: 2 giaoxa.lol.com.localdomain. A: read udp 11.5.2.154:40494->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 12.18.34.172.in-addr.arpa. PTR: read udp 11.5.2.154:38740->114.114.114.114:53: i/o timeout
[ERROR] plugin/errors: 2 12.18.34.172.in-addr.arpa. PTR: read udp 11.5.2.154:44143->114.114.114.114:53: i/o timeout

以上日志中，11.5.2.154是coredns Pod的ip。可以看到和 *.lol.com 相关的请求是 i/o timeout，而且114.114.114.114没有给返回，说明尝试通过114.114.114.114对域名进行解析是失败的

抓包coredns所在宿主机

tcpdump -n -tt -i eth0 port 53

1654681471.359635 IP 172.34.57.8.40494 > 114.114.114.114.domain: 1584+ A? giaoxa.lol.com.localdomain. (45)
1654681471.609660 IP 172.34.57.8.36977 > 114.114.114.114.domain: 5934+ AAAA? alauda.cn.localdomain. (39)
1654681471.609671 IP 172.34.57.8.52810 > 114.114.114.114.domain: 1473+ A? alauda.cn.localdomain. (39)
1654681471.624745 IP 172.34.57.8.39735 > 114.114.114.114.domain: 7872+ AAAA? alauda.cn. (27)
1654681471.624758 IP 172.34.57.8.40497 > 114.114.114.114.domain: 59218+ A? alauda.cn. (27)
1654681472.216579 IP 172.34.57.8.42082 > 114.114.114.114.domain: 53658+ A? alauda.cn. (27)
1654681472.216589 IP 172.34.57.8.33765 > 114.114.114.114.domain: 11138+ AAAA? alauda.cn. (27)
1654681472.321413 IP 172.34.57.8.59460 > 114.114.114.114.domain: 56340+ NS? . (17)
1654681472.569026 IP 172.34.57.8.55787 > 114.114.114.114.domain: 33954+ NS? . (17)
1654681473.233810 IP 172.34.57.8.39542 > 114.114.114.114.domain: 24956+ AAAA? alauda.cn.localdomain. (39)
1654681473.233819 IP 172.34.57.8.54779 > 114.114.114.114.domain: 64571+ A? alauda.cn.localdomain. (39)
1654681473.361569 IP 172.34.57.8.56071 > 114.114.114.114.domain: 1584+ A? giaoxa.lol.com.localdomain. (45)
1654681473.611310 IP 172.34.57.8.38455 > 114.114.114.114.domain: 27253+ A? alauda.cn.localdomain. (39)
1654681473.611342 IP 172.34.57.8.53131 > 114.114.114.114.domain: 31824+ AAAA? alauda.cn.localdomain. (39)
1654681473.784304 IP 172.34.57.8.48873 > 114.114.114.114.domain: 13483+ NS? . (17)
1654681474.032091 IP 172.34.57.8.39103 > 114.114.114.114.domain: 34671+ NS? . (17)
1654681474.217868 IP 172.34.57.8.37204 > 114.114.114.114.domain: 6801+ AAAA? alauda.cn. (27)
1654681474.217878 IP 172.34.57.8.40697 > 114.114.114.114.domain: 65501+ A? alauda.cn. (27)
1654681475.235208 IP 172.34.57.8.57250 > 114.114.114.114.domain: 48387+ A? alauda.cn.localdomain. (39)
1654681475.235219 IP 172.34.57.8.34787 > 114.114.114.114.domain: 50884+ AAAA? alauda.cn.localdomain. (39)
1654681475.247316 IP 172.34.57.8.52486 > 114.114.114.114.domain: 54567+ NS? . (17)
1654681475.366260 IP 172.34.57.8.38740 > 114.114.114.114.domain: 16503+ PTR? 12.18.34.172.in-addr.arpa. (43)
1654681475.494900 IP 172.34.57.8.49735 > 114.114.114.114.domain: 41610+ NS? . (17)
1654681475.613035 IP 172.34.57.8.54194 > 114.114.114.114.domain: 27016+ AAAA? alauda.cn. (27)
1654681475.613049 IP 172.34.57.8.47105 > 114.114.114.114.domain: 36162+ A? alauda.cn. (27)
1654681476.710241 IP 172.34.57.8.57710 > 114.114.114.114.domain: 24258+ NS? . (17)
1654681476.957868 IP 172.34.57.8.51551 > 114.114.114.114.domain: 14591+ NS? . (17)
1654681477.237061 IP 172.34.57.8.42955 > 114.114.114.114.domain: 13195+ A? alauda.cn. (27)
1654681477.237085 IP 172.34.57.8.42017 > 114.114.114.114.domain: 62057+ AAAA? alauda.cn. (27)
1654681477.368084 IP 172.34.57.8.44143 > 114.114.114.114.domain: 16503+ PTR? 12.18.34.172.in-addr.arpa. (43)

以上日志是从宿主机172.34.57.8 发送到域名解析服务器 114.114.114.114，可以看到都是
172.34.57.8 -> 114.114.114.114， 没有返回。

解决

改ndots

nameserver 11.6.0.10
search my-services.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:5

以上是容器内部的 /etc/resolv.conf
ndots：通俗一点说，如果你的域名请求参数中，点的个数比配置的ndots小，则会按照配置的search内容，依次添加相应的后缀直到获取到域名解析后的地址。如果通过添加了search之后还是找不到域名，则会按照一开始请求的域名进行解析。
我们发现在容器抓包的记录中做了以下域名解析:

  1. myfoo.lol.com.my-services.svc.cluster.local
  2. myfoo.lol.com.svc.cluster.local.
  3. myfoo.lol.com.cluster.local.
  4. myfoo.lol.com.localdomain.
  5. myfoo.lol.com.

直到myfoo.lol.com 才解析出来，说明以上1-4都是无用解析。我们更改ndots配置，略过这些解析步骤即可。如下设置ndots

nameserver 11.6.0.10
search my-services.svc.cluster.local svc.cluster.local cluster.local localdomain
options ndots:1

listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
1654686042.988636 IP 11.5.0.87.53253 > 11.6.0.10.domain: 27170+ A? giaoxa.lol.com. (33)
1654686042.990862 IP 11.6.0.10.domain > 11.5.0.87.53253: 27170*- 1/0/0 A 172.34.18.12 (64)
1654686042.992319 IP 11.5.0.87.49080 > 11.6.0.10.domain: 15523+ PTR? 12.18.34.172.in-addr.arpa. (43)
1654686042.992980 IP 11.6.0.10.domain > 11.5.0.87.49080: 15523 ServFail- 0/0/0 (43)
1654686042.993054 IP 11.5.0.87.49690 > 11.6.0.10.domain: 15523+ PTR? 12.18.34.172.in-addr.arpa. (43)
1654686042.994753 IP 11.6.0.10.domain > 11.5.0.87.49690: 15523 ServFail- 0/0/0 (43)

以上抓包记录显示是直接从giaoxa.lol.com开始解析的，只会经历一次114.114.114.114超时，就能解析出172.34.18.12

使用全限定域名

最直接，最有效的优化方式，就是使用 “fully qualified name”，简单来说，使用“完全限定域名”（也叫绝对域名），你访问的域名，必须要以 “.” 为后缀，这样就会避免走 search 域进行匹配
也就是说使用 xxx.lol.com.
但是这种办法不符合大家习惯

只在k8s内部进行解析

我们的集群是在私有化环境中，无公网访问，根据上面的抓包和日志可以看出，发送给公网dns解析服务器114.114.114.114的请求都timeout。既然我们不需要公网解析，给ban掉就行。
根据https://coredns.io/plugins/forward/，coredns forward插件控制 coredns 对于接收到的dns解析请求的转发。我们只需要删除掉forward插件就可以让coredns直接按照templates中的配置进行泛域名解析。
coredns 10.42.137.95:36945->114.114.114.114:53: i/o timeout,ops,k8s,容器,kubernetes,容器,云原生
这样改动后，不需要再等待向公网域名解析服务器发请求，直接在coredns返回解析结果。文章来源地址https://www.toymoban.com/news/detail-823041.html

参考

  1. core dns 配置手册 https://coredns.io/manual/toc/#configuration
  2. core dns 插件 forward https://coredns.io/plugins/forward/
  3. core dns 配置说明 https://help.aliyun.com/document_detail/380963.html
  4. core dns 插件 template https://coredns.io/plugins/template/
  5. dns ptr 是什么 https://www.cloudflare.com/learning/dns/dns-records/dns-ptr-record/
  6. dns 解析常见返回 https://bluecatnetworks.com/blog/the-top-four-dns-response-codes-and-what-they-mean/
  7. resolv.conf 中的 search 和 ndots 配置. 使用 nsenter 在容器网络命名空间抓包 https://cloud.tencent.com/developer/article/1669860
  8. k8s dns 配置，策略，解析等 https://hansedong.github.io/2018/11/20/9/
  9. k8s coredns 日志报 i/o timeout https://github.com/kubernetes/kubernetes/issues/86762
  10. 使用HostAliases向 Pod /etc/hosts 文件添加条目

到了这里，关于【容器】K8s容器内部dns解析慢解决方案的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处： 如若内容造成侵权/违法违规/事实不符，请点击违法举报进行投诉反馈，一经查实，立即删除！

分享到：
领支付宝红包 赞助服务器费用

相关文章

  • K8s 生产环境问题汇总及解决方案（持续更新 ing）

    K8s 生产环境问题汇总及解决方案（持续更新 ing）

    目录 一、前端页面显示 503 Service Temporarily Unavailable 问题背景 解决方案 原理 二、Dockfile 构建镜像失败：When using COPY with more than one source file, the destination must be a directory and end with a /  问题背景 解决方案 原理 三、前端页面显示 502 Bad Gateway 问题背景  解决方案 原理 时间：2

    2024年02月02日
    浏览(39)
  • kubeadm 安装k8s集群后，master节点notready问题解决方案

    kubeadm 安装k8s集群后，master节点notready问题解决方案

    使用kubeadm 安装k8s集群后，加载calico cni 网络组件后，master节点notready问题 表现为： 使用命令查看日志：journalctl -f -u kubelet 报错如下： Failed to start ContainerManager failed to initialize top level QOS containers: failed to update top level Burstable QOS cgroup : failed to set supported cgroup subsystems for cgroup

    2024年01月22日
    浏览(48)

  • k8s内部域名解析

    1、创建busybox容器，检查域名解析 2、检查域名解析服务 同命名空间解析，可以省略命名空间后缀？ 3、通过标签查询到后端的pod信息 [root@master01 demo]# kubectl get pod -l k8s-app=kube-dns -n kube-system -o wide #通过标签查到主机信息 4、跨命名空间解析，需要添加命名空间。

    2024年02月12日
    浏览(29)
  • 【K8S系列】Weave Net 故障排除的常见问题和解决方案

    【K8S系列】Weave Net 故障排除的常见问题和解决方案

    当使用 Weave Net 进行容器网络配置时，可能会遇到一些常见的故障情况。以下是一些常见问题及其解决方案： 解决方案 检查节点之间的网络连通性，确保可以通过 IP 地址相互访问。 检查节点的防火墙设置，确保允许 Weave Net 的流量通过。 确保在每个节点上正确安装了 Weave

    2024年02月12日
    浏览(46)
  • 【K8S系列】深入解析DNS

    【K8S系列】深入解析DNS

    世界上最幸福的事之一，莫过于经过一番努力后，所有东西正慢慢变成你想要的样子。 文章标记颜色说明： 黄色 ：重要标题 红色 ：用来标记结论 绿色 ：用来标记一级论点 蓝色 ：用来标记二级论点 Kubernetes (k8s) 是一个容器编排平台，允许在容器中运行应用程序和服务。今

    2023年04月20日
    浏览(44)
  • k8s外部访问pod内部容器的端口-NodePort

    k8s外部访问pod内部容器的端口-NodePort

    Kubernetes的Pod IP和Cluster IP都只能在集群内部访问，而我们通常需要从外部网络上访问集群中的某些服务，Kubernetes提供了下述几种方式来为集群提供外部流量入口。 有一pod,里面有rabbitmq服务，先想从外部通过ip:15672访问MQ的管理员界面查看队列消费情况。 方法1(pod会重启)： 方法

    2023年04月23日
    浏览(36)
  • K8S1.23.6版本详细安装教程以及错误解决方案（包括前置环境，使用部署工具kubeadm来引导集群）

    K8S1.23.6版本详细安装教程以及错误解决方案（包括前置环境，使用部署工具kubeadm来引导集群）

    一台兼容的 Linux 主机。Kubernetes 项目为基于 Debian 和 Red Hat 的 Linux 发行版以及一些不提供包管理器的发行版提供通用的指令。 每台机器 2 GB 或更多的 RAM（如果少于这个数字将会影响你应用的运行内存）。 CPU 2 核心及以上。 集群中的所有机器的网络彼此均能相互连接（公网和

    2024年03月14日
    浏览(43)
  • k8s容器日志收集方案

    k8s容器日志收集方案

        log-pilot安装            

    2024年02月16日
    浏览(36)
  • k8s容器加入host解析字段

    k8s容器加入host解析字段

    一、通过edit或path来修改 kubectl edit deploy /xxxxx. x-n cattle-system xxxxx为你的资源对象名称 二、添加字段  三、code

    2024年02月12日
    浏览(37)
  • 阿里云k8s容器部署consul集群的高可用方案

    阿里云k8s容器部署consul集群的高可用方案

    原本consul集群是由三个server节点搭建的，购买的是三个ecs服务器， java服务在注册到consul的时候，随便选择其中一个节点。 从上图可以看出， consul-01有28个服务注册，而consul-02有94个服务，consul-03则是29个。 有一次发生consul集群故障，某个conusl节点挂了，导致整个的服务发现

    2024年04月14日
    浏览(95)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包，优惠每天领

二维码1

领取红包

二维码2

领红包