Automatic merge from submit-queue (batch tested with PRs 49409, 49352, 49266, 48418)
Use helper to init ClusterIP and NodePort in Create of service
**What this PR does / why we need it**:
Make service `Create` more readable and testable.
- use `initClusterIP` introduced in #46197 to init ClusterIP allocation in service `Create`
- add a new helper `initNodePort` to init NodePort allocation in service `Create`
- TBD: add test case for `initNodePort`. This will cover the NodePort allocation process in `Create`. If this PR makes sense, I will write a test case later.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#35354 (not directly. #35354 was fixed by #46197. The idea of this PR is from https://github.com/kubernetes/kubernetes/pull/46197#discussion_r120910077)
**Special notes for your reviewer**:
/cc @thockin @freehan
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 49055, 49128, 49132, 49134, 49110)
add svc and netpol to discovery
Fixes https://github.com/kubernetes/kubernetes/issues/48962
one shortname was missing entirely, the other was on a storage not actually used as storage.
@ncdc
Add support for creating resources that are not immediately visible to
naive clients, but must first be initialized by one or more privileged
cluster agents. These controllers can mark the object as initialized,
allowing others to see them.
Permission to override initialization defaults or modify an initializing
object is limited per resource to a virtual subresource "RESOURCE/initialize"
via RBAC.
Initialization is currently alpha.
The result of this was that an update to a Service would release the
NodePort temporarily (the repair loop would fix it in a minute). During
that window, another Service could get allocated that Port.
Automatic merge from submit-queue (batch tested with PRs 40111, 40368, 40342, 40274, 39443)
Eliminate "Unknown service type: ExternalName"
When creating an ExternalName service, rest.go still generate the warning message "Unknown service type: ExternalName". This should be eliminated as this type of service is supported now.
