Automatic merge from submit-queue (batch tested with PRs 40543, 39999)
Improve code coverage for scheduler/algorithm/priorities
**What this PR does / why we need it**:
Improve code coverage for scheduler/algorithm/priorities from #39559
This is my first unit test for kubernetes , thanks for your review.
**Special notes for your reviewer**:
**Release note**:
```release-note
```
Automatic merge from submit-queue (batch tested with PRs 39538, 40188, 40357, 38214, 40195)
Decoupling scheduler creation from creation of scheduler.Config struc…
**What this PR does / why we need it**:
Adds functionality to the scheduler to initialize from an Configurator interface, rather then via a Config struct.
**Which issue this PR fixes**
Reduces coupling to `scheduler.Config` data structure format so that we can proliferate more interface driven composition of scheduler components.
Automatic merge from submit-queue
Add serviceaccount owners files
Poor @derekwaynecarr is the sole approver/reviewer for the entire admission package.
This adds OWNERS files for service account controller and admission packages
When a pod uses a service account that references multiple secrets,
prefer the secrets in the order they're listed.
Without this change, the added test fails:
--- FAIL: TestMultipleReferencedSecrets (0.00s)
admission_test.go:832: expected first referenced secret to be mounted, got "token2"
Automatic merge from submit-queue
move client/cache and client/discovery to client-go
mechanical changes to move those packages. Had to create a `k8s.io/kubernetes/pkg/client/tests` package for tests that were blacklisted from client-go. We can rewrite these tests later and move them, but for now they'll still run at least.
@caesarxuchao @sttts
Automatic merge from submit-queue
Skip schedule deleting pod
Since binding a deleting pod will always return fail, we should skip that kind of pod early
These files have been created lately, so we don't have much information
about them anyway, so let's just:
- Remove assignees and make them approvers
- Copy approves as reviewers
Automatic merge from submit-queue (batch tested with PRs 36693, 40154, 40170, 39033)
make client-go authoritative for pkg/client/restclient
Moves client/restclient to client-go and a util/certs, util/testing as transitives.
Automatic merge from submit-queue (batch tested with PRs 36693, 40154, 40170, 39033)
Minor hygiene in scheduler.
**What this PR does / why we need it**:
Minor cleanups in scheduler, related to PR #31652.
- Unified lazy opaque resource caching.
- Deleted a commented-out line of code.
**Release note**:
```release-note
N/A
```
Automatic merge from submit-queue
move pkg/fields to apimachinery
Purely mechanical move of `pkg/fields` to apimachinery.
Discussed with @lavalamp on slack. Moving this an `labels` to apimachinery.
@liggitt any concerns? I think the idea of field selection should become generic and this ends up shared between client and server, so this is a more logical location.
Automatic merge from submit-queue
make client-go more authoritative
Builds on https://github.com/kubernetes/kubernetes/pull/40103
This moves a few more support package to client-go for origination.
1. restclient/watch - nodep
1. util/flowcontrol - used interface
1. util/integer, util/clock - used in controllers and in support of util/flowcontrol
Automatic merge from submit-queue (batch tested with PRs 39898, 39904)
[scheduler] interface for config
**What this PR fixes**
This PR converts the Scheduler configuration factory into an interface, so that
- the scheduler_perf and scheduler integration tests dont rely on the struct for their implementation
- the exported functionality of the factory (i.e. what it needs to provide to create a scheduler configuration) is completely explicit, rather then completely coupled to a struct.
- makes some parts of the factory immutable, again to minimize possible coupling.
This makes it easier to make a custom factory in instances where we might specifically want to import scheduler logic without actually reusing the entire scheduler codebase.
Automatic merge from submit-queue (batch tested with PRs 36467, 36528, 39568, 40094, 39042)
Improve code coverage for algorithm/predicates.
Improve code coverage for algorithm/predicates for #39559 .
Improved coverage from 71.3% to 81.9%.
Coverage report: [combined-coverage.html.gz](https://github.com/kubernetes/kubernetes/files/691518/combined-coverage.html.gz)
Automatic merge from submit-queue (batch tested with PRs 39625, 39842)
Add RBAC v1beta1
Add `rbac.authorization.k8s.io/v1beta1`. This scrubs `v1alpha1` to remove cruft, then add `v1beta1`. We'll update other bits of infrastructure to code to `v1beta1` as a separate step.
```release-note
The `attributeRestrictions` field has been removed from the PolicyRule type in the rbac.authorization.k8s.io/v1alpha1 API. The field was not used by the RBAC authorizer.
```
@kubernetes/sig-auth-misc @liggitt @erictune
Automatic merge from submit-queue
Include "ingresses" resource in RBAC bootstrap roles
The bootstrap RBAC roles "admin", "edit", and "view" should all be able to apply their respective access verbs to the "ingresses" resource in order to facilitate both publishing Ingress resources (for
service administrators) and consuming them (for ingress controllers).
Note that I alphabetized the resources listed in the role definitions that I changed to make it easier to decide later where to insert new entries. The original order looked like it may have started out alphabetized, but lost its way. If I missed an intended order there, please advise.
I am uncertain whether this change deserves mention in a release note, given the RBAC feature's alpha state. Regardless, it's possible that a cluster administrator could have been happy with the previous set of permissions afforded by these roles, and would be surprised to discover that bound subjects can now control _Ingress_ resources. However, in order to be afflicted, that administrator would have had to have applied these role definitions again which, if I understand it, would be a deliberate act, as bootstrapping should only occur once in a given cluster.
