<p>I am trying to get dns pod name resolution working on my EKS Kubernetes cluster v1.10.3. My understanding is that creating a headless service will create the necessary pod name records I need but I'm finding this is not true. Am I missing something?</p>

<p>Also open to other ideas on how to get this working. Could not find alternate solution.</p>

<h3>Adding update</h3>

<p>I wasn't really clear enough. Essentially what I need is to resolved as such: 
worker-767cd94c5c-c5bq7 -> 10.0.10.10 
worker-98dcd94c5d-cabq6 -> 10.0.10.11 
and so on.... </p>

<p>I don't really need a round robin DNS just read somewhere that this could be a work around. Thanks!</p>

<pre><code># my service
apiVersion: v1
kind: Service
metadata:
  ...
  name: worker
  namespace: airflow-dev
  resourceVersion: "374341"
  selfLink: /api/v1/namespaces/airflow-dev/services/worker
  uid: 814251ac-acbe-11e8-995f-024f412c6390
spec:
  clusterIP: None
  ports:
  - name: worker
    port: 8793
    protocol: TCP
    targetPort: 8793
  selector:
    app: airflow
    tier: worker
  sessionAffinity: None
  type: ClusterIP
status:
  loadBalancer: {}





# my pod
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: 2018-08-31T01:39:37Z
  generateName: worker-69887d5d59-
  labels:
    app: airflow
    pod-template-hash: "2544381815"
    tier: worker
  name: worker-69887d5d59-6b6fc
  namespace: airflow-dev
  ownerReferences:
  - apiVersion: extensions/v1beta1
    blockOwnerDeletion: true
    controller: true
    kind: ReplicaSet
    name: worker-69887d5d59
    uid: 16019507-ac6b-11e8-995f-024f412c6390
  resourceVersion: "372954"
  selfLink: /api/v1/namespaces/airflow-dev/pods/worker-69887d5d59-6b6fc
  uid: b8d82a6b-acbe-11e8-995f-024f412c6390
spec:
  containers:
  ...
  ...
    name: worker
    resources: {}
    terminationMessagePath: /dev/termination-log
    terminationMessagePolicy: File
    volumeMounts:
      ...
      ...
  dnsPolicy: ClusterFirst
  nodeName: ip-10-0-1-226.us-west-2.compute.internal
  restartPolicy: Always
  schedulerName: default-scheduler
  securityContext: {}
  serviceAccount: airflow
  serviceAccountName: airflow
  terminationGracePeriodSeconds: 30
  tolerations:
  - effect: NoExecute
    key: node.kubernetes.io/not-ready
    operator: Exists
    tolerationSeconds: 300
  - effect: NoExecute
    key: node.kubernetes.io/unreachable
    operator: Exists
    tolerationSeconds: 300
  volumes:
    ...
    ...
status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:37Z
    status: "True"
    type: Initialized
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:40Z
    status: "True"
    type: Ready
  - lastProbeTime: null
    lastTransitionTime: 2018-08-31T01:39:37Z
    status: "True"
    type: PodScheduled
  containerStatuses:
  ...
  ...
    lastState: {}
    name: worker
    ready: true
    restartCount: 0
    state:
      running:
        startedAt: 2018-08-31T01:39:39Z
  hostIP: 10.0.1.226
  phase: Running
  podIP: 10.0.1.234
  qosClass: BestEffort
  startTime: 2018-08-31T01:39:37Z





# querying the service dns record works!
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker.airflow-dev.svc.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

Name: worker.airflow-dev.svc.cluster.local
Address: 10.0.1.234





# querying the pod name does not work :(
airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

** server can't find worker-69887d5d59-6b6fc.airflow-dev.svc.cluster.local: NXDOMAIN

airflow@worker-69887d5d59-6b6fc:~$ nslookup worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local
Server:   172.20.0.10
Address:  172.20.0.10#53

*** Can't find worker-69887d5d59-6b6fc.airflow-dev.pod.cluster.local: No answer
</code></pre>

sebastian
<p>Internally, I suggest using the service DNS records to point to the pod, which you already confirmed works. This of course does not require you to have a Headless service to use service DNS.</p>

<p>The kube-dns automatic records work in the following way:</p>

<p>pod -> service in the same namespace: curl <a href="http://servicename" rel="nofollow noreferrer">http://servicename</a></p>

<p>pod -> service in a different namespace: curl <a href="http://servicename.namespace" rel="nofollow noreferrer">http://servicename.namespace</a></p>

<p>Read more about service discovery here: <a href="https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/service/#environment-variables</a></p>

<p>You can read more about DNS records for services here <a href="https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services" rel="nofollow noreferrer">https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#services</a></p>

<p>If you need custom name resolution externally I recommend using nginx-ingress:</p>

<p><a href="https://github.com/helm/charts/tree/master/stable/nginx-ingress" rel="nofollow noreferrer">https://github.com/helm/charts/tree/master/stable/nginx-ingress</a> <a href="https://github.com/kubernetes/ingress-nginx" rel="nofollow noreferrer">https://github.com/kubernetes/ingress-nginx</a></p>

<p>EDIT: Include details about actual pod DNS</p>

<p>v1.2 introduces a beta feature where the user can specify a Pod annotation, pod.beta.kubernetes.io/subdomain, to specify the Pod's subdomain. The final domain will be "...svc.". For example, a Pod with the hostname annotation set to "foo", and the subdomain annotation set to "bar", in namespace "my-namespace", will have the FQDN "foo.bar.my-namespace.svc.cluster.local"</p>

<blockquote>
  <p>A Records and hostname based on Pod's hostname and subdomain fields
  Currently when a pod is created, its hostname is the Pod's
  metadata.name value.</p>
  
  <p>With v1.2, users can specify a Pod annotation,
  pod.beta.kubernetes.io/hostname, to specify what the Pod's hostname
  should be. The Pod annotation, if specified, takes precedence over the
  Pod's name, to be the hostname of the pod. For example, given a Pod
  with annotation pod.beta.kubernetes.io/hostname: my-pod-name, the Pod
  will have its hostname set to "my-pod-name".</p>
  
  <p>With v1.3, the PodSpec has a hostname field, which can be used to
  specify the Pod's hostname. This field value takes precedence over the
  pod.beta.kubernetes.io/hostname annotation value.</p>
  
  <p>v1.2 introduces a beta feature where the user can specify a Pod
  annotation, pod.beta.kubernetes.io/subdomain, to specify the Pod's
  subdomain. The final domain will be "...svc.". For example, a Pod with
  the hostname annotation set to "foo", and the subdomain annotation set
  to "bar", in namespace "my-namespace", will have the FQDN
  "foo.bar.my-namespace.svc.cluster.local"</p>
  
  <p>With v1.3, the PodSpec has a subdomain field, which can be used to
  specify the Pod's subdomain. This field value takes precedence over
  the pod.beta.kubernetes.io/subdomain annotation value.</p>
</blockquote>

<p><a href="https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/services-networking/dns-pod-service/" rel="nofollow noreferrer">https://unofficial-kubernetes.readthedocs.io/en/latest/concepts/services-networking/dns-pod-service/</a></p>
