Using CoreDNS for Service Discovery
This page describes how to enable CoreDNS instead of kube-dns for service discovery.
- Before you begin
- Installing CoreDNS with kubeadm
- Using a custom CoreDNS image repository with kubeadm
- Upgrading an Existing Cluster with kubeadm
- What's next
Before you begin
You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube, or you can use one of these Kubernetes playgrounds:
Your Kubernetes server must be version v1.9 or later.
To check the version, enter kubectl version.
Installing CoreDNS with kubeadm
In Kubernetes 1.9, CoreDNS is available as an alpha feature, and
in Kubernetes 1.10 it is available as a beta feature. In either case, you may install
it during cluster creation by setting the CoreDNS feature gate to true during kubeadm init:
kubeadm init --feature-gates=CoreDNS=true
This installs CoreDNS instead of kube-dns.
Using a custom CoreDNS image repository with kubeadm
To use a custom image repository for the CoreDNS image, e.g. one located in your own Docker registry, you can execute the following command after kubeadm has deployed the CoreDNS manifest:
kubectl set image -n kube-system deploy/coredns coredns=prefix.example.com/coredns/coredns:1.0.6Upgrading an Existing Cluster with kubeadm
In Kubernetes 1.10, you can also move to CoreDNS when you use kubeadm to upgrade
a cluster that is using kube-dns. In this case, kubeadm will generate the CoreDNS configuration
(“Corefile”) based upon the kube-dns ConfigMap, preserving configurations for federation,
stub domains, and upstream name server.
Note that if you are running CoreDNS in your cluster already, prior to upgrade, your existing Corefile will be overwritten by the one created during upgrade. You should save your existing ConfigMap if you have customized it. You may re-apply your customizations after the new ConfigMap is up and running.
This process will be modified for the GA release of this feature, such that an existing Corefile will not be overwritten.
FEATURE STATE:
Kubernetes v1.10
beta
This feature is currently in a beta state, meaning:
- The version names contain beta (e.g. v2beta3).
- Code is well tested. Enabling the feature is considered safe. Enabled by default.
- Support for the overall feature will not be dropped, though details may change.
- The schema and/or semantics of objects may change in incompatible ways in a subsequent beta or stable release. When this happens, we will provide instructions for migrating to the next version. This may require deleting, editing, and re-creating API objects. The editing process may require some thought. This may require downtime for applications that rely on the feature.
- Recommended for only non-business-critical uses because of potential for incompatible changes in subsequent releases. If you have multiple clusters that can be upgraded independently, you may be able to relax this restriction.
- Please do try our beta features and give feedback on them! After they exit beta, it may not be practical for us to make more changes.
What's next
You can configure CoreDNS to support many more use cases than
kube-dns by modifying the Corefile. For more information, see the
CoreDNS site.