CodecFactory construction uses an unexported struct type named "serializerType" to hold serializer
definitions. There are few differences between it and runtime.SerializerInfo, and they do not appear
to be used anymore. For example, serializerType includes an unused FileExtensions field, and has
distinct ContentType (singular) and AcceptContentTypes (plural) fields instead of
runtime.SerializeInfo's singular MediaType. All remaining uses of serializerType set
AcceptContentTypes to a single-entry slice whose element is equal to its ContentType field.
During construction of a CodecFactory, all serializerType values were already being mechanically
translated into runtime.SerializerInfo values.
Moving to an exported type for serializer definitions makes it easier to expose an option to allow
callers to register their own serializer definitions, which in turn makes it possible to
conditionally include new serializers at runtime (especially behind feature gates).
Add metrics about the sizing of the cpu pools.
Currently the cpumanager maintains 2 cpu pools:
- shared pool: this is where all pods with non-exclusive
cpu allocation run
- exclusive pool: this is the union of the set of exclusive
cpus allocated to containers, if any (requires static policy in use).
By reporting the size of the pools, the users (humans or machines)
can get better insights and more feedback about how the resources
actually allocated to the workload and how the node resources are used.
As pointed out during code review, the CEL cost estimates are not considered
perfectly reliable. Therefore it is better to also do runtime checks.
Some downstream users might decide to allow CEL expressions to run
longer. Therefore the cost limit is now part of an Options struct.
kube-scheduler uses the default cost limit defined in the resource.k8s.io API,
which is the same cost limit that also the apiserver uses during validation.
Expression evaluation in all scenarios gets benchmarked where compilation
works. A pending optimization in another PR caches compiled expressions, so the
time for compilation will become less important. What matters is the actual
evaluation.
In DRA, the cost check is done only at validation time. At runtime, any
expression that passed validation gets executed without interrupting it. The
advantage is that it becomes easier to change the limit because stored
expression do not suddenly fail after an up- or downgrade. The limit could
even become a configuration parameter of the apiserver because that is the only
place where the limit gets checked
The main purpose is to protect against denial-of-service attacks. Scheduling
time depends a lot on unpredictable factors and expected scheduling time also
varies, so no attempt is made to limit the overall time spent on evaluating CEL
expressions per claim.
When PodAndContainerStatsFromCRI FG is enabled, Kubelet tries to get
list of metrics from the CRI runtime using CRI API 'ListMetricDescriptors'.
As this API is not implemented in neither CRI-O nor Containerd versions
used in the test-infra, ResourceMetrics test case fails to gather
certain container metrics.
Excluding container metrics from the expected list of metrics if
PodAndContainerStatsFromCRI is enabled should solve the issue.
