mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
162 lines
7.5 KiB
Markdown
162 lines
7.5 KiB
Markdown
Linux DNS 查询剖析(第四部分)
|
||
============================================
|
||
|
||
在 [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 创建流程,可以看到如下的默认输出:
|
||
|
||
```
|
||
$ 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 home
|
||
nameserver 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` 这个<ruby>回环地址<rt>loopback address</rt></ruby>。如果这个地址被容器继承,容器会在其本身的<ruby>网络上下文<rt>networking context</rt></ruby>中使用;由于容器内并没有运行(在 `127.0.0.1` 地址的)DNS 服务器,因此 DNS 查询都会失败。
|
||
|
||
“有了!”你可能有了新主意:将 _主机的_ 的 IP 地址用作 DNS 服务器地址,其中这个 IP 地址可以从容器的<ruby>默认路由<rt>default route</rt></ruby>中获取:
|
||
|
||
```
|
||
root@79a95170e679:/# ip route
|
||
default via 172.17.0.1 dev eth0
|
||
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 服务器地址):
|
||
|
||
```
|
||
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 服务器。
|
||
|
||
在这个问题上,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 在内的容器 <ruby>编排引擎<rt>orchestrators</rt></ruby>,情况又有些不同。
|
||
|
||
### 2) Kubernetes 和 DNS
|
||
|
||
在 Kubernetes 中,最小部署单元是 pod;它是一组相互协作的容器,共享 IP 地址(和其它资源)。
|
||
|
||
Kubernetes 面临的一个额外的挑战是,将 Kubernetes 服务请求(例如,`myservice.kubernetes.io`)通过对应的<ruby>解析器<rt>resolver</rt></ruby>,转发到具体服务地址对应的<ruby>内网地址<rt>private network</rt></ruby>。这里提到的服务地址被称为归属于“<ruby>集群域<rt>cluster domain</rt></ruby>”。集群域可由管理员配置,根据配置可以是 `cluster.local` 或 `myorg.badger` 等。
|
||
|
||
在 Kubernetes 中,你可以为 pod 指定如下四种 pod 内 DNS 查询的方式。
|
||
|
||
**Default**
|
||
|
||
在这种(名称容易让人误解)的方式中,pod 与其所在的主机采用相同的 DNS 查询路径,与前面介绍的主机 DNS 查询一致。我们说这种方式的名称容易让人误解,因为该方式并不是默认选项!`ClusterFirst` 才是默认选项。
|
||
|
||
如果你希望覆盖 `/etc/resolv.conf` 中的条目,你可以添加到 `kubelet` 的配置中。
|
||
|
||
**ClusterFirst**
|
||
|
||
在 `ClusterFirst` 方式中,遇到 DNS 查询请求会做有选择的转发。根据配置的不同,有以下两种方式:
|
||
|
||
第一种方式配置相对古老但更简明,即采用一个规则:如果请求的域名不是集群域的子域,那么将其转发到 pod 所在的主机。
|
||
|
||
第二种方式相对新一些,你可以在内部 DNS 中配置选择性转发。
|
||
|
||
下面给出示例配置并从 [Kubernetes 文档][4]中选取一张图说明流程:
|
||
|
||
```
|
||
apiVersion: v1
|
||
kind: ConfigMap
|
||
metadata:
|
||
name: kube-dns
|
||
namespace: kube-system
|
||
data:
|
||
stubDomains: |
|
||
{"acme.local": ["1.2.3.4"]}
|
||
upstreamNameservers: |
|
||
["8.8.8.8", "8.8.4.4"]
|
||
```
|
||
|
||
在 `stubDomains` 条目中,可以为特定域名指定特定的 DNS 服务器;而 `upstreamNameservers` 条目则给出,待查询域名不是集群域子域情况下用到的 DNS 服务器。
|
||
|
||
这是通过在一个 pod 中运行我们熟知的 `dnsmasq` 实现的。
|
||
|
||
![kubedns](https://zwischenzugs.files.wordpress.com/2018/08/kubedns.png?w=525)
|
||
|
||
剩下两种选项都比较小众:
|
||
|
||
**ClusterFirstWithHostNet**
|
||
|
||
适用于 pod 使用主机网络的情况,例如绕开 Docker 网络配置,直接使用与 pod 对应主机相同的网络。
|
||
|
||
**None**
|
||
|
||
`None` 意味着不改变 DNS,但强制要求你在 `pod` <ruby>规范文件<rt>specification</rt></ruby>的 `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][a]
|
||
译者:[pinewall](https://github.com/pinewall)
|
||
校对:[wxy](https://github.com/wxy)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:https://zwischenzugs.com/
|
||
[1]:https://linux.cn/article-9943-1.html
|
||
[2]:https://linux.cn/article-9949-1.html
|
||
[3]:https://linux.cn/article-9972-1.html
|
||
[4]:https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods
|
||
[5]:https://coredns.io/
|
||
[6]:https://zwischenzugs.com/2017/10/21/openshift-3-6-dns-in-pictures/
|