Wire up peer proxy infrastructure in kube-apiserver:
- Add UnknownVersionInteroperabilityProxy feature gate
- Configure peer proxy with identity lease selectors
- Register CRD and APIService informers with exclusion filters
- Start peer discovery sync and GV cleanup workers
Includes extractors for CRDs and APIServices to identify which
GroupVersions should be excluded from peer discovery.
Part of KEP-4020: Unknown Version Interoperability Proxy
This commit migrates the container manager package to use
contextual logging.
This follows the contextual logging migration pattern where:
- Logger is passed from the boundary down to implementations
- klog.TODO() is used at call sites where context is not yet available
- Functions with context.Context extract logger via klog.FromContext(ctx)
- klog.InfoS/ErrorS/V().InfoS calls are replaced with logger.Info/Error/V().Info
- Sub-managers receive proper logger context from their callers
Some call sites still use klog.TODO() as placeholders, with TODO
comments indicating these will be replaced with proper contextual loggers
as the migration continues upward through the call stack.
Test/fake implementations use klog.Background() which is the appropriate
choice for test code where no real context is available.
Mock file updates (pkg/kubelet/cm/testing/mocks.go) were done manually
due to mockery tool incompatibility with Go 1.25 and will be committed
separately with an explanation.
Key changes:
1. PodContainerManager and ContainerManager interface updates:
- PodContainerManager.EnsureExists: add logger parameter
- PodContainerManager.Destroy: add logger parameter
- PodContainerManager.ReduceCPULimits: add logger parameter
- PodContainerManager.SetPodCgroupConfig: add logger parameter
- ContainerManager.UpdateQOSCgroups: add logger parameter
- Update all implementations (Linux, Windows, stub, noop, fake)
2. Helper function updates:
- GetKubeletContainer: add logger parameter (Linux and unsupported platforms)
- Update cmd/kubelet/app/server.go to pass logger to GetKubeletContainer
- Comment out type assertion in helpers.go due to signature change
3. Cgroup manager contextual logging:
- CgroupManager interface methods updated to accept logger:
* Destroy: add logger parameter
* ReduceCPULimits: add logger parameter
* SetCgroupConfig: add logger parameter
- Update cgroupCommon and unsupportedCgroupManager implementations
- Migrate klog.InfoS/V().InfoS calls to logger.Info/V().Info
4. Container manager implementation updates:
- Extract logger from context in NewContainerManager() and Start()
- Pass logger to sub-managers (deviceManager, topologyManager)
- Update DRA manager initialization to use logger from context
- Migrate klog.InfoS/ErrorS to logger.Info/Error throughout
5. Call sites updated with TODO comments:
- pkg/kubelet/kubelet.go: UpdateQOSCgroups, EnsureExists
- pkg/kubelet/kubelet_pods.go: UpdateQOSCgroups, ReduceCPULimits, Destroy
- pkg/kubelet/kuberuntime/kuberuntime_manager.go: SetPodCgroupConfig
- pkg/kubelet/kuberuntime/kuberuntime_manager_test.go: test expectations
Most call sites currently use klog.TODO() as placeholders, with TODO
comments indicating these will be replaced with proper contextual loggers
as the migration continues upward through the call stack.
Test/fake implementations use klog.Background() which is the appropriate
choice for test code where no real context is available.
Mock file updates (pkg/kubelet/cm/testing/mocks.go) were done manually
due to mockery tool incompatibility with Go 1.25 and will be committed
separately with an explanation.
Signed-off-by: Swati Sehgal <swsehgal@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>
