https://blog.csdn.net/F8qG7f9YD02Pe/article/details/82879414
实用的原文链接请訪问文末的“ 原文链接”获得可点击的文内链接、全尺寸原图和相关文章。 致谢 编译自 | https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/ 作者 | Zwischenzugs 译者 | Andy Song (pinewall) ????共计翻译： 38.0 篇 贡献时间：170 天
在 Linux DNS 查询剖析（第一部分）[1]，Linux DNS 查询剖析（第二部分）[2] 和 Linux DNS 查询剖析（第三部分）[3] 中，我们已经介绍了下面内容：
◈nsswitch◈ /etc/hosts◈ /etc/resolv.conf◈ ping 与 host 查询方式的对照◈ systemd 和相应的 networking 服务◈ ifup 和 ifdown◈ dhclient◈ resolvconf◈ NetworkManager◈ dnsmasq 在第四部分中，我将介绍容器怎样完毕 DNS 查询。你想的没错。也不是那么简单。
1) Docker 和 DNS
在 Linux DNS 查询剖析（第三部分）[3] 中，我们介绍了 dnsmasq。其工作方式例如以下：将 DNS 查询指向到 localhost 地址 127.0.0.1。同一时候启动一个进程监听 53 port并处理查询请求。
在按上述方式配置 DNS 的主机上，假设执行了一个 Docker 容器，容器内的 /etc/resolv.conf 文件会是怎样的呢？
我们来动手试验一下吧。
依照默认 Docker 创建流程，能够看到例如以下的默认输出：
$ docker run ubuntu cat /etc/resolv.conf# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN# 127.0.0.53 is the systemd-resolved stub resolver.# run "systemd-resolve --status" to see details about the actual nameservers.search homenameserver 8.8.8.8nameserver 8.8.4.4
奇怪！
地址 8.8.8.8 和 8.8.4.4 从何而来呢？
当我思考容器内的 /etc/resolv.conf 配置时，我的第一反应是继承主机的 /etc/resolv.conf。但仅仅要略微进一步分析，就会发现这样并不总是有效的。
假设在主机上配置了 dnsmasq，那么 /etc/resolv.conf 文件总会指向 127.0.0.1这个回环地址loopback address。假设这个地址被容器继承，容器会在其本身的网络上下文networking context中使用；由于容器内并没有执行（在 127.0.0.1 地址的）DNS server。因此 DNS 查询都会失败。
“有了。”你可能有了新主意：将 主机的 的 IP 地址用作 DNS server地址，当中这个 IP 地址能够从容器的默认路由default route中获取：
root@79a95170e679:/# ip routedefault via 172.17.0.1 dev eth0172.17.0.0/16 dev eth0 proto kernel scope link src 172.17.0.2
使用主机 IP 地址真的可行吗？
从默认路由中，我们能够找到主机的 IP 地址 172.17.0.1。进而能够通过手动指定 DNS server的方式进行測试（你也能够更新 /etc/resolv.conf 文件并使用 ping 进行測试。但我认为这里非常适合介绍新的 dig 工具及其 @ 參数，后者用于指定须要查询的 DNS server地址）：
root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION;; ANSWER SECTION:google.com. 112 IN A 172.217.23.14
可是另一个问题，这样的方式仅适用于主机配置了 dnsmasq 的情况。假设主机没有配置 dnsmasq，主机上并不存在用于查询的 DNS server。
在这个问题上，Docker 的解决方式是忽略全部可能的复杂情况，即不管主机中使用什么 DNS server。容器内都使用 Google 的 DNS server 8.8.8.8 和 8.8.4.4 完毕 DNS 查询。
我的经历：在 2013 年。我遇到了使用 Docker 以来的第一个问题，与 Docker 的这样的 DNS 解决方式密切相关。我们公司的网络屏蔽了 8.8.8.8 和 8.8.4.4，导致容器无法解析域名。
这就是 Docker 容器的情况，但对于包含 Kubernetes 在内的容器 编排引擎orchestrators。情况又有些不同。
2) Kubernetes 和 DNS
在 Kubernetes 中。最小部署单元是 pod；它是一组相互协作的容器。共享 IP 地址（和其他资源）。
Kubernetes 面临的一个额外的挑战是。将 Kubernetes 服务请求（比如。myservice.kubernetes.io）通过相应的解析器resolver。转发到详细服务地址相应的内网地址private network。这里提到的服务地址被称为归属于“集群域cluster domain”。
集群域可由管理员配置，依据配置能够是 cluster.local 或 myorg.badger 等。
在 Kubernetes 中，你能够为 pod 指定例如以下四种 pod 内 DNS 查询的方式。
Default
在这样的（名称easy让人误解）的方式中，pod 与其所在的主机採用同样的 DNS 查询路径，与前面介绍的主机 DNS 查询一致。我们说这样的方式的名称easy让人误解，由于该方式并非默认选项！ClusterFirst 才是默认选项。
假设你希望覆盖 /etc/resolv.conf 中的条目，你能够加入到 kubelet 的配置中。
ClusterFirst
在 ClusterFirst 方式中，遇到 DNS 查询请求会做有选择的转发。
依据配置的不同，有下面两种方式：
第一种方式配置相对古老但更简明，即採用一个规则：假设请求的域名不是集群域的子域，那么将其转发到 pod 所在的主机。
另外一种方式相对新一些，你能够在内部 DNS 中配置选择性转发。
下面给出演示样例配置并从 Kubernetes 文档[4]中选取一张图说明流程：
apiVersion: v1kind: ConfigMapmetadata:name: kube-dnsnamespace: kube-systemdata:stubDomains: |{ "acme.local": ["1.2.3.4"]}upstreamNameservers: |["8.8.8.8", "8.8.4.4"]
在 stubDomains 条目中，能够为特定域名指定特定的 DNS server；而 upstreamNameservers 条目则给出，待查询域名不是集群域子域情况下用到的 DNS server。
这是通过在一个 pod 中执行我们熟知的 dnsmasq 实现的。
kubedns
剩下两种选项都比較小众：
ClusterFirstWithHostNet
适用于 pod 使用主机网络的情况，比如绕开 Docker 网络配置，直接使用与 pod 相应主机同样的网络。
None
None 意味着不改变 DNS，但强制要求你在 pod 规范文件specification的 dnsConfig 条目中指定 DNS 配置。
CoreDNS 即将到来
除了上面提到的那些，一旦 CoreDNS 代替 Kubernetes 中的 kube-dns，情况还会发生变化。CoreDNS 相比 kube-dns 具有可配置性更高、效率更高等优势。
假设想了解很多其他。參考这里[5]。
假设你对 OpenShift 的网络感兴趣，我曾写过一篇文章[6]可供你參考。
但文章中 OpenShift 的版本号是 3.6。可能有些过时。
第四部分总结
第四部分到此结束，当中我们介绍了：
◈ Docker DNS 查询◈ Kubernetes DNS 查询◈ 选择性转发（子域不转发）◈ kube-dnsvia: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
作者：zwischenzugs[8] 译者：pinewall 校对：wxy
本文由 LCTT 原创编译。Linux中国 荣誉推出