Change:
<ins> --- title: CRI Pod & Container Metrics content_type: reference weight: 50 description: >- Collection of Pod & Container metrics via the CRI. --- <!-- overview --> {{< feature-state for_k8s_version="v1.23" state="alpha" >}} The [kubelet](/docs/reference/command-line-tools-reference/kubelet/) collects pod and container metrics via [cAdvisor](https://github.com/google/cadvisor). As an alpha feature, Kubernetes lets you configure the collection of pod and container metrics via the {{< glossary_tooltip term_id="cri" text="Container Runtime Interface">}} (CRI). You must enable the `PodAndContainerStatsFromCRI` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) and use a compatible CRI implementation (containerd >= 1.6.0, CRI-O >= 1.23.0) to use the CRI based collection mechanism. <!-- body --> ## CRI Pod & Container Metrics With `PodAndContainerStatsFromCRI` enabled, the kubelet polls the underlying container runtime for pod and container stats instead of inspecting the host system directly using cAdvisor. The benefits of relying on the container runtime for this information as opposed to direct collection with cAdvisor include: - Potential improved performance if the container runtime already collects this information during normal operations. In this case, the data can be re-used instead of being aggregated again by the kubelet. - It further decouples the kubelet and the container runtime allowing collection of metrics for container runtimes that don't run processes directly on the host with kubelet where they are observable by cAdvisor (for example: container runtimes that use virtualization). </ins>  No newline at end of file

Discussion:
This is a Bug Report <!-- Thanks for filing an issue! Before submitting, please fill in the following information. --<!-- See for guidance on writing an actionable issue description. --<!--Required Information--Problem: The feature gate amends node behavior around cAdvisor, but is not properly documented. Proposed Solution: Update to ~include~ hyperlink to a new page about the changes from For example, add a new page into Ideally, write those docs to be finished before the feature moves the beta, so that the only change needed for graduation there is to mark the feature as being stable. <!--Optional Information (remove the comment tags around information you would like to include)--<!--Kubernetes Version:--Additional Information: /sig node /language en
Aim to title and frame the new reference page as describing the situation after the enhancement is complete. For example, the title could be “Metrics About Containers And Pods” rather than “Migration from cAdvisor”.
/triage accepted /priority important-soon
Not sure this will make 1.25, but good to track early.
/cc
/assign yeah I agree this is good criteria for beta. This kep having missed an alpha update in 1.25, it's not clear to me which release it will arrive in
We can document this at any time. We should push back on graduation to stable if there's not been any movement on documenting the changes. It's definitely better to have good docs ready to accompany actual graduation to beta, and it's nice to have at least some docs as soon as a feature goes alpha.
Relevant to
PR helps with this.
This issue is related to this
PR helps with this too.
This issue is labeled with but has not been updated in over 90 days, and should be re-triaged. Important-soon issues must be staffed and worked on either currently, or very soon, ideally in time for the next release. You can: Confirm that this issue is still relevant with (org members only) Deprioritize it with or Close this issue with For more details on the triage process, see /remove-triage accepted
/triage accepted We should do this. The more releases this slips, the more we're letting down end users.
/retitle Document feature gate / implications