Is this a BUG REPORT or FEATURE REQUEST?:
/kind feature

What happened:

Following this guide - https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pods-hostname-and-subdomain-fields

Specifically.

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”. DNS serves an A record at that name, pointing to the Pod’s IP. Both pods “busybox1” and “busybox2” can have their distinct A records.

I expect to be able to use this feature in a Deployment, as deploying individual pods is not a scalable pattern.

Specifying a subdomain in the deployment works correctly.

Specifying a hostname causes all the pods in the deployment to have the same hostname - making the feature useless.

Not specifying a hostname causes DNS registration not to occur.

What you expected to happen:

I expect to either:

• Specify a hostname prefix in the deployment, and have the deployment put in a unique suffix, and register it with Kube-DNS

or

• Not specify a hostname, and K8s should use the standard hostname, and register that with KubeDNS.

How to reproduce it (as minimally and precisely as possible):

apiVersion: v1
kind: Service
metadata:
  name: busybox
spec:
  selector:
    type: busybox
  clusterIP: None
  ports:
  - name: foo # Actually, no port is needed.
    port: 1234
    targetPort: 1234
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: busybox
spec:
  replicas: 2
  template:
    metadata:
      labels:
        name: busybox
        type: busybox
      name: busybox
    spec:
      subdomain: busybox
#     hostname: foo      # optional
      containers:
      - name: worker
        image: busybox
        command:
        - sleep
        - "3600"

• Exec into first created pod - try to ping/dig/host other Pod by FQDN.

Anything else we need to know?:

I know all about StatefulSets, and how DNS registration works with those. The workload I'm deploying is individual scale-out processing with autoscaling and a natural fit for Deployments - but it does require functional per-pod DNS records.

Environment:

• Kubernetes version (use kubectl version): v1.7.12-gke.1
• Cloud provider or hardware configuration: GKE
• OS (e.g. from /etc/os-release): busybox
• Kernel (e.g. uname -a): 4.4.86+