It is unclear what you expect. In your example, you say that "kubernetes can resolve these two service...", but in the graphic that follows it, both results are "Not Found" ...

It's odd that an IP is allowed in the "externalName" field. The k8s documentation I found seems to infer that a IP in the field would not make sense:

ExternalName: Maps the service to the contents of the externalName field (e.g. foo.bar.example.com), by returning a CNAME record with its value. No proxying of any kind is set up. This requires version 1.7 or higher of kube-dns.

... AFIAK, a CNAME value cant be an IP.

If you want a service that resolves to a statically defined ip address, you could ...

• create a headless service
• then create a statically defined endpoint for that service that contains the ip address.

e.g.

apiVersion: v1
kind: Service
metadata:
  name: gdns
  namespace: default
spec:
  clusterIP: None
  ports:
  - name: dns
    port: 53
    protocol: UDP
---
kind: Endpoints
apiVersion: v1
metadata:
  name: gdns
  namespace: default
subsets:
  - addresses:
      - ip: 8.8.8.8
    ports:
      - port: 53
        name: dns
        protocol: UDP

Thanks for your response!

1. I'm sorry that this case is kinda confusing, what I want to show that Service returns 404 differs from Can't resolve the service, that is, domain-service should perform the same as ip-service .
2. Anyway, now I get the point , thanks again for the explanation~~ The config works well, It helps!
3. BTW, In my past experience, the ip-valued-CNAME always work in kubeadm v1.6 , It looks like some version issues : )

@chrisohaver
You give a really good example to show how to use Headless Service.
I want ask you a question, what is externalName for? I read the doc, then, toasted, confused.

ExternalName creates a locally named alias to a service name outside of the cluster.
Eg

example.default.svc.cluster.local => some.service.example.com

ExternalName creates a locally named alias to a service name outside of the cluster. Eg

example.default.svc.cluster.local => some.service.example.com

Yes. All people say in this accent...While, many people failed using this way to fetch other domain's service. For example, I must use github.com account auth service to login my web.
But the doc said, the Headless just like you write above, is the good practice.
What makes me confusing is this.

Perhaps folks in the kubernetes-novice slack channel can explain better than me.

https://slack.k8s.io/