CoreDNS is replacing KubeDNS as the default cluster DNS provider
Kubernetes recently announced that CoreDNS has become the default cluster DNS provider starting in version 1.13. To align with this announcement, CoreDNS is also the default cluster DNS provider for new IBM Cloud Kubernetes Service version 1.13 clusters. As detailed in the Kubernetes announcement, there are several reasons for this change.
CoreDNS is a general-purpose, authoritative DNS server that provides a backwards-compatible, but extensible, integration with Kubernetes. CoreDNS has fewer moving parts than the previous DNS server, since it’s a single executable and a single process, and supports flexible use cases by creating custom DNS entries. It’s also written in Go making it memory-safe.
Since the Kubernetes announcement, CoreDNS has become a graduated Cloud Native Computing Foundation (CNCF) project!
Prepare DNS transition in versions 1.12 and 1.13
IBM Cloud Kubernetes Service clusters running version 1.12 and earlier continue to use KubeDNS as the default cluster DNS provider. Also, when you update a cluster from an earlier version to 1.13, the cluster DNS provider is not automatically changed to CoreDNS. New clusters in version 1.13 and later have CoreDNS by default. Furthermore, in versions 1.12 and 1.13, your cluster administrator can toggle the cluster DNS provider to either CoreDNS or KubeDNS. This gives clusters administrators the opportunity to test CoreDNS.
Most cluster administrators and apps won’t notice any difference when transitioning to CoreDNS since it is a backward-compatible integration with Kubernetes. However, there are a couple exceptions:
Customizing CoreDNS is different than customizing KubeDNS.
CoreDNS does not allow IP addresses for external names per Kubernetes cluster DNS specification.
For Exception 1, you must transfer your KubeDNS customizations in the kube-dns or kube-dns-autoscalerconfigmaps in the kube-system namespace to the coredns and coredns-autoscaler configmaps. The customization syntax for the kube-dns-autoscaler and coredns-autoscaler configmaps is the same so a simple copy will suffice. However, the customization syntax for the kube-dns and coredns configmaps is different. For an example, see the Kubernetes documentation.
Unfortunately, for Exception 2, apps that rely on IP addresses for an external name must change to adhere to the Kubernetes cluster DNS specification.
DNS transition completed in version 1.14
IBM Cloud Kubernetes Service will complete the transition to CoreDNS in version 1.14. As a result, upgrading your cluster to version 1.14 or later will automatically migrate KubeDNS to CoreDNS. The migration will include any KubeDNS customizations. To mitigate risk for the switch to CoreDNS, test your apps today by toggling the cluster DNS provider to CoreDNS. Don’t wait until you are forced to make the change.
Cluster DNS customization options
You may be surprised to learn that you can customize your Kubernetes cluster DNS provider. Both KubeDNS and CoreDNS support this. For example, if your apps make heavy usage of cluster DNS, you can customize the cluster DNS autoscaler to ensure there are a minimum number of DNS pods to support your apps. In addition, if your apps require customized DNS resolution, you can customize the cluster DNS provider.