1、故障现象
我们一个agent代理服务，发布到k8s集群之后，pod状态是Running，但是server一直无法收到心跳信号，因此到集群内部去排查日志，发现该服务日志中出现大量的连接某一个ip地址tcp timeout
2、故障排查过程
通过查看日志发现是大量的错误日志，连接某个ip地址产生i/o timeout，因此排查服务的业务逻辑，该服务只会去连接server端，在服务的环境变量里配置了server端的域名，怀疑是不是有可能server端挂掉，在本地和集群宿主机上调用server的地址，发现是可以通的，因此排除掉了server端本身的问题
因为server端连接地址在我本地和集群宿主机上是可以正常调用，因此怀疑服务pod到server端地址不通，进入到pod中进行测试，发现的确不能调用，使用ping域名也是可以通的，但是发现ping解析出来的ip地址并不是我们server端的外网ip地址;因此怀疑到了dns解析的问题上，使用nsloopup命令进行排除(通常服务都没有该命令需要手动安装apt-get install dnsutils,yum install bind-utils，或者使用kubectl-debug工具来共享容器排查)，解析出来的发现很诡异的name，域名最后面带了一个HOST
进一步查看/etc/resolv.conf，发现搜索域中有一个HOST搜索域，因此解析域名会带上HOST
又测试了几个域名，只要最后带HOST，都会解析到一个ip地址上，上网一搜，才知道这个HOST是个域名，还会泛解析到某个ip上
至此，导致本次故障的原因，已定位到，是由于pod中的搜索域中带了一个域名HOST，产生的泛解析到了一个不是我们server端的地址上
3、故障原因分析
首先我们需要知道在k8s中的pod是如何进行服务之间域名调用，是如何解析的?
Kubernetes 中的域名解析分析
集群内部域名解析
在 Kubernetes 中，比如服务 a 访问服务 b，对于同一个 Namespace下，可以直接在 pod 中，通过 curl b 来访问。对于跨 Namespace 的情况，服务名后边对应 Namespace即可。比如 curl b.devops。那么，使用者这里边会有几个问题：
①：服务名是什么?②：为什么同一个 Namespace 下，直接访问服务名即可?不同 Namespace 下，需要带上 Namespace 才行?③：为什么内部的域名可以做解析，原理是什么?
DNS 如何解析，依赖容器内 resolv 文件的配置
cat /etc/resolv.confnameserver 10.68.0.2search devops.svc.cluster.local. svc.cluster.local. cluster.local.1.2.3.
这个文件中，配置的 DNS Server，一般就是 K8S 中，kubedns 的 Service 的 ClusterIP，这个IP是虚拟IP，无法ping，但可以访问。
root@other-8-67:~# kubectl get svc -n kube-system |grep dnskube-dns ClusterIP 10.68.0.2 <none> 53/UDP,53/TCP,9153/TCP 106d1.2.
所以，所有域名的解析，其实都要经过 kubedns 的虚拟IP 10.68.0.2 进行解析，不论是 Kubernetes 内部域名还是外部的域名。Kubernetes 中，域名的全称，必须是 service-name.namespace.svc.cluster.local 这种模式，服务名，就是Kubernetes中 Service 的名称，所以，当我们执行下面的命令时：
curl b1.
必须得有一个 Service 名称为 b，这是前提。
在容器内，会根据 /etc/resolve.conf 进行解析流程。选择 nameserver 10.68.0.2 进行解析，然后，用字符串 “b”，依次带入 /etc/resolve.conf 中的 search 域，进行DNS查找，分别是：
// search 内容类似如下（不同的pod，个域会有所不同）search devops.svc.cluster.local svc.cluster.local cluster.local1.2.
b.devops.svc.cluster.local -> b.svc.cluster.local -> b.cluster.local ，直到找到为止。
所以，我们执行 curl b，或者执行 curl b.devops，都可以完成DNS请求，这2个不同的操作，会分别进行不同的DNS
// curl b，可以一次性找到（b +devops.svc.cluster.local）b.devops.svc.cluster.local// curl b.devops，次找不到（ b.devops + devops.svc.cluster.local）b.devops.devops.svc.cluster.local// 第二次查找（ b.devops + svc.cluster.local），可以找到b.devops.svc.cluster.local1.2.3.4.5.6.7.
因此curl b，要比 curl b.devops 效率高，因为 curl b.devops，多经过了一次 DNS 查询。
集群外部域名解析
访问外部域名走 search 域吗，看情况，可以说，大部分情况要走 search 域。我们以请求 baidu.com 为例，通过抓包的方式，看一看在某个容器中访问 baidu.com，进行的DNS查找的过程，都产生了什么样的数据包。注意：我们要抓DNS容器的包，就得先进入到DNS容器的网络中(而不是发起DNS请求的那个容器)。
由于DNS容器往往不具备bash，所以无法通过 docker exec 的方式进入容器内抓包，我们采用其他的方式：
// 1、找到容器ID，并打印它的NS IDdocker inspect --format "{{.State.Pid}}" 16938de418ac// 2、进入此容器的网络Namespacensenter -n -t 54438// 3、抓DNS包tcpdump -i eth0 udp dst port 53|grep baidu.com1.2.3.4.5.6.在其他的容器中，进行 baidu.com 域名查找
nslookup baidu.com 114.114.114.1141.
注意：nslookup命令的最后指定DNS服务容器的IP，是因为，如果不指定，且DNS服务的容器存在多个的话，那么DNS请求，可能会均分到所有DNS服务的容器上，我们如果只抓某单个DNS服务容器抓到的包，可能就不全了，指定IP后，DNS的请求，就必然只会打到单个的DNS容器。抓包的数据才完整。
可以看到类似如下结果：
11:46:26.843118 IP srv-device-manager-7595d6795c-8rq6n.60857 > kube-dns.kube-system.svc.cluster.local.domain: 19198+ A? baidu.com.devops.svc.cluster.local. (49)11:46:26.843714 IP srv-device-manager-7595d6795c-8rq6n.35998 > kube-dns.kube-system.svc.cluster.local.domain: 53768+ AAAA? baidu.com.devops.svc.cluster.local. (49)11:46:26.844260 IP srv-device-manager-7595d6795c-8rq6n.57939 > kube-dns.kube-system.svc.cluster.local.domain: 48864+ A? baidu.com.svc.cluster.local. (45)11:46:26.844666 IP srv-device-manager-7595d6795c-8rq6n.35990 > kube-dns.kube-system.svc.cluster.local.domain: 43238+ AAAA? baidu.com.svc.cluster.local. (45)11:46:26.845153 IP srv-device-manager-7595d6795c-8rq6n.58745 > kube-dns.kube-system.svc.cluster.local.domain: 59086+ A? baidu.com.cluster.local. (41)11:46:26.845543 IP srv-device-manager-7595d6795c-8rq6n.32910 > kube-dns.kube-system.svc.cluster.local.domain: 30930+ AAAA? baidu.com.cluster.local. (41)11:46:26.845907 IP srv-device-manager-7595d6795c-8rq6n.55367 > kube-dns.kube-system.svc.cluster.local.domain: 58903+ A? baidu.com. (27)11:46:26.861714 IP srv-device-manager-7595d6795c-8rq6n.32900 > kube-dns.kube-system.svc.cluster.local.domain: 58394+ AAAA? baidu.com. (27)1.2.3.4.5.6.7.8.
我们可以看到，在真正解析 baidu.com 之前，经历了 baidu.com.devops.svc.cluster.local. -> baidu.com.svc.cluster.local. -> baidu.com.cluster.local. -> baidu.com.
这也就意味着有3次DNS请求，是浪费的无意义的请求。这是因为，在 Kubernetes 中，其实 /etc/resolv.conf 这个文件，并不止包含 nameserver 和 search 域，还包含了非常重要的一项：ndots。
/prometheus $ cat /etc/resolv.confnameserver 10.66.0.2search monitor.svc.cluster.local. svc.cluster.local. cluster.local. options ndots:51.2.3.4.
ndots:5，表示：如果查询的域名包含的点“.”，不到5个，那么进行DNS查找，将使用非完全限定名称(或者叫域名)，如果你查询的域名包含点数大于等于5，那么DNS查询，默认会使用域名进行查询。举例来说：
如果我们请求的域名是，a.b.c.d.e，这个域名中有4个点，那么容器中进行DNS请求时，会使用非域名进行查找，使用非域名，会按照 /etc/resolv.conf 中的 search 域，走一遍追加匹配：
a.b.c.d.e.devops.svc.cluster.local. ->a.b.c.d.e.svc.cluster.local. ->a.b.c.d.e.cluster.local.1.2.3.
直到找到为止。如果走完了search域还找不到，则使用 a.b.c.d.e. ，作为域名进行DNS查找。
我们通过抓包分析一个具体案例：域名中点数少于5个的情况：
// 对域名 a.b.c.d.com 进行DNS解析请求 root@srv-xxx-7595d6795c-8rq6n:/go/bin# nslookup a.b.c.d.comServer: 10.68.0.2Address: 10.68.0.2#53** server can't find a.b.c.d.com: NXDOMAIN// 抓包数据如下：root@srv-device-manager-7595d6795c-8rq6n:/go/bin# tcpdump -i eth0 udp dst port 53 -c 20 |grep a.b.c.d.comtcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes20 packets captured16:14:40.053575 IP srv-device-manager-7595d6795c-8rq6n.37359 > kube-dns.kube-system.svc.cluster.local.domain: 29842+ A? a.b.c.d.com.cluster.local. (43)16:14:40.054083 IP srv-device-manager-7595d6795c-8rq6n.34813 > kube-dns.kube-system.svc.cluster.local.domain: 19104+ AAAA? a.b.c.d.com.cluster.local. (43)25 packets received by filter16:14:40.054983 IP srv-device-manager-7595d6795c-8rq6n.37303 > kube-dns.kube-system.svc.cluster.local.domain: 53902+ A? a.b.c.d.com.devops.svc.cluster.local. (51)16:14:40.055465 IP srv-device-manager-7595d6795c-8rq6n.40766 > kube-dns.kube-system.svc.cluster.local.domain: 34453+ AAAA? a.b.c.d.com.devops.svc.cluster.local. (51)0 packets dropped by kernel16:14:40.055946 IP srv-device-manager-7595d6795c-8rq6n.35443 > kube-dns.kube-system.svc.cluster.local.domain: 24829+ A? a.b.c.d.com.svc.cluster.local. (47)16:14:40.057698 IP srv-device-manager-7595d6795c-8rq6n.44180 > kube-dns.kube-system.svc.cluster.local.domain: 23046+ AAAA? a.b.c.d.com.svc.cluster.local. (47)16:14:40.058062 IP srv-device-manager-7595d6795c-8rq6n.56986 > kube-dns.kube-system.svc.cluster.local.domain: 42008+ A? a.b.c.d.com. (29)16:14:40.075579 IP srv-device-manager-7595d6795c-8rq6n.55738 > kube-dns.kube-system.svc.cluster.local.domain: 32284+ AAAA? a.b.c.d.com. (29)// 结论：// 点数少于5个，先走search域，最后将其视为域名进行查询1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.
域名中点数>=5个的情况：
// 对域名 a.b.c.d.e.com 进行DNS解析请求 root@srv-xxx-7595d6795c-8rq6n:/go/bin# nslookup a.b.c.d.e.comServer: 10.68.0.2Address: 10.68.0.2#53** server can't find a.b.c.d.e.com: NXDOMAIN// 抓包数据如下：root@srv-device-manager-7595d6795c-8rq6n:/go/bin# tcpdump -i eth0 udp dst port 53 -c 20 |grep a.b.c.d.e.comtcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes16:32:39.624305 IP srv-device-manager-7595d6795c-8rq6n.56274 > kube-dns.kube-system.svc.cluster.local.domain: 43582+ A? a.b.c.d.e.com. (31)20 packets captured16:32:39.805470 IP srv-device-manager-7595d6795c-8rq6n.56909 > kube-dns.kube-system.svc.cluster.local.domain: 27206+ AAAA? a.b.c.d.e.com. (31)16:32:39.833203 IP srv-device-manager-7595d6795c-8rq6n.33370 > kube-dns.kube-system.svc.cluster.local.domain: 14881+ A? a.b.c.d.e.com.cluster.local. (45)21 packets received by filter16:32:39.833779 IP srv-device-manager-7595d6795c-8rq6n.40814 > kube-dns.kube-system.svc.cluster.local.domain: 43047+ AAAA? a.b.c.d.e.com.cluster.local. (45)16:32:39.834363 IP srv-device-manager-7595d6795c-8rq6n.53053 > kube-dns.kube-system.svc.cluster.local.domain: 17994+ A? a.b.c.d.e.com.iot.svc.cluster.local. (53)0 packets dropped by kernel16:32:39.834740 IP srv-device-manager-7595d6795c-8rq6n.47803 > kube-dns.kube-system.svc.cluster.local.domain: 15951+ AAAA? a.b.c.d.e.com.iot.svc.cluster.local. (53)16:32:39.835177 IP srv-device-manager-7595d6795c-8rq6n.60845 > kube-dns.kube-system.svc.cluster.local.domain: 38541+ A? a.b.c.d.e.com.svc.cluster.local. (49)16:32:39.835611 IP srv-device-manager-7595d6795c-8rq6n.36086 > kube-dns.kube-system.svc.cluster.local.domain: 49809+ AAAA? a.b.c.d.e.com.svc.cluster.local. (49)// 结论：// 点数>=5个，直接视为域名进行查找，只有当查询不到的时候，才继续走 search 域。1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.
优化方式1：使用全限定域名
其实最直接，最有效的优化方式，就是使用 “fully qualified name”，简单来说，使用“完全限定域名”(也叫域名)，你访问的域名，必须要以 “.” 为后缀，这样就会避免走 search 域进行匹配，我们抓包再试一次：
nslookup a.b.c.com.1.
在DNS服务容器上抓到的包如下
root@srv-device-manager-7595d6795c-8rq6n:/go/bin# tcpdump -i eth0 udp dst port 53 -c 20 |grep a.b.c.com.tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes16:39:31.771615 IP srv-device-manager-7595d6795c-8rq6n.50332 > kube-dns.kube-system.svc.cluster.local.domain: 50829+ A? a.b.c.com. (27)20 packets captured16:39:31.793579 IP srv-device-manager-7595d6795c-8rq6n.51946 > kube-dns.kube-system.svc.cluster.local.domain: 25235+ AAAA? a.b.c.com. (27)1.2.3.4.5.
并没有多余的DNS请求
优化方式2：具体应用配置特定的 ndots
其实，往往我们还真不太好用这种域名的方式，有谁请求baidu.com的时候，还写成 baidu.com. 呢?
在 Kubernetes 中，默认设置了 ndots 值为5，是因为，Kubernetes 认为，内部域名，最长为5，要保证内部域名的请求，优先走集群内部的DNS，而不是将内部域名的DNS解析请求，有打到外网的机会，Kubernetes 设置 ndots 为5是一个比较合理的行为。
如果你需要定制这个长度，更好是为自己的业务，单独配置 ndots 即可(deployment为例)。
... spec: containers: - env: - name: GOENV
value: DEV
image: xxx/devops/srv-inner-proxy
imagePullPolicy: IfNotPresent
lifecycle: {} livenessProbe: failureThreshold: 3
httpGet: path: /health
port: 8000
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
name: srv-inner-proxy
ports: - containerPort: 80
protocol: TCP
- containerPort: 8000
protocol: TCP
readinessProbe: failureThreshold: 3
httpGet: path: /health
port: 8000
scheme: HTTP
initialDelaySeconds: 5
periodSeconds: 5
successThreshold: 1
timeoutSeconds: 1
resources: {} terminationMessagePath: /dev/termination-log
terminationMessagePolicy: File
dnsConfig: options: - name: timeout
value: "2"
- name: ndots
value: "2"
- name: single-request-reopen
dnsPolicy: ClusterFirst
...1.2.3.4.5.6.7.8.9.10.11.12.13.14.15.16.17.18.19.20.21.22.23.24.25.26.27.28.29.30.31.32.33.34.35.36.37.38.39.40.41.42.43.44.45.46.47.在Kubernetes 中，有4种 DNS 策略
具体来说：
None
表示空的DNS设置
这种方式一般用于想要自定义 DNS 配置的场景，而且，往往需要和 dnsConfig 配合一起使用达到自定义 DNS 的目的。
Default
有人说 Default 的方式，是使用宿主机的方式，这种说法并不准确。
这种方式，其实是，让 kubelet 来决定使用何种 DNS 策略。而 kubelet 默认的方式，就是使用宿主机的 /etc/resolv.conf(可能这就是有人说使用宿主机的DNS策略的方式吧)，但是，kubelet 是可以灵活来配置使用什么文件来进行DNS策略的，我们完全可以使用 kubelet 的参数：–resolv-conf=/etc/resolv.conf 来决定你的DNS解析文件地址。
ClusterFirst
这种方式，表示 POD 内的 DNS 使用集群中配置的 DNS 服务，简单来说，就是使用 Kubernetes 中 kubedns 或 coredns 服务进行域名解析。如果解析不成功，才会使用宿主机的 DNS 配置进行解析。
ClusterFirstWithHostNet
在某些场景下，我们的 POD 是用 HOST 模式启动的(HOST模式，是共享宿主机网络的)，一旦用 HOST 模式，表示这个 POD 中的所有容器，都要使用宿主机的 /etc/resolv.conf 配置进行DNS查询，但如果你想使用了 HOST 模式，还继续使用 Kubernetes 的DNS服务，那就将 dnsPolicy 设置为 ClusterFirstWithHostNet。
这几种DNS策略，需要在Pod，或者Deployment、RC等资源中，设置 dnsPolicy 即可
4、结论
通过故障原因的分析，我们可以知道该故障比较好的解决办法，就是在deployment中去设置dnsPolicy，在不影响集群内服务直接调用的情况下，把ndots从默认的5修改成了2，使代理服务pod在访问server端域名的时候dns解析直接走域名，这样就会避免走 search 域进行匹配，可以正确匹配到ip地址。通过此次故障也让我知其然知其所以然，在排查故障的过程中，需要去了解背后涉及到的知识点和根本原因。
以上新闻或文章转载于网络，如有雷同或侵权，请联系IID工作人员处理，谢谢！
wendy 