As cited in
https://github.com/kubernetes/dns/issues/174 - this is documented to
work, and I don't see why it shouldn't work. We allowed the definition
of headless services without ports, but apparently nobody tested it very
well.
Manually tested clusterIP services with no ports - validation error.
Manually tested services with negative ports - validation error.
New tests failed, output inspected and verified. Now pass.
Automatic merge from submit-queue. If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>.
Fix a bug that headless service without ports fails to have endpoint created.
**What this PR does / why we need it**:
Follow up of https://github.com/kubernetes/kubernetes/pull/47250. Headless service without ports fails to have corresponding endpoint created because endpoint controller deliberately attaches a dummy endpointPort with portNum=0, which will fail API validation check. Error as below:
```
endpoints_controller.go:375] Error syncing endpoints for service "default/XXX": Endpoints "XXX" is invalid: subsets[0].ports[0].port: Invalid value: 0: must be between 1 and 65535, inclusive
```
This PR makes endpoint controller not attach the dummy endpointPort for headless service.
**Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*:
Fixes#55158, fixes#62440
**Special notes for your reviewer**:
cc @xiangpengzhao
**Release note**:
```release-note
Fix a bug that headless service without ports fails to have endpoint created.
```
A pod status change of unready -> ready results in a move from
the endpoint's unready endpoint addresses to its ready addresses
so if a pod update contains an unready -> ready status change,
the endpoint needs to be updated.
This substantially reduces the number of API calls made by the endpoint
controller. Currently the controller makes an API call per endpoint for
each service that is synced. When the 30s resync is triggered, this
results in an API call for every single endpoint in the cluster. This
quickly exceeds the default qps/burst limit of 20/30 even in small
clusters, leading to delays in endpoint updates.
This change modifies the controller to use the endpoint informer cache
for all endpoint GETs. This means we only make API calls for changes in
endpoints. As a result, qps only depends on the pod activity in the
cluster, rather than the number of services.
Combine the fields that will be used for content transformation
(content-type, codec, and group version) into a single struct in client,
and then pass that struct into the rest client and request. Set the
content-type when sending requests to the server, and accept the content
type as primary.
Will form the foundation for content-negotiation via the client.
