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 端口并处理查询请求。

在按上述方式配置 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.

  6. search home

  7. nameserver 8.8.8.8

  8. 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 服务器,因此 DNS 查询都会失败。

“有了!”你可能有了新主意:将 主机的 的 IP 地址用作 DNS 服务器地址,其中这个 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 服务器的方式进行测试(你也可以更新 /etc/resolv.conf 文件并使用 ping 进行测试;但我觉得这里很适合介绍新的 dig 工具及其 @ 参数,后者用于指定需要查询的 DNS 服务器地址):

  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 服务器。

在这个问题上,Docker 的解决方案是忽略所有可能的复杂情况,即无论主机中使用什么 DNS 服务器,容器内都使用 Google 的 DNS 服务器 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

在这种(名称容易让人误解)的方式中,pod 与其所在的主机采用相同的 DNS 查询路径,与前面介绍的主机 DNS 查询一致。我们说这种方式的名称容易让人误解,因为该方式并不是默认选项!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 服务器;而 upstreamNameservers 条目则给出,待查询域名不是集群域子域情况下用到的 DNS 服务器。

这是通过在一个 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中国 荣誉推出


阅读更多
换一批

没有更多推荐了,返回首页