0

I am trying to test inter-pod communication without expose as service. I have read that a pod does have FQDN in kubedns. kubernetes doc

Its default should be (A Record)
metadata_name.namespace.svc.cluster.local
or
hostname.subdomain.namespace.svc.cluster.local

But I tried both with curl and nslookup. All failed. The service is healthy, I could curl it with pod IP (172.17.0.5)

curl: (6) could not resolve host
nslookup: can't resolve '(null)': Name does not resolved

What am I missing?

Maxi Wu
  • 1,274
  • 3
  • 20
  • 38

2 Answers2

2

If there exists a headless service in the same namespace as the pod and with the same name as the subdomain, the cluster’s KubeDNS Server also returns an A record for the Pod’s fully qualified hostname. For example, given a Pod with the hostname set to “busybox-1” and the subdomain set to “default-subdomain”, and a headless Service named “default-subdomain” in the same namespace, the pod will see its own FQDN as “busybox-1.default-subdomain.my-namespace.svc.cluster.local”.

So in your case you need to define subdomain for pod and create headless service with the same name which points to pods.

Vasili Angapov
  • 8,061
  • 15
  • 31
1

I suggest adding a service with type ClusterIP for this: https://kubernetes.io/docs/concepts/services-networking/service/#publishing-services-service-types

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: MyApp
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

It does not expose your pod outside the cluster. Note that this is default service type and you can omit specifying it.

Then query the serivce like: 

curl http://my-service.namespace.svc.cluster.local

This approach is better than using pod DNS directly for 2 reasons:

  • you don't need to know the exact pod name (e.g. name-id)

  • in this case you can run multiple pods behind the service and it will load-balance requests. Or just run one and it does exactly what you want.

Max Lobur
  • 5,662
  • 22
  • 35