CoreDNS offers a unique approach to providing DNS service for a Kubernetes cluster. By having requests handled along a chain which allows plugins to provide the functionality, CoreDNS can provide all the flexibility Kubernetes requires to support the service discovery needs of any organization leveraging it.
Introduction
With CoreDNS now an official project for the Cloud Native Computing Foundation (CNCF), it is being positioned as the primary tool to provide basic service discovery both within a Kubernetes cluster and for clients trying to access services the cluster is hosting.
As we know, DNS is a fundamental building block of working with applications that need to interact with other services over the Internet, and even large private networks. Within the Kubernetes environment, DNS is used as the primary service discovery functionality. The running services and location of their pods are accessed by reading from etcd. Services support the LoadBalancer or NodePort as a service type to allow access outside of a single cluster. This is key to resolving across federated clusters or to any client outside the Kubernetes environment.
Architecture
CoreDNS has been built using a model that has requests follow a chain in which plugins, called middleware, connect to and provide the functionality that is used to process the request so that each Kubernetes cluster can have the DNS service functionality that best suits it.
Configuration
All configuration of CoreDNS is in a single file named Corefile. Corefile is organized by domain, where each domain has the plugins listed that are used to process requests for that domain.
The default configuration when no Corefile is found is:
. {
whoami
}
The whoami plugin simply responds to every A (IPv4) or AAAA (IPv6) request with the client’s IP. This isn’t really useful for anything other than proving it is running.
The configuration in the Corefile supports reverse DNS with two different formats: the traditional Bind syntax and a human-readable syntax that works with CIDR.
0.0.10.in-addr.arpa {
whoami
}
192.168.0.0/27 {
whoami
}
Having CoreDNS listen on specific ports for specific domains is easy enough.
example.org {
whoami
}
example.com:54 {
whoami
}
An example of a more robust Corefile configuration that might be seen in the real world:
example.net {
file net.example {
transfer to *
}
prometheus
errors
log
}
. {
proxy . 8.8.8.8:53
log
}
This example does a few things for the example.net zone:
- It is authoritative.
- It is loaded from a file named “net.example.”
- It allows AXFR transfers to anyone.
- It offers Prometheus plugin-enabled metrics.
- The errors plugin shows errors.
- The log creates an access log.
For the root zone, it’s acting as a forwarder, sending all other requests to Google’s public DNS and logging access requests.
More Information
For further information, you can review the Intro to CoreDNS slides from CNCF and visit the < a href=https://coredns.io/>CoreDNS site for documentation, downloads, and installation instructions.
Conclusion
CoreDNS has been positioned as the tool that will be used as part of the CNCF suite of products to provide DNS-based service discovery in a single service. CoreDNS will be a solid alternative to the existing SkyDNS and Kube-DNS going forward. While the project is still in the incubation phase, it has proven itself to be able to handle the requirements of providing these services in the Kubernetes ecosystem, and is well-positioned to grow and expand as more organizations go cloud-native.
