Reputation: 2855
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.
Upvotes: 5
Views: 2624
Reputation: 8830
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.
Upvotes: 5