Automatic merge from submit-queue (batch tested with PRs 47619, 47951, 46260, 48277)
[Federation] Convert the deployment controller to a sync controller.
This is based off of the work done for the ReplicaSet controller. It extracts out a schedulingAdapter that handles the shared logic between the two controllers.
Targets #40989
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue (batch tested with PRs 45610, 47628)
Add Priority to Kubernetes API
**What this PR does / why we need it**: This is the first in a series of PRs to add priority to Kubernetes API. Subsequent PRs will add priority name resolution to admission controller.
**Release note**:
```release-note
Add PriorityClassName and Priority fields to PodSpec.
```
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
[Federation]Remove duplicate constants
Clean up them, the constants are defined in replicaset_test.go and replicasetcontroller_test.go, and replicaset_test.go did not use them.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Add a spin-loop that waits for RBAC API's availability.
The very first thing that kubefed does when it comes up is run RBAC API discovery. We believe this sometimes fail on new clusters and as a result causes kubefed to assume that the RBAC API doesn't exist. Therefore, we are applying this workaround for now to ensure that the RBAC API is available before running kubefed.
Issue: #47737
**Release note**:
```release-note
NONE
```
/assign @csbell
/cc @dchen1107
/sig federation
The very first thing that kubefed does when it comes up is run RBAC API
discovery. We believe this sometimes fail on new clusters and as
a result causes kubefed to assume that the RBAC API doesn't exist.
Therefore, we are applying this workaround for now to ensure that the
RBAC API is available before running kubefed.
Automatic merge from submit-queue (batch tested with PRs 47851, 47824, 47858, 46099)
Revert "[Federation] Fix federated service reconcilation issue due to addition of External…"
Reverts kubernetes/kubernetes#45798
Reverting the temporary fix as the problem is fixed in #45869.
with that fix federation also can default ExternalTrafficLocalOnly if not set.
Issue: #45812
cc @MrHohn @madhusudancs @kubernetes/sig-federation-bugs
If there are 2 or more PR(s) in the queue, they will end up with
conflicts (and rechecks). So let us remove the timestamp entirely
when we generate the files.
Fixes#46814
Automatic merge from submit-queue
Fix api description
**What this PR does / why we need it**:
prefered -> preferred
the the -> the
**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 47451, 47410, 47598, 47616, 47473)
Revert "Ignore `daemonset-controller-hash` label key in federation before comparing the federated object with its cluster equivalent."
This reverts commit 3530c9ce87.
~This needs to wait for #47258, otherwise federation test won't pass~ (merged)
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Add NodeInternalIP as a fallback to federation api-server nodeport service
Previously NodeLegacyHostIP was used as a fallback (see #41243) but in 1.7 it was removed (#44830)
Now clusters where nodes have not set ExternalIP can not be used by kubefed to setup federation.
cc @shashidharatd
```release-note
kubefed will now configure NodeInternalIP as the federation API server endpoint when NodeExternalIP is unavailable for federation API servers exposed as NodePort services
```
Automatic merge from submit-queue
Made image as required in v1 Container struct.
**What this PR does / why we need it**:
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#47244
**Special notes for your reviewer**:
**Release note**:
```release-note
none
```
Automatic merge from submit-queue (batch tested with PRs 43005, 46660, 46385, 46991, 47103)
Ignore `daemonset-controller-hash` label key in federation before comparing the federated object with its cluster equivalent.
Kubernetes daemonset controller writes a daemonset's hash to the object label as an optimization to avoid recomputing it every time. Adding a new label to the object that the federation is unaware of causes problems because federated controllers compare the objects in federation and their equivalents in clusters and try to reconcile them. This leads to a constant fight between the federated daemonset
controller and the cluster controllers, and they never reach a stable state.
Ideally, cluster components should not update an object's spec or metadata in a way federation cannot replicate. They can update an object's status though. Therefore, this daemonset hash should be a
field in daemonset's status, not a label in object meta. @janetkuo says that this label is only a short term solution. In the near future, they are going to replace it with revision numbers in daemonset status. We
can then rip this bandaid out.
Fixes#46925
**Release note**:
```release-note
NONE
```
/assign @csbell
/cc @shashidharatd @marun @nikhiljindal @perotinus
/sig federation
Kubernetes daemonset controller writes a daemonset's hash to the object
label as an optimization to avoid recomputing it every time. Adding a
new label to the object that the federation is unaware of causes
problems because federated controllers compare the objects in
federation and their equivalents in clusters and try to reconcile them.
This leads to a constant fight between the federated daemonset
controller and the cluster controllers, and they never reach a stable
state.
Ideally, cluster components should not update an object's spec or
metadata in a way federation cannot replicate. They can update an
object's status though. Therefore, this daemonset hash should be a
field in daemonset's status, not a label in object meta. @janetkuo says
that this label is only a short term solution. In the near future, they
are going to replace it with revision numbers in daemonset status. We
can then rip this bandaid out.
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).
Automatic merge from submit-queue (batch tested with PRs 45871, 46498, 46729, 46144, 46804)
Fix some comments in dnsprovider
**What this PR does / why we need it**:
**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
```
This is part of the namespace deletion big hammer. `kubefed join` not
just creates federation-system namespace, but also cluster role and
cluster role bindings in the joining clusters. Sometimes unjoin fails
to delete them. So we use a big hammer here to delete them.
This smells like a real problem in kubefed and needs investigation.
This is a short term fix to unblock the submit queue.
Kubernetes Submit Queue