ExternalName Service

ExternalName is a special type of service that does not have selectors and uses DNS names instead.

When looking up the host ext-service.default.svc.cluster.local, the cluster DNS service returns a CNAME record of database.mycompany.com:

If developers are migrating an application into Kubernetes but its dependencies are staying external to the cluster, ExternalName service allows them to define a DNS record internal to the cluster no matter where the service actually runs.

DNS will try the search as shown in the following example:

As an example, the ExternalName service allows developers to map a service to a DNS name.

Now if we deploy the external service like so:

The A record for github.com is returned from the external-service query:

The CNAME for the external service returns github.com:

Sending traffic to a headless service via a DNS record is possible but inadvisable. DNS is a notoriously poor way to load balance, as software takes very different (and often simple or unintuitive) approaches to A or AAAA DNS records that return multiple IP addresses. For example, it is common for software to always choose the first IP address in the response and/or cache and reuse the same IP address indefinitely. If you need to be able to send traffic to the service’s DNS address, consider a (standard) ClusterIP or LoadBalancer service.

The “correct” way to use a headless service is to query the service’s A/AAAA DNS record and use that data in a server-side or client-side load balancer.

Most of the services we have been discussing are for internal traffic management for the cluster network. In our next sections, will be reviewing how to route requests into the cluster with service type LoadBalancer and ingress.