Integration testing has to this point relied on patching serving codecs for built-in APIs. The
test-only patching is removed and replaced by feature gated checks at runtime.
This had been left out unintentionally earlier. Because theoretically there
might now be existing objects with parameters that are larger than whatever
limit gets enforced now, the limit only gets checked when parameters get
created or modified.
This is similar to the validation of CEL expressions and for consistency, the
same 10 Ki limit as for those is chosen.
Because the limit is not enforced for stored parameters, it can be increased in
the future, with the caveat that users who need larger parameters then depend
on the newer Kubernetes release with a higher limit. Lowering the limit is
harder because creating deployments that worked in older Kubernetes will not
work anymore with newer Kubernetes.
The media type application/cbor describes exactly one encoded item. As a new (to Kubernetes) format
with no existing clients, streaming/watch responses will use the application/cbor-seq media
type. CBOR watch responses conform to the specification of CBOR Sequences and are encoded as the
concatenation of zero or more items with no additional framing.
The SELinuxWarningController does not necessarily need permissions to read
the objects, because it gets them through a shared informer instantiated by
KCM itself, but let's list the permissions for completeness.
This makes a configuration with --feature-gates=AllAlpha=true valid
again. Without this change, that flag enabled DRAAdminAccess without
DynamicResourceAllocation being enabled (default off!) and the kube-apiserver
refused to start.
While DRAAdminAccess isn't usable without DynamicResourceAllocation, it's also
not really wrong to allow it - it simply won't matter.
Supporting the alpha gRPC interface isn't enough anymore to be compatible
with kubelet 1.31: the "supported versions" must contain version numbers,
otherwise the older kubelet refuses to register the driver.
With this change, a DRA driver can decide to support both kubelet 1.31 and
kubelet 1.32 by registering *only* the alpha gRPC interface (NodeV1alpha4(true)
and NodeV1beta1(false) as options for Start).
The default is to provide both interfaces and using the registration mechanism
for 1.32, which makes DRA drivers compatible only with Kubernetes >= 1.32.
Listing supported gRPC services (e.g. drav1alpha3.Node, drav1beta1.DRAPlugin)
during registration enables the kubelet to determine in advance which methods
it can call.
Versioning by Kubernetes release makes less sense because it doesn't say
anything about which gRPC service is supported. New ones might get added and
obsolete ones removed. Some services might be optional.
In the past, this versioning support wasn't really used. At least one version
had to be provided and kubelet tried to use the plugin with the highest
version. This version comparison gets dropped. In the unlikely situation
that different plugins register under the same name, the most recent one is
used.
Because advertising gRPC services is a new convention, plugins only reporting
some version are treated as providing the old alpha gRPC service.
Using 1.0 was a workaround to grant Kubernetes 1.31 access to things introduce
in that same release. In Kubernetes 1.32 we don't need that workaround anymore
because everything is still available after a downgrade and thus usable.
