Automatic merge from submit-queue
add some checks for fedration-apiserver options
**What this PR does / why we need it**:
I find there is a TODO, see https://github.com/kubernetes/kubernetes/blob/master/federation/cmd/federation-apiserver/app/options/validation.go#L30
This PR add some checks for fedration-apiserver options
@sttts
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes #
**Special notes for your reviewer**:
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 50016, 49583, 49930, 46254, 50337)
[Federation] Make the hpa scale time window configurable
This PR is on top of open pr https://github.com/kubernetes/kubernetes/pull/45993.
Please review only the last commit in this PR.
This adds a config param to controller manager, the value of which gets passed to hpa adapter via sync controller.
This is needed to reduce the overall time limit of the hpa scaling window to much lesser (then the default 2 mins) to get e2e tests run faster. Please see the comment on the newly added parameter.
**Special notes for your reviewer**:
@kubernetes/sig-federation-pr-reviews
@quinton-hoole
@marun to please validate the mechanism used to pass a parameter from cmd line to adapter.
**Release note**:
```
federation-controller-manager gets a new flag --hpa-scale-forbidden-window.
This flag is used to configure the duration used by federation hpa controller to determine if it can move max and/or min replicas
around (or not), of a cluster local hpa object, by comparing current time with the last scaled time of that cluster local hpa.
Lower value will result in faster response to scalibility conditions achieved by cluster local hpas on local replicas, but too low
a value can result in thrashing. Higher values will result in slower response to scalibility conditions on local replicas.
```
Automatic merge from submit-queue (batch tested with PRs 43443, 46193, 49071, 47252)
[Federation][Kubefed] Support reference document autogeneration for kubefed
This PR is needed to address the documentation issue https://github.com/kubernetes/kubernetes.github.io/issues/2888
Apart from the code auto generation have updated some descriptions for consistency.
**Special notes for your reviewer**:
@kubernetes/sig-federation-misc
cc @madhusudancs @csbell
**Release note**:
```NONE
```
Automatic merge from submit-queue (batch tested with PRs 48012, 47443, 47702, 47178)
incluster config will be used when creating external shared informers.
**What this PR does / why we need it**:
Previously the loopback configuration was used to talk to the server.
As a consequence a custom API server was unable to talk to the root API server.
This PR changes the above by using incluster configuration to create shared informers.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 46235, 44786, 46833, 46756, 46669)
federation: Add admission controller for policy-based placement
@nikhiljindal
Here's the initial version of the scheduling policy admission controller. It's at the point where it would benefit from having another pair of eyes look at it. The main thing I'm unsure of is the serialization of Kube resources for the webhook/query call.
Release Note:
```
The federation-apiserver now supports a SchedulingPolicy admission controller that enables policy-based control over placement of federated resources.
```
Ref #39982
Handle failure cases on startup gracefully to avoid causing cascading
errors and poor initialization in other components. Initial errors from
config load cause the initializer to pause and hold requests. Return
typed errors to better communicate failures to clients.
Add code to handle two specific cases - admin wants to bypass
initialization defaulting, and mirror pods (which want to bypass
initialization because the kubelet owns their lifecycle).
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.
Automatic merge from submit-queue (batch tested with PRs 46552, 46608, 46390, 46605, 46459)
Move admission lifecycle to genericapi
**What this PR does / why we need it**: ends the whole sequence of moving some admission plugins to generic api.
**Release note**:
```release-note
NONE
```
lifecycle plugin: make use of the libraries under k8s.io/client-go/pkg/api and k8s.io/client-go/kubernetes
for the client libraries instead of k8s.io/kubernetes/client/*
move registration to AdmissionOptions
Automatic merge from submit-queue (batch tested with PRs 42256, 46479, 45436, 46440, 46417)
move CRD behind TPR
Second attempt at https://github.com/kubernetes/kubernetes/pull/46297
@liggitt since @sttts is out can you take a look and hopefully find me a different, more sane way to do this? It's a little crazy, but I left a large comment explaining why I think its the only way.
Automatic merge from submit-queue
remove init blocks from all admission plugins
**What this PR does / why we need it**:
removes init blocks from all admission plugins
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
[Federation][kubefed]: Move server image definition to cmd
This enables consumers like openshift to provide a different default without editing the kubefed init logic.
cc: @kubernetes/sig-federation-pr-reviews
Automatic merge from submit-queue (batch tested with PRs 45247, 45810, 45034, 45898, 45899)
[Federation] Segregate DNS related code to separate controller
**What this PR does / why we need it**:
This is the continuation of service controller re-factor work as outlined in #41253
This PR segregates DNS related code from service controller to another controller `service-dns controller` which manages the DNS records on the configured DNS provider.
`service-dns controller` monitors the federated services for the ingress annotations and create/update/delete DNS records accordingly.
`service-dns controller` can be optionally disabled and DNS record management could be done by third party components by monitoring the ingress annotations on federated services. (This would enable something like federation middleware for CoreDNS where federation api server could be used as a backend to CoreDNS eliminating the need for etcd storage.)
**Special notes for your reviewer**:
**Release note**:
```
Federation: A new controller for managing DNS records is introduced which can be optionally disabled to enable third party components to manage DNS records for federated services.
```
cc @kubernetes/sig-federation-pr-reviews
xilabao