coreDNS 常见问题及优化方案

问题现象一

导致原因

优化方案

问题现象二

导致原因

优化方案

Core DNS配置优化和说明

参考文章：

问题现象一

重启coredns pod导致集群业务解析域名五分钟可不用

导致原因

当集群使用IPVS作为kube-proxy负载均衡模式时，您可能会在CoreDNS缩容或重启时遇到DNS概率性解析超时的问题。该问题由社区Linux内核缺陷导致，具体信息，请参见。ipvs: queue delayed work to expire no destination connections if expi… · torvalds/linux@35dfb01 · GitHubLinux kernel source tree. Contribute to torvalds/linux development by creating an account on GitHub.https://github.com/torvalds/linux/commit/35dfb013149f74c2be1ff9c78f14e6a3cd1539d1?spm=a2c63.p38356.0.0.56a3eb84uFgUly

粗浅的理解一下大概意思就是当coredns节点有变更例如ip变化了，由于有会话保持的机制pod还会复用之前的连接。

优化方案

1. 部署NodeLocal DNSCache（推荐）

另外一篇文章我会详细介绍一下NodeLocaDNS，先简单的说一下带来的收益

1）pod首先会访问nodelocaldns，nodelocaldns会将每次请求缓存到本地。可以大大的提高性能。相当于集群的每个节点都是一个dns服务器

2）降低coredns 80% - 90%的请求量，减轻coredns的压力和瓶颈问题

3）如果coredns有变更时，由于我们使用nodelocaldns，pod会首先访问nodelocaldns 如果请求没有命中，nodelocaldns 再去请求coredns 进行tcp协议的请求重新建立连接三次握手，几乎不影响业务

2. 修改kube-proxy 会话保持超时时间 --ipvs-udp-timeout=10s

修改方式两种，都需要重启kube-proxy

1）一般通常会在kube-system命名空间下有一个kube-proxy的configmap，configmap中把这行配置加上即可。

2）修改kube-proxy daemonsets 增加参数

简单说一下不推荐第二种方式的原因

默认超时时间为300s，我当时遇到的现象就是服务五分钟无法解析。

1）可以修改为10s或者5s这样可以减少一些业务流量的损失，但是没有解决本质的问题。

2）如果设置为0则代表不开启会话保持，这种情况下我们的业务pod每进行一次域名方式的请求都会去和coredns 建立udp的连接。频繁建连首先一定会造成很多不必要的网络开销。

3）其次就是如果我们coredns 将65535个端口都占用完这个时候就会建立连接失败意味着业务会解析失败。

4）重启集群所有kube-proxy pod 尤其是在线业务这种操作对服务来说是毁灭性的

问题现象二

服务部署到集群后，业务反馈有些接口会报无法解析部分外网域名的问题。

导致原因

因为我们的Deployment默认使用的dnsPolicy策略为ClusterFirstWithHostNet，这种模式会优先走集群内部的coredns解析，如果coredns无法解析就会通过coredns的配置文件 forward 到宿主机的/etc/resolv.conf文件使用nameserver dns。我们宿主机的dns是自建的，我们的dns只做内网域名的解析，公网域名都会forward到公有云的DNS服务器。画个简图如下

注意我上面说的是部分公网无法解析并不是所有公网域名都不行。之后我们为了快速恢复业务，将dnsPolicy 策略改为了Default模式这个模式会将宿主机的 resolv.conf文件挂载到pod中相当于使用宿主机的nameserver。改成这种方式也没有恢复。

测试发现用dig命令直接解析时会报错 connection timed out; no servers could be reached，用nslookup 解析则正常由于隐私问题我就不截解析结果的图了。从nslookup的解析结果来看这个域名包含了70多条A记录。如下图

这里说明了一个问题，nslookup解析域名是用的TCP协议，dig 默认不指定协议的情况是UDP，之后我又用dig +tcp 再次解析这个域名结果符合预期使用tcp解析时没有问题的。

那么问题又来了，为什么使用UDP协议解析时会失败呢。抓包分析由于这个域名有很多A记录导致返回结果超过了512 字节达到了1866字节。

抓包的路径如下

服务器---> LB --> IDC DNS Server 这个包是在dns 服务器上看到的。同时我们也在服务器抓包发现服务器并没有接收到response只有query的包。那这个问题又是为什么呢？dns 服务器分明给我返回数据了但是我的客户端没有接收到。结合我们整体的链路判断应该是LB出现了问题

询问云厂商后得知他们LB用的NAT模式也就是说请求的结果一定还会通过LB将结果返回，而且云厂商LB还有一个限制当使用UDP请求的返回结果大于1500byte 就会丢弃。而且之前我们还测试过nameserver绑定某一台rs是没有问题。足以说明一定是LB的问题。

优化方案

1. 将LB TCP 后端rs增加为9个确保每个rs都能正常响应tcp请求

2. 部署NodeLocal DNSCache，pod 访问NodeLocalDNS默认协议是UDP，但是NodeLocal DNS 请求core DNS使用的是TCP协议。

3. 业务代码改用TCP方式（需要研发配合修改代码，如果涉及到底层依赖的库不是太友好）

Core DNS配置优化和说明

apiVersion: v1
data:Corefile: |.:53 {errorsready  # 节点就绪探测，默认监听端口8181，检测通过后挂到endpoint#logdebughealth {  #CoreDNS自身健康状态报告，默认监听端口8080，一般用来做健康检查lameduck 15s}kubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpa}hosts {198.18.96.191 xxx.xxx.xxx.xxxfallthrough}#template IN AAAA .      #禁用ipv6#template ANY AAAA {     #ipv6解析时返回NXDOMAIN#    rcode NXDOMAIN#    fallthrough#}prometheus :9153forward . /etc/resolv.conf {prefer_udp             #优先使用udp协议}cache 30loop                     #环路检测，如果检测到环路，则停止CoreDNS。reload                   #动态加载配置文件loadbalance              #循环DNS负载均衡器，可以在答案中随机A、AAAA、MX记录的顺序}
kind: ConfigMap
metadata:name: corednsnamespace: kube-system