Change:
} func addEndpointSubset(subsets []v1.EndpointSubset, pod *v1.Pod, epa v1.EndpointAddress, <del> epp v1.EndpointPort, tolerateUnreadyEndpoints bool) ([]v1.EndpointSubset, int, int) { </del> <ins> epp *v1.EndpointPort, tolerateUnreadyEndpoints bool) ([]v1.EndpointSubset, int, int) { </ins> var readyEps int = 0 var notReadyEps int = 0 <ins> ports := []v1.EndpointPort{} if epp != nil { ports = append(ports, *epp) } </ins> if tolerateUnreadyEndpoints || podutil.IsPodReady(pod) { subsets = append(subsets, v1.EndpointSubset{ Addresses: []v1.EndpointAddress{epa}, <del> Ports:     []v1.EndpointPort{epp}, </del> <ins> Ports:     ports, </ins> }) readyEps++ } else if shouldPodBeInEndpoints(pod) { glog.V(5).Infof("Pod is out of service: %s/%s", pod.Namespace, pod.Name) subsets = append(subsets, v1.EndpointSubset{ NotReadyAddresses: []v1.EndpointAddress{epa}, <del> Ports:             []v1.EndpointPort{epp}, </del> <ins> Ports:             ports, </ins> }) notReadyEps++ }

Discussion:
What happened: When creating a headless service locally with set as , field has to be specified. Otherwise, endpoint controller will not be able to create an endpoint for the headless service successfully. This is because port number of to-be-created endpoint is defaulted to 0 when the field is not specified, which results in an error (0 is a reserved number not available for TCP and UDP usage). This explicitly suggests that the field is optional, which can be confusing to those unfamiliar with kubernetes networking. What you expected to happen: Port number of to-be-created endpoint should be defaulted to any value from 1 to , not 0. Apart from this, the tutorial should not suggest the field as optional until the defaulting is fixed. How to reproduce it (as minimally and precisely as possible): : an to refer, but remember to specify field into controller manager log and search for errors related to endpoint creation for the headless service Environment: Kubernetes version (use ):Cloud provider or hardware configuration: local cluster OS (e.g. from /etc/os-release): /cc
In endpoints controller we have explicit logic allowing headless service not to have ports: Though confirmed creating a headless service with no ports defined hit the exact same error: Will investigate more to see if this is a recent regression on endpoint API validation.
Ref , which reported the same bug.
Thanks for looking at the issue! Tell me if I can be of any help. :)
Sure thing :) I have a fix opened . /assign

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: When deploying a headless service without port definition, there is no DNS endpoint created. What you expected to happen: That there would be a valid DNS entry for the service that has just been created. How to reproduce it (as minimally and precisely as possible): Use the example configuration from , but leave out the following section: Anything else we need to know?: Searching trough the issues, it seems I expect the "unexpected" behavior from ticket , which might been fixed in and PR Environment: Kubernetes version (use ):Cloud provider or hardware configuration:
Reiterating the mentions to trigger a notification: <detailsIn response to : Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
allows a headless service without ports and updates service endpoints for the service. I note that you mentioned DNS endpoint. How did you check the DNS endpoint? Thanks!
If I copy the complete example found in the you can resolve the endpoints as follows: If we recreate the example leaving out the ports, we get the following result: Describing the also does not show any endpoints:
In I'm encountering this problem too. I create a headless service with an empty Ports list Create a statefulset referring to that service Pods created by the stateful set cannot resolve each others stable names. I see the following errors in the cluster logs
Also experiencing something similar though it may not be the exact same thing. I have GlusterFS configured in a 1.8 cluster. The gluster replicas were created via a stateful set and thus has a headless service to go with it. If I try to use the glusterfs volume in a pod, in the same namespace (default) then the pod comes online fine and is able to mount the volume. I tried using the same gluster volume in a pod in a different namespace but it fails to resolve the endpoints. I've tried , and but all result in the same issue saying endpoint cannot be found. I moved the deployment into the default namespace and it started working as expected (using , haven't tested the other names but I expect they now work too).

Hi I believe there's a bug in that is not allowing the endpoints for a headless service with no ports to be created. At and , the endpoints controller is adding a port with to the EndpointSubset that is eventually included in the newEndpoints which gets created/updated. In the API, this EndpointSubset is being validated at , and the port with is failing validation at This results in the server returning a 422, and the endpoints controller dropping the service out of its queue: Logs from API: Logs from endpoint controller: Steps to reproduce (logs above from this example): Hope this helps.
Issues go stale after 90d of inactivity. Mark the issue as fresh with . Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with . Send feedback to sig-testing, kubernetes/test-infra and/or . /lifecycle stale
/remove-lifecycle stale
Open for fixing.
/assign
I had been missing this issue for a long time. Just found it again a couple days ago but haven't found a solution yet. Thanks for the fixing!