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

已于 2024-01-03 10:36:59 修改
阅读量1.4k 收藏 26
点赞数 19
分类专栏： ops k8s 容器 文章标签： kubernetes 容器 云原生
于 2023-12-05 20:04:28 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/weixin_44479465/article/details/134737316
版权
ops 同时被 3 个专栏收录
10 篇文章 0 订阅
订阅专栏
k8s
4 篇文章 0 订阅
订阅专栏
容器
4 篇文章 0 订阅
订阅专栏

需求&背景

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
}

在这里插入图片描述

问题解决

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返回解析结果。

参考

  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 文件添加条目
bee_yyy
关注
  • 19
    点赞
  • 踩
  • 26
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
专栏目录
K8s无法感知到Fabric Chaincode容器的解决方案
01-20
相信在使用k8s进行fabric部署的时候，很多人克服了重重困难，最终倒在了dns解析下的悲剧。 在使用k8s的时候，通过flannel网络能够在pod容器内进行内部local访问，也可以使用NodePort或者ClusterIP进行外部的访问。...
k8s-二进制软件包.zip
05-21
- kube-flannel.yml：这是Flannel网络插件的配置文件，Flannel是k8s集群中的一个网络解决方案，它为跨主机的Pod提供网络通信。 - coredns.yaml：CoreDNS是k8s集群的默认DNS服务，用于解析服务名称到IP地址，提供服务...
【Docker】容器内因dns解析导致网络连接慢
AlvinHuntley的博客
05-01 2525
dns解析导致网络连接慢，因docker中默认添加8.8.8.8和8.8.4.4
k8s -- 通过 cluster-ip + 端口 访问服务过慢问题处理
CN_LiTianpeng的博客
07-11 1791
1、执行如下命令 ethtool -K flannel.1 tx-checksum-ip-generic off [root@master01 ~]# ethtool -K flannel.1 tx-checksum-ip-generic off Actual changes: tx-checksumming: off tx-checksum-ip-generic: off tcp-segmentation-offload: off tx-tcp-segmentation:
K8s: 集群内Pod通信机制之DNS
最新发布
Wang的专栏
04-21 1350
有了这样的参数之后，我们创建的pod，它就会自带 DNS这个域名，它的hostname 就会变成一个 full qualified 这么一个域名。hostname，就是我的主机名, 这个pod我可以认为它是一个最小的主机，这个主机已经有个名字了，比如说叫 busybox1。有了上面全的域名地址，就可以访问到它这个pod了，通过这种方式，K8s提供了pod的dns注册机制。然后域名就是你的公司名称，集群的名称，可以是你公司的域名，比如 x.com。通过这个域名，能够让别人通过这个DNS服务来找到我。
K8S DNS解析过程和延迟问题
阿拉斯加大闸蟹的博客
02-20 7736
5、如果本地DNS服务器本地区域文件与缓存解析都失效，则根据本地DNS服务器的设置（是否设置转发器）进行查询，如果未用转发模式，本地DNS就把请求发至13台根DNS，根DNS服务器收到请求后会判断这个域名（.com）是谁来授权管理，并会返回一个负责该顶级域名服务器的一个IP。本地DNS服务器收到IP信息后，将会联系负责.com域的这台服务器。6、如果用的是转发模式，此DNS服务器就会把请求转发至上一级DNS服务器，由上一级服务器进行解析，上一级服务器如果不能解析，或找根DNS或把请求转至上上级，以此循环。
k8s集群内部网络访问慢，curl延时高
RayPick的博客
06-29 4056
我这边的环境是三台机器，均为centos7，节点为master、node1、node2，版本如下 部署方式：helm部署 部署应用： EFK 出现问题： elasticSearch应用副本数为1，被默认调度在node2启动，通过master节点输入命令 kubectl get svc 查看到es的clusterIp地址，在node2上（也就是es所在节点）用 curl clusterIp:9200 能curl通，且速度很快，然后在node1上进行curl操作，非常慢，得等接近1分钟才有反应。 这里我翻
k8s service 内部dns 地址介绍,互相依赖Pod启动介绍
justlpf的专栏
12-13 566
在Kubernetes（K8s）中，每个Service都有一个内部DNS名称。这个DNS名称是基于服务的名称和命名空间构建的。例如，如果有一个名为 `my-service` 的Service位于 `default` 命名空间下，那么它的内部DNS名称将是 `对于内部Pod之间的通信，可以通过使用这个内部DNS名称来访问其他Service。当一个Pod试图解析这个DNS名称时，Kubernetes会自动将其转换为对应的Cluster IP地址，然后将流量路由到正确的Service后端Pods。
k8s安装镜像包v1.18.0所需镜像
07-28
8. **coredns**: CoreDNS是k8s的默认DNS服务，负责解析集群内部的服务域名，使服务通过名称而非IP地址进行通信，简化了服务发现和访问。 9. **pause.tar**: 在k8s中，Pod由一个或多个容器组成，"pause"容器是一个轻...
k8s.1-18-8.tar.gz
11-13
总的来说，这个“k8s.1-18-8.tar.gz”压缩包是一个完整的Kubernetes部署解决方案，适用于想要搭建或升级到1.18.8版本的集群。用户解压后，可以按照官方文档或指南进行安装配置，利用Docker容器化应用，并通过Calico...
K8s_yaml.zip
05-17
Kubernetes，简称K8s，是Google开源的一种容器编排系统，用于自动化容器化应用程序的部署、扩展和管理。本文将详细解析与“K8s_yaml.zip”相关的Kubernetes组件，包括Grafana、Heapster、InfluxDB、KubeDNS以及...
k8s集群外部域名dns解析问题
runzhliu大数据/容器日记
04-26 2146
Overview 业务在机器学习的 GPU 集群访问集群外部域名的算法模型报超时 原因分析 查看了 coredns 的监控和日志，均没有发现异常，通过 ping harbor.fql.com 分析回包非常慢，而且频繁超时，于是抓包，发现 harbor.fql.com 添加了 search 域，因为本身域名只有三位，k8s 的 DNS 的 ndots 默认是5位，所以肯定会添加 search 域去解析域名的 默认配置下的 Pod，ndots 为 5 解决方案 由业务容器通过 Pod 的 dnsConfig 自
kubernetes-DNS解析很慢或者超时的问题
dlm520947的博客
02-18 1498
DNS的解析结构： <service_name>.<namespace>.svc.<domain> myapp.default.svc.cluster.local 解析慢的时候或者解析超时的时候： curlmyapp.default.svc.cluster.local #这种时候可能会出现解析慢或者解析超时的情况 curlmy...
关于k8s的ipvs转发svc服务访问慢的问题分析(一)
comeyes的专栏
05-15 5802
系统环境描述： 系统环境：macos,vmware下搭建k8s单master/双worker伪集群环境. 软件环境描述： 单Master结点(192.168.182.100)、WORK1(192.168.182.101)、WORK2(192.168.182.102)结点环境，网络环境为flannel+ipvs, 创建了deployment服务nginx，replicas=2，即work1、work2分别有个pod运行，同进生成svc。 备注：此3台机器最开始搭建的是calio+iptables网络环
CoreDNS解析域失败以及内网转发出现5秒卡顿
qq_19663899的博客
12-13 4984
问题描述 测试环境中服务在内网调用其他服务时偶尔出现5秒卡顿,但是在外部网络调用不会出现卡顿; 测试环境中访问外网,偶现解析域名失败; 调查过程 内网访问出现卡顿 对服务自身以及调用目标进行打点计时,发送方接收响应式出现卡顿,目标服务正常; 对网关以及Nginx进行打点计时,均未出现超时; 由于外网访问正常而内网不正常,排除网络传输问题; 外网访问与内网的区别是URL不同以及DNS解析所获取...
kubernetes 【网络组件】【3】Coredns+Nodelocaldns cache解决Coredns域名解析延迟
爱死亡机器人
07-19 3071
文章目录1. 背景2. 服务是如何工作的？3. Linux内核中的DNAT4. 问题5. 意见建议6. 内核修复7. 方案（一）：使用 TCP 协议发送 DNS 请求8. 方案（二）：避免相同五元组 DNS 请求的并发9. 方案（三） Kubernetes 集群中使用 NodeLocal DNSCache9.1 优势9.2 架构图9.3 环境检查9.4 部署9.5 两种种方案测试nodelocaldns实效性9.6 测试coredns+nodelocaldns的效果 1. 背景 【摘要】 目前18.6版
k8s指南-DNS与服务发现
xiaoyi52的专栏
03-14 1861
在k8s中，ip是随时可能发生变化的，特别是pod的ip，服务的ip也是可以改变的。因此服务或pod之间相互访问一般是通过域名来实现的
docker拉取镜像，dns无法解析网址解决方法
nansen0324的博客
02-06 656
docker拉取镜像，dns无法解析网址解决方法
关于DNS域名解析过慢的解决办法及常用DNS推荐
Evain_Wang的博客
05-17 3478
DNS域名解析过慢解决方法及常用DNS服务推荐
k8s 容器 nginx dns解析 不稳定
08-17
Kubernetes (k8s) 是一个流行的容器编排和管理工具，它能够自动部署、扩展和管理容器化应用程序。在Kubernetes中，容器一般是通过服务发现的方式来进行通信，在这个过程中，域名解析是至关重要的一环。 容器中的应用程序通常会使用DNS进行域名解析来定位其他容器或外部服务。Nginx作为一个常用的容器化Web服务器，也需要通过DNS解析来将域名转换为IP地址，以便与其他容器或外部服务进行通信。 然而，有时候在Kubernetes集群中，容器的域名解析可能会出现不稳定性的问题。这可能导致Nginx无法解析需要的域名，使得容器间的网络通信出现故障或不可靠。 引起这种不稳定性的原因可能是多种多样的。首先，DNS解析问题可能与Kubernetes集群的配置有关。如果DNS服务配置不正确或不稳定，容器中的Nginx就无法准确地解析域名。 其次，网络问题也可能导致DNS解析不稳定。如果网络延迟高或者网络带宽不足，DNS解析可能会超时或失败，从而影响到Nginx的正常运行。 最后，应用程序本身的问题也可能导致DNS解析的不稳定性。如果应用程序没有正确地处理域名解析失败的情况，可能会导致Nginx无法正常工作。 要解决这个问题，我们可以采取以下措施： 1. 检查Kubernetes集群的DNS配置，确保DNS服务正常运行并配置正确。 2. 检查网络状况，确保网络延迟低、带宽充足，减少DNS解析超时的可能性。 3. 在应用程序中添加域名解析失败的错误处理机制，例如进行重试或回退到备用解析方案。 综上所述，k8s容器中的Nginx DNS解析不稳定的问题可能与Kubernetes集群的配置、网络问题或应用程序本身相关。通过检查和调整配置，优化网络状况以及合理处理解析失败，我们可以提高Nginx DNS解析的稳定性。

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值