我正在分享我在 Kubernetes (1.12) 中使用 CoreDNS (1.2.5) 运行的某些测试结果，以便为调整集群中的 CoreDNS 提供一些参考点。除了测试默认配置下的 CoreDNS 之外，我还测试了已启用可选的自动路径插件的 CoreDNS。自动路径插件是一种优化方法，通过 Kubernetes 中臭名昭著的 ndots:5 问题帮助透明地减轻 Pod 造成的 DNS 性能损失。这些测试量化了启用自动路径时的内存/性能交易。
此文章中的指南和公式基于在 GCE 中的集群进行的一组测试，实际情况可能有所不同。此博客文章是完整结果的一部分，你可以在此处查看更多详细信息。
内存和 Pod
在大规模 Kubernetes 集群中，CoreDNS 的内存使用情况主要受集群中 Pod 和服务数的影响。
对于具有默认 CoreDNS 设置
若要估计 CoreDNS 实例所需的内存量（使用默认设置），则可以使用以下公式
所需 MB 数（默认设置）=(Pod 数 + 服务数)/1000 + 54
使用自动路径插件
自动路径插件是一种可选优化，可提高对集群外部名称（例如 infoblox.com）的查询性能。启用自动路径插件需要 CoreDNS 使用更多内存来存储有关 Pod 的信息。
启用自动路径插件还会给 Kubernetes API 带来越多的负载，因为它必须监视对 Pod 的所有更改。
若要估计使用自动路径插件的 CoreDNS 实例所需的内存量，则可以使用以下公式
所需 MB 数（带自动路径）=(Pod 数 + 服务数)/250 + 56
CPU 和 QPS
使用 kubernetes/perf-tests/dns 工具在一个使用 CoreDNS 的集群上测试最大 QPS。所使用的查询类型包括内部查询（例如 kubernetes）和外部查询（例如 infoblox.com）。
对于具有默认 CoreDNS 设置
在 GCE n1-standard-2 节点上使用单个 CoreDNS 实例（默认设置）
| 查询类型 | QPS | 平均延迟（毫秒） |
|---|---|---|
| 外部 | 67331 | 12.021 |
| 内部 | 33669 | 2.608 |
1从服务器角度看，它以 2.404 毫秒的延迟处理 33667 QPS，但从客户端角度看，每个单名称查询实际上包含 5 个串行查询。
使用自动路径插件
CoreDNS 中的**AutoPath**插件是缓解 ClusterFirst 搜索列表惩罚的一种选择。启用时，它减少了客户端在查找外部名称时发起的 DNS 查询数量。
采用 GCE n1-standard-2 节点的 CoreDNS（启用了 AutoPath 插件）的单个实例
| 查询类型 | QPS | 平均延迟（毫秒） |
|---|---|---|
| 外部 | 31428 | 2.605 |
| 内部 | 33918 | 2.62 |
请注意，外部查询的数字在这里有了很大的改善，这是由于 AutoPath 插件优化。
启用 AutoPath 时，外部查询的服务器角度延迟会略有增加（+8%）。
这是因为它在服务器端执行额外工作来检查每个搜索域。
但由于它可以在一轮往返中做出答复，而不是五轮，因此整体的客户端角度性能有了很大的改善。
更多信息...
有关测试环境以及如何收集数据方面的更多信息，请在此查看完整结果。