KubernetesDNS服务简介

介绍

域名系统 (DNS) 是一个用于将各种类型的信息（例如 IP 地址）与易于记忆的名称相关联的系统。默认情况下，大多数 Kubernetes 集群会自动配置内部 DNS 服务，以提供轻量级的服务发现机制。内置的服务发现使应用程序更容易在 Kubernetes 集群上找到并相互通信，即使在节点之间创建、删除和转移 pod 和服务时也是如此。

Kubernetes DNS 服务的实现细节在 Kubernetes 的最新版本中发生了变化。在本文中，我们将看看 Kubernetes DNS 服务的 kube-dns 和 CoreDNS 版本。我们将回顾它们的运行方式以及 Kubernetes 生成的 DNS 记录。

要在开始之前更全面地了解 DNS，请阅读 DNS 术语、组件和概念简介。对于您可能不熟悉的任何 Kubernetes 主题，您可以阅读 An Introduction to Kubernetes 。

Kubernetes DNS 服务提供什么？

在 Kubernetes 1.11 版本之前，Kubernetes DNS 服务基于 kube-dns。 1.11 版引入了 CoreDNS 以解决 kube-dns 的一些安全性和稳定性问题。

不管处理实际 DNS 记录的软件是什么，两种实现都以类似的方式工作：

创建了一个名为 kube-dns 的服务和一个或多个 Pod。
kube-dns 服务侦听来自 Kubernetes API 的 service 和 endpoint 事件，并根据需要更新其 DNS 记录。当您创建、更新或删除 Kubernetes 服务及其关联的 Pod 时会触发这些事件。
kubelet 将每个新 pod 的 /etc/resolv.conf nameserver 选项设置为 kube-dns 服务的集群 IP，并使用适当的 search 选项来允许使用更短的主机名：

解析.conf
```
nameserver 10.32.0.10
search namespace.svc.cluster.local svc.cluster.local cluster.local
options ndots:5
```
然后，在容器中运行的应用程序可以将 example-service.namespace 等主机名解析为正确的集群 IP 地址。

示例 Kubernetes DNS 记录

Kubernetes 服务的完整 DNS A 记录将类似于以下示例：

service.namespace.svc.cluster.local

一个 Pod 会有一个这种格式的记录，反映 Pod 的实际 IP 地址：

10.32.0.125.namespace.pod.cluster.local

此外，为 Kubernetes 服务的命名端口创建了 SRV 记录：

_port-name._protocol.service.namespace.svc.cluster.local

所有这一切的结果是一个内置的、基于 DNS 的服务发现机制，您的应用程序或微服务可以针对一个简单且一致的主机名来访问集群上的其他服务或 Pod。

搜索域和解析较短的主机名

由于 resolv.conf 文件中列出了搜索域后缀，您通常不需要使用完整的主机名来联系其他服务。如果您正在处理同一命名空间中的服务，则可以仅使用服务名称来联系它：

other-service

如果服务位于不同的命名空间中，请将其添加到查询中：

other-service.other-namespace

如果您以 pod 为目标，则至少需要使用以下内容：

pod-ip.other-namespace.pod

正如我们在默认的 resolv.conf 文件中看到的，只有 .svc 后缀会自动完成，因此请确保您指定了 .pod 之前的所有内容。

现在我们知道了 Kubernetes DNS 服务的实际用途，让我们来看看这两种不同实现的一些细节。

Kubernetes DNS 实现细节

如上一节所述，Kubernetes 1.11 版本引入了新的软件来处理 kube-dns 服务。更改的动机是提高服务的性能和安全性。我们先看一下原始的 kube-dns 实现。

kube-dns

Kubernetes 1.11 之前的 kube-dns 服务由三个容器组成，这些容器在 kube-system 命名空间中的 kube-dns pod 中运行。这三个容器是：

kube-dns：一个运行SkyDNS的容器，执行DNS查询解析
dnsmasq： 一种流行的轻量级 DNS 解析器和缓存，用于缓存来自 SkyDNS 的响应
sidecar：一个sidecar容器，用于处理指标报告并响应服务的健康检查

Dnsmasq 中的安全漏洞以及 SkyDNS 的扩展性能问题导致创建了替代系统 CoreDNS。

核心DNS

从 Kubernetes 1.11 开始，一项新的 Kubernetes DNS 服务 CoreDNS 已升级为通用可用性。这意味着它已准备好用于生产，并将成为许多安装工具和托管 Kubernetes 提供商的默认集群 DNS 服务。

CoreDNS 是一个用 Go 编写的单一进程，涵盖了之前系统的所有功能。单个容器解析和缓存 DNS 查询、响应健康检查并提供指标。

除了解决与性能和安全相关的问题外，CoreDNS 还修复了一些其他小错误并添加了一些新功能：

修复了使用 stubDomains 和外部服务之间不兼容的一些问题
CoreDNS 可以通过随机化返回某些记录的顺序来增强基于 DNS 的循环负载平衡
称为 autopath 的功能可以通过更智能地迭代 resolv.conf 中列出的每个搜索域后缀来提高解析外部主机名时的 DNS 响应时间
使用 kube-dns 10.32.0.125.namespace.pod.cluster.local 将始终解析为 10.32.0.125，即使 pod 实际上并不存在。 CoreDNS 有一个“pods 验证”模式，只有当一个 pod 存在于正确的 IP 和正确的命名空间中时才会成功解析。

有关 CoreDNS 以及它与 kube-dns 有何不同的更多信息，您可以阅读 Kubernetes CoreDNS GA 公告。

其他配置选项

Kubernetes 运营商通常希望自定义其 pod 和容器如何解析某些自定义域，或者需要调整上游名称服务器或搜索 resolv.conf 中配置的域后缀。您可以使用 pod 规范的 dnsConfig 选项来执行此操作：

example_pod.yaml

apiVersion: v1
kind: Pod
metadata:
  namespace: example
  name: custom-dns
spec:
  containers:
    - name: example
      image: nginx
  dnsPolicy: "None"
  dnsConfig:
    nameservers:
      - 203.0.113.44
    searches:
      - custom.dns.local

更新此配置将重写 pod 的 resolv.conf 以启用更改。配置直接映射到标准的 resolv.conf 选项，因此上述配置将创建一个包含 nameserver 203.0.113.44 和 search custom.dns.local 行的文件。

结论

在本文中，我们介绍了 Kubernetes DNS 服务为开发人员提供的基础知识，展示了一些服务和 Pod 的 DNS 记录示例，讨论了系统是如何在不同的 Kubernetes 版本上实现的，并强调了一些额外的配置选项，可用于自定义 Pod 的方式解决 DNS 查询。

关于Kubernetes DNS服务的更多信息，请参考Kubernetes DNS for Services and Pods官方文档。