How do I get individual pod hostnames in a Deployment registered and looked up in Kubernetes?

CoreDNS creates A and SRV records only for Services. It doesn't generate pods' A records as you may expect after reading the documentation:

The pods insecure option is provided for backward compatibility with kube-dns. You can use the pods verified option, which returns an A record only if there exists a pod in same namespace with matching IP. The pods disabled option can be used if you don’t use pod records.

with the one exception: if you create a Headless service (when you specify ClusterIP: None in the Service spec)

So, here is my example of Headless Service based on your YAML:

NAME                TYPE           CLUSTER-IP      EXTERNAL-IP   PORT(S)        AGEdefault-subdomain   ClusterIP      None            <none>        1234/TCP       50s

Here is the list of pods created by the above deployment on my cluster:

NAMESPACE       NAME                                        READY   STATUS    RESTARTS   AGE   IP            NODE           NOMINATED NODE   READINESS GATESdefault         busybox1-76745fcdbf-4ppsf                   1/1     Running   0          18s   10.244.1.22   kube-node2-1   <none>           <none>default         busybox1-76745fcdbf-d76q5                   1/1     Running   0          18s   10.244.1.23   kube-node2-1   <none>           <none>

In this case, instead of one A and one SRV record for Service's ClusterIP, we have two A and two SRV records with the same name, and IP addresses of Pods which are Endpoints for the Headless Service:

default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-22.default-subdomain.default.svc.cluster.local.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 10-244-1-23.default-subdomain.default.svc.cluster.local.

To resolve SRV records, A records also has been created for both Headless Service endpoints.

If you don't specify specify hostname and subdomain for pods, A records will be created with IP addresses as a hostnames:

10-244-1-22.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.2210-244-1-23.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23

But if you are specify both of them you will get these record as follows:

dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.22dummy.default-subdomain.default.svc.cluster.local. 5 IN A 10.244.1.23

SRV records will look as follows in this case (yes, there are still two of them and they are the same):

_foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local._foo._tcp.default-subdomain.default.svc.cluster.local. 5 IN SRV 0 50 1234 dummy.default-subdomain.default.svc.cluster.local.

CoreDNS server resolve such records in "random" way (IP addresses is changing):

root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.26) 56(84) bytes of data.root@ubuntu:/# ping dummy.default-subdomain.default.svc.cluster.local -c 1 | grep PINGPING dummy.default-subdomain.default.svc.cluster.local (10.244.1.27) 56(84) bytes of data.

To debug it, I've used zone transfer feature that CoreDNS supports. To enable it you should add transfer to * line to coredns ConfigMap. You can replace * with specific IP for security. Example:

$ kubectl get cm coredns -n kube-system -o yamlapiVersion: v1data: Corefile: |   .:53 {       errors       health       kubernetes cluster.local in-addr.arpa ip6.arpa {          transfer to *   <---- enable zone transfer to anyone(don't use in production)           pods insecure          upstream          fallthrough in-addr.arpa ip6.arpa       }       prometheus :9153       forward . /etc/resolv.conf       cache 30       loop       reload       loadbalance   }kind: ConfigMapmetadata: creationTimestamp: "2019-05-07T15:44:02Z" name: coredns namespace: kube-system resourceVersion: "9166" selfLink: /api/v1/namespaces/kube-system/configmaps/coredns uid: f0646569-70de-11e9-9af0-42010a9c0015 

After that you'll be able to list all DNS records from cluster.local zone using the following command:

dig -t AXFR cluster.local any

More information can be found here:

• support for zone transfer for kubernetes #1259
• Feature request: support zone transfers in Kubernetes middleware #660

if you want to do that consider using instead an Stateful Set where you can go to the pod like that:

podname-{replica-index}.{serviceName}.default.svc.cluster.local

here an example https://kubernetes.io/docs/tutorials/stateful-application/cassandra/