用于Kubernetes集群DNS的CoreDNS GA

作者：John Belamaric（Infoblox）

编者注：这篇文章是 系列深入文章 Kubernetes 1.11的新功能

介绍

在Kubernetes 1.11中， 核心DNS 作为基于kube-dns插件的替代产品，已达到基于DNS的服务发现的通用可用性（GA）。这意味着CoreDNS将作为各种安装工具的即将发布版本中的一个选项提供。实际上，kubeadm团队选择将其设为从Kubernetes 1.11开始的默认选项。

基于DNS的服务发现在kube-dns集群插件中很久以来一直是Kubernetes的一部分。通常，此方法效果很好，但是围绕实现的可靠性，灵活性和安全性存在一些担忧。

核心DNS是通用的权威DNS服务器，它提供与Kubernetes的向后兼容但可扩展的集成。它解决了kube-dns所遇到的问题，并提供了许多独特的功能，可以解决各种用例。

在本文中，您将了解kube-dns和CoreDNS的实现方面的差异，以及CoreDNS提供的一些有用的扩展。

实施差异

In kube-dns, several containers are used within a single pod: kubedns, dnsmasq, 和 sidecar. The kubedns 容器监视Kubernetes API并根据以下信息提供DNS记录 Kubernetes DNS规范, dnsmasq provides caching 和 stub domain support, 和 sidecar provides metrics 和 health checks.

This setup leads to a few issues that have been seen over time. For one, security vulnerabilities in dnsmasq have led to the need for a security-patch release of Kubernetes in the past. Additionally, because dnsmasq handles the stub domains, but kubedns handles the External Services, you cannot use a stub domain in an external service, which is very 限于该功能（请参阅 DNS＃131）。

所有这些功能都是在CoreDNS的单个容器中完成的，该容器正在运行用Go编写的进程。的 启用的不同插件可复制（并增强）在kube-dns中发现的功能。

配置CoreDNS

在kube-dns中，您可以 修改ConfigMap 更改服务发现的行为。这允许添加 服务于存根域，修改上游名称服务器以及启用联盟等功能。

在CoreDNS中，您可以类似地修改CoreDNS的ConfigMap 核心文件 改变服务发现的方式 作品。此Corefile配置提供了比kube-dns更多的选项，因为它是 主要配置文件，CoreDNS用于配置其所有功能，即使不是 Kubernetes related.

When upgrading from kube-dns to 核心DNS using kubeadm, your existing ConfigMap will be used to generate the 为您定制的Corefile，包括存根域，联合身份验证和上游名称服务器的所有配置。看到 使用CoreDNS进行服务发现 更多细节。

错误修复和增强

在CoreDNS中解决了kube-dn的多个未解决问题，无论是默认配置还是某些自定义配置。

指标

默认CoreDNS配置的功能行为与kube-dns相同。然而， 您需要了解的一个区别是发布的指标不相同。在kube-dns中， you get separate metrics for dnsmasq 和 kubedns (skydns). In 核心DNS there is a completely 不同的指标集，因为它们都是单个过程。您可以找到有关这些的更多详细信息 CoreDNS上的指标 Prometheus插件 页。

一些特殊功能

标准CoreDNS Kubernetes配置旨在与先前版本向后兼容 kube-dns行为。但是通过一些配置更改，CoreDNS可以允许您修改 DNS服务发现在您的群集中起作用。这些功能中的许多功能仍然打算 compliant 与 Kubernetes DNS规范; 它们增强了功能，但仍向后兼容。由于CoreDNS不是 只要 专为Kubernetes设计，但它是通用DNS服务器，您可以做很多事情 可以超出该规范。

豆荚验证模式

在kube-dns中，pod名称记录是“伪造的”。也就是说，任何“ a-b-c-d.namespace.pod.cluster.local”查询都将 返回IP地址“ a.b.c.d”。在某些情况下，这可能会削弱TLS提供的身份保证。所以， CoreDNS提供了一种“经过Pod验证”的模式，该模式仅在IP地址中包含Pod时才返回IP地址。 具有该IP地址的指定名称空间。

基于Pod名称的端点名称

在kube-dns中，使用无头服务时，您可以使用SRV请求来获取列表 服务的所有端点：

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 10 33 0 6234396237313665.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 10 33 0 6662363165353239.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 10 33 0 6338633437303230.headless.default.svc.cluster.local.
dnstools#

但是，端点DNS名称（出于实际目的）是随机的。在CoreDNS中，默认情况下，您获得端点 基于端点IP地址的DNS名称：

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-14.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-18.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-4.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 172-17-0-9.headless.default.svc.cluster.local.

对于某些应用程序，希望为此具有容器名称，而不是容器IP 地址（例如， kubernetes＃47992 和 coredns＃1190）。要在CoreDNS中启用此功能，请在Corefile中指定“ endpoint_pod_names”选项，结果是：

dnstools# host -t srv headless
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-qv84p.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-zc8lx.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-q7lf2.headless.default.svc.cluster.local.
headless.default.svc.cluster.local has SRV record 0 25 443 headless-65bb4c479f-566rt.headless.default.svc.cluster.local.

自动路径

核心DNS还具有一项特殊功能，可以改善外部名称的DNS请求中的延迟。在Kubernetes中， Pod的DNS搜索路径指定一长串后缀。这样可以在请求时使用短名称 群集中的服务-例如，上面的“ headless”，而不是“ headless.default.svc.cluster.local”。然而， 请求外部名称时-例如“ infoblox.com”-客户端进行了几次无效的DNS查询， requiring a roundtrip from the client to kube-dns each time (actually to dnsmasq 和 then to kubedns, since 否定缓存已禁用）：

  • infoblox.com.default.svc.cluster.local -> NXDOMAIN
  • infoblox.com.svc.cluster.local -> NXDOMAIN
  • infoblox.com.cluster.local -> NXDOMAIN
  • infoblox.com.your-internal-domain.com -> NXDOMAIN
  • infoblox.com -> returns a valid record

在CoreDNS中，一项可选功能称为 自动路径 可以启用，这将导致遵循此搜索路径 在服务器上。也就是说，CoreDNS将从源IP地址中找出客户端Pod所在的命名空间， 它将遍历此搜索列表，直到获得有效答案。由于其中的前三个是在内部解决的 在CoreDNS本身中，它可以消除客户端和服务器之间的所有来回通信，从而减少延迟。

其他一些Kubernetes特定功能

在CoreDNS中，您可以使用标准DNS区域传输来导出整个DNS记录集。这对于 调试服务以及将群集区域导入其他DNS服务器。

您还可以按名称空间或标签选择器进行过滤。这可以让您运行特定的CoreDNS实例，该实例仅将服务器记录与过滤器匹配，从而仅通过DNS公开有限的服务集。

可扩展性

除了上述功能之外，CoreDNS还可轻松扩展。可以构建自定义版本 包含您自己的功能的CoreDNS。例如，此功能已用于扩展CoreDNS以进行递归解析 with the 未绑定的插件，直接使用 pdsql插件，并允许多个CoreDNS实例与共享一个通用的2级缓存 redisc插件.

添加了许多其他有趣的扩展，您可以在 外部插件 核心DNS网站的页面。 Kubernetes和Istio用户真正感兴趣的是 kubernetai插件，它允许单个CoreDNS实例连接到多个Kubernetes集群，并在所有集群中提供服务发现。

下一步是什么？

核心DNS是一个独立的项目，因此正在开发许多非直接的功能 与Kubernetes有关。但是，其中许多将在Kubernetes中具有应用程序。例如， 即将与策略引擎的集成将使CoreDNS能够明智地选择哪个端点 请求无头服务时返回。这可用于将流量路由到本地吊舱，或者 到响应更快的吊舱。许多其他功能正在开发中，当然作为一个开源项目，我们欢迎您提出建议并贡献自己的功能！

上述特征和差异是几个示例。 核心DNS还可以做更多的事情。 您可以在 核心DNS博客.

参与CoreDNS

核心DNS是一个孵化器 CNCF 项目。

我们在Slack（和GitHub）上最活跃：

可以找到更多资源：