Automatic merge from submit-queue
Deny service ClusterIP update from `None`
**What this PR does / why we need it**: Headless service should not be transformed into a service with ClusterIP, therefore update of this field if it's set to `None` is disallowed.
**Which issue this PR fixes** *(optional, in `fixes #<issue number>(, #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes#33029
**Release note**:
```release-note
Changing service ClusterIP from `None` is not allowed anymore.
```
Automatic merge from submit-queue
Remove last probe time from replica sets
While experimenting with Deployment conditions I found out that if we are going to use lastProbeTime as we are supposed to be using it then we hotloop between updates (see https://github.com/kubernetes/kubernetes/pull/19343#issuecomment-255096778 for more info)
cc: @smarterclayton @soltysh
Automatic merge from submit-queue
Optimize label selector
The number of values for a given label is generally pretty small (in huge majority of cases it is exactly one value).
Currently computing selectors is up to 50% of CPU usage in both apiserver and scheduler.
Changing the structure in which those values are stored from map to slice improves the performance of typical usecase for computing selectors.
Early results:
- scheduler throughput it ~15% higher
- apiserver cpu-usage is also lower (seems to be also ~10-15%)
Automatic merge from submit-queue
Loadbalanced client src ip preservation enters beta
Sounds like we're going to try out the proposal (https://github.com/kubernetes/kubernetes/issues/30819#issuecomment-249877334) for annotations -> fields on just one feature in 1.5 (scheduler). Or do we want to just convert to fields right now?
Automatic merge from submit-queue
requests.storage is a standard resource name
The value `requests.storage` is a valid standard resource name but was omitted from the standard list.
Automatic merge from submit-queue
Add validation that detects repeated keys in the labels and annotations maps
Fixes#2965 (a nearly 2 year old feature request!)
@kubernetes/kubectl
@eparis
Automatic merge from submit-queue
Adding default StorageClass annotation printout for resource_printer and describer and some refactoring
adding ISDEFAULT for _kubectl get storageclass_ output
```
[root@screeley-sc1 gce]# kubectl get storageclass
NAME TYPE ISDEFAULT
another-class kubernetes.io/gce-pd NO
generic1-slow kubernetes.io/gce-pd YES
generic2-fast kubernetes.io/gce-pd YES
```
```release-note
Add ISDEFAULT to kubectl get storageClass output
```
@kubernetes/sig-storage
Automatic merge from submit-queue
Split conversion and defaulting
Separate conversion and defaulting. Defaulting occurs mixed with conversion today - change the server so that the `VersioningCodec` performs defaulting on the external type during decoding.
* Add a new method to `Scheme` - `func (*runtime.Scheme) Default(runtime.Object)` - that takes an object and performs defaulting.
* Call `Default` during decoding and at static initialization time
* Use the new `defaulter-gen` to generate top level object defaulters (`v1.Pod`) at build time for any type that needs to perform defaulting.
* Add tests and alter the existing code to adapt as necessary
* Fix a few bugs in conversions that depended on defaulting behavior
---
Step 1 of decoupling conversion and defaulting. The generator will assist in creating top level defaulters that in a single method invoke all nested defaulters, preventing the need to recurse via reflection or conversion. These top level defaulters will be registered in the scheme and invoked instead of the nested recursion path. This will set the stage for a future generator, capable of creating defaulters from embedded struct tags on external types. However, we must gradually switch these over.
The immediate goal here is to split defaulting and conversion so that the unsafe convertor can be used to maximum potential (we would be able to use direct memory conversion for any identical nested struct, even those that must be defaulted).
The generator uses `k8s:defaulter-gen=TypeMeta` on most public packages to flag any top level type that has defaulters to get a `SetObjectDefaults_NAME` function created (types that don't have defaulters won't have functions). This also creates a `RegisterDefaults` method that applies a default to an interface{} and returns true if the object was handled. Existing defaults are left as is.
Add a test to verify old and new path generate the same outcomes. Defaulter will move to gengo before this is merged, and subsequent PRs will remove defaulting during conversion and have the VersioningCodec apply defaults.
Most normal codec use should perform defaulting. DirectCodecs should not
perform defaulting. Update the defaulting_test to fuzz the list of known
defaulters. Use the new versioning.NewDefaultingCodec() method.
Automatic merge from submit-queue
Add PSP support for seccomp profiles
Seccomp support for PSP. There are still a couple of TODOs that need to be fixed but this is passing tests.
One thing of note, since seccomp is all being stored in annotations right now it breaks some of the assumptions we've stated for the provider in terms of mutating the passed in pod. I've put big warning comments around the pieces that do that to make sure it's clear and covered the rollback in admission if the policy fails to validate.
@sttts @pmorie @erictune @smarterclayton @liggitt
Automatic merge from submit-queue
Add unit test for bad ReclaimPolicy and valid ReclaimPolicy in /pkg/api/validation
unit tests for validation.go regarding PersistentVolumeReclaimPolicy (bad value and good value)
see PR: #30304
Automatic merge from submit-queue
Add PVC storage to LimitRange
This PR adds the ability to add a LimitRange to a namespace that enforces min/max on `pvc.Spec.Resources.Requests["storage"]`.
@derekwaynecarr @abhgupta @kubernetes/sig-storage
Examples forthcoming.
```release-note
pvc.Spec.Resources.Requests min and max can be enforced with a LimitRange of type "PersistentVolumeClaim" in the namespace
```
Automatic merge from submit-queue
Match GroupVersionKind against specific version
Currently when multiple GVK match a specific kind in `KindForGroupVersionKinds` only the first will be matched, which not necessarily will be the correct one. I'm proposing to extend this to pick the best match, instead.
Here's my problematic use-case, of course it involves ScheduledJobs 😉:
I have a `GroupVersions` with `batch/v1` and `batch/v2alpha1` in that order. I'm calling `KindForGroupVersionKinds` with kind `batch/v2alpha1 ScheduledJob` and that currently results this matching first `GroupVersion`, instead of picking more concrete one. There's a [clear description](ee77d4e6ca/pkg/api/unversioned/group_version.go (L183)) why it is on single `GroupVersion`, but `GroupVersions` should pick this more carefully.
@deads2k this is your baby, wdyt?
Mike Danese