mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
submit tech/20180806 Anatomy of a Linux DNS Lookup - Part IV.md
This commit is contained in:
songshunqiang
parent
de111c26b7
commit
0af0281f8b
@ -1,182 +0,0 @@
|
||||
pinewall is translating
|
||||
|
||||
[Anatomy of a Linux DNS Lookup – Part IV][2]
|
||||
============================================
|
||||
|
||||
In [Anatomy of a Linux DNS Lookup – Part I][3], [Part II][4], and [Part III][5] I covered:
|
||||
|
||||
* `nsswitch`
|
||||
|
||||
* `/etc/hosts`
|
||||
|
||||
* `/etc/resolv.conf`
|
||||
|
||||
* `ping` vs `host` style lookups
|
||||
|
||||
* `systemd` and its `networking` service
|
||||
|
||||
* `ifup` and `ifdown`
|
||||
|
||||
* `dhclient`
|
||||
|
||||
* `resolvconf`
|
||||
|
||||
* `NetworkManager`
|
||||
|
||||
* `dnsmasq`
|
||||
|
||||
In Part IV I’ll cover how containers do DNS. Yes, that’s not simple either…
|
||||
|
||||
* * *
|
||||
|
||||
1) Docker and DNS
|
||||
============================================================
|
||||
|
||||
In [part III][6] we looked at DNSMasq, and learned that it works by directing DNS queries to the localhost address `127.0.0.1`, and a process listening on port 53 there will accept the request.
|
||||
|
||||
So when you run up a Docker container, on a host set up like this, what do you expect to see in its `/etc/resolv.conf`?
|
||||
|
||||
Have a think, and try and guess what it will be.
|
||||
|
||||
Here’s the default output if you run a default Docker setup:
|
||||
|
||||
```
|
||||
$ 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
|
||||
```
|
||||
|
||||
Hmmm.
|
||||
|
||||
#### Where did the addresses `8.8.8.8` and `8.8.4.4` come from?
|
||||
|
||||
When I pondered this question, my first thought was that the container would inherit the `/etc/resolv.conf` settings from the host. But a little thought shows that that won’t always work.
|
||||
|
||||
If you have DNSmasq set up on the host, the `/etc/resolv.conf` file will be pointed at the `127.0.0.1` loopback address. If this were passed through to the container, the container would look up DNS addresses from within its own networking context, and there’s no DNS server available within the container context, so the DNS lookups would fail.
|
||||
|
||||
‘A-ha!’ you might think: we can always use the host’s DNS server by using the _host’s_ IP address, available from within the container as the default route:
|
||||
|
||||
```
|
||||
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
|
||||
```
|
||||
|
||||
#### Use the host?
|
||||
|
||||
From that we can work out that the ‘host’ is on the ip address: `172.17.0.1`, so we could try manually pointing DNS at that using dig (you could also update the `/etc/resolv.conf` and then run `ping`, this just seems like a good time to introduce `dig` and its `@` flag, which points the request at the ip address you specify):
|
||||
|
||||
```
|
||||
root@79a95170e679:/# dig @172.17.0.1 google.com | grep -A1 ANSWER.SECTION
|
||||
;; ANSWER SECTION:
|
||||
google.com. 112 IN A 172.217.23.14
|
||||
```
|
||||
|
||||
However: that might work if you use DNSMasq, but if you don’t it won’t, as there’s no DNS server on the host to look up.
|
||||
|
||||
So Docker’s solution to this quandary is to bypass all that complexity and point your DNS lookups to Google’s DNS servers at `8.8.8.8` and `8.8.4.4`, ignoring whatever the host context is.
|
||||
|
||||
_Anecdote: This was the source of my first problem with Docker back in 2013\. Our corporate network blocked access to those IP addresses, so my containers couldn’t resolve URLs._
|
||||
|
||||
So that’s Docker containers, but container _orchestrators_ such as Kubernetes can do different things again…
|
||||
|
||||
# 2) Kubernetes and DNS
|
||||
|
||||
The unit of container deployment in Kubernetes is a Pod. A pod is a set of co-located containers that (among other things) share the same IP address.
|
||||
|
||||
An extra challenge with Kubernetes is to forward requests for Kubernetes services to the right resolver (eg `myservice.kubernetes.io`) to the private network allocated to those service addresses. These addresses are said to be on the ‘cluster domain’. This cluster domain is configurable by the administrator, so it might be `cluster.local` or `myorg.badger` depending on the configuration you set up.
|
||||
|
||||
In Kubernetes you have four options for configuring how DNS lookup works within your pod.
|
||||
|
||||
* Default
|
||||
|
||||
This (misleadingly-named) option takes the same DNS resolution path as the host the pod runs on, as in the ‘naive’ DNS lookup described earlier. It’s misleadingly named because it’s not the default! ClusterFirst is.
|
||||
|
||||
If you want to override the `/etc/resolv.conf` entries, you can in your config for the kubelet.
|
||||
|
||||
* ClusterFirst
|
||||
|
||||
ClusterFirst does selective forwarding on the DNS request. This is achieved in one of two ways based on the configuration.
|
||||
|
||||
In the first, older and simpler setup, a rule was followed where if the cluster domain was not found in the request, then it was forwarded to the host.
|
||||
|
||||
In the second, newer approach, you can configure selective forwarding on an internal DNS
|
||||
|
||||
Here’s what the config looks like and a diagram lifted from the [Kubernetes docs][7] which shows the flow:
|
||||
|
||||
```
|
||||
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"]
|
||||
```
|
||||
|
||||
The `stubDomains` entry defines specific DNS servers to use for specific domains. The upstream servers are the servers we defer to when nothing else has picked up the DNS request.
|
||||
|
||||
This is achieved with our old friend DNSMasq running in a pod.
|
||||
|
||||
|
||||
|
||||
The other two options are more niche:
|
||||
|
||||
* ClusterFirstWithHostNet
|
||||
|
||||
This applies if you use host network for your pods, ie you bypass the Docker networking setup to use the same network as you would directly on the host the pod is running on.
|
||||
|
||||
* None
|
||||
|
||||
None does nothing to DNS but forces you to specify the DNS settings in the `dnsConfig` field in the pod specification.
|
||||
|
||||
### CoreDNS Coming
|
||||
|
||||
And if that wasn’t enough, this is set to change again as CoreDNS comes to Kubernetes, replacing kube-dns. CoreDNS will offer a few benefits over kube-dns, being more configurabe and more efficient.
|
||||
|
||||
Find out more [here][8].
|
||||
|
||||
If you’re interested in OpenShift networking, I wrote a post on that [here][9]. But that was for 3.6 so is likely out of date now.
|
||||
|
||||
### End of Part IV
|
||||
|
||||
That’s part IV done. In it we covered.
|
||||
|
||||
* Docker DNS lookups
|
||||
|
||||
* Kubernetes DNS lookups
|
||||
|
||||
* Selective forwarding (stub domains)
|
||||
|
||||
* kube-dns
|
||||
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
|
||||
|
||||
作者：[zwischenzugs][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://zwischenzugs.com/
|
||||
[1]:https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
|
||||
[2]:https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/
|
||||
[3]:https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/
|
||||
[4]:https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/
|
||||
[5]:https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-lookup-part-iii/
|
||||
[6]:https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-lookup-part-iii/
|
||||
[7]:https://kubernetes.io/docs/tasks/administer-cluster/dns-custom-nameservers/#impacts-on-pods
|
||||
[8]:https://coredns.io/
|
||||
[9]:https://zwischenzugs.com/2017/10/21/openshift-3-6-dns-in-pictures/
|
||||
@ -0,0 +1,165 @@
|
||||
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`；`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` 实现的。
|
||||
|
||||
|
||||
|
||||
剩下两种选项都比较小众：
|
||||
|
||||
* 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)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://zwischenzugs.com/
|
||||
[1]:https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/
|
||||
[2]:https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/
|
||||
[3]:https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-lookup-part-iii/
|
||||
[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/
|
||||
Loading…
Reference in New Issue
Block a user