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?
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.
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.