ExternalName pointing to service in other namespace doesn't resolve unless given full FQDN

Question

I've a Service my-service of type ClusterIP in namespace A which can load balance to a few pods. I want to create another Service of type ExternalName in namespace B that points to my-service in namespace A.

I create the following YAML:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: B
spec:
  type: ExternalName
  externalName: my-service.A

and if I exec into a pod running in namespace B and do:

# ping my-service
ping: my-service: Name or service not known

But if I change the externalName in the above YAML to below:

apiVersion: v1
kind: Service
metadata:
  name: my-service
  namespace: B
spec:
  type: ExternalName
  externalName: my-service.A.svc.cluster.local   <--- full FQDN here

things work as expected. Also, if I ping my-service directly from a pod in namespace B it is being resolved:

# ping my-service.A
PING my-service.A.svc.cluster.local (10.0.80.133) 56(84) bytes of data.

Why my-service.A is not resolved to my-service.A.svc.cluster.local in ExternalName Service?

My K8s version is 1.14.8 and uses CoreDNS.

Jakub Jakub · Accepted Answer · 2020-03-06T09:57:07

Based on kubernetes documentation and okd that's how it's supposed to work

Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service’s IP to resolve DNS names.

What things get DNS names?

Every Service defined in the cluster (including the DNS server itself) is assigned a DNS name. By default, a client Pod’s DNS search list will include the Pod’s own namespace and the cluster’s default domain.

Services are assigned a DNS A or AAAA record, depending on the IP family of the service, for a name of the form my-svc.my-namespace.svc.cluster-domain.example. This resolves to the cluster IP of the Service.

There are logs from kubedns when you want to use my-service.A

I0306 09:44:32.424126       1 logs.go:41] skydns: incomplete CNAME chain from "my-service.dis.": rcode 3 is not equal to success

That's why you need whole path for the service, which in your situation is

my-service.A.svc.cluster.local

Because

Using an external domain name service tells the system that the DNS name in the externalName field (example.domain.name in the previous example) is the location of the resource that backs the service. When a DNS request is made against the Kubernetes DNS server, it returns the externalName in a CNAME record telling the client to look up the returned name to get the IP address.

I hope this answer your question. Let me know if you have any more questions.

ExternalName pointing to service in other namespace doesn't resolve unless given full FQDN

1 Answers