Linux DNS 查询剖析（第四部分） | Linux 中国

版权声明：本文为博主原创文章，未经博主同意不得转载。

https://blog.csdn.net/F8qG7f9YD02Pe/article/details/82879414

640?wx_fmt=jpeg在第四部分中，我将介绍容器怎样完毕 DNS 查询。你想的没错，也不是那么简单。

-- Zwischenzugs

实用的原文链接请訪问文末的“原文链接”获得可点击的文内链接、全尺寸原图和相关文章。

致谢编译自　|　
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 创建流程，能够看到例如以下的默认输出：

  1. $  docker run  ubuntu cat /etc/resolv.conf
  2. # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
  3. #     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
  4. # 127.0.0.53 is the systemd-resolved stub resolver.
  5. # run "systemd-resolve --status" to see details about the actual nameservers.
  7. search home
  8. nameserver 8.8.8.8
  9. nameserver 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中获取：
  1. root@79a95170e679:/# ip route
  2. default via 172.17.0.1 dev eth0
  3. 172.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地址）：
  1. root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION
  2. ;; ANSWER SECTION:
  3. 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]中选取一张图说明流程：
  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4.   name: kube-dns
  5.   namespace: kube-system
  6. data:
  7.   stubDomains: |
  8.     {"acme.local": ["1.2.3.4"]}
  9.   upstreamNameservers: |
  10.     ["8.8.8.8", "8.8.4.4"]
在 stubDomains 条目中，能够为特定域名指定特定的 DNS server；而 upstreamNameservers 条目则给出，待查询域名不是集群域子域情况下用到的 DNS server。
这是通过在一个 pod 中执行我们熟知的 dnsmasq 实现的。
640?wx_fmt=png
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-dns
via: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
作者：zwischenzugs[8] 译者：pinewall 校对：wxy
本文由 LCTT 原创编译。Linux中国 荣誉推出


                

              

                






		

		
posted @ 
2018-11-02 04:50 
zhchoutai 
阅读(529) 
评论(0) 
编辑 
收藏 
举报