用于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 dnsmasqkubedns (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#47992coredns#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)上最活跃:

可以找到更多资源: