Previously, ValidateNodeSelector did not check that labels are valid. Now it
does for resource.k8s.io, regardless whether an object already was created with
invalid labels in an earlier Kubernetes release. Theoretically this is a
breaking change and could cause problems during an upgrade, but that is highly
unlikely in practice.
In contrast to node affinity, DRA does not ignore parse errors
(= uses NewNodeSelector, not NewLazyErrorNodeSelector), so invalid labels would
have been found instead of being silently ignored.
Even if some object has invalid labels, this only affects an alpha -> beta
upgrade which isn't guaranteed to work seamlessly.
1. The effective container requests cannot be greater than pod-level requests
2. Inidividual container limits cannot be greater than pod-level limits
3. Only CPU & Memory are supported at pod-level
4. Inplace container resources updates are not supported if pod-level resources are set
Note: effective container requests cannot be greater than pod-level limits is supported by transitivity. Effective container requests <= pod-level requests && pod-level requests <= pod-level limits; Therefore effective container requests <= pod-level limits
Signed-off-by: ndixita <ndixita@google.com>
Added tests, info about new feature gate in error message, fixes from review
Added basic e2e test
Added unit tests
Ran hack/update-featuregates.sh
Tolerate updates to existing resources after disabling feature gate
Added feature gate to versioned_kube_features.go
Fixed existing tests
Use PodValidationOptions for validation instead of using feature gate directly
Relaxed validation for allowing zero in prestop hook sleep action
Without this patch the error message for this example:
```
---
apiVersion: v1
kind: Pod
metadata:
name: test
spec:
containers:
- name: agent
image: debian:latest
tolerations:
- key: pool
operator: Exists
value: build
effect: NoSchedule
```
Looks like:
```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
core.Toleration{Key:"pool", Operator:"Exists", Value:"build",
Effect:"NoSchedule", TolerationSeconds:(*int64)(nil)}: value must be
empty when `operator` is 'Exists'
```
To clarify that the `Value` field is wrong, we now directly point the
`field.Invalid` to it. Now the error message becomes a more clear and
concise one:
```
The Pod "test" is invalid: spec.tolerations[0].operator: Invalid value:
"build": value must be empty when `operator` is 'Exists'
```
Signed-off-by: Sascha Grunert <sgrunert@redhat.com>
* KEP-4427 : AllowRelaxedDNSSearchValidation
* Add e2e test with feature gate to test KEP-4427 RelaxedDNSSearchValidation
* Add more validatePodDNSConfig test cases
Also update Regex to match the case we want.
Thanks Tim and Antonio!
