Cluster DNS: CoreDNS vs Kube-DNS

Comparing CoreDNS and Kube-DNS resource requirements

When compiling data for a resource deployment guide for CoreDNS a few weeks ago, I also collected the same data for kube-dns using the same test environments. Although CoreDNS and Kube-dns ultimately perform the same task, there are some key differences in implementation that affect resource consumption and performance. At a high level, some of these differences are:

  • CoreDNS is a single container per instance, vs kube-dns which uses three.
  • Kube-dns uses dnsmasq for caching, which is single threaded C. CoreDNS is multi-threaded Go.
  • CoreDNS enables negative caching in the default deployment. Kube-dns does not.

These differences affect performance in various ways. The larger number of containers per instance in kube-dns increases base memory requirements, and also adds some performance overhead (as requests/responses need to be passed back and forth between containers). For kube-dns, dnsmasq may be highly optimized in C, but it’s also single threaded so it can only use one core per instance. CoreDNS enables negative caching, which aids in handling external names searches.

Memory

Both CoreDNS and kube-dns maintain a local cache of all Services and Endpoints in the cluster. So as the number of Services and Endpoints scale up, so do the memory requirements for each DNS Pod. At default settings, CoreDNS should be expected to use less memory than kube-dns. This is in part due to the overhead of the three containers used by kube-dns, vs only one container in CoreDNS.

The chart below shows the estimated memory required to run a single instance of CoreDNS or Kube-dns based on the number of Services and Endpoints.

CoreDNS vs Kube-DNS estimated memory at scale

The sources of the above data are from Kubernetes e2e scale tests, in conjunction with small cluster QPS load tests. The Kubernetes e2e scale tests provide testing on very large clusters, but do not apply any QPS load. To account for additional memory needed while handling a QPS load, the chart adds in the memory deltas observed when applying maximal QPS load during the CPU tests (below). This was about 58Mi for kube-dns, and 5Mi for CoreDNS.

CPU

In terms of CPU performance, CoreDNS performs much better for external names (e.g. infoblox.com), and slightly worse for internal names (e.g. kubernetes).

DNS Server Query Type QPS Avg Latency (ms)
CoreDNS external 6733 12.02
CoreDNS internal 33669 2.608
Kube-dns external 2227 41.585
Kube-dns internal 36648 2.639

Take aways:

  • Kube-dns performed about 10% better for internal names. This is probably due to dnsmasq being more optimized than CoreDNS’s built-in caching.
  • CoreDNS performed about 3X better for external names. This is partly caused by negative responses not being cached in kube-dns deployments. However enabling negative cache in the kube-dns deployment did not significantly change the outcome, so the bulk of performance gain is elsewhere.
DNS Server Query Type QPS Avg Latency (ms)
Kube-dns + neg-cache external 2552 36.665
Kube-dns + neg-cache internal 28971 3.385

More

The version of kube-dns and default configuration used in these tests were those released with Kubernetes 1.12.

For more details about the test environments see: [Scaling CoreDNS in Kubernetes Clusters] (https://github.com/coredns/deployment/blob/master/kubernetes/Scaling_CoreDNS.md).

Chris O'Haver
Published: and tagged Deployment, Discovery, DNS, Documentation, Kubernetes and Service using 503 words.