自定义 DNS 服务
本页说明如何配置 DNS Pod 和自定义 DNS 解析过程。 在 Kubernetes 1.11 和更高版本中,CoreDNS 位于 GA 并且默认情况下与 kubeadm 一起安装。 请参见CoreDNS 的 ConfigMap 选项 and 使用 CoreDNS 进行服务发现。
准备开始
要获知版本信息,请输入 kubectl version
.
- Kubernetes version 1.6 or later. To work with CoreDNS, version 1.9 or later.
- The appropriate add-on: kube-dns or CoreDNS. To install with kubeadm, see the kubeadm reference documentation. –>
你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群,你可以通过 Minikube 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:
要获知版本信息,请输入 kubectl version
.
- Kubernetes 版本 1.6 或更新。如果与 CoreDNS 匹配,版本 1.9 或更新。
- 合适的 add-on 插件: kube-dns 或 CoreDNS. 使用 kubeadm 安装,请参见 kubeadm 帮助文档.
介绍
DNS 是使用插件管理器集群 add-on自动启动的内置的 Kubernetes 服务。
从 Kubernetes v1.12 开始,CoreDNS 是推荐的 DNS 服务器,取代了kube-dns。 但是,默认情况下,某些 Kubernetes 安装程序工具仍可能安装 kube-dns。 请参阅安装程序提供的文档,以了解默认情况下安装了哪个 DNS 服务器。
CoreDNS 的部署,作为一个 Kubernetes 服务,通过静态 IP 的方式暴露。
CoreDNS 和 kube-dns 服务在 metadata.name
字段中均被命名为 kube-dns
。 这样做是为了与依靠传统 kube-dns
服务名称来解析集群内部地址的工作负载具有更大的互操作性。它抽象出哪个 DNS 提供程序在该公共端点后面运行的实现细节。
kubelet 使用 --cluster-dns = <dns-service-ip>
标志将 DNS 传递到每个容器。
DNS 名称也需要域。 您可在 kubelet 中使用 --cluster-domain = <default-local-domain>
标志配置本地域。
DNS 服务器支持正向查找(A 记录),端口发现(SRV 记录),反向 IP 地址发现(PTR 记录)等。 更多信息,请参见Pod 和 服务的 DNS。
如果 Pod 的 dnsPolicy 设置为 “default
“,则它将从 Pod 运行所在节点上的配置中继承名称解析配置。 Pod 的 DNS 解析应该与节点相同。
但请参阅已知问题。
如果您不想这样做,或者想要为 Pod 使用其他 DNS 配置,则可以
使用 kubelet 的 --resolv-conf
标志。 将此标志设置为 “” 以避免 Pod
继承 DNS。 将其设置为有效的文件路径以指定除以下以外的文件
/etc/resolv.conf
,用于 DNS 继承。
CoreDNS
CoreDNS是通用的权威DNS服务器,可以用作集群DNS,符合dns 规范。
CoreDNS ConfigMap 选项
CoreDNS 是模块化且可插拔的 DNS 服务器,每个插件都为 CoreDNS 添加了新功能。 可以通过维护Corefile,即CoreDNS 配置文件。 集群管理员可以修改 CoreDNS Corefile 的 ConfigMap,以更改服务发现的工作方式。
在 Kubernetes 中,已经使用以下默认 Corefile 配置安装了 CoreDNS。
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy ./etc/resolv.conf
cache 30
loop
reload
loadbalance
}
Corefile 配置包括以下 CoreDNS 的 插件:
- 错误:错误记录到 stdout。
- 健康:CoreDNS 的健康报告给 http://localhost:8080/health。
- kubernetes:CoreDNS 将基于 Kubernetes 的服务和 Pod 的 IP 答复 DNS 查询。 您可以在 此处.
提供
pods insecure
选项是为了与 kube-dns 向前兼容。 您可以使用pods verified
选项,该选项仅在相同名称空间中存在具有匹配 IP 的 pod 时才返回 A 记录。 如果您不使用 Pod 记录,则可以使用pods disabled
选项。 ‘Upstream’ 用来解析指向外部主机的服务(外部服务)。
- prometheus:CoreDNS的度量标准以Prometheus格式在 http://localhost:9153/metrics 上提供。
- proxy: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf).
- cache:这将启用前端缓存。
- loop:检测到简单的转发循环,如果发现死循环,则中止 CoreDNS 进程。
- reload:允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后,请等待两分钟,以使更改生效。
- loadbalance:这是一个轮询 DNS 负载均衡器,它在应答中随机分配 A,AAAA 和 MX 记录的顺序。
您可以通过修改 ConfigMap 来修改默认的 CoreDNS 行为。
使用 CoreDN 配置存根域和上游域名服务器
CoreDNS 能够使用 proxy plugin. 配置存根域和上游域名服务器。
示例
如果集群操作员的 Consul 域服务器位于 10.150.0.1,并且所有 Consul 名称都带有后缀.consul.local。 要在 CoreDNS 中对其进行配置,集群管理员可以在 CoreDNS 的 ConfigMap 中创建加入以下字段。
consul.local:53 {
errors
cache 30
proxy . 10.150.0.1
}
要显式强制所有非集群 DNS 查找通过特定的域名服务器(位于172.16.0.1),请将 proxy
和 forward
指向域名服务器,而不是 /etc/resolv.conf
。
proxy . 172.16.0.1
最终的 ConfigMap 以及默认的 Corefile
配置如下所示:
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
data:
Corefile: |
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
upstream 172.16.0.1
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
proxy . 172.16.0.1
cache 30
loop
reload
loadbalance
}
consul.local:53 {
errors
cache 30
proxy . 10.150.0.1
}
在 Kubernetes 1.10 和更高版本中,kubeadm 支持将 kube-dns ConfigMap 自动转换为 CoreDNS ConfigMap。 注意:尽管kube-dns接受 stubdomain 和 nameserver 的 FQDN(例如:ns.foo.com),但 CoreDNS 不支持此功能。 转换期间,CoreDNS 配置中将省略所有 FQDN 域名服务器。
Kube-dns
由于 CoreDNS 现在是默认设置,因此 Kube-dns 现在可以用作可选的 DNS 服务器。 正在运行的DNS Pod包含3个容器:
- “
kubedns
“:监测 Kubernetes 主节点的服务和 Endpoints 的更改,并维护内存中的查找结构以服务 DNS 请求。 - “
dnsmasq
“:添加 DNS 缓存以提高性能。 - “
sidecar
“:提供单个运行状况检查端点,对 dnsmasq 和 Kubedns 进行健康检查。
配置存根域和上游 DNS 服务器
集群管理员可以指定自定义存根域和上游域名服务器通过为 kube-dns (kube-system:kube-dns
) 提供 ConfigMap。
例如,以下 ConfigMap 使用单个存根域和两个上游域名服务器设置 DNS 配置:
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"]
带 “.acme.local” 后缀的 DNS 请求 被转发到侦听 1.2.3.4 的 DNS。 通过 Google 公共 DNS 进行向上查询。
下表描述了具有特定域名的查询如何映射到 其目标DNS服务器:
域名 | 服务器回答查询 |
---|---|
kubernetes.default.svc.cluster.local | kube-dns |
foo.acme.local | 自定义 DNS(1.2.3.4) |
widget.com | 上游 DNS(8.8.8.8、8.8.4.4中的一个) |
请参见 ConfigMap options 有关配置选项格式的详细信息。
对 Pod 的影响
自定义上游域名服务器和存根域不影响 dnsPolicy
设置为 “Default
” 或 “None
” 的 Pod。
如果 Pod 的 dnsPolicy
设置为 “ClusterFirst
“,则根据是否配置了存根域和上游 DNS 服务器来不同地处理其名称解析。
不使用自定义配置:任何与配置不匹配的查询 集群域后缀(例如 “www.kubernetes.io”)将转发到从节点继承的上游域名服务器。
使用自定义配置:如果存根域和上游 DNS 服务器 配置完成后,DNS 查询将按照以下流程进行路由::
1.首先将查询发送到 kube-dns 中的 DNS 缓存层。
1.在以下情况下,从缓存层检查请求的后缀,然后将其转发到适当的 DNS::
* *带集群后缀的名称*,例如 “.cluster.local”: 该请求被发送到 kube-dns。
* *带存根域名后缀的名称*,例如 “.acme.local”: 该请求将发送到已配置的自定义 DNS 解析器,例如在 1.2.3.4 处进行侦听。
* *名称没有匹配的后缀*,例如 “widget.com”: 该请求被转发到上游 DNS, 例如位于 8.8.8.8 和 8.8.4.4 的 Google 公共 DNS 服务器。
ConfigMap 选项
kube-dns kube-system:kube-dns
的 ConfigMap 选项:
领域 | 格式 | 描述 |
---|---|---|
stubDomains (可选) |
使用 DNS 后缀键(例如“ acme.local”)和由 DNS IP 的 JSON 数组组成的值的 JSON 映射。 | 目标域名服务器本身可以是 Kubernetes 服务。 例如,您可以运行自己的 dnsmasq 副本,以将自定义 DNS 名称导出到 ClusterDNS 命名空间中。 |
upstreamNameservers (可选) |
DNS IP的 JSON 数组。 | 如果指定,则这些值替换默认情况下从节点的 /etc/resolv.conf 中获取的域名服务器。 限制:最多可以指定三个上游域名服务器。 |
例子
示例:存根域
在此示例中,用户具有他们想与 kube-dns 集成的 Consul DNS 服务发现系统。 consul 域服务器位于 10.150.0.1,所有领事名称均带有后缀 .consul.local
。 要配置 Kubernetes,集群管理员将创建以下 ConfigMap:
yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{"consul.local": ["10.150.0.1"]}
需要注意的是集群管理员不希望覆盖节点的上游域名服务器,所以他们没有指定可选的 upstreamNameservers
字段。
示例: 上游域名服务器
在此示例中,集群管理员希望显式强制所有非集群 DNS 查找通过其自己的域名服务器172.16.0.1)。 在这种情况下,他们使用指定所需域名服务器的 upstreamNameservers
字段创建一个 ConfigMap:
apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
upstreamNameservers: |
["172.16.0.1"]
CoreDNS 配置等同于 kube-dns
CoreDNS 不仅仅提供 kube-dns 的功能。
为 kube-dns 创建的 ConfigMap 支持 StubDomains
和 upstreamNameservers
转换为 CoreDNS 中的 proxy
插件。
同样,kube-dns 中的 Federations
插件会转换为 CoreDNS 中的 federation
插件。
示例
用于 kubedns 的此示例 ConfigMap 描述了 federations, stubdomains and upstreamnameservers:
apiVersion: v1
data:
federations: |
{"foo" : "foo.feddomain.com"}
stubDomains: |
{"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
upstreamNameservers: |
["8.8.8.8", "8.8.4.4"]
kind: ConfigMap
CoreDNS 中的等效配置将创建一个 Corefile:
For federations:
federation cluster.local { foo foo.feddomain.com }
For stubDomains:
abc.com:53 { errors cache 30 proxy . 1.2.3.4 } my.cluster.local:53 { errors cache 30 proxy . 2.3.4.5 }
带有默认插件的完整 Corefile:
.:53 {
errors
health
kubernetes cluster.local in-addr.arpa ip6.arpa {
upstream 8.8.8.8 8.8.4.4
pods insecure
fallthrough in-addr.arpa ip6.arpa
}
federation cluster.local {
foo foo.feddomain.com
}
prometheus :9153
proxy . 8.8.8.8 8.8.4.4
cache 30
}
abc.com:53 {
errors
cache 30
proxy . 1.2.3.4
}
my.cluster.local:53 {
errors
cache 30
proxy . 2.3.4.5
}
迁移到 CoreDNS
要将 kube-dns 迁移到 CoreDNS,可使用 详细博客 来帮助用户在迁移自 kube-dns。 集群管理员还可以使用部署脚本 进行迁移。
## 下一步是什么 - 调试 DNS 解析。 ```
反馈
此页是否对您有帮助?
感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题 报告问题 或者 提出改进建议.