Using CoreDNS on GKE

Overcoming kube-dns restrictions on GKE via stub domains

While CoreDNS reached GA for Kubernetes since v1.11 back in 2018, Google Kubernetes Engine (GKE) users are stuck with kube-dns even in rapid channels for v1.17. You can easily install CoreDNS using the migration tool on existing Kubernetes clusters, but GKE won’t let you delete kube-dns so queries end up randomly hitting one or the other.

In most cases, using kube-dns is not an issue, and according to the CoreDNS benchmark tests, kube-dns actually performed about 10% better for internal names. The need for using CoreDNS arises when configuring dnsConfigs or hostAliases on pods doesn’t suit your needs. For example, you may want to create an alias for an internal service to a FQDN to help with migration, mapping calls to an internally hosted service, or to resolve hostname certificate issues for redirected calls. All of these issues are simply solved when using CoreDNS and most of the StackOverflow answers related to managing custom DNS entries point to CoreDNS plugins.

So how do we make use of CoreDNS on GKE?

CoreDNS on GKE

To illustrate, let’s look at a scenario where we have a new scheduling service called scheduler . Inside the cluster, you can access the endpoint by calling its ClusterIP: scheduler.default.svc.cluster.local . Externally…