在Kubernetes集群中扩展CoreDNS

用于调整Kubernetes集群中的CoreDNS资源/需求的指南

Chris O'Haver

我正在分享在Kubernetes（1.12）中使用CoreDNS（1.2.5）运行的一些测试结果，以便为将CoreDNS调整到您的集群提供一些参考点。除了在默认配置中测试CoreDNS之外，我还测试了CoreDNS并启用了可选的autopath插件。autopath插件是一种优化，有助于透明地缓解由于Kubernetes臭名昭着的ndots:5问题而导致的Pod性能损失。这些测试在启用autopath时量化了内存/性能交易。

本文中的指南和公式基于GCE中的一组集群测试，您的环境可能会有所不同。这篇博文是完整结果的摘录，你可以点击文末<<阅读原文>>进入网页了解更多细节。

内存和Pod

在大规模Kubernetes集群中，CoreDNS的内存使用率主要受集群中Pod和服务数量的影响。

使用默认的CoreDNS设置

要估计CoreDNS实例所需的内存量（使用默认设置），可以使用以下公式：

MB required (default settings) = (Number of Pods + Services) / 1000 + 54

使用autopath插件

autopath插件是一个可选的优化，可以提高群集外部名称查询的性能（例如infoblox.com）。启用autopath插件需要CoreDNS使用更多的内存来存储有关Pod的信息。启用autopath插件还会对Kubernetes API产生额外的负担，因为它必须监视对Pod的所有更改。

要估计CoreDNS实例所需的内存量（使用autopath插件），可以使用以下公式：

MB required (w/ autopath) = (Number of Pods + Services) / 250 + 56

CPU和QPS

在使用CoreDNS的集群上使用kubernetes/perf-tests/dns工具测试了最大QPS。使用的两种类型的查询是内部查询（例如kubernetes）和外部查询（例如infoblox.com）。

使用默认的CoreDNS设置

GCE n1-standard-2节点上的单个CoreDNS实例（默认设置）：

1 从服务器的角度来看，它处理33667 QPS，延迟为2.404毫秒，但从客户端的角度来看，每个单一名称查找实际上包含5个串行查找。

使用autopath插件

CoreDNS中的autopath插件是一个减轻ClusterFirst搜索列表惩罚的选项。启用后，它会减少客户端在查找外部名称时进行的DNS查询次数。

在GCE n1-standard-2节点上单个CoreDNS实例（启用了autopath插件）：

请注意，此处的外部查询数量大大改善。这是由于autopath插件优化。

启用autopath时，外部查询的服务器透视延迟略有上升（+8％）。这是因为它正在检查服务器端的每个搜索域的额外工作。但由于它可以在一次往返而不是五次回答，因此整体客户视角表现得到了很大改善。