Automatic merge from submit-queue (batch tested with PRs 38377, 36365, 36648, 37691, 38339)
Do not create selector and namespaces in a loop where possible
With 1000 nodes and 5000 pods (5 pods per node) with anti-affinity a lot of CPU wasted on creating LabelSelector and sets.String (map).
With this change we are able to deploy that number of pods in ~25 minutes. Without - it takes 30 minutes to deploy 500 pods with anti-affinity configured.
Automatic merge from submit-queue (batch tested with PRs 35101, 38215, 38092)
auth duplicate detect
I think we should not allow people set duplicate tokens in token file or set duplicate usernames in password file. because the default action overwriting the old data may let people misunderstand.
Automatic merge from submit-queue
add default label to rbac bootstrap policy
allow people to retrieve information of bootstrap policy by label :
`kubectl get clusterroles -l key=value`
`kubectl get clusterrolebindings -l key=value`
Automatic merge from submit-queue (batch tested with PRs 38076, 38137, 36882, 37634, 37558)
[scheduler] Use V(10) for anything which may be O(N*P) logging
Fixes#37014
This PR makes sure that logging statements which are capable of being called on a perNode / perPod basis (i.e. non essential ones that will just clog up logs at large scale) are at V(10) level.
I dreamt of a levenstein filter that built a weak map of word frequencies and alerted once log throughput increased w/o varying information content.... but then I woke up and realized this is probably all we really need for now :)
Automatic merge from submit-queue (batch tested with PRs 38111, 38121)
remove rbac super user
Cleaning up cruft and duplicated capabilities as we transition from RBAC alpha to beta. In 1.5, we added a secured loopback connection based on the `system:masters` group name. `system:masters` have full power in the API, so the RBAC super user is superfluous.
The flag will stay in place so that the process can still launch, but it will be disconnected.
@kubernetes/sig-auth
Automatic merge from submit-queue (batch tested with PRs 36816, 37534)
Move pkg/api/unversioned to pkg/apis/meta/v1
This moves code from using pkg/api/unversioned to pkg/apis/meta/v1 with the `metav1` local package name.
Built on top of #37532 (the first three commits related to ExportOptions)
Part of #37530
Automatic merge from submit-queue
plumb in front proxy group header
Builds on https://github.com/kubernetes/kubernetes/pull/36662 and https://github.com/kubernetes/kubernetes/pull/36774, so only the last commit is unique.
This completes the plumbing for front proxy header information and makes it possible to add just the front proxy header authenticator.
WIP because I'm going to assess it in use downstream.
Automatic merge from submit-queue (batch tested with PRs 35300, 36709, 37643, 37813, 37697)
add rbac action to subjects type
This adds the ability to go from an authorization action to the list subjects who have the power to perform the action. This will be used to either back an RBAC specific endpoint or generic authorization endpoint. Because of the way authorization works today, the set of subjects returned will always be a subset of those with access since any authorizer can say yes.
@kubernetes/sig-auth
Automatic merge from submit-queue (batch tested with PRs 37945, 37498, 37391, 37209, 37169)
add controller roles
Upstream controller roles that have downstream.
@sttts this is a start at roles for controllers. I've made names match for now, but they could use some love in both the controller manager and here. I'd recommend using this as a starting point.
Automatic merge from submit-queue (batch tested with PRs 36263, 36755, 37357, 37222, 37524)
Add flag to enable contention profiling in scheduler.
```release-note
Add flag to enable contention profiling in scheduler.
```
Automatic merge from submit-queue
auth delegation role
Add a bootstrap role for authentication and authorization delegation. Useful for extension API servers.
@kubernetes/sig-auth
Automatic merge from submit-queue
Revert "Avoid hard-coding list of Node Conditions"
* we don't know how other API consumers are using node conditions (there was no prior expectation that the scheduler would block on custom conditions)
* not all conditions map directly to schedulability (e.g. `MemoryPressure`/`DiskPressure`)
* not all conditions use True to mean "unschedulable" (e.g. `Ready`)
This reverts commit 511b2ecaa8 to avoid breaking existing API users and to avoid constraining future uses of the node conditions API
