Last updated: Jan 2026. Status: proposed by SIG Node.
Next steps:
- Otel community agreement
- detailed plans
The motivation for this document is a set of new requests for cAdvisor standalone mode. These requests is a reminder that we need to define a cAdvisor roadmap in light of a current developments in K8s project and a modern landscape of tools and projects.
CAdvisor consists of two parts that are interleaved and interconnected:
- a library linked into kubelet used to provide information about resource usage that K8s project depends on.
- standalone binary for users to monitor containerized workloads. This includes, but not limited to kubernetes. Outside of kubernetes it is docker containers, Mesos, etc. and provide support for dedicated hardware such as Intel PMU perf metrics.
The project was originated when the industry looked very differently and not well aligned with modern landscape of tools and projects.
Also, since cAdvisor is a Google project, rather than a kubernetes project, results in a few issues:
- Google outsized ownership and responsibility for this project with limited OSS governance model.
- K8s contributors that currently maintains it has little vested interest in owning the standalone mode scenarios.
- Every release of kubernetes requires cAdvisor to be vendored into k8s tree, which can cause significant “dependency hell” and limits what standalone mode cAdvisor can do.
There is ongoing work to deprecate the cAdvisor as a vendored library for k8s. The work consist of multiple stages. First stage is tracked as part of this enhancement: cAdvisor-less, CRI-full Container and Pod Stats. There will be more work needed after the KEP above is merged to transition machine-wide metrics to containerd.
Once the transition of metrics to container runtime complete, the cAdvisor project will not be in scope of k8s contributors and will be more aligned with the OpenTelemetry project.
Also unless SIG instrumentation will take it as their scope, we will deprecate the cAdvisor endpoint and not accept requests like this: Configurable cAdvisor Metrics Collection as those are also more aligned with the telemetry scenarios rather than orchestration.
- finish transition of Pod merics to K8s: cAdvisor-less, CRI-full Container and Pod Stats
- start transition of machine-level metrics to Container Runtime (KEP: TBD).
- Decide on the future of
cadvisorendpoint - likely deprecation of thecadvisorendpoint of kubelet
- Stop vendoring cAdvisor to K8s.
- Remove the
cadvisorendpoint of kubelet
The proposal is to move cAdvisor standalone scenarios to Otel collector. New receivers will collect similar information to what cAdvisor collects today and Otel collector can be configured to export as Prometheus endpoint or any other supported exporter. So there will be a transition path from cAdvisor standalone to Otel collector.
The same time cAdvisor project will be placed in maintenance mode and eventually closed.
If there will be interest from any project or 3rd party to pick up the project and transfer it to CNCF or other project - there will be an open discussion on this.
This is not a detailed spec on transition to Otel Collector. The intent of this section is to highlight the tension points that needs to be clarified as the transition specs are written.
cAdvisor is a specialized software for containers metrics collection. It is easier to configure and likely more lightweight. Otel collector will need to be compiled with the right set of receivers and exporters and configured appropriately.
The benefit of using Otel Collector for these scenarios is its flexibility in collecting telemetry for more scenarios and a well-known config as oppose to a custom cAdvisor configuration.
The believe of this roadmap is that benefits of cAdvisor's distribution model will not be significant enough to prefer it over the Otel collector.
The proposal is to transition all metrics to Otel collector to make sure a smooth transition for time-proof set of metrics. However the detailed plan is needed to make a final decision.
The design may split metrics into multiple receivers if this will be more convenient.
Beyond prometheus metrics, cAdvisor supports a few more endpoint. The list is here: https://github.com/google/cadvisor/blob/master/docs/api.md
Prometheus endpoints may expose metrics in a format different as Otel collector prefer dots in names to underscores. Also other renames may potentially be needed as metric names will be aligned with Otel Semantic Convention.
Otel collector will expose the single prometheus endpoint with all metrics for all containers and will not support container-specific endpoints.
The proposal is to collect events as Otel events.
There is no analogous of events endpoint in Otel collector. So transition to Otel events will require to change design of consumers from pull model to push model for events.
Not supported. No alternatives offered.
Not supported. No alternatives offered.
Not supported. No alternatives offered.
Not supported, use Node Feature Discovery.
The proposal is to transition container-based metrics collection to Otel collector so all advanced metrics and non-Kubernetes environments monitoring is supported by Otel collector. This way Otel collector will support the same set of environments and runtimes as cAdvisor does today. This may be done by copying code from cAdvisor.
However, as a more lightweight implementation, Otel collector may also implement receivers that are based on CRI-exposed metrics based on KEP cAdvisor-less, CRI-full Container and Pod Stats. These receivers will be less flexible and limited to Kubernetes scenarios. However these receivers will be more reliable.
The proposal is to design for the full set of scenarios, but not limiting to it and allow for CRI-based metrics receivers.
cAdvisor does NOT support Windows containers monitoring while Otel collector does. There is a potential for Otel collector to implement this scenario, but it will be outside of a scope of this roadmap document.