DNS solves the issues seen with environment variables by allowing us to reference the services by their name. As services restart, scale out, or appear anew, the DNS entries will be updating and ensuring that the service name always points to the latest infrastructure. DNS is set up by default in most of the supported providers. You can add DNS support for your cluster via a cluster add on (https://kubernetes.io/docs/concepts/cluster-administration/addons/).

With DNS active, services can be accessed in one of two forms—either the service name itself, <service-name>, or a fully qualified name that includes the namespace, <service-name>.<namespace-name>.cluster.local. In our examples, it would look similar to node-js-90 or node-js-90.default.cluster.local. 

The DNS server create DNS records based on new services that are created through the API. Pods in shared DNS namespaces will be able to see each other, and can use DNS SRV records to record ports as well.

Kubernetes DNS is comprised of a DNS pod and Service on the cluster which communicates directly with kubelets and containers in order to translate DNS names to IP. Services with clusterIPs are given my-service.my-namespace.svc.cluster.local addresses. If the service does not have a clusterIP (otherwise called headless)  it gets the same address format, but this resolves in a round-robin fashion to a number of IPs that point to the pods of a service. There a number of DNS policies that can also be set.

One of the Kubernetes incubator projects, CoreDNS can also be used for service discovery. This replaces the native kube-dns DNS services and requires Kubernetes v1.9 or later. You'll need to leverage kubeadm during the initialization process in order to try CoreDNS out. You can install this on your cluster with the following command:

$ kubeadm init --feature-gates=CoreDNS=true

If you'd like more information on an example use case of CoreDNS, check out this blog post: https://coredns.io/2017/05/08/custom-dns-entries-for-kubernetes/.