Add an e2e test verifying that pods requesting extended resources
can still be admitted and processed by DRA after the corresponding
device plugin is uninstalled. The test deploys a sample device plugin,
waits for its extended resource to appear on a node, uninstalls the
plugin, and then creates a pod requesting that resource. It confirms
that the pod starts successfully and that the DRA driver processes the
resource as expected.
Updated allocateContainerResources to skip resources referring
extended resource claims as they are managed by DRA drivers.
These resources shouldn't be processed by device plugins.
Previously, the scheduler assumed an extended resource was maintained
by a device plugin if its name was present in the node's Allocatable
map, even if its value was zero. This blocked scheduling when a device
plugin was disconnected or uninstalled, because Kubelet still reported
the resource with Allocatable=0.
This change adds a check for the actual allocatable value in addition
to a key presence check, allowing nodes with uninstalled device
plugins to be considered for scheduling.
add cpumanager to contextual logging linter
regenerate with
```hack/update-golangci-lint-config.sh```
Signed-off-by: Francesco Romani <fromani@redhat.com>
migrate the cpumanager code to contextual logging
design musings:
- golang contexts "[...] carries deadlines, cancellation signals, and
other request-scoped values across API boundaries and between
processes." (see: https://pkg.go.dev/context#pkg-overview).
Thus, it generally makes sense to add contexts to most of the APIs
and functions as the resource management is done in the admission flow, when
ultimately we process a request and we have time bounds;
- however, receiving a context from the outside and depending on it
kind also conflicts with the goal of having uniform logging and "
- attach key/value pairs that get included in all log messages
- add names that describe which component or operation triggered a log messages"
(see:
https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging#summary)
Some of this conflict is due to the transitional nature of the PRs
which we do when updating the codelet codebase. We can envision a
final state on which the top level caller adds identifying information
like pod UID and pod namespace/name pair; but up until all the calling
chain is updated and wired, the results are gonna be inconsistent.
- continuing from the point above, the most realistic transition plan
for the kubelet is outlined in
https://github.com/kubernetes/kubernetes/issues/130069 .
Since we do want to move in parallel and migrate on a
subsystem-by-subsystem basis, each subsystem will be in charge to add
the data they want to their contexts. I think this is the only
reasonnable way forward, and the cost will be overhead and redundancy.
We should do sweeping changes to uniform the flows once we completed
the full transition to ensure uniformity.
- there are some well known packages which want to operate by design
only in in-memory data structure, which arguably can't block.
Shoehorning a context feels not great. Instead, we intentionally pass
only the logger, which still is the core idea of contextual logging
(see:
https://github.com/kubernetes/kubernetes/pull/125912#discussion_r1935919144)
examples are the topology subpackage and the cpu_assignment logic
(takeByTopology and friends)
Signed-off-by: Francesco Romani <fromani@redhat.com>
kube-controller-manager and kube-scheduler do not use the
configured loopback clients. Drop them.
Fix up scheduler test server to not depend on
the loopback client.
- Updated base image from python:3.6-slim-stretch to python:3.11-slim-bookworm
- Bumped version from 1.3 to 1.4
- Updated TensorFlow from 1.9.0 to 2.20.0 (latest stable)
- Updated TensorFlow models from v1.9.0 to v2.15.0
Signed-off-by: Humble Devassy Chirammal <humble.devassy@gmail.com>
