Kubernetes中的DNS解析实现
Contents
最近在处理Kuberntes中的DNS解析问题, 正好借这个机会学习下Kubernetes中的DNS服务器工作原理, 处理的dns服务器问题会稍后再水一篇博客介绍.
我对解析过程的了解也比较粗浅, 仅介绍下配置中的内容.
Pod中的DNS概览
众所周知, DNS服务器用于将域名转换为IP(具体为啥要转换建议复习下7层网络模型).
Linux服务器中, dns解析配置位于/etc/resolv.conf, 在pod中也不例外, 下面是某个Pod中的配置:
1 | nameserver 10.96.0.10 |
假如我们平时想要修改自己本机上的dns服务器, 比如想要修改为8.8.8.8, 就会这么去修改:
1 | nameserver 8.8.8.8 |
如果想要调试DNS服务器, 测试返回结果, 可以使用dig工具:
1 | > dig baidu.com @8.8.8.8 |
DNS服务器 – nameserver
我们先从nameserver 10.96.0.10来看, 为什么请求这个地址可以进行DNS解析.
这个答案就是iptables, 我仅截取udp的53端口, 以下内容可以通过iptables-save获得.
1 | -A KUBE-SERVICES -d 10.96.0.10/32 -p udp -m comment --comment "kube-system/kube-dns:dns cluster IP" -m udp --dport 53 -j KUBE-SVC-TCOU7JCQXEZGVUNU |
我们再看下这条链KUBE-SVC-TCOU7JCQXEZGVUNU:
1 | -A KUBE-SVC-TCOU7JCQXEZGVUNU -m statistic --mode random --probability 0.50000000000 -j KUBE-SEP-Q3HNNZPXUAYYDXW2 |
Kubernetes的deployment
再看下我们的kubernetes中pod的IP地址, 也就是说, dns请求实际上会到我们的coredns容器中被处理.
1 | > kubectl -n kube-system get pods -o wide | grep dns |
Kubernetes中service的具体实现
再查看下对应的service, 可以看到, 上述机器中的iptables其实就是service的具体实现方式.
1 | > kubectl -n kube-system get svc | grep dns |
可能有人会有疑问, 现在是2个pod可以均分流量, 如果是3个, 4个pod, iptables是如何做转发的呢,
正好我有这个疑问, 因此我就再加了2个pod, 看看iptables是怎么实现对于4个pod均分流量的.
这是最后的实现方式:
1 | -A KUBE-SVC-TCOU7JCQXEZGVUNU -m statistic --mode random --probability 0.25000000000 -j KUBE-SEP-HTZHQHQPOHVVNWZS |
这些语句的意思应该是:
- 前1/4的流量到一条链中, 剩3/4
- 剩下3/4的流量, 1/3到一条链, 剩2/4
- 剩下2/4的浏览, 1/2到一条链, 剩1/4
- 最后1/4到一条链
通过这样的方式对流量进行了均分, 还是挺巧妙的, 这样, 5个,10个也是可以依次去分的.
resolv.conf中其他参数解析
1 | search kube-system.svc.cluster.local svc.cluster.local cluster.local |
详细的介绍可以看这里: resolv.conf手册, 我简单的说下我的理解.
search参数
假如没有这个search参数, 我们查找时:
1 | > ping kube-dns |
如果增加了search参数后, 再去查找:
1 | > ping kube-dns |
可以看到, 解析域名时, 如果给定的域名无法查找, 会添加search后面的后缀进行查找(假如以.结尾, 类似kube-dns., 这样的域名不会再去尝试, FQDN域名).
search的工作就是帮我们去尝试, 用在kubenetes中, 配置kube-system.svc.cluster.local svc.cluster.local cluster.local
就会帮我们尝试, 我们ping abc, 就会这样进行查询
1 | [INFO] 10.202.37.232:50940 - 51439 "A IN abc.kube-system.svc.cluster.local. udp 51 false 512" NXDOMAIN qr,aa,rd 144 0.000114128s |
ndots以及其优化问题
search配置需要与ndots一起使用, 默认的ndots是1, 它的作用是:
如果检查到被查询的域名中dot的数量小于该值时, 就会优先尝试添加search域中的后缀.
1 | Resolver queries having fewer than |
实际举例
假如我们的dns配置如下:
1 | search kube-system.svc.cluster.local svc.cluster.local cluster.local |
当我们ping abc.123(此域名只有一个dot), dns服务器的日志如下, 可以注意到日志中最先尝试的是abc.123.kube-system.svc.cluster.local., 最后才会尝试我们的域名.
1 | [INFO] 10.202.37.232:33386 - 36445 "A IN abc.123.kube-system.svc.cluster.local. udp 55 false 512" NXDOMAIN qr,aa,rd 148 0.001700129s |
那我们ping abc.123.def(此域名有两个dot), dns服务器的日志像下面这样, 注意到日志中最优先尝试的是abc.123.def.
1 | [INFO] 10.202.37.232:39314 - 794 "A IN abc.123.def. udp 29 false 512" NXDOMAIN qr,rd,ra 104 0.025049846s |
希望借这个例子让大家明白两点:
- 无论ndots是多少, search参数中的后缀都会被以此查找(我们测试时使用了一个不存在的域名, 解析工具尝试了全部的可能)
- ndots的不妥当设置, 可能会给dns服务器造成压力(假如域名是存在的, dns查询会尽快返回, 不会继续查找了, 会减少服务器压力)
优化讨论
假如现在ndots是2, 我们想要查询baidu.com, 由于dot数目为1小于配置中的2, 会首先添加后缀进行查找:
1 | [INFO] 10.202.37.232:42911 - 55931 "A IN baidu.com.kube-system.svc.cluster.local. udp 57 false 512" NXDOMAIN qr,aa,rd 150 0.000116042s |
那么, 我们会产生3个无用的dns查询记录. 对于DNS服务器来说, 仅仅是baidu.com这个域名, 流量就变成了4倍.
假如n继续增大呢, 就像是Kubernetes中默认给定的5, 那我们会产生更多的无效请求, 因为不只是baidu.com,
就连map.baidu.com, m.map.baidu.com, 这些域名也要从search域中开始尝试, 会对DNS服务器造成比较大的压力.
我个人建议:
- 如果内部服务之间请求十分频繁, 也就是我们需要经常访问
xxx.svc.cluster.local这样的域名, 那么可以保持ndots较大- 但是内部服务之间请求比较少时, 强烈建议调小ndots, 以减少无用流量的产生, 减轻dns服务器的压力 我个人用的话, 改成2就好
总结
很抱歉, 这篇文章的大部分篇幅都是在说nameserver是如何解析的, resolv.conf中的内容比较少,
主要原因是我前些天一直在看iptables, 这次正好有, 所以花时间看下, 可能有种想要炫技的心理吧.
解决问题的时候, 理解后面的参数是比较重要的, 我也贴了一些自己的实验, 希望能对大家有所帮助吧, 至少了解了ndots之后再考虑调优.