This commit defines the ClusterTrustBundlePEM projected volume types.
These types have been renamed from the KEP (PEMTrustAnchors) in order to
leave open the possibility of a similar projection drawing from a
yet-to-exist namespaced-scoped TrustBundle object, which came up during
KEP discussion.
* Add the projection field to internal and v1 APIs.
* Add validation to ensure that usages of the project must specify a
name and path.
* Add TODO covering admission control to forbid mirror pods from using
the projection.
Part of KEP-3257.
Kubernetes-commit: ecfdc8fda55923c18708488ec1561a4fcf9f3e33
KEP-2593 proposed to expand the existing node-ipam controller
to be configurable via a ClusterCIDR objects, however, there
were reasonable doubts on the SIG about the feature and after
several months of dicussions we decided to not move forward
with the KEP intree, hence, we are going to remove the existing
code, that is still in alpha.
https://groups.google.com/g/kubernetes-sig-network/c/nts1xEZ--gQ/m/2aTOUNFFAAAJ
Change-Id: Ieaf2007b0b23c296cde333247bfb672441fe6dfc
Kubernetes-commit: c2d473f0d438cedab2f1831d23457d24961e0f4e
The "set" list type was chosen because it seemed appropriate (no duplicates!)
but that made tracking of managed fields more expensive (each entry in the list
is tracked, not the entire field) and for no good reason (one client is
responsible for the entire list).
Therefore the type gets changed to "atomic". Server-side-apply has not been
used in the past and PodSchedulingContext objects are short-lived and still in
alpha, so the any potential compatibility issues should be minor.
The scheduling throughput in scheduler_perf increases:
name old SchedulingThroughput/Average new SchedulingThroughput/Average
PerfScheduling/SchedulingWithResourceClaimTemplate/2000pods_100nodes-36 18.8 ± 8% 24.0 ±37%
PerfScheduling/SchedulingWithMultipleResourceClaims/2000pods_100nodes-36 13.7 ±81% 18.5 ±40%
Kubernetes-commit: 5567f288e745db05d88fc60e15915f8b0d1f6c4b
Client-side extract calls depend on `managedFields`, which might not be
available. Therefore they should not be used in production code.
They are okay in test files (because the API has to be tested), in the
generated code (because the various type specific APIs still need to be
provided) and in unstructured.go (same reason).
Kubernetes-commit: 4bc9434f99d9a87dd5b63e738b6b1b16693f10e4
This reverts commit 890a6c8f70d2e0f45b3692d34a6df1ecb6d8335b, reversing
changes made to 4f60a8d493ab9571eb328b9d98da477a50bc7446.
Kubernetes-commit: 0d90d1ffa5e87dfc4d3098da7f281351c7ff1972
* Add custom match conditions for CEL admission
This PR is based off of, and dependent on the following PR:
https://github.com/kubernetes/kubernetes/pull/116261
Signed-off-by: Max Smythe <smythe@google.com>
* run `make update`
Signed-off-by: Max Smythe <smythe@google.com>
* Fix unit tests
Signed-off-by: Max Smythe <smythe@google.com>
* Fix unit tests
Signed-off-by: Max Smythe <smythe@google.com>
* Update compatibility test data
Signed-off-by: Max Smythe <smythe@google.com>
* Revert "Update compatibility test data"
This reverts commit 312ba7f9e74e0ec4a7ac1f07bf575479c608af28.
* Allow params during validation; make match conditions optional
Signed-off-by: Max Smythe <smythe@google.com>
* Add conditional ignoring of matcher CEL expression validation on update
Signed-off-by: Max Smythe <smythe@google.com>
* Run codegen
Signed-off-by: Max Smythe <smythe@google.com>
* Add more validation tests
Signed-off-by: Max Smythe <smythe@google.com>
* Short-circuit CEL matcher when no matchers specified
Signed-off-by: Max Smythe <smythe@google.com>
* Run codegen
Signed-off-by: Max Smythe <smythe@google.com>
* Address review comments
Signed-off-by: Max Smythe <smythe@google.com>
---------
Signed-off-by: Max Smythe <smythe@google.com>
Kubernetes-commit: e5fd204c33e90a7e8f5a0ee70242f1296a5ec7af
* api changes adding match conditions
* feature gate and registry strategy to drop fields
* matchConditions logic for admission webhooks
* feedback
* update test
* import order
* bears.com
* update fail policy ignore behavior
* update docs and matcher to hold fail policy as non-pointer
* update matcher error aggregation, fix early fail failpolicy ignore, update docs
* final cleanup
* openapi gen
Kubernetes-commit: 5e5b3029f3bbfc93c3569f07ad300a5c6057fc58
This fixes the following warning (error?) in the apiserver:
E0126 18:10:38.665239 16370 fieldmanager.go:210] "[SHOULD NOT HAPPEN] failed to update managedFields" err="failed to convert new object (test/claim-84; resource.k8s.io/v1alpha1, Kind=ResourceClaim) to smd typed: .status.reservedFor: element 0: associative list without keys has an element that's a map type" VersionKind="/, Kind=" namespace="test" name="claim-84"
The root cause is the same as in e50e8a0c919c0e02dc9a0ffaebb685d5348027b4:
nothing in Kubernetes outright complains about a list of items where the item
type is comparable in Go, but not a simple type. This nonetheless isn't
supposed to be done in the API and can causes problems elsewhere.
For the ReservedFor field, everything seems to work okay except for the
warning. However, it's better to follow conventions and use a map. This is
possible in this case because UID is guaranteed to be a unique key.
Validation is now stricter than before, which is a good thing: previously,
two entries with the same UID were allowed as long as some other field was
different, which wasn't a situation that should have been allowed.
Kubernetes-commit: 508cd60760567b3832da748140e3cf782c1b8695
