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.
For historic reasons kubeadm kept track of a skew of 2+
etcd version in a map in the constants.go file.
This is really not required because kubeadm supports only
2 version of etcd mapped to two Kubernetes versions,
which are essentially the control plane versions.
Refactor the constants.go map to only include 2 versions.
Make sure that's reflected in a unit test.
Instead of pinning the versions as literal numbers,
start using the version we get on build time.
Adapt various unit tests and functions to allow this change
to work, since during unit tests we need actual values
and the build versions are not populated. This is achieved
by requiring the functions to accept a map[uint8]string
used for testing.
By using k8s.io/system-validators v1.12.1 a KubeletVersion
can be passed to the CgroupsValidator. The library
can then decide if to throw an error or a warning.
An error is thrown if the version is >= 1.35.
During upgrade pass a KubeletVersion that is with MINOR+1
to account for the target upgrade version. That is just
an assumption that the user will upgrade the kubelet too,
but it is better to throw an error for this
common use case instead of just a warning that is seen
after the upgrade command has finished.
Reflect the correct cgroupDriver setting in the configz enpoint in case
the cgroup driver setting is received from the CRI. Moves the
initialization of the configz handler to a slightly later phase where
the CRI has been queried.
When retrieving the cluster-info CM, ensure the cluster pointed
out by the current context in the kubeconfig is validated.
Add unit test for the above.
Make the function GetClusterFromKubeConfig() to return various
errors. Handle the errors on call sites. Add unit tests
for the update.
The above changes prevent panics when the users has manually
edited and malformed the kubeconfig in the cluster-info CM.
