Change:
[]string{"runtime_handler"}, ) <del> // RunningPodCount is a gauge that tracks the number of Pods currently running </del> <ins> // RunningPodCount is a gauge that tracks the number of Pods currently with a running sandbox // It is used to expose the kubelet internal state: how many pods have running containers in the container runtime, and mainly for debugging purpose. </ins> RunningPodCount = metrics.NewGauge( &metrics.GaugeOpts{ Subsystem:      KubeletSubsystem, Name:           RunningPodsKey, <del> Help:           "Number of pods currently running", </del> <ins> Help:           "Number of pods that have a running pod sandbox", </ins> StabilityLevel: metrics.ALPHA, }, )

Discussion:
<!-- Please use this template while reporting a bug and provide as much info as possible. Not doing so may result in your bug not being addressed in a timely manner. Thanks! If the matter is security related, please disclose it privately via --kubelet metric should only count pods in state. But it incorrectly reports the sum of pods in + state. Only pods in state should be counted. Create a pod with sample yaml to create a pod that stays in state. Verify that pod we created is in state, Now let's count the total number of pods using Out of 15, 1 is in and rest are in state. But the corresponding metric from Prometheus dashboard returns 15. Kubernetes version (use ): Cloud provider or hardware configuration: OS (e.g: ): Kernel (e.g. ): Install tools: Network plugin and version (if this is a network-related bug): Others:
/sig node
Does it mean that pod after initial will be take into account for running pod metrics ? According the code, it counts sandboxes. Once Pod pause container is started, and it will be counted.
/triage accepted
As some comments in , the have a different meanings between and .
Yeah. But then that means metric ends up misleading the user. Would it be possible to use API Pod instead of runtime pod?
I may follow the rules in to make it consistent with
Please feel free to tag me for review once you submit the PR.
I am wondering if we should just update the documentation for stating explicitly that the results may not always match with the due to differences between them in what they consider as a pod. What do you think?
Agree. Generally, metrics should be simple to calculate. The current logic makes sense from the runtime side. Proposal 1: update the doc for . Proposal 2: rename it to something like or an accuracy name. Proposal 3: make it the same meaning as (which need some further calculation)
I think I will go with Proposal 1. The ideal thing would be Proposal 3, but I am afraid we might be underestimating the effort required. What do you think?
IIRC, is not intended to reflect the pod phase in the API server. It is used to expose the kubelet internal state: how many pods have running containers in the container runtime, and mainly for debugging purpose.

To make it more clear: to A pod is in phase when kubelet tries to create init container after pause container started.
Thanks Closing this because we have more clarity on what that metric is supposed to mean.
/reopen
Reopened this issue. <detailsIn response to : /reopen Instructions for interacting with me using PR comments are available . If you have questions or suggestions related to my behavior, please file an issue against the repository. </details
Sorry closed it before noticing Reopened this bug.