Skip to content

Only one A record set for headless service with pods having single hostname. #116

@stroop23

Description

@stroop23

/kind bug

What happened
When a headless service is created to point to pods which share a single hostname, (which happens, for example, when the hostname field was set in the template of a deployment/replicaset)

  • Only one A record is returned for the service DNS name
  • A pod DNS name is generated based on this host name, which points to a single pod

What was expected to happen

  • Return A records for all available endpoints on the service DNS name
  • Not sure what the correct behaviour should be for the pod dns name, either also return multiple A records, or don't create at all.

Seems this has to do with the following code:
https://github.com/kubernetes/dns/blob/master/pkg/dns/dns.go#L490

Then the endpointName will be equal for any pod in the service which has the same hostname, so the entry in subCache will be overwritten.

How to reproduce

Apply the following spec:

apiVersion: v1 kind: List items: - apiVersion: extensions/v1beta1 kind: Deployment metadata: name: depl-1 spec: replicas: 2 template: metadata: labels: app: depl-1 spec: hostname: depl-1-host subdomain: depl-1-service containers: - name: test args: - bash stdin: true tty: true image: debian:jessie - apiVersion: v1 kind: Service metadata: name: depl-1-service spec: clusterIP: None selector: app: depl-1 ports: - port: 5000 

Resolving the hostnames gives back but a single A record.

# host depl-1-host.depl-1-service.default.svc.cluster.local depl-1-host.depl-1-service.default.svc.cluster.local has address 10.56.0.140 # host depl-1-service.default.svc.cluster.local depl-1-service.default.svc.cluster.local has address 10.56.0.140 

PTR records ARE being created for all the pods, all resolving back to the single hostname. This is expected behaviour.

Metadata

Metadata

Assignees

Labels

help wantedDenotes an issue that needs help from a contributor. Must meet "help wanted" guidelines.lifecycle/frozenIndicates that an issue or PR should not be auto-closed due to staleness.

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions