---
author: Zwischenzugs
category: 技术
comments_data: []
count:
  commentnum: 0
  favtimes: 0
  likes: 0
  sharetimes: 0
  viewnum: 5126
date: '2018-09-27 22:02:33'
editorchoice: false
excerpt: 在第四部分中，我将介绍容器如何完成 DNS 查询。你想的没错，也不是那么简单。
fromurl: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
id: 10056
islctt: true
largepic: /images/p/201809/27/220200ozwwbwyizwydadi0.jpeg
permalink: /article-10056-1.html
pic: /images/p/201809/27/220200ozwwbwyizwydadi0.jpeg.thumb.jpg
related:
- displayorder: 0
  raid: 9972
reviewer: wxy
selector: ''
summary: 在第四部分中，我将介绍容器如何完成 DNS 查询。你想的没错，也不是那么简单。
tags:
- DNS
- 容器
thumb: false
title: Linux DNS 查询剖析（第四部分）
titlepic: true
translator: pinewall
updated: '2018-09-27 22:02:33'
---

![](/images/p/201809/27/220200ozwwbwyizwydadi0.jpeg)


在 [Linux DNS 查询剖析（第一部分）](/article-9943-1.html)，[Linux DNS 查询剖析（第二部分）](/article-9949-1.html) 和 [Linux DNS 查询剖析（第三部分）](/article-9972-1.html) 中，我们已经介绍了以下内容：


* `nsswitch`
* `/etc/hosts`
* `/etc/resolv.conf`
* `ping` 与 `host` 查询方式的对比
* `systemd` 和对应的 `networking` 服务
* `ifup` 和 `ifdown`
* `dhclient`
* `resolvconf`
* `NetworkManager`
* `dnsmasq`


在第四部分中，我将介绍容器如何完成 DNS 查询。你想的没错，也不是那么简单。


### 1) Docker 和 DNS


在 [Linux DNS 查询剖析（第三部分）](/article-9972-1.html) 中，我们介绍了 `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 文档](https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods)中选取一张图说明流程：



```
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](/images/p/201809/27/220238y708309mckx80x8k.png)


剩下两种选项都比较小众：


**ClusterFirstWithHostNet**


适用于 pod 使用主机网络的情况，例如绕开 Docker 网络配置，直接使用与 pod 对应主机相同的网络。


**None**


`None` 意味着不改变 DNS，但强制要求你在 `pod` <ruby> 规范文件 <rt>  specification </rt></ruby>的 `dnsConfig` 条目中指定 DNS 配置。


### CoreDNS 即将到来


除了上面提到的那些，一旦 `CoreDNS` 取代 Kubernetes 中的 `kube-dns`，情况还会发生变化。`CoreDNS` 相比 `kube-dns` 具有可配置性更高、效率更高等优势。


如果想了解更多，参考[这里](https://coredns.io/)。


如果你对 OpenShift 的网络感兴趣，我曾写过一篇[文章](https://zwischenzugs.com/2017/10/21/openshift-3-6-dns-in-pictures/)可供你参考。但文章中 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](https://zwischenzugs.com/) 译者：[pinewall](https://github.com/pinewall) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出