Automatic merge from submit-queue (batch tested with PRs 38592, 39949, 39946, 39882)
move api/errors to apimachinery
`pkg/api/errors` is a set of helpers around `meta/v1.Status` that help to create and interpret various apiserver errors. Things like `.NewNotFound` and `IsNotFound` pairings. This pull moves it into apimachinery for use by the clients and servers.
@smarterclayton @lavalamp First commit is the move plus minor fitting. Second commit is straight replace and generation.
Automatic merge from submit-queue (batch tested with PRs 39947, 39936, 39902, 39859, 39915)
Make api serialization test easier to follow
**What this PR does / why we need it**:
This PR makes the serialization test easier to understand and is informed by the recent experience of writing a new serialization test in SIG service catalog.
**Release note**:
```release-note
NONE
```
Automatic merge from submit-queue
Don't blame DNS spec on Kubernetes requirement for lower-case DNS labels.
**What this PR does / why we need it**: #39635 was rejected because it wasn't clear to the author (me) that lower-case DNS labels are in fact a [Kubernetes requirement](https://github.com/kubernetes/kubernetes/pull/39635#issuecomment-271404975) rather than from the [DNS RFC 1035](https://www.ietf.org/rfc/rfc1035.txt) or/and [DNS RFC 1123](https://www.ietf.org/rfc/rfc1123.txt).
**Special notes for your reviewer**: @thockin this is a first pass to make the error messages clearer about the fact that DNS specs are not to _blame_.
Automatic merge from submit-queue
replace global registry in apimachinery with global registry in k8s.io/kubernetes
We'd like to remove all globals, but our immediate problem is that a shared registry between k8s.io/kubernetes and k8s.io/client-go doesn't work. Since client-go makes a copy, we can actually keep a global registry with other globals in pkg/api for now.
@kubernetes/sig-api-machinery-misc @lavalamp @smarterclayton @sttts
Automatic merge from submit-queue (batch tested with PRs 39803, 39698, 39537, 39478)
[scheduling] Moved pod affinity and anti-affinity from annotations to api fields #25319
Converted pod affinity and anti-affinity from annotations to api fields
Related: #25319
Related: #34508
**Release note**:
```Pod affinity and anti-affinity has moved from annotations to api fields in the pod spec. Pod affinity or anti-affinity that is defined in the annotations will be ignored.```
Automatic merge from submit-queue (batch tested with PRs 39803, 39698, 39537, 39478)
default a CSR's allowed usage to key encipherment and digital signing
Some pretty safe and sane defaults.
@liggitt
Automatic merge from submit-queue (batch tested with PRs 37845, 39439, 39514, 39457, 38866)
Move watch/versioned to pkg/apis/meta/v1/watch.go
Watch is a part of the server API
Automatic merge from submit-queue (batch tested with PRs 39394, 38270, 39473, 39516, 36243)
Improve an error message when privileged containers are disallowed on the cluster
**What this PR does / why we need it**:
At present when user creates privileged pod and creation of privileged containers disallowed globally by a system administrator (kubelet and api-server were running with `--allow-privileged=false`), user will get the following error message:
```console
$ kubectl create -f nginx.pod
The Pod "nginx" is invalid: spec.containers[0].securityContext.privileged: Forbidden: disallowed by policy
```
"Disallowed by policy" may give a wrong assumption to a user that creation of privileged containers disallowed by [`PodSecurityPolicy`](http://kubernetes.io/docs/user-guide/pod-security-policy/) while it's not.
This commit improves error message and tries to point user to the right direction:
```console
$ kubectl create -f nginx.pod
The Pod "nginx" is invalid: spec.containers[0].securityContext.privileged: Forbidden: privileged containers are disallowed on this cluster by a system administrator
```
**Release note**:
```release-note
NONE
```
PTAL @pweil-
Automatic merge from submit-queue (batch tested with PRs 39466, 39490, 39527)
bump gengo to latest
bumping gengo to limit surprises while working on https://github.com/kubernetes/kubernetes/pull/39475
@kubernetes/sig-api-machinery-misc
Automatic merge from submit-queue (batch tested with PRs 38433, 36245)
Allow pods to define multiple environment variables from a whole ConfigMap
Allow environment variables to be populated from ConfigMaps
- ConfigMaps represent an entire set of EnvVars
- EnvVars can override ConfigMaps
fixes#26299
Automatic merge from submit-queue (batch tested with PRs 39284, 39367)
Remove HostRecord annotation (beta feature)
The annotation has made it to GA so this code should be deleted.
**Release note**:
```release-note
The 'endpoints.beta.kubernetes.io/hostnames-map' annotation is no longer supported. Users can use the 'Endpoints.subsets[].addresses[].hostname' field instead.
```
Automatic merge from submit-queue (batch tested with PRs 39152, 39142, 39055)
Add test for json tags on internal and external types
Follow up from https://github.com/kubernetes/kubernetes/pull/38406
- adds static analysis tests preventing internal types from adding new json or protobuf tags
- adds static analysis tests requiring json tags on external types (and enforcing lower-case first letter)
- fixes issues found by the tests
Automatic merge from submit-queue
kubeadm: Default to using token discovery.
Recent changes to support multiple methods for discovery meant that
"kubeadm init" no longer was sufficient and users would need to add
"--discovery token://" to achieve the same results.
Instead lets assume discovery if the user does not specify anything else
to maintain parity and the brevity of our original instructions.
**Release note**:
```release-note
NONE
```
CC @mikedanese @luxas
Automatic merge from submit-queue (batch tested with PRs 38920, 38090)
Improve error message for name/label validation.
Instead of just providing regex in name/label validation error output, we need to add the naming rules of the name/label, which is more end-user readable.
Fixed#37654
Recent changes to support multiple methods for discovery meant that
"kubeadm init" no longer was sufficient and users would need to add
"--discovery token://" to achieve the same results.
Instead lets assume discovery if the user does not specify anything else
to maintain parity and the brevity of our original instructions.
Automatic merge from submit-queue
Implement kubeadm bootstrap token management
Creates bootstrap tokens as secrets per the specification in #30707
_WARNING_: These are not currently hooked up to the discovery service or the token it creates.
Still TODO:
- [x] delete tokens
- [x] merge with #35144 and adopt it's testing approach
- [x] determine if we want wholesale json output & templating like kubectl (we do not have an API object with the data we want here) may require a bit of plumbing.
- [x] allow specifying a token duration on the CLI
- [x] allow configuring the default token duration
- [x] hook up the initial token created during init
Sample output:
```
(root@centos1 ~) $ kubeadm token create
Running pre-flight checks
<cmd/token> Token secret created: f6dc69.c43e491752c4a0fd
(root@centos1 ~) $ kubeadm token create
Running pre-flight checks
<cmd/token> Token secret created: 8fad2f.e7b78c8a5f7c7b9a
(root@centos1 ~) $ kubeadm token list
Running pre-flight checks
ID TOKEN EXPIRATION
44d805 44d805.a4e78b6cf6435e33 23h
4f65bb 4f65bb.d006a3c7a0e428c9 23h
6a086e 6a086e.2ff99f0823236b5b 23h
8fad2f 8fad2f.e7b78c8a5f7c7b9a 23h
f6dc69 f6dc69.c43e491752c4a0fd 23h
f81653 f81653.9ab82a2926c7e985 23h
```
Adds kubeadm subcommands to create, list, and delete bootstrap tokens.
Tokens can be created with a TTL duration, or 0 for tokens that will not
expire. The create command can also be used to specify your own token
(for use when bootstrapping masters and nodes in parallel), or update an
existing token's secret or ttl.
Marked "ex" for experimental for now as the boostrap controllers are not
yet hooked up in core.
Automatic merge from submit-queue (batch tested with PRs 38724, 38699)
improve the forbidden message
Improves the forbidden message to include more details about what was denied.
`User "foo" cannot list replicasets.extensions in the namespace "default". `
`User "foo" cannot list replicasets.extensions at the cluster scope. `
@xilabao looks like you looking in a similar area, but focused on errors.
@sttts a lot of usual reviewers are out.
Automatic merge from submit-queue (batch tested with PRs 38720, 38533)
Priority REST Mapper: Actually honor user choice
```release-note
Fixes bug in resolving client-requested API versions
```
RESTMapping takes a desired GroupKind, and a set of versions, and
returns a rest mapper for the first matching version. It also has a
list of built-in discovered prioritized versions, to which it appends
the user versions.
However, when it goes to parse the versions, it parses them as
GroupVersions. Since only a version was passed, the group will be the
empty group (""), which will only match rest mappings for the empty
group, ergo, none of the user's versions will match if they are
attempting a match for a non-emtpy-group GroupKind.
This fixes that by taking the parsed GroupVersion, and overriding the
Group with the Group from the passed-in GroupKind.
Automatic merge from submit-queue (batch tested with PRs 38171, 37968)
add QoS pod status field
Right now, applications retrieving pod information must reimplement the QoS classification logic on the client side if they wish to know the QoS class of the pod.
The PR adds the QoS class to the pod status so it can be used directly by clients.
This is a step toward addressing #33255
@ConnorDoyle @derekwaynecarr @vishh
RESTMapping takes a desired GroupKind, and a set of versions, and
returns a rest mapper for the first matching version. It also has a
list of built-in discovered prioritized versions, to which it appends
the user versions.
However, when it goes to parse the versions, it parses them as
GroupVersions. Since only a version was passed, the group will be the
empty group (""), which will only match rest mappings for the empty
group, ergo, none of the user's versions will match if they are
attempting a match for a non-emtpy-group GroupKind.
This fixes that by taking the parsed GroupVersion, and overriding the
Group with the Group from the passed-in GroupKind.
